Managing non-functional requirements

Submissions for some of the key agile-related industry conferences are presently under review. I've noticed that this year there are a number of submissions on the subject of how to manage non-functional requirements on agile software development projects. All offer different recommendations, but they have one thing in common: Each proposal is described as if it were The Answer to The Problem with non-functional requirements on agile projects. Is there really a single problem — The Problem? And if there is really a single answer — The Answer — then why so many different recommendations?

The truth is there isn't a one-size-fits-all answer. All the approaches have merit, and all have potential risks for a project. In keeping with the principle of people over process, it's up to you to understand the implications and make a reasoned choice. Each recommendation will work, provided it is applied in an appropriate context and provided the team takes the potential downside risk into account.

full version