Bi-directional Traceability

Our organization is in the process of preparing for a CMMI Maturity Level 2 SCAMPI A appraisal. We are concerned about our approach for bi-directional traceability REQM SP 1.4. We maintain traceability is follows:

1. High Level Requirements <--> Use Cases (Includes GUIs and Database Interactions) <--> Test Cases

2. Use Cases <--> Source Code

Note: One can trace from Test Cases to Source Code through the Use Cases and Vice Versa, but the traceability is not direct. The reason behind this is, test cases are generated from use cases and are tested against the application (black box testing). Source code does not have associated test cases.

Is this kind of traceability considered bi-directional and is satisfactory for Maturity Level 2?

What you describe is one of many ways to implement bi-directional traceability and meet the intent of the CMMI. If your method supports your business goals and objectives and there are no quality issues, your approach should be acceptable for a Maturity Level 2 appraisal.

It is interesting that you think tracing from Test Cases to Source Code via Use Cases may not be acceptable. Traceability is a multi-dimensional mapping that can have one-to-many and many-to-one relationships. As long as you trace from the top all the way to the bottom and vice versa, you should be fine no matter how many links there are in the chain, and the chain can have branches as well.

Please note that bi-directional traceability does not mean tracing one whole document to another whole document. What it means is that a given item in one document (a specific requirement for example) can trace to multiple items in another document, multiple items in one document can trace to one item in another document, one item can trace to one item, etc.

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.

REQM SP 1.2 Question

Can you please help me?

I am developing a study based on CMMI-DEV and I am having some difficulty with the interpretation of Specific Practice 1.2. My concern is how to apply SP 1.2 in practice. Who are the members of the project that must be committed to the requirements (business analysts, systems analysts, test analysts, developers, systems architects, project manager, and project leader)?

How should their commitment be documented? For example, for each new or changed requirement the members must sign a document that means that they are aware of the requirement and are committed to it.

Do you have a copy of the Addison Wesley published CMMI-DEV version 1.2? If so, there are some very helpful tips in the margins for REQM SP 1.2.

When you have a set of requirements for a project team, everyone on the team impacted by the requirements needs to share a common understanding of the requirements. In addition, since you typically do not have the full set of requirements available at project start, the project team needs to continually evaluate and reevaluate their ability to meet the requirements as the requirements evolve over the life of the project. One way of evaluating requirements is an impact assessment on the existing requirements, design, documents, test cases, current and downstream tasks and activities, cost, schedule, etc. for a new or changed requirement. By going through an impact analysis, that will provide a way for the project participants to communicate their ability to meet the requirements and associated commitments. The resulting impact analysis report can be one way of documenting the commitment. Other methods for documenting commitments include meeting minutes, document signatures, or email. However, just signing a document indicating that the participants are aware of a requirement really does not indicate that they are committed to the requirements and you might run into difficulties later on in the lifecycle.

Please keep in mind that commitments include both the resources involved (people, tools, and facilities) and the schedule for completion.

REQM - SP1.1 Query

In REQM – SP1.1 calls for “Criteria for evaluation and acceptance.” Can you tell me what this expected “criteria” would be?

I suggest looking at Requirements Management (REQM) Process Area in your copy of the CMMI. On page 490 in REQM Sub-practice 2 there is a list of example evaluation and acceptance criteria.

REQM does not expect the organization to have evaluation and acceptance criteria. What you are expected to provide is evidence that support the required components (Specific Goal 1 in this case; evidence that demonstrates that your requirements are managed and inconsistencies with project plans and work products are identified) and evidence that supports the expected components (Specific Practice 1.1 in this case; evidence that demonstrates that you have developed an understanding with the requirements providers on the meaning of the requirements). If your Lead Appraiser is telling you that you have to provide these criteria, then he or she should be challenged as to why they are telling you that you need to provide this evidence.

The evaluation and acceptance criteria are one way of developing this understanding. Please bear in mind the section title is TYPICAL Work Products, not EXPECTED Work Products, or REQUIRED Work Products. The list of Typical Work Products is merely a list of example work products.

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

Upcoming Events of Interest

This Spring has a number of events of interest to readers of the PPQC Blog.

In March 2009, I will be presenting a paper titled Challenges with Implementing the CMMI in Small Settings at the 2009 SEPG North America Conference in San Jose, CA. http://www.sei.cmu.edu/sepgna/2009/

I will be presenting Session ID 2075 on Thursday morning, March 26, 2009. If you will be attending the Conference, please make plans to attend my presentation.


If you can't make it to San Jose in March, perhaps you will be able to attend the CMMI Made Practical conference in London April 28 - 29, 2009. I will be making a presentation titled A Practical Approach to Defining Useful Measures on April 29. http://www.cmminews.com/


