Download A Requirements Traceability Matrix is

BA Team:
Product Ownership,
Analysis, and
Solution Design
BA Bi-Weekly
Mini-meeting
June 2, 2011
06-2011
Traceability Matrices
Tracking Requirements, User Stories, Use Cases…
Requirements Traceability Matrix (RTM)
A Requirements Traceability Matrix is created by associating solution
requirements with other associated work products that satisfy or relate to
those requirements.
Requirements Traceability Matrix (RTM)
Any number of work products (requirements related) may need to be accounted for in a
traceability matrix. The type of matrix you build will depend on the number of items you
are linking. The effectiveness of the matrix depends on having at least 1 “hinge” work
product, for which the matrix shows how other work products relate. Usually
requirements are being linked to related work products, such as user stories or defects.
(it is easy, on a single matrix, to show a 1:1 or 1:many relationship, more difficult to show a
many:many relationship) Before formatting a matrix, think about all requirements-related “products”
on your project, and what really needs to be traced…
RTM: Requirements Traceability Matrix
RTMs may be required on any project, and are a best practice for all projects. Often, RTMs are
generated and owned by the testing or QA organization, whose sole job it is to account for the quality of
what is delivered against what has been defined/promised. They are often Excel documents.
Whether the BA owns the RTM or not, traceability is still a key consideration in requirements
management. Traceability may need to go forward (requirements to work products) or backward (work
products back to requirements). Done both ways = bi-directional traceability…
Forward Traceability
Backward Traceability
RTM – Setting the Stage for Success
Setting up a project to support an RTM
Before a manageable RTM can be implemented as part of a project’s deliverables
(or testing tools), there are a few things BAs need to do to make sure a project is
set up for RTM success:
• Requirements must be numbered with unique numbers (identifiers), that won’t change. (Our
SRS template is numbered.) For cases where we deliver a “signed” up-front document, once
signed, this is not difficult since no-one should be adding items to the SRS.
• Items related to Requirements must have unique identifiers or numbers. This means:
• User Stories in RTC, once published or approved by the customer, should always keep
the same RTC number. (Don’t re-use RTC story numbers – just close bad stories).
• Use Cases, if part of your project, have unique identifiers/numbers.
• Defects need unique identifiers.
• Test cases need unique identifiers.
• Requirements need to be high-quality. Ambiguous requirements are difficult to implement, and
more difficult to trace to actual implemented functionality.
• Traceability expectations need to be understood (and an approach designed) up front,
because going back and imposing traceability can be PAINFUL…
Using RTC to our advantage…
RTC can be used to produce a User Story to SRS RTM
If you know that you want to map user stories back to items in a requirements document
or to their source (not necessarily the other way around) an RTC query can be used. To
use this approach, you simply enter the SRS Requirement Unique ID (number) into the
XRef field of each decomposed User Story. This field was added to RTC expressly to
created traceability back to a User Story’s source.
Remember this easy way to ensure a 1:1 Mapping
User Story + Acceptance Criteria =
Functional Requirement with slightly
different syntax.
While many customers require some type of
requirements document, and may even provide a
template, most don’t dictate the syntax with which a
“requirement” is written.
As an Online Customer user I can select multiple
toppings for either or both halves of my pizza so
that I can order a specialized pizza of my liking
independently.
Details (Acceptance Criteria):
Scenario 1:
When the user selects (clicks box next to)
one of the following items from the toppings
list:
Then:
1 – the check box displays as “checked”
2 – the flash pizza image displays the
select topping on the entire pizza within 1
second
3 – the whole pizza check box in the
adjacent column is selected by default
Scenario 2:
When the user clicks the ½ pizza check box
in the column adjacent to the select topping
It is very easy to forgo the traditional “the system
shall” and use the syntax of the User Story
description (which will make more sense to most
readers anyway) and then provide the acceptance
criteria as “details”.
Done this way, there will always be a 1:1 relationship
between the SRS and User Stories for the purposes
of an RTM…
You can also add an RTC Ref column in the SRS to
handle the mapping…
Refer to User Story Training .ppt
*Ron Jeffrie
Using RTC to our advantage…
RTC can be used to product a User Story to SRS RTM
Once an XRef is included for each story that lists the number or identifier for the
SRS/FRS requirement, a Query can be built that includes the User Story ID, Description,
the XRef, and any other pertinent traceability information.
(RTC = Project > Work Items > My Queries > right click New Query > Result Layout > Selected Columns)
Using RTC to our advantage…
RTC can be used to product a User Story to SRS RTM
Below is an example of a Query in RTC that lists, by column, a User Story ID, the SRS
Reference (XRef), and the Summary.
*Note that in some XRef
fields there are other values,
such as “implied”, or n/a.
These values exist because
in Agile projects, we don’t
typically hold ourselves to
only building what is in a
requirements document, at
other times the document
was vague (thus “implied”
requirements). This means
the XRef provides
traceability to the SOURCE
of the User Story, which can
be multiple values (SRS,
SME session, etc.)
Requirements Traceability Matrices
Summary
Key points to remember…
• Traceability is always a good idea.
• Traceability requires unique identifiers for all requirements
and related work items.
• Traceability should be considered up-front, so that
requirements can be approached in a certain manner from a
project’s onset.
• Use RTC to your advantage!