Transcript Requirements Analysis and Design Engineering Southern Methodist University CSE 7313 Module 1 – The Requirements Problem.

Requirements
Analysis and
Design
Engineering
Southern Methodist University
CSE 7313
1
Module 1 – The
Requirements Problem
2
Agenda
 Definitions and general concepts
 Process and product
 Product properties
 Requirements management
 The problem domain
3
What is a requirement?
 A software capability needed by the user
to solve a problem to achieve an objective
 A software capability that must be met or
possessed by a system or system
component to satisfy a contract, standard,
specification, or other formally imposed
documentation
4
Definition of Requirement
 A condition or capability needed by a user
to solve a problem or achieve an
objective.
 A condition or capability that must be met
or possessed by a system or a system
component to satisfy a contract, standard,
specification, or other formally imposed
document. The set of all requirements
forms the basis for subsequent
development of the system or component.
(IEEE83), ANSI/IEEE Std 729/1983
5
Requirements Analysis is
Important
 Five Hypotheses:
The later in the lifecycle an error is found,
the more expensive it is to fix.
Many errors are not found until well after
they are made.
Many requirements errors are being made.
Requirements errors are typically
incorrect facts, omissions,
inconsistencies, and ambiguities.
Requirements errors can be detected
Davis90
6
Requirements Analysis
Definition
 The process of studying user needs to
arrive at a definition of system or software
requirements.
 The verification of system / software
requirements.
ANSI/IEEE Std729/1983
7
Requirements Analysis
Definition
An Iterative process of:
Definition of
required
system
behavior
 Identifying
 Analyzing
 Documenting
 Verifying
 (etc.)
8
Requirements Analysis Task
• build “outside-in”
 begin with
environment
 work inward to
the system
Conceptual
Model
derive
Software
Requirements
Document
• understandable
• modifiable
• precise
9
Environment and System
Environment
System
state of
entities in
environment
activities
events
state of
system
10
Process and Artifacts
Context
Analysis
Software
Needs
Artifact
Customer
Requirements
Process
CustomerOriented Software
Requirements Artifact
DeveloperOriented Software
Requirements Artifact
Developer
Requirements
Process
Design
Process
11
Brackett89,
CE-SPM-01-02-06
Process and Artifacts
Context
Analysis
Software
Needs
Artifact
Customer
Requirements
Process
Market Needs
User Needs
Document
CustomerSystem
Oriented Software
Requirements
Requirements
Artifact
Specification
Statement of
DeveloperOperational Need
Oriented
(SON) Software
Developer
Requirements
Process
Requirements Artifact
Design
Process
12
System Operational
Requirements
Document (SORD)
Brackett89,
ConceptCE-SPM-01-02-06
of
Operations
Process and Artifacts
Software
Needs
Artifact
Context
Requirements
Analysis
Requirements
Definition
CustomerRequirements
Customer
Oriented Software
Document
Requirements
Requirements Artifact
Process
Requirements
Specification
DeveloperDeveloper
Use Case
Model
Oriented Software
Requirements
Functional
Requirements Artifact
Process
Description
Part 1
Design
specification.
Brackett89,
Process
CE-SPM-01-02-06
13
Process and Artifacts
Software
Needs
Artifact
Context
Behavioral
Analysis
Specification
System
CustomerSpecification
Customer
Oriented Software
Specification
Requirements
Requirements Artifact
Process
Document
Requirements
DeveloperDeveloper
Specification
Oriented Software
Requirements
Functional
Requirements Artifact
Process
Specification
Functional
Design
Description
Brackett89,
Process
CE-SPM-01-02-06
14
Goals
 Process goal
keep the process under our intellectual
control at all times
 Artifact goal
organize the artifact so that it allows
others to comprehend the product to be
built
amount of effort should be proportional
to the size of the product -- not worse!
15
An Effective Artifact is
the Primary Goal
 COMMUNICATION
 Agreement between developer & customer
 A basis for design
 A basis for V&V
Weinberg89
16
Artifact Purposes
The artifact(s) answer these questions
What problem is the system supposed to
solve?
What does the customer require from the
system?
What does the developer need to know
about the system to design it?
The artifact(s) of the requirements
analysis process are specifications that
the software designer can use
17
Documentation
vs. Specifications
 "Documents" are all of the materials
produced during requirements analysis,
e.g. backs of envelopes, data dictionaries,
prototypes, etc.
 “Specifications” are formal documents
that are "contractually" binding in some
manner, such as:
Basis for acceptance tests
Basis for payment
etc.
18
Properties of a "Good"
Requirements Specification
 Unambiguous
 Complete
 Correct
 Prioritized
 Verifiable
 Sufficient for
design
 Consistent
 Modifiable
 Traceable
 Traced
 Useable during
operations &
maintenance
19
Unambiguous
Mathematically precise
ST
st : Symbol -|-> Type
defined = dom st
A matter of agreement
A “contract” between the
customer and the developer ...
20
Verifiable
 Customer and developer must agree on
the criteria and on the method for
verification.
testing
inspection
etc.
 Every requirement must have verification
criteria — or ... it isn’t a requirement ...
21
Traceable
Test Plans
4.
Context
Analysis
1.
Requirements
Document
2.
Design
Document
3.
 1.
 2.
 3.
 4.
Backward to context analysis
Forward to design
Within the document
To test/verification plans
22
Requirements Management
 Requirements Management is one of the
6 KPAs needed to go to level 2
(Repeatable) of the CMM.
 Requirements are set at the beginning
and not changed during the build -when they change, the current build
stops and a new cycle starts.
23
Key Considerations of
Requirements Management
 Identify functional requirements (e.g. draft
user’s manual)
 Identify system needs
 Identify customer expectations -- delivery,
