Software Engineering

C h a p t e r 4

Requirements E n g i n e e r i n gDr.Doaa Sami

Modified from Sommerville’s originals

Objectives2

Understand the concepts of user and system requirements.

Show differences between functional and nonfunctional

requirements.

Understand how requirements may be organized in a software

requirements document.

Understand the principal requirements engineering activities

of elicitation, analysis and validation.

Understand why requirements management is necessary.

3

Requirements Engineering

Requirements: The descriptions of the system

services and constraints that are generated during

the requirements engineering process.

Requirements Engineering (RE): The process of finding out, analyzing, documenting and checking these services and constraints.

Developed during the first phase in the software

development life cycle.

4

What is a Requirement?

It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification.

“If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organization's needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system.”

5

Requirements Types

User Requirements

Statements in a natural language plus diagrams of

the

services that system provides and its operational constraints.

Written for customers.

System Requirements

A structured document setting out more detailed to define

exactly what should be implemented, descriptions of the

system’s functions, services and operational constraints.

Written for those who are involved in system

implementation. A user requirement may expanded into several system requirements.

6

User & System Requirements Example

Readers of different types of requirements specification

7Chapter 4 Requirements engineering

constraints.

functions, services and operational

Defines what should be

User Requirements Vs. System Requirements

7User Requirements System Requirements

Written for customers . Statements that set out detailed

Statements in natural language. descriptions of the system’s

Describe the services that system constraints. provides and its operational

implemented so may be part of a

May include diagrams or tables. contract between client and

Should describe functional and non- contractor.

functional requirements.

Intended to be a basis for

Should be understandable by designing the system.

system users who don’t have Can be illustrated using system detailed technical knowledge. models.

We provide a definition for a user We provide a specification for a

requirement. system requirement.

8

Functional & Non-Functional Requirements Functional Requirements

Statements of services the system should provide, specify how the system should react to particular inputs or situation.

• They say what the system is supposed to do, not do.

Non-Functional Requirements Defines system properties and constraints such as

timing constraints, constraints on the development process, etc.

• Applied to the system as a whole, rather than individual system features or services.

Domain Requirements Derived from the domain of operation. They may be new functional requirements that constrain existing functional requirements.

9

Functional Requirements

Describe functionality or system services. Depend on:

The type of software being developed. Expected users. The general approach taken by the organization.

Functional user requirements may be high-level statements of what the system should do.

Functional system requirements should describe the system services in detail, that

includes input and outputs.

10

The LIBSYS Case Study

A library system that provides a single interface to a number of databases of articles in different libraries.

Users can search for, download and print these articles for personal study.

11

Functional Requirements for LIBSYS

1. The user shall be able to search databases for a

specific materials.

2. The system shall provide appropriate viewers for

the user to read documents in the document store.

3. Every order shall be allocated a unique identifier

(ORDER_ID) which the user shall be able to copy

to the account’s permanent storage area.

12

Ambiguous Requirements

Problems arise when requirements are not precisely stated (Ambiguous).

Ambiguous requirements may be interpreted in different ways by developers and users.

Consider the term ‘appropriate viewers ’ in requirement(2) of LIBSYS:

User intention – special purpose viewer for each differentdocument type.

Developer interpretation –provide text viewer that shows the

contents of the documents.

13

Requirements Completeness and Consistency In principle, requirements should be both

complete and consistent. Completeness:

All services required by the user should be defined.

Consistency: Requirements should not have contradictory descriptions

or definitions.

In practice, for large and complex systems, it is impossible to produce a complete and consistent requirements document.

Non-Functional Requirements

14

Define system properties rather than specific services.

Example of non-functional requirements:

System properties: reliability, response time, maintainability, storage requirements.

Constraints: I/O device capability, data representations, etc.

Process requirements: Mandating particular CASE system, Programming language.

15

Non-Functional Requirements Classifications Product Requirement

Specify that the delivered product must behave in a particular

way e.g. Performance: how fast systems is, and Reliability: acceptable failure rate.

Organizational Requirement (process requirement)

Requirements which are a consequence of organisational

policies and procedures e.g. process requirements that define how the system will be used.

External Requirement Requirements which arise from factors which are

external to the system and its development process e.g.

Interoperability: how system work with other system on other organization, Legislative requirements law requirements.

Examples of nonfunctional requirements in the MHC-PMS

