Effective Requirements Management within the CMMI
Posted On November 28, 2015 by Shruthi S filed under Enterprise
The Software Engineering Institute’s (SEI), Capability Maturity Model Integration (CMMI) is a Capability Maturity Model (CMM) for product development, including systems engineering and software engineering. The SEI describes a CMM as containing the essential elements of effective processes for one or more disciplines. A CMM also describes an evolutionary improvement path from ad-hoc, immature processes to disciplined, mature processes with improved quality and effectiveness. CMMI builds on and extends the best practices of the Capability Maturity Model for Software (SW CMM), the Systems Engineering Capability Model (SECM), and the Integrated Product Development Capability Maturity Model (IPD-CMM).
Doesn’t process improvement cost time and money? What’s the payback?
Certainly, improving organizations’ product development processes will require investment. However, the right choice of tools to support these processes can speed implementation and the time it takes to benefit from adopting them. The Return-on-Investment (ROI) achieved by organizations adopting CMMI and its predecessors is well documented.
In an previous report, SEI found that organizations using CMMI benefited significantly. They:
- Reduced the cost of finding and fixing defects by 15 percent, while decreasing the average cost of fixing a defect by more than 30 percent.
- Reduced the time to turn-around releases by 50 percent, while increasing software development productivity by 30 percent.
- Improved the quality of delivered systems with only 2 percent of all faults escaping into the field.
- Increased customer satisfaction, resulting in greater financial awards.
The CMMI maturity levels
CMMI offers two flavors: staged and continuous. In this article, we focus on the staged representation. CMMI defines five stages, or levels, of process maturity (see Figure-1). With CMMI, organizations are encouraged to concentrate on a manageable number of process areas and evolve their processes to an increasing level of sophistication. Each level is a defined point of stabilization. This article will focus on levels two and three, the levels that contain process areas related to requirements management.
A CMMI Process Area is a group of related practices, with a defined set of goals. Figure-2 shows the process areas for each of the five maturity levels.
This article focuses on the Level 2 process area of requirements management and the Level 3 process areas of requirements development and technical solution. Once implemented, these three process areas are closely associated and can run concurrently.
Requirements Management in CMMI Level 2
Organizations at Level 2 must have examined a number of key areas and implemented repeatable processes that address them.
Process Area: Requirements Management
The CMMI goal for the Requirements Management process area is:
“Requirements are managed and inconsistencies with project plans and work products are identified.”
The prime objective of any product is that it meets the needs of stakeholders and customers. But it must also abide by internal constraints of functionality and quality. A requirements management process plays a vital role in facilitating this. The importance of effective requirements management cannot be understated; indeed, recent industry analyst reports have clear findings that projects succeed with it and fail without it. When asked by Standish Group why projects succeed, 50 percent of respondents attributed successful projects to reasons related to requirements management.
The practices that must be established in order to achieve the goals of the requirements management process area, are summarized below:
Organizations must define a set of requirements
“Develop an understanding with the requirements providers on the meaning of requirements.”
“Obtain commitment to the requirements from the project participants.”
The first step of any requirements process is to ensure all stakeholders understand what the project goals are and why. Therefore, organizations must create a process where all stakeholders are invited to help define requirements and, ultimately, agree on a baseline. As the project progresses, organizations can then trace results back to the original goals and ensure they have been met, and, that any changes have been justified. In order to collaboratively create and manage a well-defined set of requirements, tools should allow multiple users to view and/or edit requirements documents and uniquely identify individual requirements statements. Users also need to easily establish and report on traceability links between evolving sets of requirements (say, between customer and product requirements) and other project artifacts, such as designs and tests. This provides an audit trail of decisions and ensures requirements have been met, even as things change. It is also vital to maintain the history of any changes to requirements statements. Tools should be able to baseline incremental versions of requirements documents and allow sign-off on baselines electronically.
Organizations must manage changes to these requirements
“Manage changes to requirements as they evolve during the project.”
Once requirements are established, everyone involved in the project must always have access to the most up-to-date information. Organizations need to understand:
- The changes that are being requested to the requirements.
- How those changes will impact the project as a whole.
- What action stakeholders agree should be taken in response to those changes.
- Whether approved changes have been included in the final product.
Changes to requirements are inevitable and must be allowed for, but controlled. Tool support must provide a collaborative, configurable change control process for requirements. Users should be able to:
- Submit change requests against requirements.
- Manage multiple change requests for a single requirement as a single item in the change control process.
- Package multiple, related change requests against a set of requirements, so resulting updates are made consistently.
- Assign reviewers to change requests.
- Review and comment on change requests online – so that all reviewers can see all comments made.
- Assess, quickly and completely, the impact of a change on related requirements, designs and tests.
- Approve or reject change requests based on the review input.
- Apply approved changes automatically so that no mistakes can be introduced.
Organizations must ensure requirements are met
“Maintain bi-directional traceability among the requirements and the project plans and work products.”
Only complete traceability can ensure that the right requirements are being fulfilled in the right way. Consequently, organizations must check that requirements are being met at every stage of the development process and demonstrate how a particular product specification maps back to requirements. Without strong tool support, creating, maintaining and reporting on traceability can be a time-consuming, tedious and error-prone task. Tool support must enable traceability links to be established quickly and easily. In order to satisfy CMMI, traceability must be maintained not only between sets of requirements but also with project plans and work products like designs and test plans. The requirements management tool must be able to synchronize data with the tools used to produce those other items. And to support iterative and incremental development processes, traceability must be established and maintained between different versions of requirements documents. Once traceability is established, tool support must make it easy to obtain a complete, single view of the relationships between requirements and other requirements, plans and work products.
Organizations must ensure project plans, work products and requirements are
“Identify inconsistencies between the project plans and work products and the requirements.”
Identifying inconsistencies ensures organizations’ development is on track – so they aren’t working on outdated information and no requirements have been overlooked. Therefore, organizations must implement a process to ensure that all project plans and work products are consistent with their requirements. This includes reviewing, analyzing and managing subsequent changes. Project plans and requirements specifications must be closely linked. Tool support should enable project tasks and requirements data to be synchronized, so traceability can be established between them. This makes it easier to assess how changes in project timelines can affect the ability to meet requirements, and vice versa.
Requirements Management in CMMI Level 3
Organizations at Level 3 need established, documented, common and consistent processes for use across all projects.
Process Area: Requirements Development
The Requirements Development process area identifies how to elicit stakeholder needs, derive formal customer requirements specifications from them and further refine these customer requirements into product and product component requirements. CMMI defines several goals for the Requirements Development area, summarized below:
Organizations must collect and translate stakeholder needs into customer Requirements
“Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements.”
Too often, the needs of stakeholders are poorly defined and understood; they can even be inconsistent or conflicting. A stakeholder representative must be involved throughout the product development lifecycle. There should be an iterative process to refine, elaborate and clarify needs to achieve a clear, well-understood set of customer requirements. This goal, and the practices that support it, mostly relate to including customer representatives on the project team throughout the development lifecycle. In addition, techniques for eliciting and elaborating requirements are also important. One popular method is to employ ‘Use Cases’. Use Cases provide a way of structuring and documenting functional requirements from the perspective of the users, in a variety of scenarios. Individual Use Cases are documented textually, while Use Case summaries, showing sets of related use cases and their usage, are best described with UML (Unified Modeling Language) Use Case diagrams. Tool support should enable UML diagrams to be interwoven with textual requirements statements in a single document.
Organizations must develop product and component requirements from the customer requirements
“Customer requirements are refined and elaborated to develop product and product-component requirements.”
Customer requirements must be fully analyzed to identify any implied but unstated requirements, complemented with new requirements associated with the technical architecture for the product. Depending on the size and complexity of the product, these can break down into product requirements, then component requirements and so on. Traceability must be maintained to provide an audit trail of decision-making and to support impact analysis.
According to the CMMI, deriving product and product-component requirements should be done by analyzing customer requirements and selecting and describing the necessary technical architecture. Tool support should make it easy to derive the next level of requirements, not only by creating traceability between requirements at different levels, but also by providing techniques to analyze higher-level requirements and document rationale. UML modeling, using techniques such as Use Case, Activity and Sequence diagrams, are an effective way to analyze requirements and derive new ones. High-level technical architectures can be described using Architecture (also known as Composite Structure) diagrams. Tool support should enable these models to be created within the requirements document in order to record decisions and provide rich guidance on developing the technical solution.
Organizations must validate the requirements
“The requirements are analyzed and validated, and a definition of required functionality is developed.”
Analysis and validation are necessary to determine whether stakeholder needs, customer requirements, product requirements, etc. are feasible, achievable within project budgets, and generally fit within the constraints of the operational environment of the product. This is when informal needs are translated into formal requirements.
Techniques used in analysis and validation can include time-sequenced scenarios to test requirements and derive new ones. Scenarios, often described using UML Activity or Sequence diagrams, are an effective way of eliciting, clarifying and refining requirements.
Required functionality is defined by performing functional analysis to establish a functional architecture. Functional analysis describes what the product is intended to do in terms of actions, sequences, inputs and outputs – anything that describes how the product is to be used. Functional architecture describes logically grouped functions (or services) together with the requirements to be satisfied by each. UML Activity diagrams can describe the required behavior of a product from a workflow perspective and identify which components will be responsible for which parts of the workflow. They are useful for describing the functional analysis and allocating requirements to product-components. Tool support should enable analysis models and textual requirements to be maintained within a single document and enable traceability to be maintained between levels of requirements (whether described textually or graphically using UML).
Process Area: Technical Solution
The Technical Solution Process Area focuses on evaluating and selecting design solutions, performing detailed design, and implementing the solution. So, what does this have to do with requirements management? Organizations must first ensure they continue to develop a solution that meets the requirements. One way is to test the resulting designs to verify that the proposed solution is correct. During this process, organizations may discover that some requirements are not feasible or sufficiently well defined to be implemented. Organizations must allow requirements to continue evolving throughout the design process, while ensuring changes are handled in a controlled manner. Traceability must continue to be maintained between the levels of requirements (customer, product, component, etc.) and between the requirements and the solutions.
All the benefits of developing requirements from stakeholder needs through to product and product-component requirements should be preserved when designing and building the solution. Tool support should enable designers and developers to view the requirements and create and maintain traceability between the requirements and their designs, in order to prove compliance and assess the impact of any changes. Requirements analysts and project managers should have a complete picture of traceability from stakeholder needs right through detailed designs and tests. This allows them to monitor progress against the requirements and ensure all development and testing is done in accordance with the requirements - no more and no less.
For organizations with large and complex product or system development projects, CMMI is an established way to evaluate and improve development processes. There is compelling evidence of its success from major corporations such as Lockheed Martin, Boeing, Northrop Grumman, General Motors and JP Morgan Chase. Effective requirements management and requirements analysis practices are key to achieving CMMI Levels 2 and 3. Comprehensive tool support is essential to help organizations implement best practices like those described by CMMI. By providing integrated support for requirements definition, requirements analysis and traceability throughout the product development lifecycle, organizations can maximize the benefits of these process improvements.
(This article has been edited for magazine publication.)
The Author is Senior Project Manager, Corporate Marketing, Telelogic.