Terminology
This topic contains questions and answers about the terminology used in CMMI products.
Contents:
- How are CMMI models and constellations named?
- What is the difference between a "stakeholder" and a "relevant stakeholder"?
- What is bidirectional traceability?
- When using a CMMI model for process improvement, is the use of functional analysis problematic for an object oriented approach?
How are CMMI models and constellations named?
Each CMMI constellation is given a name by the CMMI Product Team, which is then approved by the CMMI Steering Group.
The name of each model produced by a constellation consists of "CMMI" and the constellation name, followed by the names of the group of additions included. For example, a model in the Development constellation that does not have a group of additions is named CMMI for Development or CMMI-DEV. If the model has the IPPD group of additions, its name will be CMMI for Development +IPPD or CMMI-DEV +IPPD.
return to top
What is the difference between a "stakeholder" and a "relevant stakeholder"?
The term "stakeholder" is defined in CMMI models as
a group or individual who is affected by or is in some way accountable for the outcome of an undertaking.
The term "relevant stakeholder" is a subset of the term "stakeholder" and describes people or roles that are designated in a plan for stakeholder involvement.
Since "stakeholder" may describe a very large number of people, a lot of time and effort would be consumed by attempting to deal with all of them. For this reason, "relevant stakeholder" is used in most practice statements to describe the people identified to contribute to a specific task.
return to topWhat is bidirectional traceability?
In the Requirements Management (REQM) process area, specific practice 1.4 states, "Maintain bidirectional traceability among the requirements and work products." Bidirectional traceability is the ability to trace both forward and backward (i.e., from requirements to end products and from end product back to requirements).
Typically, traceability identifies the origin of items (e.g., customer needs) and follows these same items as they travel through the hierarchy of the Work Breakdown Structure to the project teams and eventually to the customer. When the requirements are managed well, bidirectional traceability is achieved from the source requirements to lower-level requirements and selected work products and verifications and then back to their source. Such bidirectional traceability helps determine that all source requirements have been completely addressed and that all lower level requirements and selected work products can be traced to a valid source.
return to topWhen using a CMMI model for process improvement, is the use of functional analysis problematic for an object oriented approach?
The term "functional analysis" was used in CMMI to be universally applicable, and there is no intention to exclude an object oriented approach. In Requirements Development, specific practice 3.2, it says
The definition of functionality, also referred to as "functional analysis," is the description of what the product is intended to do. The definition of functionality can include actions, sequence, inputs, outputs, or other information that communicates the manner in which the product will be used.
return to topFunctional analysis is not the same as structured analysis in software development and does not presume a functionally oriented software design. In object-oriented software design, it relates to defining what are called "services" or "methods." The definition of functions, their logical groupings, and their association with requirements is referred to as a functional architecture.
If you have a question that is not answered within this FAQ, check the CMMI FAQ Main Page or send email to an SEI person at cmmi-comments@sei.cmu.edu. You will receive a response within 48 hours.