How big of a deal are project requirements?
The Project Management Institute says, “47% of unsuccessful projects fail to meet goals due to poor requirements management.”
In his book — Just Enough Requirements Management — Alan Davis shares, “Various studies suggest that errors introduced during requirements activities account for 40 to 50 percent of all defects found in a software product.”
What are Project Requirements?
Project managers talk about this topic a lot. Stakeholders hear the term “requirements” but interpret the meaning in different ways. Before we can manage anything, it’s critical that we have a working definition.
The Project Management Body of Knowledge defines 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.”
Karl Wiegers — author of Software Requirements — shared this definition: “Requirements are a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute.”
Part of the confusion concerning requirements is that there are different types. It is wise to distinguish requirements such as:
- 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)
Be sure to include the definitions you use in your requirements management plan.
Why are Requirements Important?
Imagine that you’ve contracted with a general contractor to build your dream house. You’ve been thinking about this house for years. As you have visited friends, you’ve made notes about what you like (and don’t like) about their homes. Perhaps you have a Pinterest page where you’ve saved your favorite pictures.
So, you have your first meeting with the general contractor to discuss the requirements for your house. The contractor walks you through a checklist, explains your options and pricing. You specify the size of the house, the type of construction, the number of rooms, the types of systems, and the features of the home. You leave nothing to chance.
A week later, the contractor walks you through an interactive computer model of the home. You progressively refine your requirements. After a few more meetings, the contractor understands your needs. Guess what! The contractor has a much higher chance of meeting your expectations.
When requirements are vague, projects are at risk of not delivering what is needed. At a minimum, missed requirements result in rework. There will likely be adverse impacts to the schedule and to the budget. And your customers — as well as your team members — will not be happy!
How do we develop requirements?
1. Elicit the Requirements
When requirements change, I see project managers point their finger and say, “the users never know what they want.” While there may be some truth to this, I have always held the position that the requirements analyst — whether a project manager, business analyst or business lead — is largely the problem. Why?
A good analyst knows how to elicit — to draw out — and validate requirements. I have made an observation after hundreds of projects: The projects with a skilled requirements analyst have fewer requirement-related issues. If you are a project manager and you don’t have the time or the requirement development skills, make sure you secure a skilled requirements analyst; otherwise, you are asking for problems.
Here are some elicitation tools and techniques:
- Nominal group technique
- Document analysis
- Requirements workshops
- Job shadowing
- Context diagrams
2. Analyze the Requirements
The word “analyze” means to break down or examine in detail the constitution or structure of something. For software projects, we break the requirements into greater detail as we move from business requirements to user requirements and further into the detailed system requirements. Once we’ve determined the details, we can synthesize the components together to meet the higher level needs.
Practically speaking, how do we analyze requirements? One of the most powerful ways is to build prototypes or create diagrams; it doesn’t have to be complicated. When users see things, they can respond with what they like and don’t like.
Another tool for analysis is a context diagram that visually depicts a product such as a building, process, or software application and how actors (individuals, groups, or other systems) interact with it. We can see the things that flow in and out of the process and who receives the outputs.
Some organizations prioritize requirements during the analysis. Which features and functions provide the greatest benefit? Which ones may cause the greatest risk? In agile projects, we can rank order the user stories in the product backlog.
3. Document the Requirements
In recent years, there has been a move to lighter requirements documentation and more collaboration, particularly for agile projects. I’m all for that, but I’m not for zero documentation. When we document, we think and we analyze. It is also helpful to have a light version of documentation for reference as people extend the features and functions in future projects.
Business requirements are typically defined as goals in the project charter. User requirements are often captured in a use case or user story format. The detailed software requirements are documented in a software requirements specification (SRS) or in a requirements management tool.
4. Validate the Requirements
Finally, we talk about requirements validation, how to ensure that the project requirements are correct, free of defects/bugs, and meets the needs of the users. Conduct validation meetings to review the requirements with a cross-functional team such as the BAs, developers, and testers.
Once the team has reached agreement on the requirements, baseline the requirements with the appropriate sign off process.
Where Do We Go From Here?
As you’ve read this article, you may have thought — this is a lot of stuff! Yes, it is. As with all project management processes, scale the requirement processes to meet the needs of each project. Early in your project, think about your approach to requirements and create a simple requirements management plan:
- Will you take a traditional or agile approach?
- Who will be the requirements analyst?
- Who will be involved in the elicitation, analysis, documentation, and validation?
- What tools and techniques will you use?
- How will you prioritize requirements?
- Frequency of requirements validation
- How will you trace requirements: Requirements <–> High-Level Design <–> Detailed Design <–> Coding <–> Testing
- How will you handle changes to requirements?