RE-lectur-1

7/31/2019 RE-lectur-1

1/40

1

Software Requirements

Engineering

7/31/2019 RE-lectur-1

2/40

2

Introduction

Requirements form the basis for allsoftware products

Requirements engineering is theprocess, which enables us to

systematically determine therequirements for a software product

7/31/2019 RE-lectur-1

3/40

3

Software Requirements

Lecture # 1

7/31/2019 RE-lectur-1

4/40

4

Requirement

Something required, something wanted

or needed

Websters dictionary

There is a huge difference between

wantedand neededand it should bekept in mind all the time

7/31/2019 RE-lectur-1

5/40

5

Requirements

IEEE Standard 729 defines it as (1) a

condition or capability needed by a

user to solve a problem or achieve an

objective; (2) a condition or capability

that must be met or possessed by a

system...to satisfy a contract, standard,

specification, or other formally

imposed document

7/31/2019 RE-lectur-1

6/40

6

Importance of Requirements

The hardest single part of building a

software system is deciding what to

build...No other part of the work so

cripples the resulting system if done

wrong. No other part is difficult to

rectify later

Fred Brooks

7/31/2019 RE-lectur-1

7/40

7

Requirements Engineering

Requirements elicitation

Requirements analysis and negotiation Requirements specification

System modeling

Requirements validation

Requirements management

7/31/2019 RE-lectur-1

8/40

8

Software Requirements - 1

A complete description ofwhatthe

software system will do without

describing how it will do it is

represented by the software

requirements

7/31/2019 RE-lectur-1

9/40

9


Software requirements are completespecification of the desired external

behavior of the software system to bebuilt

They also represent External behaviorof the system

7/31/2019 RE-lectur-1

10/40

10


Software requirements may be:

Abstract statements of services and/or

constraints

Detailed mathematical functions

7/31/2019 RE-lectur-1

11/40

11


Software requirements may be:

Part of the bid of contract

The contract itself

Part of the technical document, which

describes a product

7/31/2019 RE-lectur-1

12/40

12

IEEE Definition

A condition or capability that must be

met or possessed by a system...to

satisfy a contract, standard,

specification, or other formally

imposed document

IEEE Std 729

7/31/2019 RE-lectur-1

13/40

13

IEEE Definition

A condition or capability needed by a

user to solve a problem or achieve an

objective

7/31/2019 RE-lectur-1

14/40

14

Sources of Requirements

Stakeholders

People affected in some way by the

system

Documents

Existing system Domain/business area

7/31/2019 RE-lectur-1

15/40

15

Levels of Software Requirements

Stakeholders describe requirements at

different levels of detail

What versus How

One persons floor is another persons

ceiling

7/31/2019 RE-lectur-1

16/40

16

What Versus How

User needs

Product space

Actual products behavior

Architecture/data flow

Module specifications

Algorithms

Code

WhatHow

What

HowWhat

HowWhat

How

What

HowWhat

How

7/31/2019 RE-lectur-1

17/40

17

Importance of Software

Requirements The hardest single part of building a

software system is deciding what to

build...No other part of the work so

cripples the resulting system if done

wrong. No other part is difficult to

rectify later

Fred Brooks

7/31/2019 RE-lectur-1

18/40

18

Examples of Requirements - 1

The system shall maintain records of

all payments made to employees on

accounts of salaries, bonuses,

travel/daily allowances, medical

allowances, etc.

7/31/2019 RE-lectur-1

19/40

19


The system shall interface with the

central computer to send daily sales

and inventory data from every retail

store

7/31/2019 RE-lectur-1

20/40

20


The system shall maintain records of

all library materials including books,

serials, newspapers and magazines,

video and audio tapes, reports,

collections of transparencies, CD-

ROMs, DVDs, etc.

7/31/2019 RE-lectur-1

21/40

21


The system shall allow users to search

for an item by title, author, or by

International Standard Book Number

The systems user interface shall beimplemented using a web browser

7/31/2019 RE-lectur-1

22/40

22


The system shall support at least

twenty transactions per second

The system facilities which are

available to public users shall bedemonstrable in ten minutes or less

7/31/2019 RE-lectur-1

23/40

23

Kinds of Software Requirements

7/31/2019 RE-lectur-1

24/40

24

Kinds of Software Requirements

Functional requirements

Non-functional requirements

Domain requirements

Inverse requirements

Design and implementation constraints

7/31/2019 RE-lectur-1

25/40

25

Functional Requirements

7/31/2019 RE-lectur-1

26/40

26

Functional Requirements - 1

Statements describing what the system

does

Functionality of the system

7/31/2019 RE-lectur-1

27/40

27


Statements of services the system

should provide

Reaction to particular inputs

Behavior in particular situations

7/31/2019 RE-lectur-1

28/40

28


Sequencing and parallelism are also

captured by functional requirements

Abnormal behavior is also documented

as functional requirements in the formof exception handling

7/31/2019 RE-lectur-1

29/40

29


Functional requirements should be

complete and consistent

Customers and developers usually

focus all their attention on functionalrequirements

7/31/2019 RE-lectur-1

30/40

30

Functional Requirements Example # 1

The system shall solve a quadratic

equation using the following formula

x = (-b+sqrt(b24*a*c))/2*a

7/31/2019 RE-lectur-1

31/40

31


The user shall be able to search either

the entire database of patients or select

a subset from it (admitted patients, or

patients with asthma, etc.)

7/31/2019 RE-lectur-1

32/40

32


The system shall provide appropriate

viewers for the user to read documents

in the document store

7/31/2019 RE-lectur-1

33/40

33


Every order shall be allocated a unique

identifier (ORDER_ID) which the user

shall use to access that order

7/31/2019 RE-lectur-1

34/40

34


The system shall allow customers to

return non-perishable items within

fifteen days of the purchase. A

customer must present the original sale

receipt to return an item

7/31/2019 RE-lectur-1

35/40

35

Comments on Examples

Notice the level of detail in different

requirements described above. Some

are very detailed compared to others

7/31/2019 RE-lectur-1

36/40

36


Notice the ambiguity in therequirement, which uses the term

appropriate viewers

This requirement does not mention the

formats of documents and types ofviewers, which can be used

7/31/2019 RE-lectur-1

37/40

37


Notice the ambiguity in therequirement for solving the quadratic

equation. The requirement does notspeak about the possibility when thevalue of a is zero

x = (-b+sqrt(b24*a*c))/2*a

7/31/2019 RE-lectur-1

38/40

38


Incomplete and ambiguousrequirements are open to multiple

interpretations and assumptions

This can lead to the development of

poor quality, or faulty, softwareproducts

7/31/2019 RE-lectur-1

39/40

39

Summary

Requirements form the basis of allsoftware engineering projects

Functional requirements capture thebehavioral aspects/functions of theproposed automated system

Functional requirements are thebackbone of all software products

7/31/2019 RE-lectur-1

40/40

40

References

Requirements Engineering: Processes andTechniques by G. Kotonya and I.

Sommerville, John Wiley & Sons, 1998 Software Requirements: Objects, Functions,

and States by A. Davis, PH, 1993

Software Engineering 6th Edition, by I.Sommerville, 2000

Software Engineering 5th Edition, by R.Pressman