Artifact: Supporting Requirements |
This artifact captures system-wide requirements not captured in scenarios or use cases, including requirements on quality attributes and global functional requirements.
Domain: Requirements Work Product Kinds: Specification
Relationships
Roles | Responsible: Analyst | Modified By: Analyst
Tasks | Input To: Detail Requirements Demonstrate the Architecture Design the Solution Define the Architecture | Output From: Find and Outline Requirements Detail Requirements
Description
Main Description | Supporting requirements and use cases together define the requirements on the system. Use Cases describe the behavioral requirements for the system and Supporting Requirements describe system-wide requirements not captured in Use Case Specifications. Making this distinction simplifies maintenance. Supporting Requirements may be categorized according to the FURPS+ model, an acronym for Functionality, Usability, Reliability, Performance, Supportability + Constraints. For more information on this classification see Concept: Supporting Requirements. The figure below illustrates the relationship between the supporting requirements and the use case specifications and actors.
Illustrations
Templates | Supporting Requirements Specification
Tailoring
Impact of not having | The 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. These requirements are frequently the major cost driver because they drive architectural choices. Furthermore, if system-wide requirements are not captured in a central location, but instead repeated throughout the use cases there will be more maintenance and more chance for error.
Representation Options | This work product does not imply one physical document to capture all requirement types. To manage the communication of the information, it can make more sense to separate out the information into separate physical documents or to use the work items list. The following are recommendation and options for representing the Supporting Requirements. #### Option: Use the Work Items List. Consider capturing supporting requirements in the Artifact: Work Items List which can be used for prioritizing and managing requirements. If stakeholders are comfortable with it, or with accessing a report automatically generated from it, then no separate document is required. #### Option: Include as Part of the Vision Document Consider including some supporting requirements types in the Artifact: Vision. In order to keep the Vision stable, follow this option for the requirements types that will need less refinement such as Product Qualities, Documentation or Compliance. #### Recommendation: Use the Supporting Requirements Specification Template. The Template: Supporting Requirements Specification 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.
More Information
Checklists | Supporting Requirements Qualities of Good Requirements
Concepts | Supporting Requirements
Guidelines | Supporting Requirements
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