IntroDEV LC Mod1.3

Introduction to CMMI®
For Development, V1.3

CMMI® Institute
Pittsburgh, PA 15222
Module 1.3: Define and Engineer
the Product
© 2016 CMMI Institute. All rights reserved.

CMMI, the CMMI logo, Data Management Maturity (DMM), and SCAMPI are registered marks of CMMI Institute
© 2016 CMMI® Institute

Introduction to CMMI for Development, V1.3 | Module 1.3 September 2016
DISCLAIMER
THIS MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CMMI INSTITUTE MAKES

NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY
MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR
PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM
USE OF THE MATERIAL. CMMI INSTITUTE DOES NOT MAKE ANY WARRANTY
OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR
COPYRIGHT INFRINGEMENT.
© 2016 CMMI® Institute 2

You are Here
Next, we’ll talk about how you Define and Engineer the Product, which
includes these topics:
• Requirements development (RD)
• PA structure
• Requirements management (REQM)
• Technical solutions (TS)
• Process integration (PI)
Still to come:
• Ensure product success
• Manage and monitor the development
• Make work explicit and measurable
• Manage decisions and suppliers
• Create a culture to sustain excellence

Making CMMI Practices Work for You
Key enablers
• Willingness to learn unfamiliar practices
• Desire to extract value rather than “check the box”
• Ability to interpret CMMI in your context
• Access to experts
Adapted from Hefner, Strategies for Transitioning to CMMI-SVC,

CMMI Technology Conference and User Group, 2009 © 2016 CMMI® Institute 4
Requirements Development (RD) in Brief
Requirements Development (RD):

• RD is about understanding what stakeholders think they need and
documenting that understanding for the people who will be designing
solutions.
• Why do the practices in RD? Because you want clarity among end users,
customers, and solution developers about what is expected from the solution.
In this module, we also discuss the structure of a CMMI PA:

• Process area components
• Specific goals and practices
• Informative components
• Numbering scheme

Requirements Development (RD)
Purpose
Elicit, analyze, and establish customer, product, and product component
requirements.

Relevant Terminology 1 of 2
Allocated Requirement
Requirement that results from levying all or part of a higher level requirement on
a lower level architectural element or design component
Derived Requirements
Requirements that are not explicitly stated in the customer requirements but are
inferred (1) from contextual requirements (e.g., applicable standards, laws,
policies, common practices, management decisions), or (2) from requirements
needed to specify a product or service component
Derived requirements can also arise during analysis and design of
components of the product or service.

Relevant Terminology 2 of 2
Quality Attribute
A property of a product or service by which its quality will be judged by relevant
stakeholders. Quality attributes are characterizable by some appropriate
measure.
Quality attributes are nonfunctional, such as timeliness, throughput,
responsiveness, security, modifiability, reliability, and usability. They have a
significant influence on the architecture.

Requirements Development Goals
SG 1: Develop Customer Requirements

Stakeholder needs, expectations, constraints, and interfaces are collected and
translated into customer requirements.
SG 2: Develop Product Requirements

Coordination and collaboration of relevant stakeholders are conducted.
SG 3: Analyze and Validate Requirements

The requirements are analyzed and validated.
The process area also has generic goals to support institutionalization.

Requirements Development Context
Develop Customer Requirements Develop Product Requirements
SP 1.2 SP 2.1 SP 2.2

Transform SP 2.3
SP 1.1 Establish Product Allocate
Stakeholder and Product Product Identify
Elicit Needs into Component Component Interface
Needs Customer Requirements Requirements Requirements
Requirements
Product, Product
Customer Component, and Interface
Requirements Requirements
Stakeholder
Needs
SP 3.2
SP 3.1 Establish a SP 3.4
Establish Definition of SP 3.3 Analyze SP 3.5
Operational Required Analyze Requirements Validate
Concepts and Functionality Requirements to Achieve Requirements
Scenarios and Quality Balance
Attributes
Analyze and Validate Requirements

Reviewing Process Area Components
PA
Specific Goals (SG) Generic Goals (GG)
Specific Generic LEGEND

