Time and time again I come across the question and related issues of how does Agile deal with NFR's ( or Non Functional Requirements ). Those requirements which are often impossible to capture as stories. I have seen some teams ( and even tried my self early on ) to write stories such as As a <> I want all data stored in an Oracle Database, or As a business owner, I want the system to support 10,000 current users. While these capture the intent, because they cannot be assigned to a single iteration they can easily become forgotten about, or just overlooked in the white heat of iterative development.
I've become increasingly in favour of the use of architecture governance where by there is a specific role defined within the team who owns NFRs, and is responsible to ensure that they are adhered to within each story. The best solution I've found is that the Architect responsible for NFRs have an responsibility to ensure that each story is reviewed at some point with a view of the NFRs and the specific requirements are then capture as Acceptance tests on the story. Any story with data can state a critieria demanding Oracle, any story with UI can refer to usability tests
Issues with this approach
1) Large agile teams may require more than one named architecture resource
2) Small agile teams may have this as a part time basis
3) Inexperienced architects may apply all NFRs to all Stories to "cover their backs"
