Requirements are conditions or tasks that need to be addressed and completed in order for the project to be accepted as complete. They originate from the project’s stakeholders and can be expressed as physical deliverables or business benefits, as aspirations or solutions, and as functional or technical needs. As an example, if you are building a website, a requirement could be that it should be integrated with an e-commerce solution.
There are 4 kinds of requirements that must be addressed on order to gain a complete overall vision of the project.
Business Requirements: These are the high-level business needs that need to be resolved by the project. They are usually general needs, such as “Grow Sales” or “Increase Brand Awareness.”
Stakeholder Requirements: These refer to the needs of those most impacted by the project and are usually a more detailed version of the Business Requirements. For example, from the general needs stated above, you would describe more specific ways you will grow the sales numbers or increase the brand awareness.
Solution Requirements: These requirements address specifics, such as quantifiable numbers to judge success. For example, sales numbers will increase X% with the proposed initiative.
Transition Requirements: These requirements relate to needs that are only present during the transition, and can be phased out once the project is up and running. This could include training or rollout activities.
RBS Tips for Success:
- Go to the lowest possible level:Be as detailed as possible in the planning. What may seem obvious to one team member may not be so to another team member or stakeholder.
- Hold a requirements workshop: Instead of holding individual interviews, you can engage the group of stakeholders at the same time in order to clarify assumptions, identify redundancies and avoid misunderstandings.
- Be objective: Write the requirements in a clear, objective way.
- Don’t focus on the implementation: Implementation comes later when building the Work Breakdown Structure. For now, only be concerned about the “what” not the “how” of the project.




