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.