And lastly, if all else fails, I will be teaching a public offering the SEI's Introduction to CMMI class, plus PPQC's Overview of Requirements Management in Stuttgart, Germany May 18 - 21, 2009. If you need to take the Introduction to CMMI class to help you implement the model in your organization or if you will be on an appraisal team, here is your opportunity to take the class in Germany's sixth largest city while enjoying its many hills, valleys, and parks in the evening. You can register for this class at PPQC's German partner KT-BITS' web site.

http://www.kt-bits.net/ If you attend one of these events, please be sure to introduce yourself. I certainly look forward to meeting you at one of these events.

Role of the System Architect

Someone sent me the link to this YouTube video that explains the role of the systems architect.

The message given in this video also addresses the need for proper documentation of requirements, Requirements Management, and Requirements Engineering. The video uses simple roles and examples to clearly illustrate these concepts. Plus it is cute and fun to watch. Enjoy!

Developing Questions for the CMMI Specific and Generic Goals Would Lead to Implementing Alternative Practices

I would be very CAUTIOUS about taking this approach to implementing the CMMI. The CMMI authors did not go to the lengths they did with defining the Expected components (Specific and Generic Practices) if all they really wanted an organization to do was start at the Goals and identify the supporting practices. In my experience as a Lead Appraiser, it is only on the rare occasion that I have identified and documented an alternative practice in a SCAMPI. 99.999% of the time, the organization’s practices are aligned with the Expected components. And I assert that the only time an alternative practice comes up is with legacy projects that are years in duration using practices that are no longer state of the art and there is no business value in changing them. For example one of the underlying assumptions of REQM is that an organization is using tools to help manage and control the project’s requirements. But if the original requirements were established before the advent of requirements tools and the organization’s documented process for reviewing and managing requirements was to manually review, trace, and track requirements through meetings and discussions re-deriving the traceability each time and the process works, it is an alternative practice. There is no requirements database, just a requirements document. There is no requirements traceability matrix or requirements tracking system, just the documented requirements and the expertise of the requirements analysts who are highly trained in how to procedurally review, maintain, manage, and control requirements. So it is difficult to evaluate SP 1.1 – 1.5 as FI, but REQM SG 1 is clearly FI.

GP 2.1 Establish an Organizational Policy

This Generic Practice is fairly simple and straightforward, but one that many organizations have difficulties implementing the first time around. The practice states "Establish and maintain an organizational policy for planning and performing the process." What I see many organizations do is write a high level process or procedure as the policy instead of providing the necessary organizational expectations for the process.

One of the underlying principles of the CMMI is the principle of setting goals and objectives. Senior/Executive Management should be setting and clearly communicating the organization's business goals and objectives. The policy required by GP 2.1 is then the place for aligning the quality system with the organization's business goals and objectives.

Another problem I have encountered is that organizations tend to write huge policies when in point of fact, all that is necessary to clearly communicate the organization's policy is a few sentences or a paragraph.

And in an extreme case, I have seen one organization declare that it is their policy for each organizational unit to achieve a specific Maturity Level. This odd policy is very similar to the blog I wrote the other day titled Setting Proper Goals and Objectives. The organization's core business is NOT to achieve a Maturity Level, implement a specific model, or comply with with a specific standard. The organization may need to achieve a specific Maturity Level or comply with a standard in order retain existing business or win new business, but that is not why the organization is in business. The organizational policy writer(s) need to dig a bit deeper and write the policies to be aligned with the organization's actual business goals.

For example, if one of the organization's core business goals and objectives is to deliver high quality products and services to their customers, then each organizational policy should have that focus. Keeping this focus in mind, then an example Requirements Management Policy might look like this:

Organization XYZ is committed to delivering high quality products to its customers by establishing a common understanding between the customer and the project of the customer’s requirements. This policy applies to all XYZ projects that meet one or more of the following criteria:
1. [Project effort is expected to exceed 1000 hours]; OR
2. [Project budget is expected to exceed $250,000]; OR
3. [Project schedule is expected to exceed 6 months].

All projects that satisfy these criteria must follow the Requirements Management Process and ensure that:
1. The requirements are documented.
2. The requirements are reviewed by the managers, and other affected groups.
3. The plans, work products, and activities are changed to be consistent with changes to the requirements.

Senior Management is responsible for:
1. Establishing and ensuring conformance to this policy.
2. Establishing responsibility for analyzing the system requirements and allocating them to hardware, software, and other system components.
3. Providing adequate resources and funding for managing the allocated requirements.
4. Reviewing the activities for managing the allocated requirements on a periodic basis.