Software requirements engineering lecture 01

Definitions

SoftwareEngineeringSoftware EngineeringProcessRequirementSoftware Requirement Engineering

Requirements Engineering

Cobb’s Paradox

"We know why projects fail, we know how to prevent their failure -- so why do they still fail?”

Martin CobbTreasury Board of Canada Secretariat

Ottawa, Canada

Project Resolution

Resolution Type 1

Project Success

Resolution Type 2

Challenged

Resolution Type 3

Impaired

Cost Overruns

16%4%

9%

10%

30%

31%

<20%21% - 50%51% - 100%101%-200%201%-400%>400%

Percent Over Budget

Time Overruns

14%

18%

20%

36%

11% 1%

<20%

21%-50%

51-100%

101%-200%

201%-400%

>400%

Percent of Time Under Estimated

Content Deficiencies

27%

22%

39%

7% 5%<25%25-49%50-74%75-99%100%

Percent of Originally Planned Functionality

Project Success Factors

13.913

9.68.2 7.7 7.2

5.3

2.9 2.4

13.9

15.9

0

2

4

6

8

10

12

14

16

18

Oth

er

Use

r

Invo

lvem

en tEx

ecut

ive

Man

agem

ent

Supp

ort

Pro

per

Pla

nnin

gR

ealis

tic

Exp

ecta

tion

Com

pete

nt S

taff

Sm

alle

r Pro

ject

Mile

ston

es

Cle

ar S

tate

men

t

of R

equi

rem

ents

Ow

ners

hip

Cle

ar V

isio

n

and

Obj

ectiv

esH

ard-

Wor

king

Focu

sed

Sta

ff

Top Ten Project Success Factors

1. user involvement2. executive management support3. clear statement of requirements4. proper planning5. realistic expectations6. smaller project milestones 7. competent staff8. ownership9. clear vision and objectives10. hard-working, focused staff

Properties of Challenged Projects

Lack

of E

xecu

tive

Sup

port

12.8 12.3 11.8

7.5 7 6.4 5.9 5.3 4.3 3.7

23

0

5

10

15

20

25

Oth

er

Lack

of U

ser

Invo

lvem

ent In

c.

Req

uire

men

ts &

Sp

ecs

Tech

nolo

gy

Inco

mpe

tenc

e

Unr

ealis

tic

Exp

ecta

tion

Lack

of R

esou

rces

Cha

ngin

g

Req

uire

men

ts &

S

pecs

Unc

lear

O

bjec

tives

Unr

ealis

tic T

ime

Fram

eN

ew T

echn

olog

y

Top Ten Challenged Project Factors

1. Lack of user involvement2. Incomplete requirements and specifications3. Changing requirements and specifications4. Lack of executive support5. Technology Incompetence6. Lack of Resources7. Unrealistic expectations8. Unclear objectives9. Unrealistic timeframe10. New technology

Properties of Impaired Projects

Unr

ealis

tic

Exp

ecta

tions

Lack

of E

xecu

tive

Sup

port

Lack

of P

lann

ing

Cha

ngin

g

Req

uire

men

ts &

S

pecs

13.112.4

10.69.9

9.38.7

8.17.5

6.3

4.3

9.9

0

2

4

6

8

10

12

14

Oth

er

Inco

mpl

ete

Req

uire

men

ts

Lack

of U

ser

Invo

lvem

ent

Lack

of

Res

ourc

es

Did

n’t N

eed

any

Long

erLa

ck o

f IT

Man

agem

ent

Tech

nolo

gy

Illite

racy

Top Ten Impaired Project Factors

1. Incomplete requirements2. Lack of user involvement3. Lack of resources4. Unrealistic Expectations5. Lack of executive support6. Changing requirements & specs7. Lack of planning8. Didn’t need anymore9. Lack of IT management10. Technology illiteracy

Case Studies

FAILED SUCCESS

SUCCESS CRITERIA POINTS DMV AA HYATT BANCO

1. User Involvement 19 NO (0) NO (0) YES (19) YES (19)

2. Executive Management Support 16 NO (0) YES (16) YES (16) YES (16)

3. Clear Statement of Requirements 15 NO (0) NO (0) YES (15) NO (0)

4. Proper Planning 11 NO (0) NO (0) YES (11) YES (11)

5. Realistic Expectations 10 YES (10) YES (10) YES (10) YES (10)

6. Smaller Project Milestones 9 NO (0) NO (0) YES (9) YES (9)

7. Competent Staff 8 NO (0) NO (0) YES (8) YES (8)

8. Ownership 6 NO (0) NO (0) YES (6) YES (6)

9. Clear Vision & Objectives 3 NO (0) NO (0) YES (3) YES (3)

10. Hard-Working, Focused Staff 3 NO (0) YES (3) YES (3) YES (3)


The disciplined application of scientific principles and techniques for developing, communicating, and managing

requirements.6

Systems Requirements Engineering Lifecycle

User Requirements

SystemRequirements

SystemArchitecture

User Requirements

User RequirementsComponentDevelopment

IntegrationTest

AcceptanceTest

System Development

Capability Development

Component Development

Component Development Lifecycle

SoftwareRequirements

