Requirements definition is the most crucial part of the project. Incorrect, inaccurate, or excessive definition of requirements must necessarily result in schedule delays, wasted resources, or customer dissatisfaction.
The requirements analysis should begin with business or organizational requirements and translate those into project requirements. If meeting stated requirements will be unreasonably costly, or take too long, the project requirements may have to be negotiated down, down-scoped or down-sized, in discussions with customers or sponsors.
Any discussion of requirements analysis methods will quickly become specific to the type of project effort. Many industry areas have specific, proven techniques for obtaining thorough and accurate definition of requirements. Sometimes it is useful to write a draft users manual as a way to define requirements. While the methods may differ, the principles remain the same across all types and sizes of projects. The requirements analysis should cover the whole scope of the project. It must be comprehensive and thorough. It must consider the views and needs of all the project stakeholders.
It is easy to leave scope out of a requirements analysis or to omit necessary clarity or detail thereby making the requirements definition ambiguous. The completed requirements analysis should be reviewed and approved by the customer or project sponsor before work continues. On large projects, the first formal design review is actually a requirements review.
To summarize the basic points:
Examine the Business Need or Opportunity
Write a Clear Statement of Project Objectives
Know the Difference Between Wants and Needs
Negotiate the Requirements Definition Interactively with the Customer
Conduct a Thorough and Comprehensive Analysis
- Document the Results Unambiguously in Sufficient Detail
- Put the Requirements Document under Version Control