14603_srs complete (1)

7/29/2019 14603_srs Complete (1)

1/53

1

Requirements Analysis and

Specification

7/29/2019 14603_srs Complete (1)

2/53

2

Organization of this

Lecture

Brief review of previous lecturesIntroduction

Requirements analysisRequirements specificationSRS documentSummary

7/29/2019 14603_srs Complete (1)

3/53

3


Specification

Many projects fail:

because they start implementing

the system:without determining whether

they are building what the

customer really wants.

7/29/2019 14603_srs Complete (1)

4/53

4


Specification

It is important to learn:

requirements analysis andspecification techniques thoroughly.

7/29/2019 14603_srs Complete (1)

5/53

5


Specification

Goals of requirements analysis andspecification phase:

fully understand the user

requirements

remove inconsistencies, anomalies,etc. from requirements

document requirements properly inan SRS document

7/29/2019 14603_srs Complete (1)

6/53

6


Specification

Consists of two distinctactivities:

Requirements Gatheringand Analysis

Specification

7/29/2019 14603_srs Complete (1)

7/53

7


Specification

The person who undertakesrequirements analysis and specification:

known as systems analyst:

collects data pertaining to the product

analyzes collected data:

to understand what exactly needs to be

done.

writes the Software RequirementsSpecification (SRS) document.

7/29/2019 14603_srs Complete (1)

8/53

8


Specification

Final output of this phase:Software Requirements

Specification (SRS)Document.

The SRS document is reviewedby the customer.reviewed SRS document forms

the basis of all futuredevelopment activities.

7/29/2019 14603_srs Complete (1)

9/53

9

Requirements Analysis

Requirements analysisconsists of two main

activities:Requirements gathering

Analysis of the gatheredrequirements

7/29/2019 14603_srs Complete (1)

10/53

10

Requirements Analysis

Analyst gathers requirementsthrough:

observation of existing systems,studying existing procedures,

discussion with the customer and

end-users,analysis of what needs to be

done, etc.

7/29/2019 14603_srs Complete (1)

11/53

11

Requirements Gathering

If the project is to automate someexisting procedures

e.g., automating existing manualaccounting activities,

the task of the system analyst is alittle easier

analyst can immediately obtain:

input and output formats

accurate details of the operational

procedures

7/29/2019 14603_srs Complete (1)

12/53

12

Requirements Gathering(CONT.)

In the absence of a workingsystem,

lot of imagination and creativityare required.

Interacting with the customer to

gather relevant data:requires a lot of experience.

7/29/2019 14603_srs Complete (1)

13/53

13

Requirements Gathering(CONT.)

Some desirable attributes ofa good system analyst:

Good interaction skills,imagination and creativity,

experience.

7/29/2019 14603_srs Complete (1)

14/53

14

Analysis of the Gathered

Requirements

After gathering all the requirements:

analyze it:

Clearly understand the user requirements,Detect inconsistencies, ambiguities, and

incompleteness.

Incompleteness and inconsistencies:resolved through further discussions

with the end-users and the customers.

7/29/2019 14603_srs Complete (1)

15/53

15

Inconsistent requirement

Some part of the requirement:

contradicts with some other part.

Example:One customer says turn off heater

and open water shower when

temperature > 100 CAnother customer says turn off

heater and turn ON cooler whentemperature > 100 C

7/29/2019 14603_srs Complete (1)

16/53

16

Incomplete requirement

Some requirements have beenomitted:

due to oversight.Example:The analyst has not recorded:

when temperature falls below 90 Cheater should be turned ON

water shower turned OFF.

7/29/2019 14603_srs Complete (1)

17/53

17


Requirements (CONT.)

Requirements analysis involves:

obtaining a clear, in-depth

understanding of the product tobe developed,

remove all ambiguities and

inconsistencies from the initialcustomer perception of theproblem.

7/29/2019 14603_srs Complete (1)

18/53

18



It is quite difficult to obtain:

a clear, in-depth understandingof the problem:

especially if there is no working

model of the problem.

7/29/2019 14603_srs Complete (1)

19/53

19



Experienced analysts takeconsiderable time:

to understand the exactrequirements the customer has inhis mind.

7/29/2019 14603_srs Complete (1)

20/53

20



Experienced systems analystsknow -

often as a result of painfulexperiences ---

without a clear understanding ofthe problem, it is impossible todevelop a satisfactory system.

7/29/2019 14603_srs Complete (1)

