CS 410/510 - Software Engineering
Requirements Engineering
Reference: Sommerville, Software Engineering, 10 ed., Chapter 4
The big picture
Requirements engineering (RE) is the process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process. Requirements may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification. As much as possible, requirements should describe what the system should do, but not how it should do it.
Two kinds of requirements based on the intended purpose and target audience:
Three classes of requirements:
Functional requirements
Functional requirements describe functionality or system services. They depend on the type of software, expected users and the type of system where the software is used.
Problems arise when requirements are not precisely stated. Ambiguous requirements may be interpreted in different ways by developers and users. In principle, requirements should be both
In practice, it is impossible to produce a complete and consistent requirements document.
Non-functional requirements
Non-functional requirements define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. Process requirements may also be specified mandating a particular IDE, programming language or development method. Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless.
Non-functional requirements may affect the overall architecture of a system rather than the individual components. A single non-functional requirement, such as a security requirement, may generate a number of related functional requirements that define system services that are required. It may also generate requirements that restrict existing requirements.
Three classes of non-functional requirements:
Non-functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify. If they are stated as a goal (a general intention of the user such as ease of use), they should be rewritten as a verifiable non-functional requirement (a statement using some quantifiable metric that can be objectively tested). Goals are helpful to developers as they convey the intentions of the system users.
Domain requirements
The system's operational domain imposes requirements on the system. Domain requirements may be new functional or non-functional requirements, constraints on existing requirements, or define specific computations. If domain requirements are not satisfied, the system may be unworkable. Two main problems with domain requirements:
Requirements engineering process
Processes vary widely depending on the application domain, the people involved and the organization developing the requirements. In practice, requirements engineering is an iterative process, in which the following generic activities are interleaved:
Requirements elicitation and analysis
Software engineers work with a range of system stakeholders to find out about the application domain, the services that the system should provide, the required system performance, hardware constraints, other systems, etc. Stages include:
Closed (based on pre-determined list of questions) and open interviews with stakeholders are a part of the RE process. User stories and scenarios are real-life examples of how a system can be used, which are usually easy for stakeholders to understand. Scenarios should include descriptions of the starting situation, normal flow of events, what can go wrong, other concurrent activities, the state of the system when the scenario finishes.
Use-cases are a scenario-based technique in the UML which identify the actors in an interaction and which describe the interaction itself. A set of use cases should describe all possible interactions with the system.
Problems to look for during requirements elicitation and analysis:
Requirements specification
Requirements specification is the process of writing down the user and system requirements in a requirements document. User requirements have to be understandable by end-users and customers who do not have a technical background. System requirements are more detailed requirements and may include more technical information. The requirements may be part of a contract for the system development and it is important that these are as complete as possible.
In principle, requirements should state what the system should do and the design should describe how it does this. In practice, requirements and design are inseparable.
User requirements are almost always written in natural language supplemented by appropriate diagrams and tables in the requirements document. System requirements may also be written in natural language but other notations based on forms, graphical system models, or mathematical system models can also be used. Natural language is expressive, intuitive and universal. This means that the requirements can be understood by users and customers.
Structured natural language is a way of writing system requirements where the freedom of the requirements writer is limited and all requirements are written in a standard way. This approach maintains most of the expressiveness and understand-ability of natural language but ensures that some uniformity is imposed on the specification.
Requirements validation
Requirements validation is concerned with demonstrating that the requirements define the system that the customer really wants. Requirements error costs are high so validation is very important.
What problems to look for:
Requirements validation techniques:
Requirements change
Requirements management is the process of managing changing requirements during the requirements engineering process and system development. New requirements emerge as a system is being developed and after it has gone into use. Reasons why requirements change after the system's deployment: