I consider Roxanne Miller's book The Quest for Software Requirements the definitive book on the topic. I strongly recommend you check it out. In addition to process, it includes a library of 2,000 sample questions you can use in preparation for NFR elicitation. Should be required reading for all BA's
Hi Pichaty,
I would suggest that you stick with the same methodology that you use for Functional requirements - just note them as non-functional. In the 'good old days' of BRDs and the like, there would be a different section for Non-Functional requirements, but it was still in the same document. This should be carried forward for todays world where you may not be using a BRD (i.e. Agile). Keep to the same methodology otherwise the people who have to read your Non-functional requirements and carry them out may not understand what it is you are asking for.
Sticking to the same methodology should remove this danger. A requirement us still a requirement - whether it is a functional or non-functional one. So why change methodology?
In an ideal world, a functional requirement should be linked to a non-functional one, and vice-versa. So splitting them out would probably make yours and other peoples lives, working on your project harder.
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: