Delta acknowledges that requirements definition is the most crucial part of a project. Incorrect, inaccurate, or excessive definition of requirements must necessarily result in schedule delays, wasted resources, and, ultimately, 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 of defining 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 through and take into consideration the views and needs of all of the project stakeholders.
It is easy to leave scope out of a requirement 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 requirement review.
To summarize the basic points:
- Know the Difference Between Wants and Needs
- Examine the business need or opportunity
- Write a clear statement of project objectives
- 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
- Retain Delta Analysts help you with your business or organizational requirements
|
|