According to the Project Management Institute, 47% of unsuccessful projects fail to meet goals due to poor requirement management. In his post for the Project Risk Coach, Harry Hall explains what project requirements are, why they matter, and offers four ways to develop them.
Merriam-Webster Dictionary says a requirement is something that is needed or must be done. The Project Management Body of Knowledge meanwhile defines a requirement as “a condition or capability that is required to be present in a product, service, or result to satisfy a contract or other formally imposed specification.” That being said, requirements can further be broken down into different types:
- Business requirements – describe why the project is being undertaken
- User requirements – describes what the users will be able to do (e.g., invoice customer, pay claim)
- System requirements[:] Functional requirements – describe product capabilities (e.g., the system shall notify the operator when the job is completed) [&] Non-Functional requirements– properties the product must have (e.g., response time, hours of availability)
Why is it important to set requirements? With no requirements, there is no clarity or guidelines. What is desired to get done will not get done and could result in doing things over, which means more time, materials, and money that no one wants to waste. So how can we develop requirements then?
- Elicit the requirements: No one is going to just hand you over the requirements. Sit down with the sponsor/stakeholders/users to draw out and validate the requirements.
- Analyze the requirements: Break things down and examine in detail. Build a prototype, create diagrams. Nothing too complicated. Give the user a change to see what they do and do not like.
- Document the requirements: Documenting allows us to think and analyze. As well, some type of documentation is useful for reference as features and extended for future projects functioning.
- Validate the requirements: This is important to safeguard the project requirements to be free of defects/bugs, and to meet the needs of the users.
You can access the original post here: http://projectriskcoach.com/2016/11/07/the-what-why-and-how-of-project-requirements/