Requirements Management Definitions


Requirements are real capabilities which the system must provide. It makes sense therefore to find out what the requirements are, write them down and organize them, and manage them in the event that they change. Stated another way we’ll define requirements management as a systematic approach to eliciting, organizing, and documenting the requirements of a system.


It is also our responsibility to understand the needs of users and other stakeholders whose lives will be affected by our solution. As we elicit those needs, we’ll stack them in a little pile called stakeholder needs, which we represent as a pyramid.


Features should be stated as simple descriptions in the user’s language that we will use as labels to communicate with the user how the system addresses the problem. These labels will become part of our everyday language, and much energy will be spent defining them. So the full definition of a feature is a service that the system provides to fulfill one more more of the stakeholder needs. In the requirements management process, features should be defined first.


Once we have established the feature set and have gained agreement with the customer, we can move on to defining the more specific requirements that we will need to impose on the solution. If we build a system that conforms to those requirements, we can be certain that the system we develop will deliver the features we promised. In turn, since the features address one or more of the stakeholder needs, we will have addressed those needs directly in the solution. In the requirements management process, software requirements can be either functional or non-functional requirements. If they are functional requirements, use cases should be used to describe them.

These more specific requirements are the software requirements.


Actors are basically users of the system. They are actually user types or categories. Actors are external entities (people or other systems) who interact with the system to achieve a desired goal.

Use Cases are what happens when actors interact with the system. An actor uses the system to achieve a desired goal. By recording all the ways our system is used (“cases of use” or Use Cases) we accumulate all the goals or requirements of our system.

Therefore: A use case is a collection of possible sequences of interactions between the system under discussion and its Users (or Actors), relating to a particular goal. The collection of Use Cases should define all system behavior relevant to the actors to assure them that their goals will be carried out properly. Any system behavior that is irrelevant to the actors should not be included in the use cases.

There are many methods of defining how to pick or create a use case. The use cases in this report are generated using a goal oriented Structuring Methodology presented by Alistair Cockburn of Humans and Technology. Examining all the Actor’s goals that the system satisfies yields the functional requirements. Goals summarize system function in understandable verifiable terms of use that users, executives and developers can appreciate and leave little open to interpretation.

-To Capture the Requirements of the systems.
-To act as a springboard for the software design.
-To validate the software design against.
-For Software Test and Quality Assurance. (Tests are performed to validate proper and complete implementation of the use cases)
-Potentially as an initial framework for the on line help and user manual.

Primary Actors
The Actor(s) using the system to achieve a goal. The Use Case documents the interactions between the system and the actors to achieve the goal of the primary actor.

Secondary Actors
Actors that the system needs assistance from to achieve the primary actors goal.

Use Case
A collection of possible scenarios between the system under discussion and external actors, characterized by the goal the primary actor has toward the system’s declared responsibilities, showing how the primary actor’s goal might be delivered or might fail.

Use cases are goals (use cases and goals are used interchangeably) that are made up of scenarios. Scenarios consist of a sequence of steps to achieve the goal, each step in a scenario is a sub (or mini) goal of the use case. As such each sub goal represents either another use case (subordinate use case) or an autonomous action that is at the lowest level desired by our use case decomposition.

This hierarchical relationship is needed to properly model the requirements of a system being developed. A complete use case analysis requires several levels. In addition the level at which the use case is operating at it is important to understand the scope it is addressing. The level and scope are important to assure that the language and granularity of scenario steps remain consistent within the use case.