Recommended
More Related Content
What's hot
What's hot (18)
Similar to Lesson Plan 0 - Traceability Intro
Similar to Lesson Plan 0 - Traceability Intro (20)
Lesson Plan 0 - Traceability Intro
- 1. Traceability Stephanie Walsh – Jan 2016 “Too frequently in the life of a software development project, a requirement cannot be attributed to a stakeholder, important functionality is missing, or unnecessary features appear in the final product -- all "without a trace." That is, there is no discoverable connection between the work pertaining to a specific feature and an actual requirement for that feature. Yet, the concept of traceability is inherently linked with the quality of the product to be delivered. Unfortunately, traceability is often treated as an unwanted orphan.”*
- 2. What is traceability? Traceability is a means of revealing the record of the process of creating and adapting a business solution, by establishing and maintaining relationships between each of the project elements, in order to better understand the business solution
- 3. Hierarchical and Interdependent Traceability Hierarchical Traceability Good for functional requirements Doesn’t allow for other types of relationships other than parent-child Helps to see where requirements have been de-scoped or missed in later stages i.e. scope changes Interdependent Traceability Identifies the relationships among related work items / artefacts across the project Enables links to be established between similar requirements which are related by a non-hierarchical relationship Helps to assess impact of change, manage change Business Objective Functional Requirement Design document Source Code Test Case Functional Requirement NFR Business Rule Use Case Functional Requirement Change Request Both are important to establish full traceability of the solution
- 4. Why do we want traceability? 1. To ensure the solution is built right - i.e. all the capabilities in the requirements are working in the solution 2. To ensure we build the right solution - i.e. there are no excess features in the solution which were not asked for by the customer 3. To ensure the coherence of the solution - i.e. the solution works as a whole and doesn’t contradict itself 4. To help manage change and risk – e.g. by ensuring all project elements relating to a change are updated at the same time 5. To assess the impact of change - to be able to correctly identify all project elements affected by a change as quickly and efficiently as possible 6. To prove we have delivered what we were contractually requested to deliver – in case the customer believes that the contract has not been met 7. For regulatory compliance – some projects, for example in the medical industry require traceability to be documented for regulatory purposes
- 5. What are the risks of ignoring traceability? “Research has shown that inadequate traceability is an important contributing factor to software project failures and budget overruns”* Risk of wasting time creating unwanted functionality Risk of solution not meeting client needs Risk of the solution not being consistent or integrated Risk of wasting time/ making errors in assessing the impact of change Risk of confusion on project due to unmanaged change Inability to prove the solution meets the contractually agreed requirements Risk of wasting time trying to understand the product when investigating defects
- 6. Main challenges in establishing and maintaining traceability Lack of understanding about what traceability is People having different views on what traceability is or placing different emphasis of particular parts of traceability without understanding the full picture Lack of understanding the importance of traceability People placing more emphasis on delivering a solution and treating traceability as a ‘nice to have’ rather than essential to the essence of the solution
- 7. Other challenges in establishing and maintaining traceability Lots of changes / Poorly tracked change / Out of date requirements specification Insufficient detail /Links are established too generically Project longevity/ People leaving the project / New people joining the project / Insufficient knowledge transfer Unproductive decision making not involving the original sources of the requirements in further discussions and refinements Poor collaboration / Individual responsibility as opposed to team responsibility for requirements Poor reuse of requirements Poor tool choice/Inflexible tools/ Tools not integrated or unable to maintain traceability for whole project lifecycle
- 8. Traceability and Project Methodologies Traceability is essential regardless of project methodology, since it enables us to better understand a solution Traceability gives visibility of what we are building and why Traceability should not be sacrificed for the sake of producing software faster Traceability actually enables us to be more efficient by providing is with the intelligibility, soundness and coherence of the solution
- 9. Best Practices Plan and Document Adopt consistent practices. Use unique identifiers. Take ownership of traceability. Centralise traceability Educate the team Keep it iterative Communicate changes NEVER use traceability as a measure in performance reviews
- 10. A Basic Traceability set-up Stakeholder Need Satisfies Implements Use Case Feature Supplem entary Test Case Validates Use case realisation Implements Satisfies Satisfies Validates Development domain Analysis domain Test domain
- 11. Relationships between requirements artefacts There are lots of different types of requirement artefacts. Which artefacts you create will be dependant on the nature of the project. Here are some common types of requirement artefacts: Business Objective/Stakeholder Request Functional Requirements Non Functional Requirements User Stories Process Flows Use Cases Business Rules Supporting artefacts e.g. Interface specifications, sample messages, WSDLs, XML schemas So what are all these types of requirements artefact, and how do they relate to each other?
- 13. Functional Requirements, Use Cases and Business Rules Functional requirements – capture behaviour of the system Use cases- describe how a user interacts with the system to accomplish a goal FR Use Case Fulfils / Is fulfilled by Use Case Fulfils / Is fulfilled by Fulfils / Is fulfilled by Fulfils / Is fulfilled by Fulfils / Is fulfilled by Calls FR FR FR FR Child of/ Parent of Business Rule Constrains / Constrained by Embedded in
- 14. FRs and Features Baseline FR Describes / Is described by System Feature Differentiates / Is differentiated by Extends / Is extended by
- 15. Use Case Breakdown Actor Use Case Describes / Described by Main Flow Exception FlowAlternate Flow Involved In / Involves Notificati on / Alert Triggered By / Triggers Use Case Use Case Extends / Extended by Includes / Included in Includes / Included in Describes / Described by Describes / Described by
- 16. Interface Specifications, Validation rules and supporting artefacts Interface Specifications describe the interface between two systems Validation rules specify exactly what validations are performed on messages travelling across an interface. NFR Interface Specification Characteristic of Qualifies Includes Describes WSDL Sample Message Validation Rule Authenticates FR Constrains Elaborates
- 17. Message Validation Rules System Message Type Meta Data Rule Sample Message Functional Requirements Link To Link To Link To Link To Link To Link To Link To Is Elaborated By Is Fulfilled By Triggers Link To Demonstrates Is Constrain By Link To Meta Data Mapping Master List Meta Data Status Rules Meta Data Map System Use Case Alerts Use Case Flow Supporting Use Case Artefact Business Rules Interface Summary Routing Rules Interface Specifications Functional Requirements Link To Link To Parent Of Is Elaborated By
- 18. Sample Message User Story Functional Requirement NFR System Use Case System Use Case Diagram Message Validation Rule Notification Interface Specification Routing Rule Qualifies Business Rule XML schema WSDL Functional Requirement Glossary Term Authenticates Is represented by Includes Issues Elaborates Parent of Represents Is elaborated by Is a characteristic ofMonitoring Rule Refund Rule UI Validation Rule Elaborates Supports Constrains Constrains Constrains Report Specificatio n Constrains Constrains Describes
- 19. How Rational DOORS NG follows best Practices Best Practices How DOORS NG meets this Plan and Document Customisation Adopt consistent practices. Roles and permissions, customisation Use unique identifiers. Unique artefact IDs Take ownership of traceability. Audit history, named users Centralise traceability Single, online requirements repository Educate the team Keep it iterative Audit history, baselines, live versions Communicate changes Audit history, suspect profiles NEVER use traceability as a measure in performance reviews
- 20. How does DOORS NG help to reduce challenges in traceability Challenges How does DOORS NG reduce the challenge? Change Management (lots of changes, poorly tracked change) DOORS NG works alongside RTC for change management. Suspicion profiles Links established to generically / Insufficient detail DOORS NG has artefacts for each requirement, so links can be established per requirement. Resource changes / Insufficient knowledge transfer DOORS NG has full audit trails, so you can see who created the artefact Unproductive decision making not involving the source of business need In DOORS NG you can have stakeholder request artefacts, with customisable attributes to capture all the information you need Poor collaboration Full audit history, artefact owners and communications within the tool Inflexible tools DOORS NG is designed with traceability in mind and has full customisation on traceability links
- 21. How does Rational (DOORS NG, RTC, RQM) help to overcome these challenges? Centralised platform Unique IDs Traceability Traceability links to specific artefacts / specific parts of artefacts / external sources Flexibility and configuration with links (not merely hierarchical) Links throughout project lifecycle from requirements to test Suspicion profiles Tracks changes and aids with analysing the impact of change Baselines and Audit History
- 22. DOORS NG Default traceability links Synonym Extracted / Extracted from External Link to / External link from Child of / Parent Of Embeds / Embedded in Satisfies / Satisfied by Link to / Link From Implement ed By Tracked by Actor FR Feature Heading Informatio n NFR Process Diagram Sketch Stakeholde r Request Storyboard Supplemen tary Term Use Case
- 23. DOORS NG Default traceability links Term Suppleme ntary Storyboar d Stakehold er Request Sketch Heading Actor Feature Informati on Process Diagram NFR FR Use Case Diagram Use Case Satisfies / Satisfied By
- 24. Proposal for Interdependent Traceability Links between requirements artefacts Term Supplementa ry Storyboar d Stakeholder Request Sketch Headingctor Feature Informati on Process Diagram NFR FR Use Case Diagram Use Case Satisfies / Satisfied By Includes / Included in FR Child of / Parent of CR Test case Elaborates / Is elaborated by Satisfies / Satisfied By Satisfies / Satisfied By Tracked by Validated by Dev task Implemented by olved in / nvolves