Practices Practices
Required
Expected
Generic
Example Work Practice Subpractices
Subpractices
Products Elaborations
Informative
Related
Purpose Introductory
Process
Statement Notes
Areas

Process Area
A cluster of related practices in an area that, when implemented

collectively, satisfies a set of goals considered important for making
improvement in that area.
CMMI-DEV has 22 process areas: 16 core PAs, 1 shared PA with CMMI-

SVC, and 5 engineering-specific PAs.
Each PA follows the same structure and has the same components.

Process Area Contents
All process areas contain the following:

• Purpose
• Introductory notes
• Related process areas
• Specific goal and practice summary
• Specific practices by goal
• Generic practices by goal

Purpose
Describes the purpose of the process area
Requirements Development example:

Purpose
The purpose of Requirements Development (RD) is to elicit, analyze, and
establish customer, product, and product component requirements.

Introductory Notes
This section describes the major concepts covered in the process area.

…these requirements address the needs of relevant stakeholders, including
needs pertinent to various product lifecycle phases and product attributes.

Related Process Areas
This section lists references to related process areas and reflects the
high-level relationships among the process areas.

Refer to the Product Integration process area for more information about
ensuring interface compatibility.

Specific Goal and Practice Summary
The titles of the specific goals and specific practices for that process area
are summarized at the beginning of each process area.

SG 1: Develop Customer Requirements
SP 1.1 Elicit Needs
SP 1.2 Transform Stakeholder Needs into Customer Requirements

Process Area Components
PA
Specific Goals (SG) Generic Goals (GG)
Specific Generic LEGEND

Practices Practices
Required
Expected
Generic
Example Work Subpractices Practice Subpractices
Products Elaborations
Informative
Related
Purpose Introductory
Process
Statement Notes
Areas

Specific Goals (SGs)
A specific goal applies to a process area and describes the unique

characteristics that must be present to satisfy the process area.

SG 1: Stakeholder needs, expectations, constraints, and
interfaces are collected and translated into customer
requirements.
Specific goals are numbered starting with the prefix SG (e.g., SG 1). The
number is only there to uniquely identify the goal.

Specific Practices (SPs)
Specific practices describe the activities expected to result in

achievement of the specific goals of a process area.

SP 2.2: Allocate the requirements for each product component.
Specific practices are of the form SP x.y where

x is the same number as the goal to which the specific practice maps.
y is the sequence number of the specific practice under the specific
goal.

Example Work Products
This section lists sample output from a specific practice.

Example work products are samples of specific practices’ outputs and are
not a complete list.
For example, requirements allocation sheets might be an example work
product for the Requirements Development specific practice SP 2.2,
“Allocate the requirements for each product component.”

Subpractices
Subpractices are detailed descriptions that provide guidance for

interpreting and implementing a specific or generic practice.
The following is an example of a subpractice from the “Identify Interface
Requirements” specific practice (SP 2.3) in the Requirements
Development process area:
1. Identify interfaces both external to the product and internal to the
product (e.g., between functional partitions or objects).

Supporting Informative Components
CMMI models provide further information in the form of the following

components:
• Examples
• References
• Notes

Examples
An example is a component comprising text and often a list of items,

usually in a box, that can accompany any other component and provides
one or more examples to clarify a concept or described activity.
Requirements Development SP 1.1 example:
Example of techniques to elicit needs include the following:
• Technology demonstrations
• Interface control working groups
• Technical control working groups

References
References are pointers to additional or more detailed information in

related process areas and can accompany nearly any other model
component.
Refer to the Requirements Management process area for more
information about managing requirements.

Notes
A note is text that can accompany nearly any other model component. It
may provide detail, background, or rationale.
The example below shows a note that accompanies specific practice 2.1
in the Requirements Development process area.

The customer functional and quality attribute requirements can be
expressed in the customer’s terms and can be nontechnical descriptions.

