6 April 2011

IIBA says Requirements Traceability is optional?

The BABOK says this about Requirements Traceability;
"Determine whether and how to trace requirements based on the complexity of the domain, the number of views of requirements that will be produced, potential impacts from risk, and an understanding of the costs and benefits involved. Tracing requirements adds considerable overhead to business analysis work and must be done correctly and consistently to add value."  (Section, BABOK version 2.0)
I'm the most low doc guy you can get and still get a quality outcome and this is a clanger for me.  Requirements traceability MUST ALWAYS be done in one format or another on any project that warrants the name "project."

Traceability is an umbrella term for a number of auditing activities on requirements as they pass from concept to fulfilled, and one day potentially retired.  Here is what decent traceability auditing can do for you;

  • Maintain a focus on the mission of the project; if a requirement is not aligned to project goals, and is being shoehorned in by a stakeholder with a local agenda up-line traceability will give you a clear sign that there is an issue and a tool to defend your scope from the potentially contentions issue.
  • Monitor solution progress against goals; Traceability gives you the ability to monitor the progressive completion of requirements independent on the project management plan.  Traceability only measures things in black and white states of done, and not done.  You can choose in your local context what done means (So you could have testing layers as increments if you want.)  This gives you a real view of project progress and potential issues that another measurement model - say estimated effort expended/to go does not provide.

Now those two issues are enough along to afford them a seat at the Things you Must Do table.  But they also allow other benefits such as the ability to monitor cross team or feature dependencies, to spot when requirements are not sufficiently tested, and in my "Enterprise context" to help manage scope fallout - where the solution is going to fall short and so business process workarounds are going to be required.

Requirements Traceability is a MANDATORY activity in all serious projects.

Any questions?


  1. Hi Craig,

    This is where I have to point out that the BABOK Guide describes "generally accepted" business analysis practices. Traceability is not a universally accepted practice in all business analysis contexts.

    It's one of the challenges of writing a standard like the BABOK Guide--it's not about what I or anyone else on the team believe to be true, or how we do our work, but rather what we can confirm is being done.

  2. I hear you Kevin, but I think in this instance you guys should have forced the issue a little.

    Also, generally accepted by whom? High performing organizations? Academia? The people on the BABOK committee?

    This one is an area for improvement.

  3. I've struggled a LOT with this idea of traceability; mostly in what exactly it means. I talk with colleagues who create massive traceability matrices that map corporate goals to project scope to functional requirements to design to test cases and back up. I see these beautiful documents and ask, exactly how again does this add value?

    What I've done is a lot less documentation and a lot more process. First, I've been fortunate enough to work for companies who do projects only that are (at least on paper) in the company's best interest. The stated goals of my projects always align with corporate goals. Its my job as an analyst to ensure that the project requirements stay within the scope of the project charter. That's alignment back.

    When the technical team creates a design, I verify that matches with the requirements. I then flip over to the other half of my job, as a QA manager, and have my testers create test scripts based on the requirements and the design. Their test scenarios must cover every item in those previous two documents.

    So, in the end, we achieve traceability, we just do it without some over complicated, unwieldy document. If your job is to create said traceability matrix, and it works for your organization, great. Don't let my experience and methods stop you; but I do recommend asking yourself if that huge document is really worth the effort.

  4. Ted, I see you performing traceability there. And your focused (privately owned?) company means it's easy for most projects to maintain alignment with org goals.

    But what about scope boundary issues and prioritizing scarce resources?

    As for traceability, it sounds like you are doing it. Creating an unwieldy doc/spreadsheet is busywork. The fundamental purpose of a traceability document is;

    a) A checklist to help you think through complexity, and
    b) A baseline for a conversation with your partners and stakeholders.

  5. We're a public company, but because we franchise, most of the key players are right in the building with me. Its convenient and because we know each other, we can work (a lot of the time anyway) without a lot of heavy documentation.

    This is the smallest company I've worked for though and neither of the two larger (one a Fortune 400 and another a Fortune 200) did I ever do a formal traceability matrix, either.

    For scope boundary, I was generally doing system replacement or upgrade projects, so the scope was predefined. For my current company, we develop our own applications internally, so scope is whatever the release manager and sponsor say it is. :)

    Prioritization I can tell you about though! We fully staff (or as fully as possible in a lean organization) each project, knock it out and move on to the next. Which project is in focus is set by the executive advisory committee and we tackle them in their desired order, or we work to change their mind on why a different order would be better. Simplistic, but it does work for us.

  6. Craig,

    Generally accepted by the BA community. Survey data, plus feedback from experts and practitioners, made it clear that not all business analysts agree that traceability is valuable. Talk to Scott Ambler about it sometime, for instance. ;-)

    Also, the concept doesn't even exist in all BA domains. It doesn't really exist in a meaningful sense in continuous improvement efforts, for example. So I think "whether" is correct in this case.