Decide How to Use Work Products

Make a decision about what work products are to be used and how they are to be used.  In addition to identifying what work products are to be used, it is also important to also tailor each work product to be used to fit the needs of the project. 

The table below specifies which Requirements work products are recommended and which are considered optional (i.e., may only be used in certain cases). For additional tailoring considerations, see the tailoring section of the work product description page.

Work Product	Purpose	Tailoring (Optional, Recommended)
Artifact: Use-Case Model (Artifact: Actor, Artifact: Use Case, Artifact: Use-Case Package)	Use cases are used to define functional requirements.	Recommended for most projects. Use cases are the recommended method for capturing functional requirements.
Artifact: Storyboard	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.
Artifact: Glossary	Ensures that everyone on the project is using a common vocabulary.	Recommended for most projects.
Artifact: 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.
Artifact: 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 lightweight 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.
Artifact: 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.
Artifact: 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.
Artifact: Supplementary Specifications	Used to capture non-functional requirements.	Recommended for most projects.
Artifact: 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.

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 work products, such as Use-Cases and Actors. Existing reports in your RUP configuration are available from the work product description pages and grouped under the relevant work product in the treebrowser.

Decide How to Maintain "Input Requirements"

This section only applies if a formal contract, standard or specification document is imposing requirements to the requirements management effort. It is referred to as the "input requirements specification".

During the requirements effort, you capture the requirements in these documents: Artifact: Vision, Artifact: Stakeholder Requests, Artifact: Use-Case Model, Artifact: Supplementary Specifications.

Decide whether the input requirements specification will be maintained or not. Will you go back and update the input requirements specification when you discover a requirement was bad, wrong or faulty? You must also decide how to maintain  traces or references between the input requirement specification and the Artifact: Use Case.

Choose one, or a combination of, the following strategies:

• Do not update the input requirement specification. Let the Use Cases and the Supplementary Specification specify what the system will do hereafter.
• Do not update the input requirements specification, but maintain the  Traceability from use cases back to it.
• Update the input requirements specification with all work and costs involved.
• Let the input requirements specification evolve into a Supplementary Specification containing requirements. The functional input requirements are simply transferred to the use cases.

Most projects find that the number of requirements which are bad, faulty or wrong is so large, it doesn't make sense to maintain the original input requirements specification. Very few projects have customers willing to pay for the work of updating the input requirements specification with the new information revealed during use-case modeling.

Don't stress this topic too early. In the beginning of a project, people still believe in the initial requirements specification, however, after working through the problem area with a use case, most people have quite a different view of the initial requirements specification.

Decide How to Approve Use Cases

Decide how to approve the use cases. A lot of time can be saved by limiting the number of use cases that have to be formally reviewed by the customer. Perhaps it's acceptable for the customer to formally review only a subset of all use cases.

Choose one or more of the following strategies:

• All use cases must pass formal external reviews with representatives who are external to the project.
• Some secondary use cases can be approved in a simplified way, at either an informal or an internal formal review.

Secondary use cases are those use cases essential to the system but not to the task of the primary user; for example, use cases related to the administration and maintenance of the system, such as adding users to the system, changing their authority, and making backups. The system will not work without these use cases, although they're not of primary interest to the important users.

The strategy you use depends on your relationship with your customer. Do they trust that you can do the supporting use cases correctly without a formal approval process? Although this would save a considerable amount of time, will you reach the right quality of the use-case model?

Note: A solution to the problem may involve the customer in the Requirements effort. By involving customer representatives, they will be able to approve or give recommendations to other customers, and by involving the customer, the project gains credibility.

For more information on review levels, see Guideline: Review Levels.