Introduction to Requirements

• Purpose
• Relation to Other Workflows
• Concepts
  • Use-Case View
  • Requirement
  • Types of Requirements
  • Traceability

Purpose

The purposes of Requirements are:

• To come to an agreement with the customer and the users on what the system should do.
• To give system developers a better understanding of the requirements on the system.
• To delimit the system.
• To provide a basis for planning the technical contents of iterations.
• To define a user-interface for the system.

To achieve these goals, a Vision document, a Stakeholder Needs document, a use-case model, and a Supplementary Specification document are developed that describes what the system will do - an effort that views customers and potential users as important sources of information (in addition to system requirements).

The Vision document states the overall goals of the project and main features of the system.

The Stakeholder Needs document collects a "wish list" of what different stakeholders of the project (customers, users, product champions) expect the system to include, together with information on how each request has been considered by the project.

The use-case model can serve as a contract between the customer, the users, and the system developers, which allows:

• Customers and users to validate that the system will become what they expected.
• System developers to build what is expected.

The use-case model consists of use cases and actors. Each use case in the model is described in detail, showing step-by-step how the system interacts with the actors, and what the system does in the use case. Use cases function as a unifying thread throughout the software lifecycle; the same use-case model is used in system analysis, design, implementation, and testing.

The Supplementary Specifications is an important complement to the use-case model, because together they capture all requirements (functional and nonfunctional) that need to be described to serve as a complete system requirements specification.

Complementary to the above mentioned artifacts, the following artifacts are developed:

• Glossary
• Use-Case Storyboard
• Boundary Class
• User-Interface Prototype

The Glossary is important because it defines a common terminology for in all models and textual descriptions of the required system.

Use-Case Storyboard, Boundary Class and User-Interface Prototype are all results of user-interface modeling and prototyping, which are done in parallel with other requirements activities.

Relation to Other Workflows

The Requirements workflow is related to other process workflows.

• The Business Modeling workflow provides a organizational context for the system.
• The Analysis & Design workflow gets its primary input (the use-case model and the Glossary) from Requirements. Flaws in the use-case model can be discovered during analysis & design; change requests are then generated, and applied to the use-case model.
• The Test workflow tests the system to verify the code against the use-case model. Use cases are input to writing test specifications.
• The Environment workflow, develops and maintains the supporting artifacts that are used during use-case modeling, such as the Use-Case-Modeling Guidelines.
• The Management workflow plans the project, and each iteration (described in an Iteration Plan). The use-case model is an important input to the iteration planning activities.