Requirements Traceability: Planning, Tracking and Managing Requirements Presenter: Paula R. Maychruk, BV/TEd., CAPM, CBAP

Key Learning Points Describe requirement attributes, and how they can assist with requirements planning and prioritization (PLANNING) Understand how to trace requirements from planning, through design and development, and on into the testing and implementation phases of a project/product (TRACKING) Recognize how requirements traceability can facilitate requirements change (MANAGING)

Session Agenda Planning (and Prioritizing) Requirements “Setting up for Traceability” Tracking Requirements “Traceability in Action” Managing Requirements “The Power of Traceability”

Traceability, Defined Links downstream work products to the purpose for which they were created Provides a process to confirm that the Requirements Elicitation process is complete Ensures that project work is not authorized for items that are outside of project scope Enables stakeholder notification during the change management process Increases quality on all project sizes and types Facilitates the requirements change control process BABOK, Version 1.6, Page 131

The PLANNING Process 1.Identify the business problem 2.Drill down to the business needs/wants 3.Create a detailed scope list 4.Set initial business priorities and assess overall business risk 5.Determine what the high- to mid-level business requirements are (feature list) 6.Assign requirements attributes

The PLANNING Process – continued 7.Set priorities (based on both business and technical attributes) 8.Begin defining high-level estimates 9.Refine scope of the project; re-prioritize (if necessary) 10.Once final scope is set, begin documenting detailed requirements (including NFRs) 11.Control requirements change

Where Does Traceability Begin? Start with Business Needs/Wants Start with Scope Start with High-Level Business Requirements Start with Product Features Requirements Attributes

Traceability in the BABOK BABOK, Version 1.6, Page 132 User Needs High-Level Product Desc Trace Enterprise Analysis BRD Supp Specs Test Case Trace Requirements Gathering & Analysis Test Period Design Artifact Design & Construction Trace

Requirements Numbering Unique numeric and/or textual identifier (R1, R2, etc.) Can use prefix to differentiate between Functional and Non- Functional requirements (F1, F2 and N1, N2, etc.) No rules, except no duplicates Absolute reference – not to be altered or re-used if the requirement is moved, changed or deleted

Requirements Attributes – BABOK Definitions “Requirements attributes provide information about the requirement…” “The information documented by the attributes helps the team efficiently and effectively make tradeoffs between requirements… understanding the impact of a proposed change.” BABOK, Version 1.6, Page 203

Types of Attributes (Examples) Requirement ID Version Owner Source Status Risk Complexity Stability Priority Author Use Case Xref Dependencies Test Case Xref

Prioritizing Requirements Using Requirement Attributes High risk items should be implemented first, but only if high stability High complexity items should be implemented first, but only if medium-low risk Ranking adjusted based on business/technical priority Using Agile Methodology Start with items of technical/architectural significance

Calculating Requirements Priority Risk * Complexity * Stability * Priority = Calculated Rating Risk (H = 5, M = 3, L = 1) Complexity (H = 5, M = 3, L = 1) Stability (H = 1, M = 3, L = 5) Priority (H = 5, M = 3, L = 1) Scoring Highest Point Value = 625 Lowest Point Value = 1

Requirements Cross-Referencing Types of Requirements Xrefs: High-level business requirements or features Use Cases or User Stories (detailed requirements) Supplementary Specifications (NFRs) Design elements Development components Test scenarios, test cases

The TRACKING Process Tracing requirements through: Requirements Planning Solution Design Software Development (Coding) System Testing Implementation

Traceability Matrix – Part 1

Traceability Matrix – Part 2

Traceability and the BRD BRD = detailed requirements For a large BRD, issue amendments If design is in progress, issue amendments If design is finished, updated detailed design doc (development) and the BRD (testing) Use Cases – separate documents with overall index (easier to update and maintain) Requirements versioning

Implementation All requirements should now be marked “complete” Validate that all requirements were met Validate that all business objectives were met Metrics: Assess the % of unused requirements Assess the % of changed requirements Were estimates accurate?

The MANAGING Process Managing requirements by: Controlling scope Responding to change Change management (project change control) Traceability

Controlling Scope Requirements Change Control New Modifications Removal Avoid SCOPE CREEP Alignment with business objectives Using traceability to assess impact

Responding to Change Typical responses to change: Sniff out change early Scurry into action Deny and resist change; fear it will lead to something worse Learn to adapt in time Become a Change ______________ (Advocate, Navigator, Catalyst)

Change Management Generate formal Change Requests Revisit the source of the requirement Involve requirement owner in evaluating the proposed change Cycle back through the phases, beginning with Draft

Traceability for Changed Requirements Update the Traceability Matrix to reflect changes to requirements Requirements versioning Document, document, document! Consider dependencies, linked documentation Re-prioritize (if necessary)

Post-Project Uses for Traceability Obtain sign-off Governance/Steering Committee reviews Project Close-out reports Lessons Learned

In Summary… Plan the Work, Work the Plan Requirements Attributes are Key Underscoring Traceability: Knowledge is POWER Traceability Matrix = Roadmap for Success

Key Learning Points Describe requirement attributes, and how they can assist with requirements planning and prioritization Understand how to trace requirements from planning, through design and development, and on into the testing and implementation phases of a project/product Recognize how requirements traceability can facilitate requirements change

Questions?