Could you please help us to understand the following terms.
- Vertical traceability
- Horizontal traceability
- Bi-Directional traceability
Which of Vertical & Horizontal is mandatory ?
Ah, the 'ol "bi-directional traceability question!" This one is a topic of much discussion at Lead Appraiser geek fests, and most people have there own particular spin on it. Here's mine.
Traceability helps us to understand the relationships between work products, whether they be requirements, code, designs, tests, or others, and helps ensure that those relationships have integrity.
For Requirements, traceability helps us to understand the link between the elicited customer need and the product, sub-product, and test (VER) requirements (often a 1:many relationship). The ability to start "at the top" and trace it all the way to the many test cases, or start at a single test case (or sub product requirement) and trace it "up to the top" is what we call "bi-directional traceability." This is also an example of vertical traceability and is also what is implied by "requirements traceability" in the CMMI.
If you're a software engineer it helps to think of these relationships as an object model. A master object has below it many others that directly support it and inherit its attributes and behaviors, and these can all be traced together as part of the object model taxonomy. The same goes for requirements.
Horizontal traceability is less common (although equally important), and applies to the tracing of functionality across multiple related components, such as interfaces or data access components, and helps to enable more effective integration testing, troubleshooting, and implementation.
Most seem to agree that vertical traceability is what REQM.SP1.4 is all about (in its bi-directional form) and that horizontal traceability, though valuable, is not specifically expected by the CMMI.
http://www.broadswordsolutions.com/
Showing posts with label REQM Traceability. Show all posts
Showing posts with label REQM Traceability. Show all posts
Tuesday, January 1, 2008
Tuesday, August 7, 2007
Some REQM Practices seem complex if done properly. Can you provide some practicle examples?
Can you explain following two REQM practices with some practical examples?
- Identify inconsistencies between the project plans and work products and the requirements
- Establish and maintain an organizational policy for planning and performing the requirements management process
Sure! Practical examples is what this 'blog is all about.
I'll start with the last first. Your question appears to be about REQM.GP2.1 "Establish an Organizational Policy." Let's start with a question: "what's an organizational policy?" According to the CMMI, an OP is: "A guiding principle typically established by senior management that is adopted by an organization to influence and determine decisions." To put it more simply, it's management's expectations for performing a process.
My advice to you here is to keep it simple and not use your policy to describe the process. You will probably be going through an exercise to define a Requirements Management process, so there is no need to be redundant within the policy. A simple documented policy that sets management's expectations is sufficient.
"All employees are required to read, understand, and follow the REQM process as defined in the process guide."
Of course, there needs to be a process guide for this to be valid, and a valid REQM process as well to point to.
The second part of the practice refers to "maintaining" the policy. This implies a cyclical review of all policies, and updating or changing it as appropriate (keeping it all under CM of course!)
You first question refers to REQM SP1.5 Identify Inconsistencies Between Project Work and Requirements. What could this possibly mean, and whose job is it?
To begin with, we can think about this practice as part of PMC because it is clearly a project management activity. It involves keeping up to date on all of the latest requirements changes, and ensuring that the tasks being performed by the project team reflects the latest approved requirements set.
Imagine a large scale project with dozens of developers who are each assigned a set of requirements or features to implement. They may not be involved in all of the meetings and approvals for new or changed requirements. How does the PM ensure that, as requirements change, the developers are working on the latest and greatest requirements set? How do we avoid having them work on the old requirements, or when the requirements have changed to something different?
The place to manage this, IMHO, is in the traceability matrix. This tool can quickly identify who is working on what code and gives the PM a way to rapidly determine what work needs to be halted, modified, or added.
www.broadswordsolutions.com
- Identify inconsistencies between the project plans and work products and the requirements
- Establish and maintain an organizational policy for planning and performing the requirements management process
Sure! Practical examples is what this 'blog is all about.
I'll start with the last first. Your question appears to be about REQM.GP2.1 "Establish an Organizational Policy." Let's start with a question: "what's an organizational policy?" According to the CMMI, an OP is: "A guiding principle typically established by senior management that is adopted by an organization to influence and determine decisions." To put it more simply, it's management's expectations for performing a process.
My advice to you here is to keep it simple and not use your policy to describe the process. You will probably be going through an exercise to define a Requirements Management process, so there is no need to be redundant within the policy. A simple documented policy that sets management's expectations is sufficient.
"All employees are required to read, understand, and follow the REQM process as defined in the process guide."
Of course, there needs to be a process guide for this to be valid, and a valid REQM process as well to point to.
The second part of the practice refers to "maintaining" the policy. This implies a cyclical review of all policies, and updating or changing it as appropriate (keeping it all under CM of course!)
You first question refers to REQM SP1.5 Identify Inconsistencies Between Project Work and Requirements. What could this possibly mean, and whose job is it?
To begin with, we can think about this practice as part of PMC because it is clearly a project management activity. It involves keeping up to date on all of the latest requirements changes, and ensuring that the tasks being performed by the project team reflects the latest approved requirements set.
Imagine a large scale project with dozens of developers who are each assigned a set of requirements or features to implement. They may not be involved in all of the meetings and approvals for new or changed requirements. How does the PM ensure that, as requirements change, the developers are working on the latest and greatest requirements set? How do we avoid having them work on the old requirements, or when the requirements have changed to something different?
The place to manage this, IMHO, is in the traceability matrix. This tool can quickly identify who is working on what code and gives the PM a way to rapidly determine what work needs to be halted, modified, or added.
www.broadswordsolutions.com
Subscribe to:
Posts (Atom)