These are requirements that are not about specific functionality (”As a user of a word processor, I want to insert a table into my document.”), but are rather about an attribute or characteristic of the system... “If it’s non-functional, why do I care about it?”... Each constraint we put on a system narrows the design choices a bit; calling these “constraints” rather than “non-functional requirements” helps us remember this... Trying to put a constraint into this template is a good exercise as it helps make sure you understand who wants what and why.This post resonates with me because I firmly believe that any feature in your application must fulfill the needs of its users not its engineers. Doing so will encourage simplicity in your application development that way you avoid useless stories like, As an architect, I want for the system to be integrated using an ESB (so that my resume looks good and I can frustrate the developers who are forced to use it).
Saturday, November 22, 2008
Non Functional Requirements as stories
Mike Cohn has this to say: