Requirements Engineering

The primary measure of success of a software system is the degree to which it meets the purpose for which it was intended.

Software systems requirements engineering (RE) is the process of discovering that purpose and documenting these in a form that is amenable to analysis, communication, and subsequent implementation.

Requirements are typically expressed from the system’s point of view.

Examples of requirements:

The system shall allow users to reserve taxis.

The system should be implemented in Java.

Types of requirements

• Functional requirements:
  • Describe the interactions between the system and its environment.
  • Independent from implementation.
  • These are the main goals the software to be has to fulfill.
  • Examples:
    • "A word processor user should be able to search for strings in the text"
    • "The system shall allow users to reserve taxis"

• Non-functional requirements:
  • User-visible aspects of the system not directly related to functional behavior.
  • Constraints on how functionality has to be provided to the end user.
  • Have a strong impact on the structure of the system to be.
  • Examples:
    • "The response time must be less than 1 second"
    • "The server must be available 24 hours a day"

    

• Constraints (“pseudo requirements”):
  • Imposed by the client or the environment in which the system operates.
  • Examples:
    • "The implementation language must be Java"
    • "The credit card payment system must be able to be dynamically invoked by other systems relying on it"

Example of bad requirements:

• Two requirements instead of one in the same “sentence”: if one of the requirements is satisfied and the other not, is the general requirement satisfied?

The World and the Machine

Terminology:

• The machine = the portion of system to be developed.
  • typically, software-to-be + hardware

• The world (a.k.a. the environment) = the portion of the real-world affected by the machine

The purpose of the machine is always in the world.

Requirements engineering is concerned with phenomena occurring in the world.

For an ambulance dispatching system:

• the occurrences of incidents

• the report of incidents by public calls

• the encodings of calls' details into the dispatching software

• the allocation of an ambulance

• the arrival of an ambulance at the incident location

As opposed to phenomena occurring inside the machine:

• the creation of a new object of class Incident

• the update of a database entry

Requirement models are models of the world!

Goals, domain assumptions, requirements

Goals are prescriptive assertions formulated in terms of world phenomena (not necessarily shared). (What we want to achieve)

Domain properties/assumptions are descriptive assertions assumed to hold in the world. (We have no control on them)

Requirements are prescriptive assertions formulated in terms of shared phenomena.

Example:

Goal:

• "For every urgent call reporting an incident, an ambulance should arrive at the incident scene within 14 minutes"

Domain assumptions:

• "For every urgent call, details about the incident are correctly encoded"

• "When an ambulance is mobilized, it will reach the incident location in the shortest possible time"

• "Accurate ambulances’ locations are known by GPS"

• "Ambulance crews correctly signal ambulance availability through mobile data terminals on board of ambulances"

Requirement:

• "When a call reporting a new incident is encoded, the Automated Dispatching Software should mobilize the nearest available ambulance according to information available from the ambulances’ GPS and mobile data terminals".

The requirements R are complete if:

1. R ensure satisfaction of goals G in the context of domain properties D
   1. R and D ⊨ G
   2. Analogy with program correctness: a Program P running on a particular Computer C is correct if it satisfies the Requirements R
      1. P and C ⊨ R

2. G adequately capture all the stakeholders’ needs

3. D represent valid properties/assumptions about the world