Requirements Analysis and Design Engineering

1
RequirementsAnalysis andDesignEngineering

• Southern Methodist University
• CSE 7313

2
Module 1 The Requirements Problem
3
Agenda

• Definitions and general concepts
• Process and product
• Product properties
• Requirements management
• The problem domain

4
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

5
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
6
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
7
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
8
Requirements Analysis Definition

• An Iterative process of
• Identifying
• Analyzing
• Documenting
• Verifying
• (etc.)

Definition of required system behavior
9
Requirements Analysis Task

• build outside-in
• begin with environment
• work inward to the system

Conceptual Model
derive
Software Requirements Document

• understandable
• modifiable
• precise

10
Environment and System
Environment
System
state of entities in environment
activities
state of system
events
11
Process and Artifacts
Software Needs Artifact
Context Analysis
Customer- Oriented Software Requirement
s Artifact
Customer Requirements Process
Developer- Oriented Software Requirements
Artifact
Developer Requirements Process
Design Process
Brackett89, CE-SPM-01-02-06
12
Process and Artifacts
Market Needs User Needs Document System
Requirements Specification Statement of
Operational Need (SON) System Operational
Requirements Document (SORD) Concept of Operations
Software Needs Artifact
Context Analysis
Customer- Oriented Software Requirement
s Artifact
Customer Requirements Process
Developer- Oriented Software Requirements
Artifact
Developer Requirements Process
Design Process
Brackett89, CE-SPM-01-02-06
13
Process and Artifacts
Software Needs Artifact
Requirements Requirements Definition Requirements
Document Requirements Specification Use Case
Model Functional Description Part 1 specification.
Context Analysis
Customer- Oriented Software Requirement
s Artifact
Customer Requirements Process
Developer- Oriented Software Requirements
Artifact
Developer Requirements Process
Design Process
Brackett89, CE-SPM-01-02-06
14
Process and Artifacts
Software Needs Artifact
Behavioral Specification System
Specification Specification Document Requirements
Specification Functional Specification Functional
Description
Context Analysis
Customer- Oriented Software Requirement
s Artifact
Customer Requirements Process
Developer- Oriented Software Requirements
Artifact
Developer Requirements Process
Design Process
Brackett89, CE-SPM-01-02-06
15
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!

16
An Effective Artifact is the Primary Goal

• COMMUNICATION
• Agreement between developer customer
• A basis for design
• A basis for VV

Weinberg89
17
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

18
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.

19
Properties of a "Good" Requirements Specification

• Unambiguous
• Complete
• Correct
• Prioritized
• Verifiable
• Sufficient for design

• Consistent
• Modifiable
• Traceable
• Traced
• Useable during operations maintenance

20
Unambiguous

• Mathematically precise
• A matter of agreement
• A contract between the customer and the
  developer ...

21
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 isnt a requirement ...

22
Traceable
Test Plans
4.
Design Document
Requirements Document
Context Analysis
1.
2.
3.

• 1. Backward to context analysis
• 2. Forward to design
• 3. Within the document
• 4. To test/verification plans

23
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.

24
Key Considerations of Requirements Management

• Identify functional requirements (e.g. draft
  users 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

25
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)

26
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
27
Why Requirements Management? (contd)

• In large-scale programs, the task of writing a
  complete statement of requirements is not just
  difficult it is practically impossible.
• customer doesnt 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
28
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
29
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!

30
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

31
Errors
You are here.
Source of Errors - 's Communications of the ACM,
Jan. '84
50
30
10
Requirements Definition
Software Design
Coding
Testing
Deployment
10
Relative Cost to Correct Errors - 1000's Source
ATT Bell Labs Estimates
5
Reqts Definition
Software Design
Coding
Testing
Deployment
32
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)
• ..

33
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

34
Defect Summary
35
Defect Summary
36
Relative cost to repair
Stage
.1-.2
Requirements
Design
.5
Coding
1
Unit test
2
Acceptance test
5
Maintenance
20
37
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

• 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

38
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

39
Requirements Management

• Boeing 777 300,000 requirements
• gt 4 million loc
• 1280 embedded processors

40
Lifecycle models
41
Stagewise Model
System Requirements
1970 Royce
Software Requirements
Analysis
Program Design
Implementation
Testing
Operations
42
Waterfall Model
System Requirements
1970 Royce
Software Requirements
Analysis
Program Design
Implementation
Testing
Operations
43
Spiral Model
CUMULATIVE COST
Evaluate Alternatives Identify, Resolve Risks
Determine Objectives, Alternatives, Constraints
COMMITMENT PARTITION
Develop, Verify Next-Level Product
Plan Next Phases
44
Requirements Definition Overlaps Later Phases
Requirements Definition
Design
Generation
Testing
at some arbitrary time ...
45
Evolutionary Delivery Model Rational Unified
Process
Time
Phases
Workflows
Inception
Elaboration
Construction
Transition
Business Modeling
Requirements
Analysis Design
Implementation
Test
Content
Deployment
Configuration Change Management
Project Management
Environment
Initial
E 1
E 2
C 1
C 2
C n
T 1
T 2
Iterations
46
Generalized Software Development Process
S/W Requirements
S/W sys test plan
System test
Prelim Design
Integration test plan
Integration test
deliver product
Detail Design
Unit test plan
Unit test
maintain enhance
coding
47
Summary

• Definitions and general concepts
• Process and product
• Product properties
• Requirements management
• The problem domain