21/53

21


Requirements(CONT.)

Several things about the project shouldbe clearly understood by the analyst:

What is the problem?

Why is it important to solve the problem?What are the possible solutions to the

problem?

What complexities might arise while solvingthe problem?

7/29/2019 14603_srs Complete (1)

22/53

22


Requirements(CONT.)

Some anomalies and inconsistenciescan be very subtle:

escape even most experienced eyes.

If a formal model of the system isconstructed,

many of the subtle anomalies and

inconsistencies get detected.

7/29/2019 14603_srs Complete (1)

23/53

23


Requirements(CONT.)

After collecting all data regardingthe system to be developed,

remove all inconsistencies andanomalies from the requirements,

systematically organize requirementsinto a Software Requirements

Specification (SRS) document.

7/29/2019 14603_srs Complete (1)

24/53

24

Software Requirements

Specification

Main aim of requirementsspecification:

systematically organize therequirements arrived during

requirements analysisdocument requirements properly.

7/29/2019 14603_srs Complete (1)

25/53

25

Software Requirements

Specification

The SRS document is useful invarious contexts:

statement of user needs

contract document

reference documentdefinition for implementation

7/29/2019 14603_srs Complete (1)

26/53

26

Software Requirements Specification: A

Contract Document

Requirements document is areference document.

SRS document is a contractbetween the development team andthe customer.

Once the SRS document is approvedby the customer,

any subsequent controversies are settledby referring the SRS document.

7/29/2019 14603_srs Complete (1)

27/53

27

Software Requirements Specification:

A Contract Document

Once customer agrees to the SRSdocument:

development team starts to develop theproduct according to the requirementsrecorded in the SRS document.

The final product will be acceptable to thecustomer:

as long as it satisfies all the requirementsrecorded in the SRS document.

7/29/2019 14603_srs Complete (1)

28/53

28

SRS Document (CONT.)

The SRS document is known as black-boxspecification:

the system is considered as a black boxwhose internal details are not known.

only its visible external (i.e. input/output)behavior is documented.

SInput Data Output Data

7/29/2019 14603_srs Complete (1)

29/53

29


SRS document concentrates on:

what needs to be done

carefully avoids the solution (how to do)aspects.

The SRS document serves as a contract

between development team and thecustomer.

Should be carefully written

7/29/2019 14603_srs Complete (1)

30/53

30


The requirements at this stage:

written using end-userterminology.

If necessary:

later a formal requirementspecification may be developed fromit.

7/29/2019 14603_srs Complete (1)

31/53

31

Properties of a goodSRS

document

It should be conciseand at the same time should not be

ambiguous.

It should specify what the system must doand not say how to do it.

Easy to change.,i.e. it should be well-structured.

It should be consistent.It should be complete.

P ti f d SRS

7/29/2019 14603_srs Complete (1)

32/53

32

Properties of a goodSRS

document (cont...)

It should be traceableyou should be able to trace which part of the

specification corresponds to which part of thedesign and code, etc and vice versa.

It should be verifiablee.g. system should be user friendly is not verifiable

7/29/2019 14603_srs Complete (1)

33/53

33


SRS document, normallycontains three important parts:

functional requirements,

nonfunctional requirements,

constraints on the system.

7/29/2019 14603_srs Complete (1)

34/53

34


It is desirable to consider everysystem:

performing a set of functions {fi}.

Each function fi considered as:

transforming a set of input data tocorresponding output data.

Input Data Output Data

fi

7/29/2019 14603_srs Complete (1)

35/53

35

Example: Functional

Requirement

F1: Search BookInput:

an authors name:

Output:

details of the authors books and thelocations of these books in the library.

Author Name Book Details

f1

7/29/2019 14603_srs Complete (1)

36/53

36

Functional Requirements

Functional requirementsdescribe:A set of high-level requirementsEach high-level requirement:takes in some data from the useroutputs some data to the user

Each high-level requirement:might consist of a set ofidentifiable functions

7/29/2019 14603_srs Complete (1)

37/53

37


For each high-level requirement:

every function is described in terms

ofinput data set

output data set

processing required to obtain theoutput data set from the input dataset

N f ti l

7/29/2019 14603_srs Complete (1)

38/53

38

Nonfunctional

Requirements

Characteristics of the systemwhich can not be expressed asfunctions:

maintainability,

portability,

usability, etc.

N f ti l

