REQM and RD in the CMMI

Why is REQM Management at Maturity Level 2 and Requirement Development at Maturity Level 3? We develop the requirements first and then manage them in the project.

There reason for the placement is due to the meaning of ML 2 vs. ML 3. ML 2 is all about stabilizing projects and gaining control over project estimates. Once the organization has achieved this, then it can begin to evaluate how to improve the engineering areas.

Since you need to have a baseline upon which to plan a project and the other ML 2 Process Areas, that is why REQM is the first Process Area in ML 2. The intent is to manage the collection of project requirements: good, bad, or indifferent. And use this collection to plan the project, etc. Then when you have achieved ML 2 and move to ML 3, then you can address how to improve the Requirements Elicitation to obtain better requirements.

Please keep in mind that the CMMI is a collection of guidelines and best practices for doing process improvement. The CMMI is not a roadmap for how to do software engineering.

CMMI Practices for Documentation Teams

Our organization is CMMI Maturity Level 3 Ver 1.2 certified. Our delivery teams are going to implement CMMI practices soon. I did see the processes of the organization and though all the roles appeared from project leader to developer to manager, except for documentation teams. In the same context, I am very curious to see if there are any set of practices to be followed for the documentation department in CMMI as all the processes at CMMI ML2, ML3 are specific to project management, engineering, support, organization areas.

Your question actually raises some other questions:

1. What are the roles and responsibilities of your documentation teams and documentation department?
2. If this group of people is responsible for the technical documentation (e.g. requirements, design, etc.) and the user documentation, how and why were they excluded from your ML 3 SCAMPI A?
3. How are the delivery teams different from the organization that achieved Maturity Level 3?

What is puzzling with your question is that REQM, RD, TS, PI, and CM cover the different aspects of writing and controlling the various documents associated with designing, developing, maintaining, operating, using, and deploying products. And then VER covers the inspection/review of the documents before placing them in the baseline and controlling them with CM.

It does appear from your description that your organization omitted the documentation people as a process role from your process documentation. In my opinion, at a minimum, your PPQA audits should have identified this omission long before your SCAMPI A appraisal. Then your Lead Appraiser should have identified this gap during the appraisal planning process before the SCAMPI A and should have taken steps to address the gap or postponed your appraisal until the documentation group was included in the scope. Since your documentation group was apparently not included in the scope of your appraisal, this oversight also calls into question your Lead Appraiser’s credentials and quite possibly the validity of your SCAMPI A results.

The bottom line, in my opinion, and based on only what you stated, your documentation group should have been included in the scope of your ML 3 SCAMPI A. Even if all they do is Document Configuration Control (which would be covered under CM) or Document Quality Assurance (which would be covered under PPQA).

The answers to my above questions could provide additional information that would change my opinion.

Requirements Development/Management Question

I was slightly confused after reading this statement in the Requirements Development (RD) Process Area (PA), Specific Practice (SP) 2.1 states "Establish and maintain product and product component requirements, which are based on the customer requirements"

The informative material goes on to say "The modification of requirements due to approved requirement changes is covered by the "maintain" function of this specific practice; whereas, the administration of requirement changes is covered by the Requirements Management process area."

I do not understand the difference between maintenance of requirements in RD and administration of requirement changes in REQM. How are they different?

The Requirements Management (REQM) Process Area (PA) is there to help an organization manage changes to an agreed to set of requirements (baseline). So, no one makes any changes to the requirements (add/modify/delete) without following the documented requirements change control process, which should include review and approval by the relevant stakeholders of the requirements.

And actually, REQM is a specific instance of Configuration Management (CM). But REQM is such an important and vital practice that it is its own Process Area. So it is entirely possible for an organization to have one Change Management process that it uses to manage changes to requirements, documents, plans, test scripts, code, etc.

In contrast the intent of Requirements Development (RD) is to actively elicit and further refine the requirements that are then agreed to and incorporated into the requirements baseline. Specific Practice 2.1 contains the phrase “establish and maintain,” which has a special meaning within the context of the CMMI. If you have taken the Introduction to CMMI class you would have learned what this phrase means. This phrase is also defined in the CMMI Glossary and it means formulate, document, and use. For SP 2.1, this means that the product and product component requirements are formulated (elicited, discussed, refined, reviewed, etc.), documented (written down in a requirements specification, requirements management tool, etc.), and used (develop the project plan, design, code, tests, etc.).

So the connection between REQM and RD is that proposed requirements changes are reviewed, analyzed, approved, and processed by REQM and the authorized and approved changes are propagated through the baselined requirements by RD.

I would not get too focused on trying to understand the separation between REQM and RD. You have identified one of the many areas in the CMMI where there is a tight coupling between PAs, if not overlap. What is important is that you

1. create a requirements baseline that does not change unless there is an approved change request,
2. investigate, impact, review, and disposition all proposed requirements changes with the relevant stakeholders (approved or rejected), and
3. only make approved changes to the baselined requirements and appropriately update the traceability

Quantify Functionality - RD Process Area

Sub-practice 1 of Requirements Development SP 3.2 states " Analyze and quantify functionality required by end users". What does quantifying functionality mean? Does it refer to quality characteristics of functionality or does it refer to Function Point estimation?

What quantify means in this sub-practice is to spell out the required functionality requirements so everyone is in agreement, as well as state exactly how many functionality requirements there are. And since this is a sub-practice, this is an informative component of the model and it is supplied for clarification of the intent of the practice statement “Establish and maintain a definition of required functionality.” If you are implementing RD in your organization, you are not required to implement the sub-practices. You need to do what makes good business sense for your organization in order to determine the definition of the required functionality.

Applicability of Requirements Development (RD)

Is Requirements Development (RD) applicable for maintenance projects?

