Requirements Engineering

1
RequirementsEngineering

• Southern Methodist University
• CSE 7316

2
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

• Re-specification
• 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

48
Analyzing the Problem
49
Requirements roundtable

• http//interactive.sei.cmu.edu/Features/1999/March
  /Roundtable/Roundtable.mar99.htm

50
The Problem Domain

• Home of real users and other stakeholders
• People whose needs must be addressed
• People who need the rock
• These people are not like us !
• Different technical and economic backgrounds
• Speak in funny acronyms
• Motivations that seem strange and unfathomable

51
The problem domain
52
A more Realistic Problem domain
53
Features

• A service that the system provides to fulfill one
  or more stakeholder needs
• Simple descriptions in the users language used
  as labels to communicate with the user how the
  system addresses the problem

54
Problem/solution domains
needs
Problem domain
features
Software requirements
solution domain
55
Software as a team activity

• Software development has become a team sport
  Booch 1998
• COCOMO capability of the TEAM has the greatest
  impact on software productivity

56
Requisite team skills for requirements management

• Analyzing the problem domain
• Understanding user needs
• Defining the system
• Managing scope
• Refining system definition
• Building the right system
• We will discuss all of these !!

57
Different Skills

• Working with customers
• Software programming
• Testing
• Design and architecture abilities
• Also requirements management

58
Problem Analysis

• Some applications solve problems
• Others take advantage of opportunities in the
  market (existence of a problem may not be clear)
• SimCity
• Myst
• Problem analysis the process of understanding
  real-world problems and user needs and proposing
  solutions to meet those needs

59
What is a Problem?

• A problem can be defined as the difference
  between things as perceived and things as
  derived Weinberg
• Sometimes the simplest solution is a workaround
  or revised business plan, rather than a new
  system
• Changing the desire or perception may be the most
  cost effective solution!

60
Problem Analysis

• The goal of problem analysis is to gain a better
  understanding of the problem being solved before
  development begins
• Gain agreement on the problem definition
• Understand the root causes the problem behind
  the problem
• Identify the stakeholders and the users
• Define the system boundary
• Identify the constraints to be imposed on the
  solution

61
1. Gain Agreement on the Problem Definition

• Write down the problem and see if everyone agrees
• Have the customer describe the benefits
• Seems simple but this step can cause much
  discussion and emotion

62
Problem Statement Format
63
2. Understand Root Causes

• Gain understanding of real problem and real
  causes
• Root cause analysis
• Total Quality Management techniques
• Ask people directly involved what the problems
  are!

64
Fishbone Diagram
Inaccurate sales orders
Damaged in shipment
Customer returns
Too much scrap
Finished goods Obsolescence
Other
Manufacturing defects
65
Addressing the root cause

• Quality data demonstrates that many root causes
  are simply not worth fixing

66
Sales order problem statement
67
3. Identify the Stakeholders and the Users

• Stakeholder anyone who could be materially
  affected by the implementation of a new system or
  application
• Many stakeholders are users
• Others are indirect users
• Affected by the business outcomes that the system
  influences
• Non-user stakeholder needs must also be
  identified and addressed

68
Questions

• Who are the users of the system?
• Who is the customer (economic buyer) for the
  system?
• Who else will be affected by the outputs that the
  system produces?
• Who will evaluate and bless the system when it is
  delivered?
• Who will maintain the system?

69
Users and stakeholders of new system
70
4. Define the solution system boundary

• Boundary defines the border between the solution
  and the real world that surrounds the solution

inputs
outputs
system
71
System boundary

• World divided into two parts
• Our system
• Things that interact with our system

72
Actors

• Someone or something, outside the system, that
  interacts with the system

System boundary
I/O
Our solution
Other systems
I/O
users
73
Finding actors

• Who will supply, use, or remove information from
  the system?
• Who will operate the system?
• Who will perform any system maintenance?
• Where will the system be used?
• Where does the system get its information?

74
System Perspective
Sales Order clerk
Legacy System With Pricing data
New sales Order entry
Billing clerk
System boundary
Shipping clerk
Production foreman
75
5. Identify the constraints to be imposed on the
solution