Glossary
The CMMI glossary defines the basic terms used in CMMI models.
It was designed to document the meaning of words and terms that
should have the widest use and understanding by users of CMMI
products.
Definitions of terms were selected based on recognized sources that
have a widespread readership (e.g., ISO, CMMI source models, IEEE).
Glossary term example:
Establish and maintain
Create, document, use, and revise work products as necessary to ensure that
they remain useful.
The phrase “establish and maintain” plays a special role in communicating a
deeper principle in CMMI.

PAs Have a Consistent Structure
Each PA in CMMI-DEV has the same structure and same components as

those we just examined in RD.
Next, we will look at REQM, followed by TS and PI.

Requirements Management (REQM) in Brief
Requirements Management (REQM):
• REQM is about keeping clear with your customers and other stakeholders
about the products you provide, and adjusting when you find inconsistencies
or mismatched expectations.
• Why do the practices in REQM? Because you and your customers, end users,
and suppliers will be on the same page about your product. You can avoid
customer and user disappointment and increase satisfaction by managing
expectations. When needs change, you’ll know how to adjust your product
development, training, and communication without doing more rework than
necessary.

The Requirements Management and

Requirements Development Partnership
REQM
RD
Compliments of Kasse Initiatives, LLC

Requirements Management (REQM)
Purpose
Manage the requirements of the project’s products and product components and
to ensure alignment between those requirements and the project’s plans and
work products.

Requirements Management Goal
SG 1: Manage Requirements
Requirements are managed and inconsistencies with project plans and work
products are identified.

Relevant Terminology
Requirements traceability
A discernable association between requirements and related requirements,
implementations, and verifications.
Bidirectional traceability
An association among two or more logical entities that is discernable in either
direction (i.e., to and from an entity).

Requirements Management Context
Manage Requirements
SP 1.4 SP 1.5
SP 1.2 SP 1.3
SP 1.1 Maintain Ensure Alignment
Obtain Manage
Understand Bidirectional Between Project
Commitment to Requirements
Requirements Traceability of Work and
Requirements Changes
Requirements Requirements
Requirements Traceability
Matrix

Technical Solution (TS) in Brief
Technical Solution (TS):

• TS is about using effective engineering to design and build solutions that meet
end user needs.
• Why do the practices in TS? Because you increase your confidence that
engineering activities will result in a viable solution.

Technical Solution (TS)
Purpose
Select, design, and implement solutions to requirements. Solutions, designs, and
implementations encompass products, product components, and product related
lifecycle processes either singly or in combinations as appropriate.

Relevant Terminology
Product Related Lifecycle Processes

Processes associated with a product or service throughout one or more phases of
its life (e.g., from conception through disposal), such as manufacturing and
support processes
Sustainment
The processes used to ensure that a product or service remains operational

Technical Solution Goals
SG 1: Select Product Component Solutions

Product or product component solutions are selected from alternative solutions.
SG 2: Develop the Design

Product or product component designs are developed.
SG 3: Implement the Product Design

Product components, and associated support documentation, are implemented
from their designs.

Technical Solution Context
Select Product Component Solutions Implement the Product Design
SP 1.1 SP 1.2 SP 3.2

Develop Select SP 3.1 Develop
Alternative Product Implement Product
Solutions and Component the Design Support
Selection Solutions Documentation
Criteria
Designs Implemented Designs

and Documentation
SP 2.1 SP 2.2 SP 2.3 SP 2.4

Design Establish Design Perform
the Product a Technical Interfaces Make, Buy,
or Product Data Using Criteria or Reuse
Component Package Analyses
Develop the Design

Product Integration (PI) in Brief
Product Integration (PI):

• PI is about putting together all the product components so that the
assembled product has expected behaviors and characteristics.
• Why do the practices in PI? Because you increase your confidence that all the
pieces of the product can work successfully together, you are more sure that
you’re ready for product delivery.

Product Integration (PI)
Purpose
Assemble the product from the product components, ensure that the product, as
integrated, behaves properly (i.e., possesses the required functionality and
quality attributes), and deliver the product.

Product Integration Goals
SG 1: Prepare for Product Integration

Preparation for product integration is conducted.
SG 2: Ensure Interface Compatibility

