BA Team: Product Ownership, Analysis, and Solution Design BA Bi-Weekly Mini-meeting June 2, 2011

1. 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…

2. 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.

3. 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…

4. 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

5. 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…

6. 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.

7. 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. 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… 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 Refer to User Story Training .ppt *Ron Jeffries

8. 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)

9. 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.)

10. 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!