software requirements engineering lecture 01
DESCRIPTION
TRANSCRIPT
![Page 1: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/1.jpg)
Definitions
SoftwareEngineeringSoftware EngineeringProcessRequirementSoftware Requirement Engineering
![Page 2: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/2.jpg)
Requirements Engineering
![Page 3: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/3.jpg)
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
![Page 4: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/4.jpg)
Project Resolution
Resolution Type 1
Project Success
Resolution Type 2
Challenged
Resolution Type 3
Impaired
![Page 5: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/5.jpg)
Cost Overruns
16%4%
9%
10%
30%
31%
<20%21% - 50%51% - 100%101%-200%201%-400%>400%
Percent Over Budget
![Page 6: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/6.jpg)
Time Overruns
14%
18%
20%
36%
11% 1%
<20%
21%-50%
51-100%
101%-200%
201%-400%
>400%
Percent of Time Under Estimated
![Page 7: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/7.jpg)
Content Deficiencies
27%
22%
39%
7% 5%<25%25-49%50-74%75-99%100%
Percent of Originally Planned Functionality
![Page 8: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/8.jpg)
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
![Page 9: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/9.jpg)
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
![Page 10: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/10.jpg)
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
![Page 11: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/11.jpg)
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
![Page 12: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/12.jpg)
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
![Page 13: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/13.jpg)
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
![Page 14: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/14.jpg)
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)
![Page 15: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/15.jpg)
Requirements Engineering
The disciplined application of scientific principles and techniques for developing, communicating, and managing
requirements.6
![Page 16: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/16.jpg)
Systems Requirements Engineering Lifecycle
User Requirements
SystemRequirements
SystemArchitecture
User Requirements
User RequirementsComponentDevelopment
IntegrationTest
AcceptanceTest
System Development
Capability Development
Component Development
![Page 17: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/17.jpg)
Component Development Lifecycle
SoftwareRequirements
Architecturaldesign
Detailed design & coding
Integration &Verification
User RequirementsUser
RequirementsUser RequirementsComponentDevelopment
![Page 18: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/18.jpg)
Requirements Engineering
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
![Page 19: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/19.jpg)
Requirements Elicitation
SoftwareRequirements
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
![Page 20: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/20.jpg)
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
![Page 21: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/21.jpg)
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.
![Page 22: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/22.jpg)
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?
SoftwareRequirements
![Page 23: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/23.jpg)
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
SoftwareRequirements
![Page 24: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/24.jpg)
Quality attributes
![Page 25: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/25.jpg)
Requirements Specification
Software function Performance External Interfaces Design Constraints Quality Attributes
SoftwareRequirements
![Page 26: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/26.jpg)
Statement of Requirements Criteria
SoftwareRequirements
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
![Page 27: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/27.jpg)
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.
Integration &Verification
![Page 28: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/28.jpg)
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.
SoftwareRequirements
![Page 29: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/29.jpg)
Requirements Engineering
Requirements Verification
Requirements Analysis
Requirements Specification
Requirements Management
Requirements Elicitation
![Page 30: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/30.jpg)
Release 1 Release 3Release 2
Requirements Engineering III
Requirements Management
Requirements Elicitation
Requirements Verification
Requirements Specification
Requirements Management
Requirements Analysis
Foundation
Requirements Elicitation
Requirements Verification
Requirements Specification
Requirements Management
Requirements Analysis
Foundation
Requirements Elicitation
Requirements Verification
Requirements Specification
Requirements Management
Requirements Analysis
Requirements Elicitation
Requirements Verification
Requirements Specification
Requirements Management
Requirements Analysis
![Page 31: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/31.jpg)
Successful Release Cycle Proportions
4N months
3N months
2N Months
![Page 32: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/32.jpg)
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
![Page 33: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/33.jpg)
Requirements Engineering Conclusion
SoftwareRequirements
Architecturaldesign
Detailed design & coding
Integration &Verification
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
![Page 34: Software requirements engineering lecture 01](https://reader033.vdocuments.site/reader033/viewer/2022061119/546af348af7959664c8b68de/html5/thumbnails/34.jpg)
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.