Recommended Requirements Gathering Practices

A " requirement " is a necessary attribute in a system, a statement that identifies a capability, characteristic, or quality factor of a system in order for it to have value and utility to a user [1]. According to Steve McConnell in Software Project Survival Guide, " The most difficult part of requirements gathering is not documenting what the users 'want'; it is the effort of helping users figure out what they 'need' that can be successfully provided within the cost and schedule parameters available to the development team. " 1 Each requirement should be necessary, verifiable, attainable, unambiguous, complete , consistent, traceable, concise, implementation free , and have a unique identifier [1]. All of these characteristics of a good requirement should be self-evident, with the possible exception of " implementation-free. " The reason that a requirement should be implementation-free is that requirements specify " what " shall be provided and not " how " – the how is a design aspect rather than a requirement. Documenting the rationale for each requirement (why it is required) is a good technique to reduce the number of requirements. Taking this one step, according to industry requirements consultant Ivy Hooks' experience, can eliminate " up to half " of the stated requirements [2]. Begin by understanding the organiza-tion's " business requirements. " This leads to a " vision and scope " document that describes the background leading to the decision to develop a new or modified system or capability and describes the system to be developed. An agreed upon understanding of the capability is critical to a successful project. Consider having iterative scoping meetings with customers and users. The process of requirements elicitation itself generates more detailed and creative thinking about the problem that in turn can affect the scope. As the possibilities for a solution emerge, there are numerous decision points concerning what should and should not be included within the scope of the system. The next step is to gather the stated requirements of the customers and users of the new capability. An effective requirements practice distinguishes " stated " requirements from " real " requirements [1]. Industry experience has shown that customers and system developers should jointly evaluate stated requirements to ensure that each is a verified need. Part of the requirements process is to prioritize requirements. 2 This is important, because rarely is there enough time and money to …