Comments 0

Presentation transcript

The process of establishing the services that thecustomer requires from a system and theconstraints under which it operates and isdeveloped.

The requirements themselves are thedescriptions of the system services andconstraints that are generated during therequirements engineering process.

𝐴=𝜋𝑟2

Requirements abstraction (Davis)

“If a company wishes to let a contract for a large softwaredevelopment project, it must define its needs in a sufficientlyabstract way that a solution is not pre-defined. Therequirements must be written so that several contractorscan bid for the contract, offering, perhaps, different ways ofmeeting the client organization’s needs. Once a contracthas been awarded, the contractor must write a systemdefinition for the client in more detail so that the clientunderstands and can validate what the software will do.Both of these documents may be called the requirementsdocument for the system.”

𝐴=𝜋𝑟2

Types of requirement

User requirements

Statements in natural language plus diagramsof the services the system provides and itsoperational constraints. Written for customers.

System requirements

A structured document setting out detaileddescriptions of the system’s functions,services and operational constraints. Defineswhat should be implemented so may be partof a contract between client and contractor.

𝐴=𝜋𝑟2

User and system requirements

𝐴=𝜋𝑟2

Readers of different types of requirementsspecification

𝐴=𝜋𝑟2

Functional and non-functional requirements

Functional requirements

Statements of services the system should provide, howthe system should react to particular inputs and how thesystem should behave in particular situations.

Non-functionalrequirements

Constraintson the services or functions offered by thesystem such as timing constraints, constraints on thedevelopment process, standards, etc.

Domain requirements

Constraints on the system from the domain of operation

𝐴=𝜋𝑟2

Functional requirements

Describe functionality or system services.

Depend on the type of software, expectedusers and the type of system where thesoftware is used.

Functional user requirements may behigh-level statements of what the systemshoulddo.

Functionalsystem requirements shoulddescribe the system services in detail.

𝐴=𝜋𝑟2

Functional requirements for the MHC-PMS

A user shall be able to search theappointments lists for all clinics.

The system shall generate each day, foreach clinic, a list of patients who areexpected to attend appointments that day.

Each staff member using the system shallbe uniquely identified by his/

her8-digitemployee number.

𝐴=𝜋𝑟2

Requirementsimprecision

Problems arise when requirements are notprecisely stated.

Ambiguous requirements may be interpreted indifferent ways by developers and users.

The system shall implement patient privacy provisions as set out inHStan-03-2006-priv.

𝐴=𝜋𝑟2

Usability requirements

The system should be easy to use bymedical staff and should be organized insuch a way that user errors are minimized.

Medical staff shall be able to use all thesystem functions after four hours of training.After this training, the average number oferrors made by experienced users shall notexceed two per hour of system use. (Testablenon-functional requirement)

𝐴=𝜋𝑟2

Metrics for specifying nonfunctionalrequirements

Property

Measure

Speed

Processed

transactions/second

User/event

response

time

Screen

refresh

time

Size

Mbytes

Number

of

ROM

chips

Ease

of

use

Training

time

Number

of

help

frames

Reliability

Mean

time

to

failure

Probability

of

unavailability

Rate

of

failure

occurrence

Availability

Robustness

Time

to

restart

after

failure

Percentage

of

events

causing

failure

Probability

of

data

corruption

on

failure

Portability

Percentage

of

target

dependent

statements

Number

of

target

systems

𝐴=𝜋𝑟2

Domain requirements

The system’s operational domain imposesrequirements on the system.

For example, a train control system has to take intoaccount the braking characteristics in differentweather conditions.

Domain requirements be new functionalrequirements, constraints on existingrequirements or define specific computations.

If domain requirements are not satisfied, thesystem may be unworkable.

𝐴=𝜋𝑟2

Train protection system

This is a domain requirement for a train protectionsystem:

The deceleration of the train shall be computed as:

Dtrain

=Dcontrol

+Dgradient

whereDgradient

is 9.81ms2 * compensated gradient/alpha andwhere the values of 9.81ms2 /alpha are known for different typesof train.

It is difficult for a non-specialist to understand theimplications of this and how it interacts with otherrequirements.

𝐴=𝜋𝑟2

Domain requirements problems

Understandability

Requirements are expressed in the languageof the application domain;

This is often not understood by softwareengineers developing the system.

