Task: Detail Requirements |
This task describes how to detail one or more requirements for the system.
Disciplines: Requirements
Purpose
The purpose of this task is to describe one or more requirements in sufficient detail to validate understanding of the requirement, to ensure concurrence with stakeholders expectations, and to permit software development to begin.
Relationships
Roles | Primary Performer: Analyst | Additional Performers: Architect Developer Stakeholder Tester
Inputs | Mandatory: Glossary Supporting Requirements Use Case Use Case Model Vision | Optional: None
Outputs | Actor Glossary Supporting Requirements Use Case Use Case Model
Steps
Detail Use Cases and Scenarios
Some Use Cases and Scenarios may need to be described in more detail to validate our understanding of the requirement and to permit software development to begin. This does not imply that all use cases and scenarios will be detailed prior to commencing implementation. Work with stakeholders to detail only those that are prioritized for implementation in the next iteration or two (see Artifact: Work Items List), or those that are deemed architecturally significant (see Concept: Architecturally Significant Requirements.) The level of detail captured will vary depending upon the needs of the project and the complexity of the use case. For a discussion of the different levels of detail that may be applicable see Guideline: Use Case Formats. Capture the use case details in Artifact: Use Case. For additional information on detailing use cases and scenarios, see Guideline: Detail Use Cases and Scenarios. For assistance in assessing the quality of your use cases see Checklist: Use Case.
Detail supporting requirements
Some Supporting Requirements may need to be clarified or described in more detail, new requirements may have been discovered as we detailed the use cases and scenarios, and new requirements may have been submitted as Change Requests. Work with stakeholders to capture, refine and validate those requirements that will have an impact on near term work (see Artifact: Work Items List) or are deemed architecturally significant (see Concept: Architecturally Significant Requirements). Capture these requirements in the Artifact: Supporting Requirements. For additional guidance on detailing supporting requirements see Guideline: Supporting Requirements. For assistance in assessing the quality of your supporting requirements see Checklist: Supporting Requirements.
Detail glossary terms
Review the use case flow of events. If information is exchanged, be specific about what is passed back and forth. Work with stakeholders to ensure that you define newly discovered domain terms, or ambiguous terms properly in the Glossary. If your understanding of the domain has improved, refine existing glossary terms.
Update Use-Case Model
Based on your work update the Use Case Model. Add, remove or update Actors and Use Cases as required. For more information on creating and structuring your use case model see Guideline: Use-Case Model. For assistance in assessing the quality of your use case model see Checklist: Use-Case Model.
Achieve concurrence
Conduct a review of the requirements (Artifact: Use Case and Artifact: Supporting Requirements) with relevant Stakeholders and the development team to ensure consistency with the Vision, assess quality, and identify required changes. See Guideline: Effective Requirement Reviews for more information.
More Information
Checklists | Qualities of Good Requirements Supporting Requirements Use Case
Concepts | Requirements Use Case Supporting Requirements Requirement Attributes Traceability Use-Case Model
Guidelines | Detail Use Cases and Scenarios Effective Requirement Reviews Requirement Pitfalls Writing Good Requirements Use Case Formats
This program and the accompanying materials are made available under the Eclipse Public License v1.0 which accompanies this distribution. View copyright information here: OpenUP Copyright