Would you please explain to me the meaning of bi-directional traceability? If I am not wrong, Horizontal Traceability indicates mapping of a requirement across all the SDLC phases like Requirement->Design->Construction->Testing. But I do not get what is meant by Vertical Traceability. Would you please educate me on this?
Vertical traceability is top-down bottom-up traceability. Vertical traceability is the most common type of traceability. Basically it is tracing from the highest level requirements all the way down to the product component level (could be even to a specific line of code). And then starting at the lowest level and tracing all the way back up to the top. Horizontal traceability is tracing within a document or between peer documents. What you have listed as tracing from requirements to design to construction to test is actually vertical traceability. And when you come right down to it, it doesn’t really matter what type of traceability you label it. All that matters is that you can trace forward from a starting point to an end point and vice versa. The level and complexity of the traceability is determined by the criticality of the product and project. For a program like the Space Shuttle or Space Station, you would need very rigorous requirements traceability. Whereas a small application or a product would only need some simple traceability.
Showing posts with label requirements traceability. Show all posts
Showing posts with label requirements traceability. Show all posts
Monday, October 19, 2009
Tuesday, August 4, 2009
Requirements Traceability, To What Level?
It certainly makes sense to include relations between requirements and source code in the requirements traceability matrix. If requirements change, we've a direct view on the impact on source level. But can this be managed and maintained, even with a tool? Is it wortwhile to put a huge effort in maintaining relations between requirements and the source code? Isn't it sufficient to define these relations at the level of design elements and user acceptance test cases? In this case, we've a means to verify that each requirement is covered by design and test. I believe this strongly reduces the risk of uncovered requirements in the final delivery, which is one of the main purposes of requirements traceability.
The answer is, you do whatever is necessary to meet your business goals and objectives. It depends upon the criticality of the product or service you are delivering. If your product is highly complex and someone could lose their life if there was a missed requirement, then it is necessary to put a huge amount of effort into requirements traceability. Just consider the Space Shuttle program, the amount of requirements etc. The Space Shuttle software is as close to zero defects as you will ever find. And at the other end of the spectrum, you would be justified limiting the amount of effort for traceability.
The answer is, you do whatever is necessary to meet your business goals and objectives. It depends upon the criticality of the product or service you are delivering. If your product is highly complex and someone could lose their life if there was a missed requirement, then it is necessary to put a huge amount of effort into requirements traceability. Just consider the Space Shuttle program, the amount of requirements etc. The Space Shuttle software is as close to zero defects as you will ever find. And at the other end of the spectrum, you would be justified limiting the amount of effort for traceability.
Subscribe to:
Posts (Atom)