• Constraints are restrictions on the degrees of
  freedom we have in providing a solution
• Various sources of constraints
• Schedule
• ROI
• Budget for labor and equipment
• Environmental issues
• Operating systems and databases
• etc

76
Constraints

• Constraints may be given to us before we start or
  we may have to actively elicit them
• Should understand the perspective of the
  constraint
• Should understand when the constraint no longer
  applies to the solution
• The less constrained the better!

77
Potential system constraints
78
Potential system constraints
79
Summary 5 steps of problem analysis

• Gain agreement on the problem definition
• Understand root causes
• Identify stakeholders and users
• Identify the system boundary
• Identify the constraints on the system

80
Constraints

• Purpose of the product
• Client, customer, other stakeholders
• Users of the product
• Requirements constraints
• Naming conventions and definitions
• Relevant facts
• Assumptions

81
Project issues

• Open issues
• Off the shelf solutions (COTS)
• New problems
• Tasks
• Cutover
• Risks
• Costs
• User documentation
• Waiting room

82
Problem Solving
83
Problem Solving

• Course not about programming
• Mainly about how to define a problem for people
  to solve by programming a computer
• must provide all the information that programmers
  and interface designers need to make a computer
  bring about effects outside the computer
• This complete statement of the problem is called
  requirements

84
Problem Solving

• Writing software requirements is a form of
  communication between people
• All lot of stakeholders involved
• people who desire effects from the software
• people who want to perform some task
• people who design the machine behavior
• people who configure (program) the machines

85
R
S
Not programming
Interface design documents
Pick up cargos
Database schemas
subroutines
interfaces
Haul cargos to destinations
Linked lists
Print reports
86
Introduction

• Goal of any kind of engineering is to give people
  ability to do something they currently cant do
• Task of the engineer is to build the device
• To write a useful requirements document we must
  understand what engineers to in order to produce
  a design that meets the requirements

87
Engineering

• Engineering is essentially bridging the gap
  between requirements and available materials
• aeronautical materials for flight
• software engineer configuring a computer to
  perform tasks related to information,
  transmitting information and causing objects to
  behave in accordance with specified rules

88
Materials of a Software Engineer

• Materials are intangible
• instructions that a computer is capable of
  executing
• subroutine libraries
• high level programming languages
• Bridging the requirements/materials gap is not
  easy
• sponge for cleaning easy to see
• dishwasher took many years

89
Bridging the Gap

• Once somebody figures out how to bridge the gap
  successfully, the design can be repeated and
  slightly verified to solve new problems

90
How to bridge the gap

• Many theories on how to bridge the gap
• Functional decomposition
• top-down design
• stepwise decomposition
• Steps
• engineer identifies function of the system to be
  built
• if function maps directly to available parts,
  allocate function to those parts -gt done

91
Functional Decomposition

• otherwise divide the function into subfunction
  and repeat steps 2 and 3 until every subfunction
  is small enough to map onto the smallest parts of
  the design
• Divide and conquer approach
• Problem is that there are many different ways to
  divide a high level function into subfunctions
  and there is no way to tell if these divisions
  are good until into lowest levels of design

92
Problem solving and design patterns

• Exhaustive list of all problem solving techniques
  (order of decreasing effectiveness)
• Already knowing the solution
• Already knowing the solution to a similar problem
• All other techniques

93
Problem solving and design patterns

• As engineers we are not interested in giving
  problems a sporting chance
• Engineering problems are so different from each
  other that few of the ideas or knowledge that
  enable you to solve one problem will help you
  solve a problem from a different field
• Completely generalized ideas are too unfocused

94
How engineering really works

• Engineers apply and slightly vary already
  existing, time-tested designs
• Engineers engage in unstructured exploration of
  new designs and new ways to put old designs
  together
• Both types can occur on the same project

95
Design Patterns

• Despite the importance of standard designs in all
  engineering fields, it has mostly been left
  implicit
• People learn standard designs for bridges, D.C.
  generators, brakes, etc