7/29/2019 14603_srs Complete (1)

39/53

39

Nonfunctional

Requirements

Nonfunctional requirements include:

reliability issues,

performance issues,human-computer interface issues,

Interface with other external systems,

security, maintainability, etc.

7/29/2019 14603_srs Complete (1)

40/53

40

Constraints

Constraints describe things that thesystem should or should not do.

For example,

standards compliance

how fast the system can produce results

so that it does not overload another

system to which it supplies data, etc.

7/29/2019 14603_srs Complete (1)

41/53

41

Examples of constraints

Hardware to be used,Operating systemor DBMS to be used

Capabilities of I/O devicesStandards complianceData representationsby the interfaced system

7/29/2019 14603_srs Complete (1)

42/53

42

Organization of the SRS

Document

Introduction.


Nonfunctional RequirementsExternal interface requirements

Performance requirements

Constraints

7/29/2019 14603_srs Complete (1)

43/53

43

Example Functional

Requirements

List all functional requirementswith proper numbering.Req. 1:Once the user selects the search

option,he is asked to enter the key words.

The system should output details of allbooks

whose title or author name matches any ofthe key words entered.Details include: Title, Author Name,

Publisher name, Year of Publication, ISBNNumber, Catalog Number, Location in the

Library.

7/29/2019 14603_srs Complete (1)

44/53

44

Example Functional Requirements

Req. 2:When the renew option is selected,the user is asked to enter his

membership number and password.After password validation,the list of the books borrowed by him

are displayed.

The user can renew any of the books:by clicking in the corresponding renew

box.

7/29/2019 14603_srs Complete (1)

45/53

45

Req. 1:

R.1.1:Input:search option,Output: user prompted to enter the key words.

R1.2:

Input: key wordsOutput: Details of all books whose title or author

name matches any of the key words.Details include: Title, Author Name, Publisher name, Year

of Publication, ISBN Number, Catalog Number, Location in

the Library.Processing: Search the book list for the keywords

7/29/2019 14603_srs Complete (1)

46/53

46

Req. 2:

R2.1:Input:renew option selected,Output: userprompted to enter his

membership number and password.R2.2:Input: membership number and passwordOutput:list of the books borrowed by userare

displayed. User prompted to enter books to berenewed or

userinformed about bad passwordProcessing: Password validation,search

books issued to the user from borrower listand display.

7/29/2019 14603_srs Complete (1)

47/53

47

Req. 2:

R2.3:

Input: user choice for renewal of the

books issued to him through mouseclicks in the corresponding renew box.

Output: Confirmation of the books

renewedProcessing: Renew the books selected

by the in the borrower list.

E l f B d SRS

7/29/2019 14603_srs Complete (1)

48/53

48

Examples of Bad SRS

Documents

Unstructured Specifications:Narrative essay --- one of the worst

types of specification document:

Difficult to change,

difficult to be precise,

difficult to be unambiguous,

scope for contradictions, etc.

E amples of Bad SRS

7/29/2019 14603_srs Complete (1)

49/53

49

Examples of Bad SRS

Documents

Noise:Presence of text containing information

irrelevant to the problem.

Silence:aspects important to proper solution of the

problem are omitted.

Examples of Bad SRS

7/29/2019 14603_srs Complete (1)

50/53

50

Examples of Bad SRS

Documents

Overspecification:

Addressing how to aspects

For example, Library member names shouldbe stored in a sorted descending order

Overspecification restricts the solution spacefor the designer.

Contradictions:Contradictions might arise

if the same thing described at several places indifferent ways.

E l f B d SRS

7/29/2019 14603_srs Complete (1)

51/53

51

Examples of Bad SRS

Documents

Ambiguity:Literary expressions

Unquantifiable aspects, e.g. good user

interfaceForward References:

References to aspects of problem

defined only later on in the text.

Wishful Thinking:

Descriptions of aspects

for which realistic solutions will be hard to find.

7/29/2019 14603_srs Complete (1)

52/53

52

Summary

Requirements analysis andspecification

an important phase of software

development:

any error in this phase would affectall subsequent phases of

development.

Consists of two different activities:

Requirements gathering and analysis

7/29/2019 14603_srs Complete (1)

53/53

SummaryThe aims of requirements analysis:Gather all user requirements

Clearly understand exact user requirements

Remove inconsistencies andincompleteness.

The goal of specification:

systematically organize requirementsdocument the requirements in an SRS

document.