Product requirementThe MHC-PMS shall be available to all clinics during normal working hours (Mon–Fri, 0830–17.30). Downtime within normal working hours shall not exceed five seconds in any one day.

Organizational requirementUsers of the MHC-PMS system shall authenticate themselves using their health authority identity card.

External requirementThe system shall implement patient privacy provisions as set out in HStan-03-2006-priv.

17Chapter 4 Requirements engineering

16

Non-Functional Requirements Classifications

17

Non-Functional Requirements Implementation

Non-functional requirements may affect the overall

architecture of a system rather than the individual

components. For example, to ensure that performance

requirements are met, you may have to organize the system

to minimize communications between 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

existingrequirements.

18

Goals and Requirements

Common problem with non-functional

requirement is that user express them as a

general goal.

Goals:

General intention of the user such as ease of use.

Verifiable Non-Functional Requirement:

Statements using some measures that can be objectively

tested.

Goals are helpful to developers as they

convey the intentions of the system users.

19

Example

Goal: The system shall be easy to use.

Better expressed as: Experienced users shall be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users shall not exceed two per day.

20

Screen refresh time

Availability

Non-Functional Requirements Specifying Metrics

Property Measure

Speed User/event

response time

Size Number of ROM chips

Ease of use Training time

Reliability Rate of failure

occurrence

Time to restart after failure

Robustness Percentage of events causing failure

Probability of data corruption on failure

Portability Number of target systems

21

Domain Requirements

The operational domain of the system imposes requirements on the system. For example, a train control system has to take into

accountthe braking characteristics in different weather

conditions.

Domain requirements may be new functional requirements, constraints on existing

requirements or define specific computations. If domain requirements are not satisfied, the

system may be unworkable.

22

LIBSYS Domain Requirement

Because of copyright restrictions, some documents

must be deleted immediately on arrival.

Depending on the user’s requirements, these documents will either be printed locally on the system server for manually forwarding to the user or routed to a network printer.

23

Domain Requirements Problems

Understandability Requirements are expressed in the language of the

application domain;

This is often not understood by software engineers developingthe system.

Implicitness Domain specialists understand the area so well that

they do not think of making the domain requirements explicit.

24

Software Requirements Specification (SRS)

Representing requirements using SRS document: The software requirements specifications document is 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 set WHAT the

system should do rather than HOW it should do it.

25

Ways of Writing a SRS

1. Natural language The requirements are written using numbered

sentences in natural language. Each sentence should express one requirement.

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.

26

Problems with Natural Language

Lack of clarity

Precision is difficult without making document

difficult to read.

Requirements confusion

Functional and non-functional requirements tend

to be mixed-up.

Requirements Mixture

Several different requirements may be expressed

together.

Example requirements for the insulin pump software system

3.2 The system shall measure the blood sugar and deliver insulin, if required, every 10 minutes. (Changes in blood sugar are relatively slow so more frequent measurement is unnecessary; less frequent measurement could lead to unnecessarily high sugar levels.)

3.6 The system shall run a self-test routine every minute with the conditions to be tested and the associated actions defined in Table 1. (A self-test routine can discover hardware and software problems and alert the user to the fact the normal operation may be impossible.)

29Chapter 4 Requirements engineering

27

Ways of Writing a SRS

2. Structured natural language

The freedom of the requirements writer is limited.

Requirements are written in a standard form or template.

Each field provides information about an aspect of the

requirement.

3. 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.

28

Ways of Writing a SRS

4. Graphical models Supplemented by text annotations, are used to define

the functional requirements for the system; UML use

case and sequence diagrams are commonly used.

Use cases for the MHC-PMS

32Chapter 4 Requirements engineering

29

Users of the SRS Document

Customers check that requirements meet

needs.

Managers plan developments process.

System engineers understand what

system to be developed.

System test engineers develop validation

tests for the system.

System maintenance engineers

understand the system and the relationships

between its parts.

30

describe its version history,

It should also describe how the system fits into the overall business or

definitiondescription may use natural language, diagrams, or other notations that

modules. Architectural components that are reused should be

Structure of a Requirements Document

Chapter Description

Preface This should define the expected readership of the

document and

This should describe the need for the system. It should briefly describe

Introduction the system’s functions and explain how it will work with

other systems.

strategic objectives of the organization commissioning the software.