• What they do not learn is that standard designs
  separates professional engineering from tinkering

96
Design Patterns

• In software this standard design has become to be
  know as a design pattern
• The word pattern emphasizes that the design can
  be applied a million times over without ever
  doing it the same way twice
• a brick pattern varies little from application to
  application
• a suspension bridge pattern is a more flexible
  idea that requires additional intelligence and
  imagination to apply

97
Design Patterns

• Patterns were applied by Christopher Alexander in
  town planning and architecture
• Patterns found in towns and buildings
• street café is a pattern
• corner grocery is a pattern
• dormer window
• Rich vocabulary of words allows you to write well
  - rich vocabulary of design patterns allows us to
  design well

98
Design Patterns

• A pattern is not a reusable component
• a component is a physical object
• two different instances are identical - both are
  instances of the same design
• a pattern is a reusable idea - no two instances
  are quite the same
• The application of patterns is called design or
  engineering the creation of new instances is
  called manufacturing

99
Why Software is Hard

• Early in the history of an engineering field,
  practices tend to be unstructured exploration
  instead of application of time-tested ideas
• This is natural - in the early days there are
  fewer time-tested ideas
• In the early days there is emphasis on innovation
  - the field does not produce reliable results
• Many untested ideas which often fail

100
Why Software is Hard

• Mature engineering fields
• engineers spend most of their time combining and
  making slight variations to time-tested ideas
• Solve problems from a well defined set of
  problems
• building a transformer
• this is a standard design in electrical
  engineering
• ingenuity still required to solve unexpected
  problems

101
Why Software is Hard

• Invention of entirely new designs still continues
• space shuttle tiles
• A large vocabulary of time tested ideas makes for
  a systematic and reliable engineering discipline
• very few homes collapse from their own weight
• few transformers fail to meet specification

102
Why Software is Hard

• Orderly engineering application and slight
  variation of time-tested design patterns
• Exploratory engineering unstructured exploration
  of new kinds of designs
• Major reason software projects fail is because
  there is still a large gap between the system
  that the customer wants delivered and the
  available time-tested designs

103
Pattern Composition and Decomposition

• Patterns in software engineering
• sorting
• searching
• many types of data structures
• parsing
• rendering 3-D images
• Allow experienced programmers to make design
  decisions at a higher level than program code

104
Pattern Composition and Decomposition

• Pattern decomposition recognizing a pattern that
  is built from smaller patterns
• Difference from function decomposition is that
  the patterns have been put together before
• Function composition is what led the Wright
  brothers to succeed where others failed

105
Pattern Composition and Decomposition

• Structure of birds versus decomposing flight into
  its subfunctions
• Each subfunction then implemented by further
  decomposition
• But is this what they really did .. ?

106
Functional decomposition of Wright brothers
airplane
107
Functional decomposition of Wright brothers
airplane
108
Pattern Composition and Decomposition

• Wright brothers used wings, an engine, a
  propeller, rudder was because they had those
  things
• nobody had components that implemented up/down
  propulsion, east/west propulsion, etc
• despite mathematical elegance, nobody does this!
• If internal combustion engine did not exist, they
  would not have deduced one!

109
Pattern Decomposition

• Most of the design came from imitation
• idea of wings came from birds
• steering mechanism from observing the way birds
  bend their wings to change direction
• engine designed to meet own needs
• Town planner wants to build a bridge to go across
  the bay gives requirements to the engineer who
  then decomposes the problems into patterns
  (girders, etc)

110
Pattern Composition and Decomposition

• Exploratory engineering works the other way
  around
• composing patterns
• build a solution in search of a problem
• early computers went this way
• were still a long way from determining
  everything we can do with a computer
• In orderly engineering pattern decomposition is
  the rule

111
Pattern Composition and Decomposition

• Architecture-driven project starts with an
  implementation idea and looks for ways to extend
  it that provide new and unanticipated benefits to
  the customer
• Requirements-driven project starts with
  well-defined benefits and draws upon existing,
  proven implementation ideas