We will briefly look at a few of the key ingredients in managing requirements, including what gets created during planning, documenting "good" requirements, traceability, and managing changes.

Planning

Two of the key outputs from requirements management are a planned and communicated approach to business analysis and a requirements management plan.

The business analysis approach. The approach that we take to business analysis work is primarily concerned with the type of framework, method, or methodology we use to capture our requirements. The approach is the cornerstone of our effort, and it determines how we go about collecting and managing requirements. It describes the processes we will follow and the templates, if any, that we will complete. the approach will probably be different for different methodologies  and frameworks. For example, prioritizing requirements on an Agile project is different from prioritizing them on a Waterfall project. In choosing an approach, we need to make sure that it's communicated to all appropriate stakeholders and that they are onboard with the approach that will be taken.

The requirements management plan (RMP) describes how the business analysis work will be completed. It describes processes for how requirements will be documented, traced, prioritized, baselined, and changed. We might also think of the RMP as a collection of the plans that are used to manage business analysis. The RMP can be a formal set of documents with many subsidiary plans, such as a business analysis communication plan, business analysis risk plan, estimates for the business analysis work effort, and many more. This type of RMP might be appropriate for larger, riskier projects. On some smaller efforts the RMP can be an informal roadmap. In either case, it is subsidiary to the overall project management plan.

Documenting "Good" Requirements

Requirements documentation. Requirements are always documented, either formally or informally. Requirements might be documented as part of a detailed requirements specification, in the form of a short text known as a user story, or as part of one or several models, such as a business process, data, or use case model, or as a prototype or mock-up. There is no right way or wrong way to document requirements, as long as all the requirements are understood by everyone who hears or reads them--which means they need to be "good."

What makes a Good Requirement?

In order for a requirement to be worth managing, it must be useful. To be useful, a requirement has to be understood by all key stakeholders. Sponsors and business subject matter experts need to know that the ultimate solution will solve their problem and meet their objectives. Developers need to understand how to design and build the final product. The testing staff needs to be able to find and remove any defects the product may have. Change managers (Human Resources staff, consultants, business managers, etc.) need to understand how the end product will affect the organization. If a requirement is not clear, some or all of the components that comprise the product could be defective. To that end requirements must be clear and unambiguous, consistent, complete, concise, and confirmed (validated and verified). They must also be testable and traceable. Here are some tips to make requirements "good."

• Describe what is needed rather than how the need will be implemented.
• Use units of measure or specific words to reduce ambiguity. So, "less than five seconds" is preferable over "fast," for example.
• Use a glossary to reduce ambiguity. As new stakeholders become involved over the life of the project, a glossary can prevent misinterpretations and increase productivity. It is also helpful to include an acronym reference list with the glossary for easy access to those acronyms.
• Keep sentences concise and simple in relationship to number of words and grammatical structure.
• Organize and group requirements into a hierarchical list, with high-level requirements broken down into sub-requirements as they are uncovered.
• Uniquely identify each requirement. Use a hierarchical numbering system (1.0, 1.1, 1.1.1, 1.2, etc.). Such a scheme can be used to more easily trace requirements (see below).
• Remove redundant requirements or clarify requirements that seem similar but are really unique.
• Use graphical models, diagrams, and prototypes where appropriate.

 Traceability

Requirements traceability is a structured way to keep track of requirements. Requirements are traced back to their source, to themselves as detailed requirements are discovered, and throughout the project. Tracing requirements back to their source is sometimes called backwards or upwards traceability and involves linking requirements to the identified business problem, business objectives, and project objectives. Figure 1 illustrates the concept of backwards traceability.

Figure 1 - Backwards Traceability 

Tracing requirements throughout the project is called forwards allocation or forwards traceability and involves documenting the linkage between the requirements and other requirements, and requirements to the design, development, testing, and deployment work products. Figure 2 illustrates the concept of forwards traceability.

 Figure 2 - Forwards Traceability

Requirements traceability aids requirements management by ensuring that each requirement:

• Adds value. By tracing each requirement, its value in helping the organization solve its problems and meet its objectives becomes apparent, thus helping the organization focus on doing all the right things and only the right things.
• Belongs in the approved scope. Requirements that cannot be traced do not belong in the project. Scope management is one of the biggest project challenges, so traceability is a useful tool in controlling scope.
• Is actually delivered at the end of the project or project phase. Once the right requirements have been identified and agreed upon, it is important to ensure that all the pieces needed to satisfy those requirements are designed, built, tested, and delivered.

Traceability also aids in determining impacts and interrelationships, so that:

• The cost of each requirement and requested changes can be more easily estimated.
• Testing coverage can be planned.
• Risks can be more easily identified, and a risk response plan developed.

Managing Changes

An important part of requirements management is handling changes. During requirements planning, processes to handle changes are established, including who requests changes, who authorizes them, and who vetoes them. The "who" might be an individual, or it might be some type of change control board. Once the change process is approved, it is necessary to follow it. The approved process depends on the business analysis approach taken, and might vary from project to project. For example, the process for handling changes on an Agile project might well be different from a traditional project. Regardless of what that process is, however, it must be communicated and agreed to by affected stakeholders.

Summary

We have looked at a few of the key ingredients in managing requirements. They included planning tasks of determining the approach and creating the requirements management plan, which needs to be appropriate for the business analysis effort. As we do the business analysis work, we document "good" requirements in the format and to the level of detail required for the project at hand. Finally, to help control the scope, we trace requirements and manage changes.

Don't forget to leave your comments below

Elizabeth Larson, CBAP, PMP, CSM, and Richard Larson, CBAP, PMP, are Co-Principals of Watermark Learning (http://www.watermarklearning.com/), a globally recognized business analysis and project management training company. For over 20 years, they have used their extensive experience in both business analysis and project management to help thousands of BA and PM practitioners develop new skills. They have helped build Watermark's training into a unique combination of industry best practices, an engaging format, and a practical approach. Watermark Learning students immediately learn the real-world skills necessary to produce enduring results. Both Elizabeth and Richard are among the world's first Certified Business Analysis Professionals (C BAP ) through the International Institute of Business Analysis (IIBA) and are contributors to the IIBA Business Analysis Body of Knowledge (BABOK). They are also certified Project Management Professionals (PMP) and are contributors to the section on collecting requirements in the 4th edition of the Project Management Body of Knowledge (PMBOK).