Glossary This should define the technical terms used in the document.

Here, describe the services provided for the user. The non-functionalUser

Requirements

system requirements should also be described in this

section. This

are understandable to customers. Product and process standards that must be followed should be specified.

This chapter should present a high-level overview of the anticipatedSystem architecture

system architecture, showing the distribution of functions

across system

highlighted.

31

between the system components and the system and its environment.

Structure of a Requirements Document Cont.

Chapter Description

System This should describe the functional and nonfunctional requirements in more Requirements detail. If necessary, further detail may also be added to the nonfunctional specification requirements. Interfaces to other systems may be defined.

System Models This might include graphical system models showing the

relationships

This should describe the fundamental assumptions on which the system is

System Evolution based, and any anticipated changes due to hardware evolution, changing user needs, and so on.

These should provide detailed, specific information that is related to theAppendices application being developed; for example, hardware and

databasedescriptions and Hardware requirements.

Index Several indexes to the document may be included.

32

Requirements Engineering Processes

The processes used for RE vary widely depending

on the application domain, the people involved and

the organisation developing the requirements.

However, there are four generic activities which

common to all requirements engineering processes:

1. Feasibility study.

2. Requirements elicitation and analysis.

3. Requirements specification.

4. Requirements validation.

33

Requirements Engineering Processes

34

1. Feasibility Study

Feasibility study decides whether or not the

proposed system is worthwhile.

A short focused study that checks

If the system contributes to organisational objectives;

If the system can be engineered using current technology

and within budget;

If the system can be integrated with other systems

that are used.

A spiral view of the requirements engineering

process

39Chapter 4 Requirements engineering

35

2. Requirements Election and Analysis

software engineers work with customers and system end-users to find out about the application domain, the services that the system should provide and the system’s operational constraints.

May involve a variety of different kinds of people in an organization: end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders.

Can you identify possible stakeholders for theLIBSYS?

36

2. Requirements Election and Analysis Cont.

Requirements Discovery

Sources of information

Documentation ex: Existing documents and files

(business mission, sample forms, flowcharts...etc.

System stakeholders by:

Interviews.

Observation (ethnography).

Questioners.

Specifications of similar systems (reports).

37

System Models

Requirements Analysis (System Models)

The model aids the analyst in understanding

the system, thereby makes the

requirements analysis easier and more

systematic.

The model becomes the focal point of review.

The model becomes foundation for design.

Produced during requirements analysis.

38

3. Requirements Specifications

Requirements specifications

o It is the final work product produced by the

requirements engineer.

o The SRS document

o It serves as a foundation for the software design and

implementation.

39

4. Requirements Validation

The process of ensuring that the requirements actually define the system that the customer wants.

Why is it important? The cost of fixing a requirements problem by

making a system change is much greater than repairing design or coding errors.

40

4. Requirements Validation Cont.

Validity checks Is this what the user wants?

Consistency checks Requirements should not conflict

Completeness checks Requirements should define all functions and constraints

Realism checks Ensure they could be implemented

Verifiability Requirements should be written so that they are

verifiable, you should be able to write tests for each requirement.

41

Requirements Validation Techniques

Requirements reviews

A team of reviewers manually check the

requirements.

Prototyping

An executable model of the system is demonstrated to

customers.

Test-case generation

Requirements should be testable. If tests are difficult

or impossible to design, this means that the

requirements will be difficult to implement.

42

Requirements Management

Requirements Management is the process of

controlling changes to system requirements. New requirements emerge as a system is beingdeveloped and after it has gone into use.

You need to keep track of individual requirements and maintain links between dependent requirements, so that you can assess the impact of requirements changes.

You need to establish a formal process for making change proposals and linking these to system requirements.

Requirements change management

48Chapter 4 Requirements engineering

43

Summery

Requirements for a software system set out what the

system should do and define constraints on its

operation and implementation. Functional requirements are statements of

the services that the system must provide or are descriptions of how some computations must

be carried out. Non-functional requirements often

constrain the system being developed and the

development process being used.

44

Summery

You can use a range of techniques for requirements

elicitation including interviews, scenarios and use-

cases . Requirements validation is the process of

checking the requirements for validity, consistency, completeness, realism and verifiability.

Business, organizational and technical changes

inevitably lead to changes to the requirements for a

software system. Requirements management is the

process of managing and controlling these changes.