packaging, and support
 Identify measures of success -- cost,
schedule, and performance
 Identify validation & acceptance criteria
 Identify support requirements
24
Managing the Process
 Estimation -- how can one estimate the
scope of the requirements definition effort
early?
 Effort depends on
size/scope of project
breadth of sources
duration of effort
 Two common errors
too much effort (over-specification)
too little effort (under-specification)
25
Why Requirements
Management?
 Sometimes we get firm requirements, but
the law of software perversity states:
“The firmer the requirements; the more
likely they are wrong.”
 Requirements change as the job progresses
writing the program changes our
perception of the task
computer implementation of a human
task changes the task itself
Humphrey89
26
Why Requirements
Management? (cont’d)
 In large-scale programs, the task of writing a
complete statement of requirements is not
just difficult – it is practically impossible.
customer doesn’t know what is needed
statement of requirements is wrong
statement of requirements will change
 Recommendation: establish a link to
someone who knows the application and
work together until the job is done.
Humphrey89
27
Practical Solution
 Incremental development process
gradually increase level of detail as the
requirements and implementation are
mutually refined
 Start with the minimal requirements that
both we and the user “know” are valid ...
implement
test
use in trial form
plan & develop next increment
Humphrey89
28
The requirements problem
Customers
External entity; buy ours instead of
theirs!!
Company that has hired us to
develop high quality s/w that will
give them a competitive advantage
Tools vendor
Defense business
Our company! Something that will
make us better!
29
Some Data (Standish)
 $250 billion spent on IT for 175,000
projects
$2,322,000 for large company
$1,331,000 for medium company
$434,000 for small company
 31% of projects canceled before
completion
 52.7% will cost an average of 181% of
original estimate
30
Errors
50%
You are here.
Source of Errors - %'s
Communications of the ACM, Jan. '84
30%
10%
Requirements Software
Definition
Design
Coding
Testing
Deployment
$ 10
$5
Relative Cost to Correct Errors - $1000's
Source: AT&T Bell Labs Estimates
Req’ts
Software
Definition Design
31
Coding
Testing
Deployment
Root causes of
“challenged” projects
 Lack of user input (13% of all projects)
 Incomplete requirements and
specifications (12% of projects)
 Changing requirements and specifications
(12% of projects)
 Inadequate technology skills (7%)
 …..
32
Primary success factors
 User involvement (16% of all successful
projects)
 Executive management support (14%)
 Clear statement of requirements (12%)
 Two largest problems cited in other
surveys
Requirements specifications
Managing customer requirements
33
Defect Summary
Defect origins
Requirements
Defect
potential
1.00
Removal Delivered
efficiency defects
77%
0.23
Design
1.25
85%
0.19
Coding
1.75
95%
0.09
Documentation
0.60
80%
0.12
Bad fixes
0.40
70%
0.12
Total
5.00
85%
0.75
34
Defect Summary
Defect origins
Requirements
Defect
potential
1.00
Removal Delivered
efficiency defects
77%
0.23
Design
1.25
85%
0.19
Coding
1.75
95%
0.09
Documentation
0.60
80%
0.12
Bad fixes
0.40
70%
0.12
Total
5.00
85%
0.75
35
Relative cost to repair
Stage
.1-.2
Requirements
.5
Design
1
Coding
2
Unit test
5
Acceptance test
20
Maintenance
36
Fixing a defect





Respecification
Redesign
Recoding
Retesting
Change orders; telling
users and operators to
replace
 Corrective action; refund
checks to angry
customers, rerunning a
computer job
37
 Scrap; code, design,
test cases
 Recall of defective
versions of shrink
wrap and manuals
 Warranty costs
 Product liability;
customers suing for
damages
 Service costs
 Documentation
Requirements Management
 A systematic approach to eliciting,
organizing, and documenting the
requirements of the system, and a process
that establishes and maintains agreement
between customer and the project team on
the changing requirements of the system
 Requirements management process called
for by both CMM and ISO 9000
38
Requirements Management
Boeing 777 – 300,000 requirements
 > 4 million loc
 1280 embedded processors
39
Lifecycle models
40
Stagewise Model
System
Requirements
1970 [Royce]
Software
Requirements
Analysis
Program
Design
Implementation
Testing
Operations
41
Waterfall Model
System
Requirements
1970 [Royce]
Software
Requirements
Analysis
Program
Design
Implementation
Testing
Operations
42
Spiral Model
CUMULATIVE
COST
Determine
Objectives,
Alternatives,
Constraints
Evaluate
Alternatives;
Identify,
Resolve Risks
COMMITMENT
PARTITION
Develop,
Verify
Next-Level
Product
Plan
Next
Phases
43
Requirements Definition
Overlaps Later Phases
Requirement
s
Definition
Desig
n
Generatio
n
Testing
at some arbitrary time
...
44
Evolutionary Delivery Model:
Rational Unified Process
Time
Phases
Workflows
Business Modeling
Inceptio
n
Elaboration
Construction
Transiti
on
Requirements
Content
Analysis & Design
Implementation
Test
Deployment
Configuration &
Change Management
Project Management
Environment
Initial
E#1
E#2
C#1
Iterations
45
C#2
C#n
T #1
T #2
Generalized Software Development Process
S/W
Requirements
S/W sys
test plan
Prelim
Design
Integration
test plan
Detail
Design
Unit
test
plan
coding
46
System
test
Integration
test
Unit
test
deliver
product
maintain &
enhance
Summary
 Definitions and general concepts
 Process and product
 Product properties
 Requirements management
 The problem domain
47