RequirementOne requirements management - best practices - web


Published on

Requirements development deals with getting good software requirements. Requirements management addresses the challenges of handling these requirements as the project proceeds over time. This presentation summarizes several best practices for requirements management.

The following topics are addressed:

• Version control of requirements documents
• Change control
• The change control board
• Impact analysis of change requests
• Requirements attributes
• Tracking requirements status
• Requirements traceability
• Using requirements management tools

Published in: Business, Technology
  • Be the first to comment

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

No notes for slide
  • Ask: Do any of you have specific expectations for this seminar?[Write down expectations on a flipchart. At midday, look over them as a process check, to see if you are addressing the students’ objectives.Go through the handoutpoint out references on final slidespoint out the Worksheets and Work Aids section; suggest students mark that page for easy reference throughout the class]Ask: If any students have tried to apply use cases on their project before. If so, can anyone share any of their experiences with the class?
  • Some people call the whole discipline “requirements engineering”; others call it all “requirements management”I find it helpful to split the whole domain of “reqs engineering” into separate subdisciplines of reqs development and reqs management.The goal of reqs development is to deduce, capture, and agree upon a set of functional requirements and product characteristics that will achieve the stated business objectives.Elicitation = discovering, inventing, and collecting reqsAnalysis = understanding requirementsSpecification = documenting requirementsValidation = determining that requirements are correct, of high quality, and will satisfy user needsA key to success is to iterate through these development steps, progressively refining the reqs over time. You can’t just do just one pass from elicitation through validation.
  • Now we’re going to look at some basic practices that can help you achieve the requirements management goals.
  • You need to be able to know the version of every requirements document, and (ideally) every individual requirement, at all times.Problems arise when project team members are unknowingly working from different versions of the requirements.Automated tools can best manage versions, but manual identification methods, and the discipline to use them, can also work.Avoid document identification schemes based on dates.You might also want to keep track of different versions of individual requirements. This is because requirements change over time, and sometimes people want to revert or refer to a previous version. This level of version tracking isn’t feasible by hand, but the commercial RM tools can do it for you.
  • Change control is the heart of requirements management.Only authorized individuals should be allowed to incorporate changes into the SRS, by following a defined process that includes assessing the benefits and impact of the change, reviewing the new requirement, and updating the baseline SRS, including the date and reason the change was made.We need to communicate changes to all affected parties, so work is always based on the current requirements version.Problem tracking/bug reporting systems can be used for collecting proposed changes.No work should be done based on proposed changes in the requirements until they are approved, documented, reviewed, and incorporated into the SRS.
  • Define a set of possible statuses that a change request could have at any time, and a set of allowed changes from one status to another. This describes the life cycle of a change request.A state-transition diagram like the one shown here, or a UML statechart diagram, is an excellent way to represent this set of possible statuses.All change requests must have one of these statuses at any given time.You’ll find it illuminating to track the distribution of change requests over time. This will show you how much change activity is taking place and how promptly your team responds to change requests.
  • This figure illustrates how a typical change control system works.We used a system like this that we developed at Kodak to let people submit bug reports, enhancement requests, requests for requirements changes in new systems, and simply pleas for help.The automatic e-mail communications with stakeholders makes this a useful two-way communication tool.Remember, a tool is not a process.Buy a tool, don’t build one.
  • The term “board” conjures an image of time-wasting bureaucratic process overhead, but the CCB should be no larger or more formal than it needs to be to ensure that the right people make informed business decisions about which change requests to approve.One person might be fully empowered to do this on a small project.Note: The people on the CCB are the people who need to participate in making the decisions, not all the people who need to be informed about the decisions.A template for a charter for a CCB is available on the Goodies page at the web site.
  • The Work Aids and Worksheets section of the seminar handout contains a checklist and an effort estimating worksheet for requirements change impact analysis.A few of the items from the checklist are shown here.Too often, we make commitments to requirements changes without having worked through the real implications of impact and cost. These checklists can help you do a more thorough analysis job, in just a little time.Adapt the checklists to fit your situation.
  • More items from the impact analysis checklist. These are just some questions to ask yourself when contemplating a proposed change.
  • Do a micro project plan for each proposed change, by estimating the work effort (not calendar time!) for each task you might have to perform, and assembling these task efforts into an overall cost.If tasks in the change affect the project’s critical path, the project will slip (by definition).
  • It’s a good idea to store additional information -- attributes -- about each functional requirement beyond the textual statement of the desired system behavior. You can think of attributes as providing a third dimension of information to supplement the two-dimensional form of a requirements list.It’s cumbersome to manage several attributes in a textual document, but commercial requirements management tools make it easy.This slide lists a few of the attributes you might want to store about each requirement. Don’t try to use too many attributes at first. Start with just a few and add more when you are ready to take full advantage of them.The commercial requirements management tools let you filter the requirements in the database to view just a subset that satisfies certain attribute characteristics.This lets you mix requirements that are allocated to multiple baselines or releases in a single database.
  • Status should be one of the basic requirement attributes.Define a set of statuses that will characterize the life cycle of a proposed requirement.Define objective criteria for changing a status.Some people also use a status of “Deferred” (as to a future release), but I prefer to handle that with a “Release Number” requirement attribute.“Rejected” lets you keep track of reqs that were proposed at some point; sometimes they come back!You can track project status by describing what percent of the requirements allocated to the product baseline have each status. This is much better than the usual “90% done” with some activity that characterizes so much of project status tracking.A body of work is completed when all the requirements allocated to it have a status of either “verified” or “deleted.”
  • We need to trace software requirements both backward to a specific origin, and forward to the design and code elements that implement them and the tests that validate them. If you don’t know where a requirement came from, question why it is there.To do requirements traceability, each requirement must be uniquely identified.Most people use a hierarchical numbering system, but if a requirement is inserted or deleted, the numbering can get thrown off. Also, the numbers don’t tell you anything about the requirement.It might be better to use a text-based hierarchical “tagging” notation instead. This is bulkier than a numbering system, but is environmentally independent.Or, you can just number the individual requirements, and never reuse a number, even if you delete the requirement.
  • We can organize the connections between requirements and other system elements in a requirements traceability matrix.The RTM constitutes a roadmap for the components of the system.Don’t view the RTM as nuisance documentation to be created at the end of the project if you have time. Create the matrix after requirements are written, and populate it as development progresses. This way it becomes a working quality tool during the development stage.It can be tedious to do manually for any but small systems. RM tools can store the information, but you still have to define the logical links manually.You might think this is unnecessary. However, Boeing did a complete RTM for the Boeing 777 software, which was in an SRS 6 feet thick! It can be done, if it’s important enough.
  • This is another way to draw a requirements traceability matrix. This is a true matrix, in which the rows are all the instances of one kind of object (functional requirements in this example) and the columns are all the instances of another kind of object (use cases here).This is the way the requirements management tools present the traceability matrix.You have to define the logical links between objects. Here, we’re using an arrow to indicate that use case 1 traces into functional requirements 1, 2, and 4. UC-2 reuses FR-2 and leads to FR-3. Different tools use different symbols.If you change an object on one end of the link (like UC-2), the next time you see the matrix there will be some visual indicator that the objects on the other end might need to be changed (diagonal red lines here). You need to make those changes and clear the suspect links.
  • This figure suggests the project team members who might be able to provide the various types of traceability link information.The job of collecting, managing, and reporting on the traceability information generally falls to the project’s requirements analyst.
  • These tools can import requirements of various kinds from Word documents and store them in a database.Then you can define attributes for each requirement, including status, and view or report on just those requirements that have certain attribute values.
  • [Leave this slide hidden in the handout but not in the presentation.]The reason we emphasize understanding user requirements is to avoid the unpleasant surprise factor that happens at the end of so many software projects. Use cases are a powerful way to get user representatives engaged in the requirements exploration process, which leads to a higher level of customer satisfaction.
  • Final slide
  • RequirementOne requirements management - best practices - web

    1. 1. Requirements Management Best PracticesSponsored by: Karl Wiegers Principal Consultant, Process Impact
    2. 2. Sponsor: RequirementOne  Delivers 100% of Karl’s recommended requirement tool capabilities Free 30 day trial  Collaborative working in $45/month/project the cloud Unlimited users  Write individual requirements in intuitive Word format  Quick to implement 2
    3. 3. Featured Speaker Karl Wiegers Principal Consultant, Process Impact Phone #: 503-698-9620 E-mail: Blog: Consulting Tips & Tricks Blog: 3Sponsored By
    4. 4. Components of Requirements Engineering Requirements Engineering Requirements Requirements Development Management Elicitation Analysis Specification Validation 4 Sponsored By
    5. 5. Key Requirements Management Practices  Creating a requirements baseline.  Manage versions of requirements documents.  Adopt and enforce a change control process.  Perform requirements changeimpact analysis.  Store requirementattributes.  Track the statusof each requirement.  Trace requirements into designs, code, and tests.  Store requirements in a requirements management tool. 5Sponsored By
    6. 6. The Requirements Baseline Baseline:A reviewed, approved, and agreed-upon set of requirements committed to a specific product release. “Sign-off” is a matter of approving the baseline. When a baseline is defined:  formal change control begins  managers make schedule commitments  managers determine the staff and budget needed to meet their schedule commitments 6Sponsored By
    7. 7. Requirements Version Management Place requirements documents under version control.  keep requirements documentation up to date  everyone must have access to current versions  restrict document update access to authorized individuals Best: Store requirements in a database. Better: Store documents in a configuration management system. Good: Define a version identification scheme. #1= “version 1.0 draft 1” #2= “version 1.0 draft 2” #n= “version 1.0 approved” #n+1 = “version 1.1 draft 1” or “version 2.0 draft 1” 7Sponsored By
    8. 8. Requirements Change Control Uncontrolled changes cause problems:  rework, degraded quality, unpredictable schedules Define a requirements change process.  propose, review, approve, and incorporate changes  define state-transition model for allowed change states  include impact analysis  support with a tool, but a Tool Is Not a Process! All change requests must follow the process. Requirements changes may require renegotiating project commitments. change process 8Sponsored By
    9. 9. Possible Change Request Statuses Change Submitted Request Evaluated Rejected Approved Change Made Canceled Verified Closed 9Sponsored By
    10. 10. A Change Control System User defect report, enhancement, e-mail e-mail with requirement with response change entry e-mail with entry e-mail with entry Change Tool response database response Customer Support Reps reports Staff 10Sponsored By
    11. 11. Change Control Board Diverse group  development testing  project management customer  documentation  others? Authorized to make binding decisions Adopt a CCB Charter  purpose, scope of authority, membership, meeting frequency, decision-making process, communicating status Consider change requests periodically  request impact analysis  make and communicate accept/reject decisions  set priorities or targeted releases 11Sponsored By
    12. 12. Impact Analysis for Requirements Changes - 1  Identify conflicts with existing requirements.  Identify affected design, code, test components.  Assess impact on user interface, database, reports, files, help screens, publications.  Identify other systems, libraries, or hardware affected.  Determine which work products will require reviewing.  Identify plans to update (SPMP, SCMP, SQAP, etc.). 12Sponsored By
    13. 13. Impact Analysis for Requirements Changes - 2  Will the change affect performance or other quality attributes?  Is the change technically feasible?  Will the change overload computer resources for development, test, or host environment?  Will you have to discard other completed work?  Does it violate any business rules?  Does the change affect any other current tasks? 13Sponsored By
    14. 14. Impact Analysis for Requirements Changes - 3 Estimate total labor hours for all tasks to be performed.  create new designs, code, tests, UI, database, files, reports  modify existing designs, code, tests, UI, database, files, reports  develop and evaluate prototype  retesting  reviews and rework Allocate resources to tasks. Sequence tasks and identify predecessors. Determine if change is on critical path. Estimate schedule and cost impact from effort. 14Sponsored By
    15. 15. Requirement Attributes  Store additional information about each requirement.  Some suggestions:  status  date created and version number  author and person responsible for the requirement  origin or rationale behind the requirement  allocated subsystem, product release, and build  priority  risk The Spec  criticality ~~~~~~ ~~~~~~  validation method ~~~~~~ ~~~~~~  Track project status through requirements status. 15Sponsored By
    16. 16. Requirements Status Tracking - 1 Proposed requirement was requested by a legitimate source Approved requirement was analyzed, impact evaluated, and allocated to a baseline Implemented code was designed, written, and tested Verified requirement was shown to be implemented correctly in the product Deleted planned requirement was deleted from the baseline Rejected requirement was requested, not approved 16Sponsored By
    17. 17. Requirements Status Tracking - 2 100% 90% Percent of Requirements 80% 70% 60% Proposed Approved 50% Implemented 40% Verified 30% Deleted 20% 10% 0% 1 2 3 4 5 6 7 8 9 10 Month 17Sponsored By
    18. 18. Requirements Traceability System Requirement, Use Case, Business Rule Functional Requirement Design Component Test Case Each requirement must be Source Code File & Function uniquely identified:, FR-117, Print.ConfirmCopies 18Sponsored By
    19. 19. Requirements Traceability Matrix - 1 Req. Design Element Source File Function Test Case FR-117 DFD 8.8.7 progmgr.c execute_action, action.1, select_manage action.3 Benefits: 1. No requirements are overlooked during design and implementation. 2. You can see at a glance what work has been completed. 3.If a test fails, it points to the code to search for the problem. 4. A requirement change points to the affected design, code, and test elements. 19Sponsored By
    20. 20. Requirements Traceability Matrix - 2 Use Cases Functional UC-1 UC-2 UC-3 Requirements FR-1 FR-2 FR-3 FR-4 FR-5 FR-6 20Sponsored By
    21. 21. Where Traceability Links Might Come From Link Source Link Target Information SourceProduct requirement Software or hardware System Engineer requirementUser requirement Functional requirement Business AnalystFunctional requirement Functional requirement Business AnalystFunctional requirement Test case Test EngineerFunctional requirement Architecture element ArchitectFunctional requirement Software or hardware Developer design elementDesign element Code DeveloperBusiness rule Functional requirement Business Analyst 21 Sponsored By
    22. 22. Limitations of Requirements Documents  Difficult to handle requirements for multiple releases  Difficult to move a requirement from one baseline to another  Difficult to reuse requirements information  Difficult to link information in multiple locations across documents  Difficult to give stakeholders access to current versions 22Sponsored By
    23. 23. Requirements Management Tool Capabilities Manage versions and changes  version history of every requirement  baselining capability Store requirements attributes  system and user-defined  filter to view requirements with specific attribute values Define traceability links  requirements to other requirements, designs, tests, etc.  assist with change impact analysis Control access  group and individual permissions  web access to requirements database 23Sponsored By
    24. 24. Getting the Most from Your RM Tool  Write good requirements first.  Don’t expect the tool to replace a requirements process.  Expect a culture change.  Don’t create too many requirement types or attributes.  Train the tool users.  Assign responsibilities.  Take good advantage of tool features. 24Sponsored By
    25. 25. Requirements Management Best Practices NO SURPRISES! 25 Sponsored By
    26. 26. Sponsor: RequirementOne  Execute Karl’s recommendations TODAY!  Sign up for a free 30 day trial  Specifications app $45/project/month 26
    27. 27. Q&A 27Sponsored By
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.