Your SlideShare is downloading. ×

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

When Requirements Change


Published on

Published in: Technology, Business

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • Requirements traceability is the process of starting with a requirement and correlating it with artifacts – specs, test cases, defects – throughout the development process.
  • Traceability is important for a number of reasons. It helps us understand the product in terms of its intended business use, it helps us determine the quality (fitness for use) of that product, Learn from our mistakes – Project post-mortem, we can isolate the requirements that saw the most issues and/or testing effort and evaluate why those areas were such a problem.
  • Requirements traceability enables project teams to keep requirements foremost as they design, develop, and test software.
  • If your development project is subject to regulatory or legal requirements, traceability helps you demonstrate compliance. During the development process, it can help identify where a requirement hasn’t been properly incorporated farther downstream.
  • What about changing requirements? During the course of a lengthy development effort, it’s normal for requirements to change. How can traceability help make sure these changes become a part of the final product?What about Agile? If I go agile, then I fix the problem of spending a year+ with the same requirements; do I still care about traceability?What happens to the schedule – Does that change blow up the schedule? Does the team suffer longer hours, to meet the existing schedule?
  • Once we change a requirement, downstream artifacts must change to reflect that. If we don’t know what downstream artifacts a requirement refers to, we cannot ensure that changes to that requirement are reflected in the completed product.Traceability is especially important when requirements start changing. If we can’t trace changes to requirements, we can’t be sure that the right product has been built.
  • It’s readily apparent why we have to trace forward, in order to make sure that requirements and their changes are reflected in downstream artifacts.
  • It’s also important to be able to trace backward, in order to understand where an artifact came from, and whether or not it is still relevant. Is the product on track, based on new business realities?
  • Tracing change in requirements is especially difficult because our requirements and related artifacts often reside in different applications. There’s no single place we can go to see an overall picture of requirements, test cases, source code, and defects.
  • There are three ways to approach traceability. You can do it manually, and it is a lot of work. You can have a programmatic interface between different tools (such as SOAP or other communications mechanism), and pass data back and forth using a custom interface. Or you can have an integrated solution, where most or all of the traceability information is automatically available between requirements, test cases, defects, and so on.
  • Traceability flows out from requirements. You should have requirements referenced in test cases, specs, source code, and defects. When requirements change, this should be a documented process, so that you have a mechanism for changing requirements and associated artifacts.
  • Change requests/orders may or may not identify affected artifacts. If they don’t, it falls on the team to have traceability defined so that these artifacts can be readily called up and examined.
  • A traceability matrix visualizes the relationship between requirements and other artifacts. This relationship should also be a part of each document, but the matrix provides a means of picturing those relationships.
  • The traceability matrix lets you create relationships between requirements and other artifacts; in this case, test cases.
  • Traceability sounds like it can be a complex and high maintenance process. It shouldn’t be.
  • Here are some guidelines for managing change and traceability in your projects.
  • First, as artifacts begin to be developed, link requirements (both forward and backward) to those artifacts.An automated, integrated solution will handle the backward links for you.
  • Use a documented mechanism to change requirements. Initiate the change, but look at the related artifacts. Work with the artifact owners to decide if and how an artifact must change.
  • Make sure that you note what changes have occurred to artifacts, and why.
  • Use a matrix or tree to visualize the relationships.
  • Transcript

    • 1. © 2011 Seapine Software, Inc. All rights reserved.
      When Requirements Change: Continuing to Meet User Expectations with Requirements Traceability
      A Seapine Software Webinar
      Peter VarholSolutions Evangelist, Seapine Software
    • 2. Agenda
      What is requirements traceability?
      Why we care about traceability
      Traceability and changing requirements
      Approaches to traceability
      Summary and questions
    • 3. What Is Requirements Traceability?
      Requirements traceability refers to the ability to describe and follow the life of a requirement, from conception to deployment
      Documents relationships between artifacts
      Document the transformation of a requirement into design, development and testing artifacts
    • 4. Why is Traceability Important?
      Traceability helps us:
      Determine the overall quality of the application under development
      Understand product under development and its artifacts
      Manage and communicate change
      Learn from our mistakes
    • 5. Why is Traceability Important?
      Makes sure we deliver the product defined by the requirements
      Requirements can get lost in day-to-day software development and test
    • 6. Why is Traceability Important?
      Provides an audit trail for accountability
      Identify where information can be lost
      Satisfy regulatory requirements
    • 7. Traceability and Change
      Design and development efforts can take a year or longer
      Unrealistic to expect that user needs don’t change over time
      What happens to these changes?
      What happens to the schedule?
    • 8. Traceability and Change
      Changes have to propagate in several directions
      Functional descriptions
      Design specifications
      Test plans and test cases
      Acceptance criteria
    • 9. Traceability and Change
      Changes have to trace forward and backward
      From requirement to final acceptance test
      From final acceptance test back to requirements
    • 10. Traceability and Change
      Why trace backward?
      Helps ensure that the evolving product remains on the right track with regards to evolving requirements
    • 11. Traceability and Change
      Requirements and related artifacts often reside in isolated silos
      Design/UML software
      Requirements management software
      Test management software
      Source code control software
      Defect tracking software
    • 12. Traceability and Change
      Best solution
      Integrated tool solution – requirements, test management, defect tracking, source code control
      Good solution
      A robust interfaces between different tools
      Poor solution
      Trying to trace manually
    • 13. Approaches to Traceability
      Traceability begins with requirements
      Product success based on fulfilling requirements
      Requirements must be documented
      Changes must be formally requested and documented
      Change requests and change orders
    • 14. Approaches to Traceability
      Ideally, change orders identify downstream artifacts
      Team members know what must be changed
      In reality, team doesn’t usually know what else needs to be changed
      Artifact tree or matrix is needed
    • 15. Approaches to Traceability
      The traceability matrix
      Correlates requirements with development and testing artifacts
      Provides a visual connection between requirements and other artifacts
      Enables validation that project requirements are being met
    • 16. Approaches to Traceability
    • 17. Approaches to Traceability
      Traceability is not rocket science
      It doesn’t have to be complex and difficult to maintain
      Automation can make traceability almostautomatic
    • 18. Steps to Change and Traceability
    • 19. Steps to Change and Traceability
      Link requirements to related artifacts
      Test cases
      Spec paragraphs
      Code modules
      Also create backward links
    • 20. Steps to Change and Traceability
      Use change requests/change orders
      Change requirements first, then look at artifacts
      Use traceability to identify potential changes to artifacts
      Work with artifact owners to ensure requirement changes are reflected in artifacts
      Changed requirement  changed test case
    • 21. Steps to Change and Traceability
      Make sure changed requirements and artifacts are appropriately labeled
      Team members using these artifacts need to know they have changed, and what the changes are
    • 22. Steps to Change and Traceability
      Use a traceability matrix or tree for easy reference
      These can be generated using automation
    • 23. Summary
      There is a need to relate business requirements to the delivered product
      Traceability provides the ability to define and maintain that relationship
      Traceability doesn’t have to be difficult or time-consuming
      Automation with integrated tools do the best job
    • 24. Thank You
      Seapine Software –
      The Seapine View -