Within my role, and due to my keen interest in requirements management, I am often asked for advice on what constitutes a non-functional requirement and what these typically contain or define. It seems to me that the art of defining requirements has, in some cases, been lost and people all too easily blur the lines between the problem space and the solution space leading to unnecessarily constrained solutions to problems.
When eliciting the requirements it is imperative that all the stakeholders are identified and not just those who are immediately apparent; additionally those involved in the process maintain a clear separation between the requirements and design aspects.
The following is a good introductory post by a gentleman called Peter Eeles to what he terms ‘Architectural Requirements’ but which to my mind covers functional and non-functional requirements; I believe his classification is due to these being requirements which have a significant bearing on the architecture.
http://www.ibm.com/developerworks/rational/library/4706.html
Whilst these are often ignored early on in the project due to the focus on what are commonly referred to as ‘business requirements’, you do this at your peril as in my experience these can significantly affect the costs of delivering the solution and thus the viability of the overall project.
