Artifact: Supporting Requirements
This artifact captures the system requirements that are not readily captured in behavioral requirements artifacts such as use-case specifications.
Domain:  Requirements
Work Product Kinds:  Specification
Relationships
Description
Main Description

There is a finite set of requirements to be considered when it comes to gather system-wide functional requirements, qualities or constraints. Many of them are unfamiliar to stakeholders. They may find difficult to answer questions retated with topics such availability, or performance, or scalability, or localizability. Use alternative questions whose answers lead to specifying supporting requirements on their behalf. Use the provided template as a checklist to talk to the stakeholders and ask the right questions to make sure that all topics are discussed. Make sure that stakeholders understand the costs of their selections, and do not end up wanting everything that is on the list.

Besides technical requirements, consider as well the particular business domain where the system should fit. Business rules or policies that the system must conform to may constrain system functionality. Business rules are referred to by system use cases, and can be in the form of decision tables, computation rules, decision trees, algorithms, and so on. Describing business rules in the flows of the use cases usually clutters the use-case specifications. Hence, they are normally captured in separate artifacts or as annexes to the use-case specifications. In many cases a business rules applies to more then one use case so these shared business rules should be stored in a single repository, such as a business rules document, supporting requirements or work items list.

Illustrations
Key Considerations

This work product does not imply one physical document to capture all requirement types. To manage the communication of the information, it can make make more sense to separate out the information into separate physical documents or to use the work items list.

Tailoring
Impact of not havingThe goal of  this work product is  to make sure that all requirements types are covered, reducing the risk of not considering some important facet of the system. FURPS+ requirements are system wide and they will influence the architectural mechanisms that will be created, driving the system's foundations. They can be more  architecturally significant than the requirements specified in use cases.
Reasons for not needingThe Artifact: Work Items List may be used to capture non-functional requirements.
Representation Options

The following are recommendation and options for representing the Supporting Requirements.

Recommendation: Use the Supporting Requirements Artifact.

The Template: Supporting Requirements provides a means to capture, structure and organize the supporting requirements.

Even in a small project, a requirements management tool, a database, or a spreadsheet, are recommended for prioritizing and managing requirements. If stakeholders are comfortable with accessing requirements directly from the tool, or with accessing a report automatically generated from the tool, then no separate document is required.

Option: Use the Work Items List.

Consider capturing supporting requirements in the Artifact: Work Items List.

Option: Include as Part of the Vision Document

If there are stakeholders that prefer a document, consider including supplementary requirements in the Vision document. The master can still be in some kind of tool, as described previously, and the Vision would then contain a report from the tool, or a table cut and paste from a spreadsheet.

See the Template: Vision.

More Information