If the CMMI-DEV is applicable to your maintenance projects, then the short answer is YES!

Definition of SOW

I would like to know what is the content of the Statement of Work and how does this document meet requirements of the CMMI?

As a best practice with definition questions, the first place to look is the CMMI Glossary. In this case there is a definition of Statement of Work (SOW) in the Glossary. “A description of contracted work required to complete a project.” In other words, the SOW contains the requirements for what you have to delivery to the customer. And there are varying levels of detail from SOW to SOW depending on the size, criticality, and nature of the work. For large government contracts, the SOW may also contain the Work Breakdown Structure (WBS) for the program/project as well. At a minimum, the SOW will contain the customer’s requirements that the organization will further develop. So the SOW supports RD and may also support PP.

Trying to Understand the Differences Between RD SP 2.1 and SP 2.2

I have difficulties understanding the difference between Product Requirements and Product Component Requirements. For me Product Requirements are when I have documented the customer needs and I have performed the next step, interpreting and writing the technical requirements in tree categories, functional, non functional, interface. But what happens with Product Component Requirements? In which category do they apply? When in the project lifecycle do I have to describe this kind of requirement? Is it in design while the developers are writing code and they discover that something is missing? And then in SP2.2 "Allocate product component requirements", I cannot figure out what kind of allocation the CMMI refers to.


The intent of Requirements Development (RD) Specific Goal 2 (SG 2) is to refine and further elaborate on the customer requirements. If you think of the customer requirements being at 50,000 feet, SG 2 is adding the information necessary to bring you down to 10,000 feet. Still pretty high level, but with some detail now.

As I always recommend to people who have model interpretation questions, the first place you should consult is the CMMI Glossary. If you look in the Glossary you will find definitions for product component and product component requirements.

Product Component – In the CMMI Product Suite, a work product that is a lower level component of the product. Product components are integrated to produce the product. There may be multiple levels of product components.

Product Component Requirements – A complete specification of a product component, including fit, form, function, performance, and any other requirement.

Here is an illustrative example to help you better understand the concept of a product component. Let’s consider a mechanical alarm clock. The clock consists of several parts or components: clock face and hands, gears and levers, alarm bell, setting levers/buttons, and a clock housing. There may be others, but these will do for now. Each of these parts is a separate clock component with associated detailed requirements.

So when you consider a software system at a high level, it breaks down into one or more components. And it is possible for each component to further break down into sub-components. This concept is easy to understand for new development. For the maintenance case, you may only be receiving requirements for one component. So it may not be immediately obvious what the difference is between a product and a product component requirement.

Product component requirements apply throughout the lifecycle. However, you are more likely to encounter them in the early phases.

Specific Practice 2.2 “Allocate the requirements for each product component.” If you have a copy of the CMMI book, there are some helpful hints in the margin that should clarify what is meant by this practice. The intent of this practice is to ensure that the requirements for each product component are correctly specified (allocated). At this point in the lifecycle you aren’t addressing implementation, that will be at the 5 foot level. So at the product component level, you may have a mixture of hardware requirements, software requirements, performance requirements, operational requirements, etc. The intent of SP 2.2 is to allocate these different requirements to the proper component so you don’t implement a hardware requirement in software or vice versa by mistake. And once again, in the sustaining maintenance environment, when you receive new requirements, they may have already been allocated for you. So the distinction is not immediately obvious.

Does "interface" in CMMI include user interface ?

In interpreting RD SP2.3 "Identify interface requirements", someone told me that the interfaces can also include man-machine interface, or so-called user interface. But the model says "Interface between functions (or between objects) are identified", at first, I thought that the definition of "interface" in CMMI does not include user interface. But however, in some software development methodologies (e.g. object-oriented), the users are also considered as objects, so, maybe user-interface is also a kind of interface? The same question is also in TS SP2.3 "Design interfaces using criteria", PI SP 2.1 "Review interface descriptions for completeness", and PI SP2.2 "Manage interface."

The interface requirements referred to in Requirements Development (RD) Specific Practice (SP) 2.3, Technical Solution (TS) SP 2.3, and Product Integration (PI) SP2.1 and 2.2 cover ALL interfaces. Keep in mind that you have to do whatever is right for your organization and your projects. If the user interface is important to your project and product, then it should be included in the interfaces covered by the referenced SPs.

Interpreting RD SP 1.2

Please help me understand Requirments Development (RD) Specific Practice (SP) 1.2 Develop the Customer Requirements. The Typical Work Products listed for this practice are

1. Customer requirements
2. Customer constraints on the conduct of verification
3. Customer constraints on the conduct of validation

How are work products 2 and 3 different from the first work product?

The expected component for SP 1.2 is “Transform stakeholder needs, expectations, constraints, and interfaces into customer requirements.” There are many different ways to accomplish this Specific Practice as well as there are many different work products that will be created by accomplishing this SP. Your question is regarding the list of Typical Work Products. Typical Work Products are part of the Informative Component and are NEITHER required NOR expected. They are provided to give you some idea or hint, if you need it, as to what types of work product(s) result from transforming needs etc. into customer requirements.

Customer requirements are the most obvious output or work product from this SP. The other two may only be evident or applicable when providing a custom-built product. In this situation the customer may be placing some restrictions on how you perform verification and/or validation. Possibly on the use of certain test facilities, use of certain test data, etc. The specific constraints would be specified by the customer and/or be the result of requirements analysis.

In my opinion, it is not that important to be concerned about the second and third items in the list of Typical Work Products. What is important is performing the practice and creating the list of customer requirements. The proper performance of this practice will determine what the true work products are for your organization. And, in point of fact, you may end up calling all three examples of Typical Work Products “customer requirements.”