Pretty much the same is with performance-related non-functional requirements. Let’s say our goal is 20k requests per hour (whatever a request is – it doesn’t matter). At the moment application at the peak gets about 7,5k requests. If we put our milestones at 10k, 12,5k, 15k, 17,5k and finally at 20k for each consecutive sprint we risk that our current architecture will die in the middle of the march and whole work was useless. I would rather spend some effort in one of early sprints (possibly the very first) or at the beginning of a project to do extensive load testing and learn how far current performance can be pushed. If results weren’t satisfactory I would start working on major changes enabling performance improvement from the beginning (hopefully the second iteration) instead of somewhere in the middle of process.

Non-functional requirements are always tricky to deal with, no matter if your project is done agile-way or you’re waterfall zealot (are there any of them still?) because they’re hard to pack into frames we use for functional requirements.

AOP works by intercepting interobject messaging doing some processing, and then sending the message to the original target object. It’s a system of sideband consumption.

You can use it as a means of extending your testing budget. To do this, you could code the core, and never change it. Instead, when you need it to change, you would build the change as an aspect. Since you didn’t change the core code, you don’t have to do regression on it. You might still do that until you are convinced, but most of the testing would be focused on the new code.

In terms of non-functional requirements (NFR), you would write your core at some level of “how well”. Then, when you wanted to increase your “how well” by some factor, you would write an aspect to do that. It wouldn’t effect the full scope of the non-functional requirement. It would effect only some small portion. You could then write another aspect for the next small portion. There is no need to break the whole thing, or to have the whole thing comply with a single metric NFR.

There might even be a business case for tiered compliance with the NFR. Sure, it’s nice if everything is operating on the same NFR levels, but it’s more important that the premium functionality meets it, or maybe the base functionality depending on your pricing scheme, and segmentation.

It might sound like a nightmare, but your NFRs would be encapsulated in an AOP approach where they are spread throughout your code today.

And you’re right that you can spike or iterate on the stringency of the nonfunctional requirements. It’s very much like basing iterations on constraint-based use case versions.