Implicitness

Domain specialists understand the area sowell that they do not think of making thedomain requirements explicit.

𝐴=𝜋𝑟2

The

software requirementsdocument

The

software requirementsdocument is theofficial statement of what is required of thesystem developers.

Should include both a definition of userrequirements and a specification of the systemrequirements.

It is NOT a design document. As far as possible,it should set of WHAT the system should dorather than HOW it should doit.

𝐴=𝜋𝑟2

Problem Identification & RequirementsSpecification

Answering question:

What problem is being solved?

10-25% of life cycle should be spent here

E.g., Expected software or application life is 10 years

•1 to 2.5 years in this phase

Techniques

Partitioning: Divide and conquer

•Parts & relationships

Abstraction: Defining in general terms

•Leaving out details

Projection: Viewing problem from different perspectives

•User perspective, programmer perspective, maintainer perspective

Many other techniques

•E.g., data flow diagrams

𝐴=𝜋𝑟2

Users of a requirements document

𝐴=𝜋𝑟2

Requirements document variability

Information in requirements document dependson type of system and the approach todevelopment used.

Systems developed incrementally will, typically,have less detail in the requirements document.

Requirements documents standards have beendesigned e.g. IEEE standard. These are mostlyapplicable to the requirements for large systemsengineering projects.

𝐴=𝜋𝑟2

The structure of a requirements document

Chapter

Description

Preface

This

should

define

the

expected

readership

of

the

document

and

describe

its

version

history,

including

a

rationale

for

the

creation

of

a

new

version

and

a

summary

of

the

changes

made

in

each

version.

Introduction

This

should

describe

the

need

for

the

system.

It

should

briefly

describe

the

system’s

functions

and

explain

how

it

will

work

with

other

systems.

It

should

also

describe

how

the

system

fits

into

the

overall

business

or

strategic

objectives

of

the

organization

commissioning

the

software.

Glossary

This

should

define

the

technical

terms

used

in

the

document.

You

should

not

make

assumptions

about

the

experience

or

expertise

of

the

reader.

User

requirements

definition

Here,

you

describe

the

services

provided

for

the

user.

The

nonfunctional

system

requirements

should

also

be

described

in

this

section.

This

description

may

use

natural

language,

diagrams,

or

other

notations

that

are

understandable

to

customers.

Product

and

process

standards

that

must

be

followed

should

be

specified.

System

architecture

This

chapter

should

present

a

high-level

overview

of

the

anticipated

system

architecture,

showing

the

distribution

of

functions

across

system

modules.

Architectural

components

that

are

reused

should

be

highlighted.

𝐴=𝜋𝑟2

The structure of a requirements document

Chapter

Description

System

requirements

specification

This

should

describe

the

functional

and

nonfunctional

requirements

in

more

detail.

If

necessary,

further

detail

may

also

be

added

to

the

nonfunctional

requirements.

Interfaces

to

other

systems

may

be

defined.

System

models

This

might

include

graphical

system

models

showing

the

relationships

between

the

system

components

and

the

system

and

its

environment.

Examples

of

possible

models

are

object

models,

data-flow

models,

or

semantic

data

models.

System

evolution

This

should

describe

the

fundamental

assumptions

on

which

the

system

is

based,

and

any

anticipated

changes

due

to

hardware

evolution,

changing

user

needs,

and

so

on.

This

section

is

useful

for

system

designers

as

it

may

help

them

avoid

design

decisions

that

would

constrain

likely

future

changes

to

the

system.

Appendices

These

should

provide

detailed,

specific

information

that

is

related

to

the

application

being

developed;

for

example,

hardware

and

database

descriptions.

Hardware

requirements

define

the

minimal

and

optimal

configurations

for

the

system.

Database

requirements

define

the

logical

organization

of

the

data

used

by

the

system

and

the

relationships

between

data.

Index

Several

indexes

to

the

document

may

be

included.

As

well

as

a

normal

alphabetic

index,

there

may

be

an

index

of

diagrams,

an

index

of

functions,

and

so

on.

𝐴=𝜋𝑟2

Ways of writing a system requirementsspecification

Notation

Description

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;

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

𝐴=𝜋𝑟2

Example requirements for the insulin pumpsoftware system

3.2 The system shall measure the blood sugar anddeliver insulin, if required, every 10 minutes.

