122034900 Requirement Analysis

8/9/2019 122034900 Requirement Analysis

1/28

Requirements Analysis&

Requirements Specification

Originally developed by Michael Madigan

StorageTekManager, PAL Engineering

Software Engineering of Standalone Programsniversity of !olorado, "o#lder


2/28

Requirements Engineering

Requirements Elicitation Requirements Analysis

Requirements Specification Requirements Verification

Requirements Management

Requirements Engineering


3/28

Requirements Analysis & Specification

DefinitionsRequirements Analysis

–The process of studying and analyzing the c#stomer and the#ser$stakeholder needs to arrive at a definition of software

re%#irements&'Requirements Specification

–A doc#ment that clearly and precisely( describes, each of theessential re%#irements of the software and the e)ternal

interfaces&(functions, performance, design constraint, and qualityattributes)

–Each re%#irement is defined in s#ch a way that its achievementis capable of being objectively verified by a prescribed method*

for e)ample inspection, demonstration, analysis, or test&+


4/28

Types of Requirements

Functional requirementsPerformance requirements

–Speed, accuracy, frequency, throughputExternal interface requirementsDesign constraints

–Requirements are usually about “hat!, this is a

“ho!"#uality attributes – i"e" reliability, portability, maintainability,

supportability


5/28

Wat !s" #o$ Dilemma

%

User Needs

User Needs

System

Requirements

System

Requirements

System Design

System Design

Software

Requirements

Software

Requirements

Software

Design

Software

Design

What

How

WhatHow

What

How

WhatHow


6/28

Requirements !s" Design

e%#irements -esign

Describe what will be delivered3 Describe how it will be done3

Primary goal of analysis:.-ESTA.-/.01

Primary goal of design:OPT/M/2AT/O.1

There is more than one solution There is only one (final) solution

Customer interested Customer not interested (Most ofthe time) excet for external


7/28

Soft$are uality Attributes

'

orrectnessReliability

– Rating * + (um Errors- um ./) – an be allocated to subsystems

Efficiency 0ntegrity1sabilitySur!i!ability2aintainability

3erifiability4le5ibility6ortabilityReusability 0nteroperabilityE5pandability


8/28

Analysis of Elicitation

results elps to createa 3isionSettle on which problem

3 E)plain in the problem statement 4+&+5

Marketing gro#p establishes positioning of the prod#ct 4+&15Stakeholder and ser S#mmaries

3 ser is a special case of stakeholder3 /dentify all stakeholders w&r&t& development6

.ame epresents ole3 /dentify all #sers w&r&t& system6 .ame -escription Stakeholder


9/28

Sta7eolder 6rofiles (%"8)

epresentative 3 who 4name5 is representing this stakeholdertype&

-escription 3 brief description of the stakeholder typeType 3 7#alify s3h8s e)pertise, technical backgro#nd, degree of

sophisticationesponsibilities 3 List s3h8s key responsibilities with regard to

the system being developed 3 why a stakeholder9S#ccess !riteria 3 :ow does the stakeholder define s#ccess9

:ow rewarded9/nvolvement 3 involved in the pro;ect in what way9e%#irements reviewer, system tester, &&&

-eliverables( 3 re%#ired by the stakeholder!omments$/ss#es 3 Problems that interfere w$ s#ccess, etc&


10/28

1ser 6rofiles (%"9)

epresentative 3


11/28

1ser En!ironment (%"')

:: $or7ing en!ironmentof target user

.#mber of people involved in doing this now9 !hanging9:ow long is a task cycle now9 !hanging9Any #ni%#e environmental constraints6 mobile, o#tdoors, in3

flight, etc&


12/28

;ey Sta7eolder or 1ser eeds (%"


13/28

6roduct /!er!ie$ ('")

(at last>)

>&' Prod#ct perspective 4conte)t5P#t the prod#ct in perspective to other related prod#cts

and the #ser8s environment&/ndependent9!omponent of a larger system9 :ow do the s#bsystems interact with this9

?nown interfaces between them and this component9 "lock diagram


14/28


(at last>)

>&+ Summary of !apabilities!#stomer Benefit S#pporting =eat#res

'&+&1&>&


15/28


(at last>)

>&1 Ass#mptions and dependencies&> !ost and pricing 33 not done by engineering

>&@ Licensing and installation 33 different types of licenseenforcement will create more re%#irements for thedevelopment effort


16/28


17/28

Wat is not in te

6roduct 4eatures Section?

-esign!onstraints 33 These go in section &

–-esign constraints –E)ternal constraints7#ality anges 33 These go in section B

– ranges for performance, rob#stness, fa#lt tolerance, etc& thatare not really feat#res 4specific capabilities, f#nctions5


18/28

6recedence and

6riority (=")


19/28

/ter 6roduct Requirements

These are re%#irements that are not features (functions) of the prod#ct

–hardware platform re%#irements 33 –system re%#irements 33 s#pported host o&s&8s, peripherals,companion software

–environmental re%#irements 33 temperat#re, shock, h#midity,radiation, #sage conditions, reso#rce availability, maintenance

iss#es, type of error recovery –applicable standards 33 legal, reg#latory, comm#nications


20/28

Documentation Requirements


21/28

3ision Doc adds

basis for SRS


22/28

1se ase 0nternals :: ompare to e5ample

in .arman te5t (p" 9= ff")" Terms@


23/28

4ully Dressed E5ample@ 6rocess

Sale, .arman te5t, p" 9= ff"Primary Actor6 !ashierStakeholders and /nterests63 !ashier6


24/28

4ully Dressed E5ample@

6rocess Sale, .arman te5t,p" 9= ff" : continued

3 0overnment Ta) Agencies6


25/28

4ully Dressed E5ample@ 6rocess Sale,

.arman te5t, p" 9= ff" : continued

Main S#ccess Scenario 4of "asic=low56

'& 3 '&E)tensions 4Alternative =lows56(a&(b&'a

+3>a

1a&1b&1c&13a3c>a @a3ca

Ba3fFa3c


26/28

Special e%#irements63 To#ch Screen / on a large flat panel monitor& Te)t visible from ' meter&3 !redit a#th& response within 1 seconds FG of the time&

&&&Technology and -ata Hariations List6&&&=re%#ency of Occ#rrence6 !o#ld be nearly contin#o#s&

Open /ss#es63


27/28

o$ $at :: after de!elopment of use case(s)

Look for consistency, correctness, completeness –Most important for core re%#irements likely to be implemented

soon"y translation to other formats –See Hision -oc#ment –State diagrams and tables –Event tables

–!ondition tables –-omain diagram 4ML5


28/28

References

' Ie%#irements Analysis,J ichard Thayer, SM! '$FBHersion +, 'FFB

+ I/EEE 0#ide for Software e%#irements Specification,J/EEE K13'FFK

1 ISoftware e%#irements6Ob;ects, =#nctions, andStatesJ, Prentice :all, 'FF1

> Software 7#ality Meas#rement for -istrib#ted Systems,A-!3T3K13'B@

Documents

122034900 Requirement Analysis