Managing requirements is a key tool for business and project success. This paper explains some of the concepts of requirements management and introduces a number of techniques that can be applied. Through these approaches, you can help ensure that the final delivery from a project or initiative aligns with the initial strategic intent. In other words, you can deliver exactly what the stakeholders expect and what the business needs.
What is a Requirement?
Requirements exist within all organizations; all organizations exist to delivery products and/or services to customers, which are always delivered through business processes that are decomposed into individual requirements. Requirements are simply a capability needed by a stakeholder (person) to deliver a product and/or service.
What is Requirements Management?
Requirements Management is an iterative set of activities that help ensure that elicitation, documentation, refinement, and changes of requirements is adequately dealt with during a lifecycle, with a view toward satisfying the overall mission or need in a quality manner and to the customers’ satisfaction.
Whether part of a project management plan or standalone, a Requirements Management Plan (RMP) describes the requirements artifacts, requirement types (including attributes), the requirements management process, and the metrics and tools to be used for measuring, reporting, and controlling changes to the requirements.
Why Manage Requirements?
Studies have shown that requirements management improves all major aspects of organizational strategy (portfolio, programs, and projects) or operations management (day-to-day business) by:
- Reducing cost
- Improvings quality
- Decreasing time taken
- Decreasings risks
- Enabling effective scope management
In 2009, IAG Consulting conducted a Business Analysis Benchmark survey, 68% of companies surveyed used poor requirements practices and reported that while having estimated a project at US$3 million, it will be on budget less than 20% of the time. On average, these companies with poor requirements practices will pay US$5.87 million per project, a significant increase over estimation.
According to the 2004 CHAOS Report, three of the top five reasons projects fail are related to requirements:
- Users are not involved enough in requirements definition
- Requirements are incomplete or don't meet acceptance criteria
- Requirements are constantly changing, and these changes are not managed effectively.
The CHAOS Summary (2009) reported that 44% were challenged (late, over budget, and/or with less than the required features and functions); and 24% failed (cancelled prior to completion or delivered and never used).
Where are Requirements Managed in an Organization?
Organizations exist to deliver products and/or services, which are delivered through business processes that are decomposed into requirements. Requirements should be managed in organizational strategy (portfolio, programs, and projects) or operations management (day-to-day business). Often, requirements management is lacking in strategic planning, portfolios, and day-to-day business initiatives (often referred to as continuous improvement).
- Strategic Planning (strategy to execution) –business requirements (outcomes and benefits) are defined and quantified
- Portfolio –business requirements are used to link the strategy to the portfolio of change
- Program –business requirements are used to define the program scope and success criteria
- Project –business and stakeholder requirements are used to define the project scope and success criteria. Solution –nonfunctional and transition requirements are used to build and implement a solution
- Continuous Improvement (day-to-day business) – business requirements and stakeholder requirements are used to define the continuous improvement, scope, and success criteria. Solution–nonfunctional and transition requirements are used to build and implement a solution.
Figure 1: Strategy to operations
When do you plan requirements management? Anytime-it is never too late to do a requirements management plan. The ideal situation is to manage requirements from the strategic plan, which are often expressed as outcomes and benefits, all the way to execution. However, the reality is that most of the time, requirements management is not done until the start-up of a project. One of the reasons why many organizations fail to realize value from a good strategy is the lack of requirements management with benefits realization.
Is there any time you don't need an RMP? Probably not, but it is important to varying levels of detail in a requirements management plan, depending on the project complexity and risk.
The Requirements Management Plan (RMP)
RMP Contents
The contents of a typical RMP contain the following sections:
- Stakeholder roles and responsibilities
- Requirements management process (elicited, analyzed, documented, and managed)
- Requirements type definition
- Requirements type/artifact mapping
- Naming and numbering convention
- Requirements prioritization
- Requirements traceability
- Requirements versioning
- Requirements baseline (requirements change control)
- Communication strategy for requirement changes
- Requirements management tools
Stakeholder Roles and Responsibilities
Who creates the RMP?
- Business Analysts with input from the project manager
Who approves/endorses RMP?
- Leaders from each Software Delivery Lifecycle SDLC team
Who participates in the RM process?
- Business subject matter expert – source of project/product requirements
- Business analyst – gathers, analyzes, and documents requirements
- Designer – uses requirements to design solutions
- Developer – develops solutions to requirements
- Tester – verifies the solution and satisfies the requirements
- Project manager – reports project status based on requirement metrics
- Change management analyst – determines organizational change due to requirements
Who maintains the RMP?
- Business Analysts (BA)
Who is involved in a requirements management plan? As a BA, you must work fairly closely with the project manager in creating a requirements management plan. The project manager will have project planning requirements that he/she needs to satisfy, so the BA needs to be aware of that and needs to help ensure the requirements management plan works well for the project.
In some cases, the project management plan may actually encompass the main components of the RMP, so it may not be necessary to have a separate document. Who endorses the RMP? Typically each of the team leaders in the application lifecycle. Who participates in the process? Subject matter experts are people who are going to help define and specify requirements. TBAs will gather, analyze, document the requirements. The designers and developers will design and develop the solution components from the requirements that BAs have elicited. The testers then take those requirements and test them to help ensure they still fit the purpose and satisfy the original requirements. Finally, the change management analyst reviews and implements changes to the organization based on the requirements.
The project manager can use requirements to provide meaningful reporting on the status of the project using the metrics that we keep talking about - things like how many requirements are still yet to be approved or outstanding to be approved by stakeholders; how many requirements are deferred which are going to potentially change the scope; and critically, what the impacts are on the project.
So there are a lot of people interested in requirements and they all have a slightly different view so we need to make sure upfront that we consult with each of those people. The RMP is the mechanism to engage so we understand what they need and keep them engaged throughout the entire project.
Use a RACI matrix, if possible, to show the stakeholder their role in requirements, their interest, and when in the process they are typically involved. Identifying the stakeholders helps define and verify the requirements management process.
Requirements Management Process
- Identify stakeholders
- Gather/elicit requirements
- Analyze requirements
- Specify/document requirements
- Baseline requirement groups (verify, validate, and prioritize requirements- i.e.: agree and sign-off on requirements)
- Communicate requirements
- Monitor/track requirements
- Manage and control changes to requirements
- Report requirements compliance
The process is a really important part of the requirements management plan. You need to have a process that pulls together the steps: identify stakeholders; solicit the requirements; analyze the requirements; document requirements; baseline;, communicate; monitor and track; manage and control; and report. The process is important because you want it to be repeatable, so that a change of the requirements does not want initiate a different process.
It is important to document and articulate the process so that everybody who has an interest in requirements change complies. It should also link in nicely to the project change management control. Naturally, this would link directly into your issues register and that is where you would hook into your lower level requirements process. It is important that those two controls mesh together on any project.
Requirements Types
Requirement types are a mechanism to enable a cascading hierarchy of requirements. This allows the initial broad coverage of requirements with a business focus to be traced to detailed requirements with a technical focus.
Figure 2: Requirement types
Requirements Artifacts
Requirement artifacts are the documents produced that contain requirements and other supplementary information for the stakeholders.
Figure 3: Requirement artifacts
One of things we need to do early on is to work out what artifacts are to be produced. Figure 3 shows examples of some artifacts that have been produced on a project. The terminology used is general terminology. Often, organizations will call these artifacts different things, and it is important to identify what artifacts are going to be produced on a project. The RMP should include these artifacts and identify them right at the start of a project.
The project approach is going to influence the different levels of artifacts. Likewise, we need to identify what types of requirements are going to be used on the project. Have you worked on a project where you have only had solution and nonfunctional requirements? If so, you've gone straight into solution requirements without understanding the business benefits.
By identifying higher level requirement types, we create linkages to strategy.-What are the business goals and objectives? What are they trying to achieve? What is the need? We need to make sure that, as we move through the requirement types, we distill them down into lower level requirements. It is important that we understand where those requirements came from and what their main purpose was.
To put this in context, at the top we are looking at a high-level need, the next level down is business requirements, and still further down, we get a technical focus. I've seen organizations talk about a systems agnostic approach. This is where you use business process to flush out where those business requirements sit, and then drop down into the nonfunctional and functional requirements. The levels evolve from a business focus drawing down into a more technical focus. You can see a direct correlation between the requirements types and the interest of the different stakeholders. Requirements types are specifically targeted toward different types of stakeholders.
Remember that different organizations use different names for their artifacts (this is an example only). The first hurdle is understanding what different types of requirements exist within your organization and who uses them. In this article, I've use industry standards with requirements types to reduce confusion.
Requirement Attributes
The following requirement attributes should be captured for all requirements:
- Requirement identifier (unique)
- Requirement name
- Requirement description
- Requirement version number
- Requirement type
- Requirement change history
- Requirement status
- Requirement priority
- Requirement owner
- Requirement trace information
- Requirement process/activity reference
Every requirement needs a unique identifier and a meaningful name. The requirement needs a brief description that is understandable to the business. I've seen some implementations where descriptions can be some kind of a graphic that you attach (a screen shot or something that you might put on the web with your requirements). The version number of the requirement (e.g. we are now at version 1.3 of this business requirement) is important to track changes which are inevitable through a project.
Requirement types and change history are a little more subtle in that typically, if you're managing your requirements in a text document, it is the document that is versioned and not the individual requirement. That is probably not too bad in a simple project, but when you have different stakeholders interested in different sets of requirements, you may actually want to publish a particular version of requirements to subgroups of people.
Requirements status is an important input to your project metrics. An example of this is when a draft requirement waiting approval has been approved, has been deferred, and has been removed. An analysis of status metrics can help you understand why things in a project might be taking longer than expected. At a point in time, you might want to say, “give me all of the requirements that were actually created at this point in time, but still have to be approved two months later.” This leads to questions such as: What is going on? What is the issue? What is the problem? Why have I got 50 requirements that have been removed, suspended, or deferred? What is the cause of that? Why is that not going to go ahead?
Requirements priority is particularly important for stakeholders. Questions that may be asked are: What are my mandatory requirements? Which ones are not mandatory, but are desirable so that if I have time constraints, I canlook at deferring implementation of those requirements?
The requirements owner needs to be identified, so that if a requirement is not understood, more information can be obtained. If the developer comes back and says that something is a good idea, but it will cause grief in terms of implementation, you can also go back and ask the owner if there is something else that can be done with thatrequirement. Going back and talking to the business stakeholder helps ensure that he/sheis aware of this and gainstheir truast and approval. You may also have a stakeholder that is going on leave and his script of requirements may go to someone else who can manage those requirements temporarily and then update the stakeholder on changes when they return.
Just a word of caution, do not put in too many attributes the requirements management plan to start with. There is a real temptation to put in lots of attributes, but then you end up being a slave to your requirements management plan. Start with the simple ones and expand out as you have some different projects and different company needs.
Requirements Traceability
One of the most important components of requirements management is traceability. Tracing allows us to understand why the requirement exists, the impact of change, if the set of requirements is complete, and helps prioritize requirements.
Figure 4: Requirements tracing
Figure 4 shows how traceability starts off with the business requirements’ outcomes/benefits and traces through the stakeholder requirements, solution requirements, supplementary requirements/nonfunctional, and down into testing scenarios and test cases. The complexity of tracing could be very simple or it could be quite extensive. It really depends upon the maturity of the organization and the groups that you are working with. You can see that the volume of requirements at a high level is quite small, but as you go down, you go down into a lower level of granularity where the volume is going to grow. Yet, it is critically important to understand how they relate back up to the top.
Requirements Artifacts, Types, and Traceability
Putting it all together is how an expert BA will differentiate him or herself. Once all the requirements artifacts are traced tightly together, we start to achieve clarity and control of the scope.
Figure 5: Requirements artifacts, types, and traceability
Finally, trace information gives you the ability to look at a particular requirement and trace whether it is a genuine solution requirement. Does it relate back up to a stakeholder requirement which relates back up to a Subject Matter Expert (SME)? Does that solution requirement have any associated nonfunctional requirements?
At the next level, publish a baseline set of requirements to the development team. The development team then tags the code components back to those original requirements and the test team actually takes their test cases back to those requirements as an extension of that traceability. When we talk about traceability, it is not just between solution and nonfunctional requirements; it is the whole gambit back to strategy.
When we trace consistently, it becomes second nature and its value becomes apparent. Every time you are looking at changing a requirement, you must think of the impact it will have and what else it will affect. You have to go back and look at what other requirements this is traced to and make sure that you have not upset anything else. Typically, this happens more frequently in the early analysis. Then as you go through to development, you are still always trying to ensure that you trace between requirements and maintain integrity between the solution and the strategy.
Requirements Versioning
Requirements versioning is the process of documenting and maintaining a history of all changes to a specific requirement. The primary purpose of versioning an individual requirement is to help ensure that the project team is working from the exact same requirement.
Versioning is important to increment changes to a requirement. Unless you are using a requirements management tool, this is probably something that you are not going to continually do. Important requirements may change a number of times-10, 20, 50 times, and this may occur through the whole lifecycle of the project. It is important to track what version of that requirement and what the specifics of the changes to that requirement are. This allows you to link it to the owner, who is the one who performed the change.
Other purposes for versioning include:
- Enable the project team to determine how and why a requirement has changed over time
- Help ensure that a review of requirements is being conducted on the correct version of requirements, and not an old version
Requirements Baseline
A baseline is a basis for comparison between requirements (all or subset) over a period of time; it is a “snapshot” of requirements (not a one-time event). Each project should define a baseline strategy that includes defining the baseline in terms of creation, frequency, content, and publishing. A baseline is the vehicle for communicating changes in the detail of requirements to interested parties.
Baselining is a mechanism to package a set of requirements at a particular point in time and pass that off to the next group in the project team.
It is important in your RMP to specify when to create a baseline and how frequently they are going to be tied to formal project milestones. The content of the baseline and how it is going to be published also need to be specified. Is the baseline published into a document? Is it published using a tool that will actually take a set of requirements and then send them to the development environment, so that the developers can code against those requirements? There are a number of ways this can be performed.
The important thing is that the requirements management plan is all about this upfront planning. We are trying to make sure that we have planned these activities and as we move through the application lifecycle of the project, we don't want to have to make these decisions as we are getting to critical delivery points.
A baseline can be formal or informal.
- Formal - A prescribed project milestone that carries a formal acceptance of requirements (all requirement attributes need to be populated and requirements need to be validated as complete, unambiguous, and verifiable)
- Informal - An agreement between project team members that requirements are correct at a point in time (minimum set of requirement attributes need to be populated)
Balance the number of baselines with the project size. Once the formal baseline is created, then any changes to any of these requirements needs to be handled through the project's change management procedure.
Communication of Requirements Changes
The communication strategy for changes to requirements should be linked to a change control process.
- Waterfall processes treat changing requirements as the exception
- Iterative and agile processes accommodate requirements change
A robust communications strategy will facilitate the auditing of requirements by internal and external groups to help ensure that the delivered solution accurately reflects the requirements.
A good communications strategy is particularly important if you are working in a complex environment, with many internal stakeholders and external stakeholders. Your communications strategy needs to be some sort of plan around a communication method, and it needs to be a repeatable process. You need to formalize it into the plan. This will help ensure that it is repeatable. On large projects, it is going to be quite complex. On smaller projects, it will be pretty easy, but it is important to think about that.
Embrace requirements change, as it is inevitable as you validate and verify requirements. However, control change carefully so that it is managed.
Reasons for Using Requirements Management Tools
A requirements management tool can increase the efficiency of an established requirements management process by:
- Managing requirement version and content changes
- Storing requirement attributes
- Linking requirements to other system elements
- Providing multiple views of groups of requirements based on their attribute values
- Monitoring the state of each requirement or groups of requirements
- Controlling access to requirements and therefore, preventing unauthorized changes
- Facilitating the communication of requirements to requirement stakeholders
Why do we use tools? We have shown that there are a number of requirements management attributes to collect and there is an overhead in doing this. You can use requirements management tools to help you with tasks such as storing requirement attributes, traceability, the change history to requirements, the automated updated versioning, and the importance of requirements.
A tool can help to provide multiple views to user groups of requirements. You may have a particular stakeholder or project manager that needs a regular report or a regular understanding of where their requirements are at. This may be for a subcomponent of a project or the entire project, and he/she may need to know which requirements are waiting to be approved, who are they waiting to be approved by, and how many requirements have been deferred this week.
Controlling access to requirements is a common feature of a requirements management tool. We have all seen the situation where we have got soft copies of work documents and inadvertently changed the content of those documents without following all change control procedures. If you have your requirements controlled inside a requirements management tool, the access that particular analysts or stakeholder have is what they require. For instance, the BA may have update access, while other stakeholders may only have read-only access to your requirements. This helps ensure that stakeholders do not change any requirements outside of an agreed upon process.
Some requirements management tools allow you to publish the requirements in a document or as browser-based content. It is a mechanism that allows you to be a bit more flexible and integrated about how you communicate your requirements to your stakeholders.
The important thing is to have a requirements management plan first and then implement it through the tool. Do not let the tool drive the plan. Use a business process first and then venture into a functionality tool. Tools cost money so they require justification. We have performed requirements management without a tool using spread sheets or locally-built databases. Typically, it is only when these become too complex that a tool is justified. It is probably a staged process to move to a full blown requirements management tool. Hopefully, we have given you enough reason to go back and talk to your company about your potential need for a tool.
Requirements Management Tools Lessons Learned
Tool complexity should match the budget and business analyst capabilities and needs of the organization.
Understand your requirements management needs before you purchase a tool.
- Standalone requirements management
- Integration with other modeling tools
Don't take the vendor's word regarding functional capabilities. It is best to conduct a proof of the concept before buying in.
Critical Success Factors for a Requirements Management Plan
- Work to ensure that the Requirements Management Plan is implemented at project start and adhered to and incorporated throughout the full lifecycle of the project or product
- Work to ensure customers, stakeholders, managers, developers, and users are all involved in the requirements management process
- Try to ensure that all team members understand the importance of adhering to the Requirements Management Plan
- Foster good communication among team members during the process of gathering, documenting, verifying, and managing changes to requirements
- Work to ensure that a requirements management tool is used to show traceability and consistency and to assist in validation, verification, and testing of the requirements
- Try to ensure Analysts have the discipline to continually maintain the requirements traceability when using RM tools that will assist you, but won't enforce the discipline of continually updating traceability
- Work to ensure that a requirements configuration management process is implemented and that no changes are made to baselined requirements without performing a risk analysis, re-estimating impacts to cost and schedule, and validation amongst the stakeholders
Summary
Requirements management should be performed in strategy planning, implementation, and operations. Try to ensure your customer, stakeholders, project managers, and business managers are engaged and involved in the requirements management process from the start. The key is to have no surprises—we should all know our roles and when they are going to happen.
Work to ensure that team members know the importance of adhering to the requirements management plan. Your BAs have to do things consistently and they have to understand and enforce requirements change management. The designers, developers, and testers need to understand that Bas are all using this requirements management plan. This tells them how they are specifying requirements, when they are going to get a baseline, how we are going to communicate the changes, and how to communicate amongst team members during the process for verifying and managing the changes to those requirements.
The requirements management traces across the whole lifecycle. The BAs must have the discipline to maintain all aspects of the traceability and must be disciplined to help ensure that everything fits together. They have to be sure that there is requirements configuration and that baselining is being done in a controlled way, and that requirements are being understood and approved. This approach has a dramatic effect in improving project outcomes.
References
IAG Consulting. (2009). Business analysis benchmark : The path to success (2nd ed.). New Castle, DE: Author.
The Standish Group International, Incorporated. (2004). CHAOS report.
The Standish Group International, Incorporated. (2009). CHAOS summary report.