(Changesin blood sugar are relatively slow so more frequentmeasurement is unnecessary; less frequentmeasurement could lead to unnecessarily high sugarlevels.)

3.6 The system shall run a self-test routine everyminute with the conditions to be tested and theassociated actions defined in Table 1.

(A self-testroutine can discover hardware and software problemsand alert the user to the fact the normal operation maybe impossible.)

𝐴=𝜋𝑟2

A structured specification of a requirement foran insulin pump

𝐴=𝜋𝑟2

A structured specification of a requirement foran insulin pump

𝐴=𝜋𝑟2

Tabular specification of computation for aninsulin pump

Condition

Action

Sugar

level

falling

(r2

<

r1)

CompDose

=

0

Sugar

level

stable

(r2

=

r1)

CompDose

=

0

Sugar

level

increasing

and

rate

of

increase

decreasing

((r2

–

r1)

<

(r1

–

r0))

CompDose

=

0

Sugar

level

increasing

and

rate

of

increase

stable

or

increasing

((r2

–

r1)

≥

(r1

–

r0))

CompDose

=

round

((r2

–

r1)/4)

If

rounded

result

=

0

then

CompDose

=

MinimumDose

𝐴=𝜋𝑟2

Stakeholders in the MHC-PMS

Patients

whose information is recorded in thesystem.

Doctors

who are responsible for assessing andtreating patients.

Nurses who coordinate the consultations withdoctors and administer some treatments.

Medical receptionists

who manage patients’appointments.

IT staff who are responsible for installing andmaintaining the system.

𝐴=𝜋𝑟2

Scenarios

Scenarios are real-life examples of how asystem can be used.

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 the scenariofinishes.

𝐴=𝜋𝑟2

Scenario for collecting medical history in MHC-PMS

𝐴=𝜋𝑟2

Scenario for collecting medical history in MHC-PMS

𝐴=𝜋𝑟2

Requirements validation

Concerned with demonstrating that therequirements define the system that thecustomer really wants.

Requirements error costs are high sovalidation is very important

Fixing a requirements error after delivery maycost up to 100 times the cost of fixing animplementation error.

𝐴=𝜋𝑟2

Requirements checking

Validity.

Doesthe system provide the functionswhich best support the customer’s needs?

Consistency.Are there any requirementsconflicts?

Completeness. Areall functions required by thecustomer included?

Realism. Canthe requirements be implementedgiven available budget and technology

Requirements management is the process of managingchanging requirements during the requirementsengineering process and system development.

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

You need to keep track of individual requirements andmaintain links between dependent requirements so thatyou can assess the impact of requirements changes.You need to establish a formal process for makingchange proposals and linking these to systemrequirements.

𝐴=𝜋𝑟2

Changing requirements

Requirementswill

change!

inadequately captured

or expressed in the first place

user and businessneeds may change

during the project

Validation is neededthroughout

the softwarelifecycle, not only when the “final system” isdelivered!

build constantfeedback

into your project plan

plan forchange

earlyprototyping

[e.g., UI] can help clarify requirements

𝐴=𝜋𝑟2

Changing requirements

The business and technical environment of the systemalways changes after installation.

New hardware may be introduced, it may be necessary tointerface the system with other systems, business priorities maychange (with consequent changes in the system supportrequired), and new legislation and regulations may be introducedthat the system must necessarily abide by.

The people who pay for a system and the users of thatsystem are rarely the same people.

System customers impose requirements because oforganizational and budgetary constraints. These may conflictwith end-user requirements and, after delivery, new features mayhave to be added for user support if the system is to meet itsgoals.

𝐴=𝜋𝑟2

Requirements evolution

𝐴=𝜋𝑟2

Requirements change management

Deciding if a requirements change should be accepted

Problem analysis and change specification

•During this stage, the problem or the change proposal is analyzedto check that it is valid. This analysis is fed back to the changerequestor who may respond with a more specific requirementschange proposal, or decide to withdraw the request.

Change analysis and costing

•The effect of the proposed change is assessed using traceabilityinformation and general knowledge of the system requirements.Once this analysis is completed, a decision is made whether or notto proceed with the requirements change.

Change implementation

•The requirements document and, where necessary, the systemdesign and implementation, are modified. Ideally, the documentshould be organized so that changes can be easily implemented.