Guidelines: Important
Decisions in Requirements
Topics
- Decide How to Perform the Workflow
- Decide How to Use Artifacts
- Decide Which Reports to Use
- Decide How to Maintain "Input Requirements"
- Decide How to Approve Use Cases
Decide
How to Perform the Workflow 
The following decisions should be made regarding the Requirements discipline's workflow:
- Decide how to perform the workflow by looking at the Requirements: Workflow. Study the diagram with its guard conditions. Decide which workflow details to perform and in which order.
- Decide what parts of the Requirements workflow details to perform. The table below shows some parts that can be introduced relatively independently from each other.
- Decide when, during the project lifecycle, to introduce each part of the workflow. As a general rule, the Requirements discipline should be introduced early in the project.
Part of workflow |
Comments |
| Use-Cases | Some projects do not employ use-cases, which means that the project will not develop artifacts such as a Use-Case Model, Use-Case Package and Use Case. Instead use the Software Requirements Specification. |
| Workflow Detail: Manage Changing Requirements | This can be introduced after a few iterations in the project when there is a stable baseline. |
Document the decisions in the Development Case, under the headings Disciplines, Requirements, Workflow .
Decide How to Use Artifacts
Decide which artifacts to use and how to use each of them. The table below describes those artifacts you must have and those used in some cases. For more detailed information on how to tailor each artifact, and a discussion of the advantages and disadvantages of that specific artifact, read the section titled "Tailoring" for each artifact.
For each artifact, decide how the artifact should be used: Must have, Should have, Could have or Won't have. For more details, see the Guidelines: Classifying Artifacts.
| Artifact | Purpose |
Tailoring (Optional, Recommended) |
| Use cases are used to define functional requirements. |
Recommended for most projects. Use cases are the recommended method for capturing functional requirements. |
|
| Projects with behavioral requirements that are not really understood should consider Storyboarding as a means to elicit requirements. |
Optional Other requirements elicitation techniques may be used. |
|
| Glossary | Ensures that everyone on the project is using a common vocabulary. |
Recommended for most projects. |
| Requirements Attributes | A database of requirements attributes helps ensure that requirements are properly prioritized, tracked, and traced. |
Optional However, on projects with relatively few requirements, a database of requirements attributes may not be strictly necessary. |
| Requirements Management Plan | Describes the information to be collected and control mechanisms to be used for measuring, reporting, and controlling changes to the product requirements. A separate document is needed if requirements management complexity or customer visibility warrants it. |
Optional Projects with relatively few requirements may take a light-weight approach to requirements management which can be documented directly in the Software Development Plan. Other projects may select and follow a more rigorous approach, but produce little or no formal description. For example, the set of requirements attributes to be gathered may be implicitly documented by the configuration of the tools. |
| Software Requirements Specification | Used to collect the set of all requirements in a formal document provided to the customer. |
Optional On less formal projects, a formal document may not be required. |
| Stakeholder Requests | Captures all requests made on the project, as well as how these requests have been addressed. |
Recommended for most projects. In order to build a system that meets the needs of the stakeholders, it is important to solicit and review their requests. Many projects manage Stakeholder Requests as just a category of Change Requests. Other projects may capture Stakeholder Requests only informally. |
| Supplementary Specifications | Used to capture non-functional requirements. |
Recommended for most projects. |
| Vision | Captures very high-level requirements and design constraints, to give the reader an understanding of the system to be developed. |
Recommended for most projects. |
Tailor each artifact to fit the needs of the project. For tailoring considerations, see the tailoring section of the artifacts' description page, or the steps described under the heading "Tailor Artifacts per Discipline" in the Activity: Develop Development Case.
Decide Which Reports to Use
The decision of which reports to use will depend on the reporting tools available to the project. If report generation tools are available, we recommend generating reports for model oriented or database oriented artifacts
