Introduction to Requirements

Disciplines > Requirements > Introduction

Purpose
Relation to Other Disciplines

Concepts

Purpose

The purpose of the Requirements discipline is:

To establish and maintain agreement with the customers and other stakeholders on what the system should do.
To provide system developers with a better understanding of the system requirements.
To define the boundaries of (delimit) the system.
To provide a basis for planning the technical contents of iterations.
To provide a basis for estimating cost and time to develop the system.
To define a user-interface for the system, focusing on the needs and goals of the users.

To achieve these goals, it is important, first of all, to understand the definition and scope of the problem which we are trying to solve with this system. The Business Rules, Business Use-Case Model and Business Object Model developed during Business Modeling will serve as valuable input to this effort. Stakeholders are identified and Stakeholder Requests are elicited, gathered and analyzed.

A Vision document, a use-case model, use cases and Supplementary Specification are developed to fully describe the system - what the system will do - in an effort that views all stakeholders, including customers and potential users, as important sources of information (in addition to system requirements).

Stakeholder Requests are both actively elicited and gathered from existing sources to get a "wish list" of what different stakeholders of the project (customers, users, product champions) expect or desire the system to include, together with information on how each request has been considered by the project.

The Vision document provides a complete vision for the software system under development and supports the contract between the funding authority and the development organization. Every project needs a source for capturing the expectations among stakeholders. The vision document is written from the customers' perspective, focusing on the essential features of the system and acceptable levels of quality. The Vision should include a description of what features will be included as well as those considered but not included. It should also specify operational capacities (volumes, response times, accuracies), user profiles (who will be using the system), and inter-operational interfaces with entities outside the system boundary, where applicable. The Vision document provides the contractual basis for the requirements visible to the stakeholders.

The use-case model should serve as a communication medium and can serve as a contract between the customer, the users, and the system developers on the functionality of the system, 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 are an important complement to the use-case model, because together they capture all software requirements (functional and nonfunctional) that need to be described to serve as a complete software requirements specification.

A complete definition of the software requirements described in the use cases and Supplementary Specifications may be packaged together to define a Software Requirements Specification (SRS) for a particular "feature" or other subsystem grouping.

A Requirements Management Plan specifies the information and control mechanisms which will be collected and used for measuring, reporting, and controlling changes to the product requirements.

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

The Glossary is important because it defines a common terminology which is used consistently across the project or organization.

The Use-Case Storyboard and User-Interface Prototype are all results of user-interface modeling and prototyping, which are done in parallel with other requirements activities. These artifacts provide important feedback mechanisms in later iterations for discovering unknown or unclear requirements.

Relation to Other Disciplines

The Requirements discipline is related to other process disciplines.

The Business Modeling discipline provides Business Rules, a Business Use-Case Model and a Business Object Model, including a Domain Model and an organizational context for the system.
The Analysis & Design discipline 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 discipline validates the system against (amongst other things) the Use-Case Model. Use Cases and Supplementary Specifications provide input on requirements used in the definition of the evaluation mission, and in the subsequent test and evaluation activities.
The Configuration & Change Management discipline provides the change control mechanism for requirements. The mechanism for proposing a change is to submit a Change Request, which is reviewed by the Change Control Board.
The Project Management discipline plans the project and each iteration (described in an Iteration Plan). The use-case model and Requirements Management Plan are important inputs to the iteration planning activities.
The Environment discipline develops and maintains the supporting artifacts that are used during requirements management and use-case modeling, such as the Use-Case-Modeling Guidelines and User-Interface Guidelines.

Rational Unified Process