Soft Engineering Ch 4: Requirements Engineering

Requirements Engineering

The process of establishing the services that a customer
requires from a system and the constraints under which
it operates and is developed.

User requirements

Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.

System requirements

A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented so written for developers and may be part of a contract between client and contractor.

AGILE Methods & Requirements

• Many AGILE methods argue that producing detailed system requirements is a waste of time as requirements change so quickly.

• AGILE methods usually use incremental requirements engineering and may express requirements as ‘user
  stories’ (discussed in Chapter 3).

• This is practical for business systems but problematic for systems that require pre-delivery analysis (E.G., critical systems) or systems developed by several teams.

Functional Requirements

• Statements of services the system should provide in detail, how the system should react to particular inputs and how the system should behave in particular situations.

• May state what the system should not do.

• Depend on the type of software, expected users and the type of system where the software is used.

Non-functional requirements

• Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.

• Often apply to the system as a whole rather than individual features or services.

• Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless.

Requirements Elicitation

Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational
constraints. (usually through interviewing customers)
May involve end-users, managers, engineers involved in
maintenance, domain experts, trade unions, etc. These
are called stakeholders.

Closed Interviewing

based on pre-determined list of questions

Open interviews

where various issues are explored with stakeholders.

Effective Interviewing

• Be open-minded, avoid pre-conceived ideas about the requirements and are willing to listen to stakeholders.

• Prompt the interviewee to get discussions going using a springboard question, a requirements proposal, or by working together on a prototype system.

Ethnography

Observing the stakeholders social and organizational, and day-to-day work habits in the working environment to infer requirements for software.

Scope of Ethnography

Requirements that are derived from the way that people
actually work rather than the way which process
definitions suggest that they ought to work.
 Requirements that are derived from cooperation and
awareness of other people’s activities.
 Awareness of what other people are doing leads to changes in the ways in which we do things.
 Ethnography is effective for understanding existing
processes but cannot identify new features that should
be added to a system.

Stories and Scenarios

Real-life examples of how a system can be used.
A description of how a system may be used for a particular task.
 Because they are based on a practical situation,
stakeholders can relate to them and can comment on
their situation with respect to the story.
 User stories

• As a (user type) I want to (action/feature) so that (reason)

Scenarios

A structured form of user story

They should include:
 A description of the starting situation
 A description of the normal flow of events
 A description of what can go wrong
 Information about other concurrent activities
 A description of the state when it finishes

Requirement Specification

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.
 It is therefore important that these are as complete as possible.

Natural Language

The requirements are written using numbered sentences in natural language. Each sentence should express one requirement.

Structured natural language

The requirements are written in natural language on a standard form or template. Each field provides information about an aspect of the requirement.

Design description languages

This approach uses a language like a programming language, but with more abstract features to specify the requirements by defining an operational model of the system. This approach is now rarely used although it can be useful for interface specifications.

Graphical notations

Graphical models, supplemented by text annotations, are used to define the functional requirements for the system;

Ex: UML use case and sequence diagrams are commonly used.

Mathematical specifications

These notations are based on mathematical concepts such as finite-state machines or sets. Although these unambiguous specifications can reduce the ambiguity in a requirements document, most customers don’t understand a formal specification. They cannot check that it represents what they want and are reluctant to accept it as a system contract.

Guidelines for Writing Requirements Specifications

• Invent a standard format and use it for all requirements.

• Use language in a consistent way. Use shall for
  mandatory requirements, should for desirable
  requirements.

• Use text highlighting to identify key parts of the
  requirement.

• Avoid the use of computer jargon.

• Include an explanation (rationale) of why a requirement is necessary.

Form-Based Requirement Specifications

• Definition of the function or entity.

• Description of inputs and where they come from.

• Description of outputs and where they go to.

• Information about the information needed for the computation and other entities used.

• Description of the action to be taken.

• Pre and post conditions (if appropriate).

• The side effects (if any) of the function.

Software requirement document

the official statement of what is required of the system developers.

Should include both a definition of user requirements and a specification of the system requirements.
It is NOT a design document. As far as possible, it
should be a set of items describing WHAT rather than HOW to do it.