Architecturaldesign

Detailed design & coding

Integration &Verification

User RequirementsUser

RequirementsUser RequirementsComponentDevelopment


R e q u ire m e nts E licita t ion R e q u irem e n ts A n a lys is

R e q u ire m en ts S p e c ifica tion R e q u ire m en ts V e rif ica tion

R e qu irem e nts M a n ag e m e nt

R e q u ire m e n ts E ng in ee ring

R e q u ire m e nts E licita t ion R e q u irem e n ts A n a lys is

R e q u ire m en ts S p e c ifica tion R e q u ire m en ts V e rif ica tion

R e qu irem e nts M a n ag e m e nt

R e q u ire m e n ts E ng in ee ring

Requirements Elicitation


Identify relevant sources of requirements (usually customer)

Determine what information is needed. Analyze the gathered information, looking for

implications, inconsistencies, or unresolved issues Confirm your understanding of the requirements with

the source Synthesize appropriate statements of the requirements

Outcome of good elicitation activities–The buyer/customer fully explore and fully understand their

requirements.–The buyer/customers are able to separate their wants from their

needs.–The buyer/customers are able to understand the capabilities

and limitations of computer technology.–The buyer/customers understand the alternative solutions and

impact of each alternative.–The buyer/customers understand the impact of the

requirements on the developer and themselves.–The developers are solving the right problem.–The developers have confidence that the system to be delivered

is feasible to build.–The developers have the trust and confidence of the customer.–The developers gain domain knowledge of the system

Outcome of poor elicitation effort

–The customer probably will be dissatisfied.–The customer and developer have to cope with

constantly changing requirements.–The developer is solving the wrong problem.–The developer has a difficult time building the system.

Requirements ElicitationUser Involvement Criteria2

13.913

9.68.2 7.7 7.2

5.3

2.9 2.4

13.9

15.9

0

2

4

6

8

10

12

14

16

18

Oth

erUse

r

Invo

lvem

en tEx

ecut

ive

Man

agem

ent

Supp

ort

Pro

per

Pla

nnin

gR

ealis

tic

Exp

ecta

tion

Com

pete

nt S

taff

Sm

alle

r Pro

ject

Mile

ston

es

Cle

ar S

tate

men

t

of R

equi

rem

ents

Ow

ners

hip

Cle

ar V

isio

n

and

Obj

ectiv

esH

ard-

Wor

king

Focu

sed

Sta

ff

Project Success Factors

Do I have the right user(s)? Did I involve the user(s)early and often? Do I have a quality user(s)

relationship?

Do I make involvement easy?

Did I find out what the user(s) needs?


Requirements Analysis

Obtain Requirements from all possible sources (include but not limited to):–observation and measurements of the

current system– interviews with customers–current system documentation– feasibility studies–models and prototypes–competitive analysis


Quality attributes

Requirements Specification

Software function Performance External Interfaces Design Constraints Quality Attributes


Statement of Requirements Criteria


Do I have a concise vision? Do I have a functional analysis? Do I have a risk assessment? Do I have a business case? Can I measure the project?

13.913

9.68.2 7.7 7.2

5.3

2.9 2.4

13.9

15.9

0

2

4

6

8

10

12

14

16

18Project Success Factors

Requirements Verification

To identify and resolve software problems and high risk issues early in the software cycle.

The assurance that the software requirement specification is in compliance with the system requirements, conforms to document standards, and is an adequate basis for the architectural design.


Requirements Management

Basic responsibility is to keep project within costs, within budget, and to meet customers needs.

Estimate cost of system based on requirements.

Control the volatility of the requirements. Manage the requirements configuration of the

system Negotiate requirement changes Re-estimate cost of the system when

requirements change.


Release 1 Release 3Release 2

Requirements Engineering III







Foundation






Foundation











Successful Release Cycle Proportions

4N months

3N months

2N Months

Success Attributes that Requirements Engineering Affect

User InvolvementClear Statement of requirementsProper PlanningRealistic ExpectationsSmaller Project MilestonesClear Vision and ObjectivesHard Working, Focused Staff

13.913

9.68.2 7.7 7.2

5.3

2.9 2.4

13.9

15.9

0

2

4

6

8

10

12

14

16

18 Project Success Factors

Requirements Engineering Conclusion


Architecturaldesign

Detailed design & coding


User RequirementsUser

RequirementsUser RequirementsComponent

Development

Software Requirements Engineering includes:–elicitation–analysis–specification–verification and validation–management of requirements

development process Affects 7 of 10 attributes of

successful projects

References

1 The Standish Group, Chaos, January 1995 2 The Standish Group, Unfinished Voyages, September 1995 3 Software Quality Measurement for Distributed Systems,

RADC-TR-83-175 4 Requirements Engineering, Thayer, SMC 10/97, version 2 5 Richard Thayer, Software Requirements Engineering, IEEE,

1997 6 STEP, Operational Requirements for Automated Capabilities,

STEP, 1991 7 MBASE, “Avoiding the Software Model-Clash Spiderweb,”

IEEE Computer, November, 2000, pp. 120-122.

Software requirements engineering lecture 01

Education

Transcript of Software requirements engineering lecture 01