Ulad Shauchenka analyzed various failed projects and wrote the book ‘Why Projects Fail’. He writes about some of the findings from research surveys in this book.
Three out of five research findings have reasons related to requirements –
- Unclear goals and objectives that change during the project (Coverdale Organization research)
- Incomplete requirements (Chaos Report)
- Poor articulation of user requirements (OASIG Study)
Sample these findings from some of other sources –
- Failure to adequately identify, document and track requirements
- Poor or No Requirements
- Unclear goals and objectives
- Loose definition of project scope and management
- Vague requirements
They all indicate the all-important step in ensuring success of a project – collecting the right requirements.
A sample Software Requirements Template is linked at the bottom of this post.
What are the different types of requirements to be collected?
This is an important consideration for the project manager. For many organizations (especially in software industry), usual categorization is Business / Functional requirements and Non-functional requirements (such as availability of system, performance, maintainability, response time and so on). For some, categorization is Business requirements and Technical requirements – former indicating what stakeholders want, and the latter indicating what project should do to implement these stakeholders’ wants.
In PMBOK 5th edition there is clarity provided in this regard. There are 6 fine-tuned areas that can be looked at while collecting requirements!
This mind map outlines these requirements (Click on the image to open mind map) –
At this stage of the project the documents already available are project charter and stakeholder register.
Who already knows the requirements that you can collect from? The stakeholders. So you need the stakeholder register and the plan to understand how to manage stakeholders as well. And there is one more – project charter.
Recall the contents of project charter from Developing Project Charter project management activity –
It contains, but not limited to,
- short description of the project,
- high level requirements
- assigned project manager who is authorized to come up with budget, resource planning, decision on types of people based on skillset
- ballpark budget figures
High level requirements are available at this stage to start collecting detailed requirements.
Hows this done?
There are quite a few. Take a look at this mind map to get a hold on all of them. Spend few minutes, we shall look into them individually in further posts. Start with ‘Interviews’ bulb and move clockwise.
Let us look at these in a bit detail in the next couple of lessons.
Recall the characteristics of a project –
- Definite start and end date
- Produces a specific benefit
- Progressively elaborated
The progressive elaborative nature of project means that not everything about requirements is known upfront. It starts with high-level information that is required to get started, and as project progresses you pick up more details and include them into requirements.
What is requirements documentation
A project creates a product, service or result that satisfies customer’s business needs. The requirements documentation identifies individual requirements and describes how they map to these business needs. So, when these requirements are implemented during project execution, business needs of customer are met.
Although requirements are progressively elaborated, they cannot be ambiguous when baselined. Only baselined requirements are taken for implementation, and at that point they need to be clear, complete, verifiable, and acceptable to stakeholders.
The format and level of detailing of requirements depends on the nature of project and is left to the discretion of stakeholders and project management team. Some may have just description of requirements listed per business priority. Some may have elaborate structure, attachments etc.
In software industry, Requirements Documentation is sometimes called as Software Requirements Specifications.
Some of the parts of requirements documentation are –
- Business needs detailed from the project charter
- business and project objectives
- business rules
- Stakeholder requirements
- stakeholder communication and reporting needs
- Solution requirements
- functional requirements – behavior of the product
- non-functional requirements such as performance, safety, security, government or industry compliance needs, reliability, ease of use, maintainability. These are the inherent expectations from the product.
- standards and compliance (industry, domain, government) requirements
- product support and training needs
- quality needs and reporting needs
- Project requirements – performance, safety so on. Includes acceptance criteria.
- Transition needs (to production, support and/or operations)
- Assumptions and constraints
Consider our earlier example of Landscaping project that Kathy was managing. The business need is to build a jogger’s garden, blending nature’s feel and functional need of jogging track.
To satisfy this business need, one of the functional requirements would be to have jogging track, which is a spray-coated anti-slip rubber runway, with rebound value of 24%.
Non-functional requirements are that it is environmental-friendly, it should be easy on any kind of shoes that joggers may wear, and should last at least 5 years.
What is Requirements Traceability Matrix (RTM)
RTM is the way in which baselined requirements are linked across different baselined data, such as use case, design, test plan and test case. This document will ensure that various activities of the project work fulfill the business needs, and that none of the business needs go missing from implementation.
A sample requirements traceability matrix would be –
We saw the inputs and outputs of Collect Requirements process. I can’t wait to share notes of the cool tools and techniques of this process in next couple of posts. Click here for the first part of the post .
If you manage Software projects and need a quick start-up document, you can download a simple Software Requirements Template: MSDoc version or PDF version. This is based on IEEE recommendation for Software Requirements Specifications. For non-software projects this document may need some tweaking as specific to the domain.
More often than not requirements are collected in less than ideal ways in organizations. Reasons are many – from customer’s inability to provide access to real stakeholders (end users) to lack of awareness about tools and techniques, to lack of support in the organizational process assets. What has been your experience with gathering requirements for any of your project?