The product component interfaces, both internal and external, are compatible.
SG 3: Assemble Product Components and Deliver the Product

Verified product components are assembled and the integrated, verified, and
validated product is delivered.

Product Integration Context
Prepare for Product Integration Ensure Interface Compatibility
SP 1.1 SP 1.2 SP 1.3 SP 2.1

Establish Establish Review SP 2.2
Establish Product Integration
the Product Interface Manage
an Integration Integration Procedures and Descriptions for Interfaces
Strategy Environment Criteria Completeness
Integration Strategy,
Procedures, Criteria, Assemblies
and Environment
SP 3.1 SP 3.3 SP 3.4

Confirm SP 3.2 Evaluate Package
Readiness Assemble Assembled and Deliver the
of Product Product Product Product or Product
Components for Components Components Component
Integration
Assemble Product Components and Deliver the Product

Applying Process Areas in the Multiple Layers

of a Product
Engineering process areas are written to support recursion throughout
the product architecture.
This means that the specific practices need to be interpreted according

to the needs of the product.
Engineering process areas can be applied to a product that has several

layers of product components.

Process Area Applicability in a Product

Hierarchy
Process areas can be applied in more than one instance in a product
structure.
Product requirements
exist here.
Product component
requirements exist here.
One person’s product component may be another person’s product.

Summary
We have now discussed the group of PAs that covers many of the
practices for defining, designing, and implementing a product.
Next, we will consider several PAs that have practices for ensuring the
success of product development: VER, VAL, and RSKM.

IntroDEV LC Mod1.3

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

IntroDEV LC Mod1.3

Enviado por

Direitos autorais:

Formatos disponíveis

Introduction to CMMI®

For Development, V1.3

© 2016 CMMI Institute. All rights reserved.

© 2016 CMMI® Institute

THIS MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CMMI INSTITUTE MAKES

© 2016 CMMI® Institute 2

You are Here

© 2016 CMMI® Institute 3

Making CMMI Practices Work for You

Adapted from Hefner, Strategies for Transitioning to CMMI-SVC,

Requirements Development (RD) in Brief

Requirements Development (RD):

In this module, we also discuss the structure of a CMMI PA:

© 2016 CMMI® Institute 5

Requirements Development (RD)

© 2016 CMMI® Institute 6

© 2016 CMMI® Institute 7

© 2016 CMMI® Institute 8

Requirements Development Goals

SG 1: Develop Customer Requirements

SG 2: Develop Product Requirements

SG 3: Analyze and Validate Requirements

The process area also has generic goals to support institutionalization.

© 2016 CMMI® Institute 9

Requirements Development Context

Develop Customer Requirements Develop Product Requirements

SP 1.2 SP 2.1 SP 2.2

Analyze and Validate Requirements

© 2016 CMMI® Institute 10

Reviewing Process Area Components

Specific Goals (SG) Generic Goals (GG)

Specific Generic LEGEND

© 2016 CMMI® Institute 11

A cluster of related practices in an area that, when implemented

CMMI-DEV has 22 process areas: 16 core PAs, 1 shared PA with CMMI-

© 2016 CMMI® Institute 12

Process Area Contents

All process areas contain the following:

© 2016 CMMI® Institute 13

Describes the purpose of the process area

Requirements Development example:

© 2016 CMMI® Institute 14

Requirements Development example:

© 2016 CMMI® Institute 15

Related Process Areas

Requirements Development example:

© 2016 CMMI® Institute 16

Specific Goal and Practice Summary

Requirements Development example:

© 2016 CMMI® Institute 17

Process Area Components

Specific Goals (SG) Generic Goals (GG)

Specific Generic LEGEND

© 2016 CMMI® Institute 18

Specific Goals (SGs)

A specific goal applies to a process area and describes the unique

Requirements Development example:

© 2016 CMMI® Institute 19

Specific Practices (SPs)

Specific practices describe the activities expected to result in

Requirements Development example:

Specific practices are of the form SP x.y where

© 2016 CMMI® Institute 20

Example Work Products