Effective Requirements Management within the CMMI

- By Andy Gurd, Senior Project Manager, Corporate

Marketing, Telelogic

Introduction



This guide provides

recommendations for implementing the tool support that will help organizations

achieve key CMMI levels. 

What's CMMI?



The

Software Engineering Institute's (SEI), Capability Maturity Model Integration (CMMI)i

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 October 2003 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 guide, 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 guide will focus on levels two and three,

the levels

that contain process areas related to requirements

management.

Figure 1: The five staged levels of CMMI

Process

Areas

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.

Figure 2: Process Areas at each CMMI Level

This

guide 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 iii

iv 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

CMMI

says:

“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,

suchas 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

CMMI

says:

“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

CMMI

says:

“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 Consistent

CMMI

says:

“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

CMMI

says:

“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

CMMI

says:

“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

CMMI

says:

“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.

Summary



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.