Requirements Engineering fall under two categories: User Requirements and System Requirements.
User Requirements are natural language statements and diagrams telling the system users what service the system will provide and the constraints under which the system will operate.
System Requirements define the software system’s functions, services and constraints in greater detail. It should clearly state what should be implemented. It may even become the part of the contract between the system buyer and software developer.
Software system requirements may be further categorized as functional and non- functional requirements.
For instance, functional requirements define what service the system will provide, how it reacts to particular inputs and how it should behave under certain conditions. It may also mention what the system may not do.
Non-functional requirements consist of constraints and functions imposed by the system such as timing constraints, constraints on the development process and standards- based constraints. These may be applied to the system as a whole.
We can categorize three activities to elicit requirements:
Listening involves the users’ needs or requirements of the system, asking them about goals and constraints of the system and finally recording their viewpoints of the system requirements.
Requirements analysis is the level where the system simply thinks. S/he transforms the users’ view of the system as an organized representation of the system as seen by the analyst.
Requirements definition is a clear statement, usually in natural language, of what the system should actually provide for its user. This definition translates into a requirements specification.
Three important factors to be considered are:
The specification, as we have already mentioned, should tell in detail the user’s view of the system rather than how the system should be implemented.
The specification is a contract between users and developers. While users will prefer it in natural language, developers would like to use some mathematical notations to be more precise. This problem can be resolved by drawing up two documents. These are:
Simply put, a requirements specification consists of functional and non-functional requirements as we have mentioned earlier.
Functional requirements state what the system should do. Non-functional requirements consist of:
Let us look at each of these by turns.
Data Requirements consist of three parts:
Performance Requirements are usually measures of performance used quantitatively, which may also be used in part for testing. These can be
Constraints are influences on the implementation of a system. They define conditions on items such as,
Guidelines provide useful information for applying an implementation strategy to a situation.
One popular method to document requirements is by using UML (Unified Modeling Language) use case diagrams. A user in a use case is an actor carrying out a task. The use case is the action carried out by the user/actor. It tells what the system should do.
For instance, in the case study of ATM system, the user withdraws cash. The use case for withdrawing cash is:
withdraw cash. The user inserts their card. The system prompts for the PIN. The user enters the PIN. The system checks the PIN. If the card and PIN are valid, the system prompts the user for their action. The user selects dispense cash. The system prompts for the amount. The user enters the amount. The system ejects the card. When the user has withdrawn the card, the system dispenses the required cash.
A set of use cases constitutes the functional specification of a system. Use cases can also be used to:
We can document a use case such as an UML case diagram but it does not contain the detail as a textual use case. However, it does give the big picture of the actors and use cases. So in this sense it provides an informal representation of user requirements in the system.
The figure 2.1 shows an example of a UML case diagram. The actor is a bank customer and his roles (use case functions) are withdraw cash and check balance.
Fig 2.1: Use Case Diagram for the ATM