When Requirements Change
•Transferir como PPTX, PDF•
1 gostou•1,385 visualizações
This document discusses the importance of requirements traceability for managing changing requirements during software development. Requirements traceability links requirements to related artifacts like test cases, code, and defects to ensure changes propagate in all directions. When requirements change, the traceability matrix helps identify what other artifacts need updating by showing connections between requirements and development items. Maintaining bidirectional traceability from requirements to final tests and vice versa allows projects to stay on track as needs evolve.
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a When Requirements Change
Semelhante a When Requirements Change (20)
Mais de Seapine Software
Mais de Seapine Software (20)
Último
Último (20)
When Requirements Change
- 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 Code 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
- 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 Defects 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 – www.seapine.com The Seapine View - http://blogs.seapine.com/
Notas do Editor
- 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.