Register  |  Login

The biggest hurdle to achieve level 2 is to implement the capability of “bi-directional traceability of requirements”. This is the ability to trace work products to each other and to requirements and visa versa. Without this capability, level 2 and its time/cost benefits cannot be fully achieved. To do this manually is near impossible, and certainly not cost effective – you need a tool.


Bi-directional traceability is needed to track and accurately estimate change impacts. For example (figure below), when you change code, which tests need to be re-run? Or, through requirements linkages - what other requirements, code or documentation is affected? Bi-directional traceability ensures accurate change impact assessment, long term maintainability, and lowers Total Cost of Ownership (TCO).



Say a developer changes a code file, and that code delivers requirement 23. Where in the test scripts is requirement 23 tested? where in the documentation does it occur? In the documentation, if one reads the text near requirement 23, are any other requirements affected? For example requirement 23 may be described in the same paragraph as requirement 47 regarding security; so is the security functionality affected?, where does this occur … and so on.

What if you can’t maintain bi-directional traceability?

If you can’t quickly / accurately find the change impacts, then before long, you’ll notice:


       poor quality,

       significant defects immediately following production release,


       not meeting what has been agreed,



Thus before long you have hard-to-maintain legacy software and escalating total cost of ownership (TCO).

What does the CMMI say?

The CMMI has found that projects that do apply Requirements Management - including bi-directional traceability - show a significant stepped-up improvement in time/cost performance. The research found that, amongst others, the following Specific Practices are exhibited by level 2 projects (verbatim):


2   RQM    SP 1.3  Manage Requirements Changes 
as they evolve during the project

2   RQM    SP 1.4  Maintain Bi-directional Traceability of Requirements 
between requirements, project plans and work products

2   RQM    SP 1.5  Identify Inconsistencies 
between Project Work & Requirements i.e. between the project plans, work products and the requirements


Thus Requirements Management consists of two parts:

       Prioritization – which is about the ability to prioritize requirements in order to deliver the best / maximum agreed outcome within your time/cost constraints;

       Bi-directional traceability – which is about being able to accurately assess and manage the time/cost impacts of change (as shown by these three specific practices).

Why is traceability so difficult to achieve?

What clients and managers often don’t appreciate is that software development involves a huge number of files. Think of the hundreds of code files, test scripts, and tens of documents involved in any medium-sized project. Think of the 100-200 or more, requirements you may have. Think of the dependencies between requirements, like performance requirements impacting a range of functional requirements. How are you going to find the linkages between all of these files to requirements, requirements to requirements and visa versa?


Of course you can do this manually; this is typically what testers do to the extent that they have been allocated time! They get a brightly colored high-lighter and mark each body of text that represent a requirement, scribble a number in the margin, log the requirement, and reference it in their many test files. But it is a huge job, and when requirements change, there is typically no time to manually update everything to keep the entire system consistent. Oh, and who is doing this for the code L?


Clearly, to manage and maintain this web of linkages is a computer job – you need a requirements management and bi-directional traceability tool.

Why don’t organizations just buy tools?

Here is the snag: not many requirements management tools provide bi-directional traceability, and those big name tools that do (like RequisitePro or CaliberRM) are for many cost prohibitive. To gain the benefits everyone in the team must have a copy (the BA, Tester, Architect, Developer, PM). Thus, at list price, for a business unit of 60-70 people this can easily mean US$100-150K in just Requirements Management tools, excluding training, test tools, etc, you still have to buy. Not very palatable for management!

So which tool?

We’ve searched long and hard for a tool which is easy to learn, supports gradual expansion of capability (first prioritization, then linking, then tracing), is non-invasive (i.e. keeps all files loosely coupled, so that you can move and exchange them), and doesn’t break the bank!


Since we couldn’t find one that meets all these criteria, we developed ScopeTracker to have a solution which is affordable for the entire team, and help our clients over the traceability hurdle so that they can achieve level 2 and 3 capability maturity.

What if we can’t trace, but we do manage our requirements?

If you capture and prioritize your requirements, you’ll definitely have time/cost improvement gains, but not as much as with fully fledged level 2 capability maturity which includes bi-directional traceability.


Based on our own data, if all CMMI level 2 processes except bidirectional traceability are applied, there is actually a noticeable improvement in reducing time/cost and time/cost variation. The reason is simple: if you prioritize in agreement with your client, then everyone is informed, there are no surprises, and there is an understanding that you are trying to maximize the best outcome for available time/cost budgets (time is a budget too). 


Hence in the CMMI quick self assessment you’ll notice that we recognize a level 1.5, in case all level 2 capabilities are in place, except for bi-directional traceability. From a strict CMMI perspective there is of course no level 1.5, but from a metrics and improvement perspective, you may find it useful to introduce it in order to measure if basic capabilities do make a difference, and to reward good practice behavior.

So if it is so difficult to achieve, how real is a claim of level 2, 3 or 5?

If someone or a vendor organization is claiming they operate at level 2 or higher here is the test: ask them to explain (show) how requirements are traced (between tests, code and documentation). You’ll very soon know if they have merely passed the auditors, or can actually manage change J !  


Of course, if they use a tool like our ScopeTracker, they may well be applying this capability.



 mail to colleague


Your Rating: 0.0   Average Rating: 0   Ratings: 0
Site Software v2.2.0, 26 Oct 2016