1 requirements engineering southern methodist university cse 7316

1

RequirementsRequirements

EngineeringEngineering

Southern Methodist University

CSE 7316

2

The Requirements ProblemThe Requirements Problem

3

AgendaAgenda

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

4

What is a requirement?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

(IEEE83), ANSI/IEEE Std 729/1983

Definition of RequirementDefinition 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.

6

Davis90

Requirements Analysis is Requirements Analysis is ImportantImportant

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

7

ANSI/IEEE Std729/1983

Requirements Analysis Requirements Analysis DefinitionDefinition

The process of studying user needs to arrive at a definition of system or software requirements.

The verification of system / software requirements.

8

Requirements Analysis Requirements Analysis DefinitionDefinition

An Iterative process of:

Identifying Analyzing Documenting Verifying (etc.)

Definition of

requiredsystem

behavior

9

Requirements Analysis TaskRequirements Analysis Task

SoftwareRequirements

Document

ConceptualModel

derive

• understandable• modifiable• precise

• build “outside-in” begin with

environment work inward to

the system

10

Environment and SystemEnvironment and SystemEnvironment System

state ofentities in

environment

state ofsystem

activities

events

11

Process and ArtifactsProcess and Artifacts

ContextAnalysis

DesignProcess

Developer- Oriented Software

Requirements Artifact

Customer RequirementsProcess

DeveloperRequirementsProcess

Customer- Oriented SoftwareRequirements Artifact

Brackett89, CE-SPM-01-02-06

Software NeedsArtifact

12

ContextAnalysis

DesignProcess








Market Needs

User Needs Document

System Requirements Specification

Statement of Operational Need (SON)

System Operational Requirements Document (SORD)

Concept of Operations


13

ContextAnalysis

DesignProcess








RequirementsRequirements

DefinitionRequirements

DocumentRequirements

SpecificationUse Case ModelFunctional

DescriptionPart 1

specification.


14

ContextAnalysis

DesignProcess








Behavioral Specification

System Specification

Specification Document

Requirements Specification

Functional Specification

Functional Description


15

GoalsGoals

Process goalkeep 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

Weinberg89

An Effective Artifact is An Effective Artifact is the Primary Goalthe Primary Goal

COMMUNICATION Agreement between developer & customer A basis for design A basis for V&V

17

Artifact PurposesArtifact PurposesThe 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 Documentation vs. Specificationsvs. 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 testsBasis for paymentetc.

19

Properties of a "Good" Properties of a "Good" Requirements SpecificationRequirements Specification

Unambiguous Complete Correct Prioritized Verifiable Sufficient for

design

Consistent Modifiable Traceable Traced Useable during

operations & maintenance

20

UnambiguousUnambiguous

Mathematically precise

A matter of agreement

A “contract” between the customer and the developer ...

STst : Symbol -|-> Type

defined = dom st

21

VerifiableVerifiable

Customer and developer must agree on the criteria and on the method for verification.testinginspectionetc.

Every requirement must have verification criteria — or ... it isn’t a requirement ...

22

ContextAnalysis

DesignDocument1. 2.

3.

RequirementsDocument

Test Plans

4.

TraceableTraceable

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

23

Requirements ManagementRequirements 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 Key Considerations of Requirements ManagementRequirements 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

25

Managing the ProcessManaging the Process Estimation -- how can one estimate the

scope of the requirements definition effort early?

Effort depends onsize/scope of projectbreadth of sourcesduration of effort

Two common errorstoo much effort (over-specification)too little effort (under-specification)

26

Humphrey89

Why Requirements Why Requirements Management?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 progresseswriting the program changes our

perception of the taskcomputer implementation of a human

task changes the task itself

27

Humphrey89

Why Requirements Why Requirements Management? (cont’d)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 neededstatement of requirements is wrongstatement of requirements will change

Recommendation: establish a link to someone who knows the application and work together until the job is done.

28

Humphrey89

Practical SolutionPractical Solution

Incremental development processgradually 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 ...implementtestuse in trial formplan & develop next increment

29

The requirements problemThe requirements problem

CustomersExternal 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 vendorDefense business

Our company! Something that will make us better!

30

Some Data (Standish)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

10%

30%

50%

RequirementsDefinition

SoftwareDesign

Coding Testing Deployment

$ 5

$ 10

Req’tsDefinition

SoftwareDesign

Coding Testing Deployment

Source of Errors - %'s

Communications of the ACM, Jan. '84

Relative Cost to Correct Errors - $1000'sSource: AT&T Bell Labs Estimates

ErrorsErrors You are here.

32

Root causes of Root causes of “challenged” projects“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 factorsPrimary success factors

User involvement (16% of all successful projects)

Executive management support (14%) Clear statement of requirements (12%)

Two largest problems cited in other surveysRequirements specificationsManaging customer requirements

34

Defect SummaryDefect Summary

Defect origins Defect potential

Removal efficiency

Delivered defects

Requirements 1.00 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

Defect SummaryDefect Summary

Defect origins Defect potential

Removal efficiency

Delivered defects

Requirements 1.00 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

36

Relative cost to repairRelative cost to repair

.1-.2

.5

1

2

5

20

Stage

Requirements

Design

Coding

Unit test

Acceptance test

Maintenance

37

Fixing a defectFixing 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


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


Boeing 777 – 300,000 requirements > 4 million loc 1280 embedded processors

40

Lifecycle modelsLifecycle models

41

Stagewise ModelStagewise ModelSystemRequirements


Analysis

ProgramDesign

Implementation

Testing

Operations

1970 [Royce]

42

Waterfall Waterfall ModelModelSystem

Requirements


Analysis

ProgramDesign

Implementation

Testing

Operations

1970 [Royce]

43

Spiral Spiral ModelModel Evaluate

Alternatives;Identify,Resolve Risks

Determine Objectives,Alternatives,Constraints

Develop, VerifyNext-Level Product

PlanNextPhases

CUMULATIVECOST

COMMITMENT

PARTITION

44

Requirements Definition Requirements Definition Overlaps Later PhasesOverlaps Later Phases

Requirements

Definition Design

Generation

Testing

at some arbitrary time ...

45

Evolutionary Delivery Model: Evolutionary Delivery Model: Rational Unified ProcessRational Unified Process

Business Modeling

Requirements

Analysis & Design

Workflows Inception

Elaboration

PhasesConstruction Transition

Implementation

Test

DeploymentConfiguration &

Change Management

Project Management

Environment

Iterations

Initial E # 1 E # 2 C # 1

C # 2

C # n

T #1 T #2

Co

nte

nt

Time

46

Generalized Software Development ProcessGeneralized Software Development Process

S/WRequirements

S/W systest plan

Systemtest

maintain &enhance

PrelimDesign

Integrationtest plan

Integrationtest

DetailDesign

Unittest plan

Unittest

coding

deliverproduct

47

SummarySummary

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

48

Analyzing the ProblemAnalyzing the Problem

49

Requirements roundtableRequirements roundtable

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

50

The Problem DomainThe Problem Domain

Home of real users and other stakeholdersPeople whose needs must be addressedPeople who need “the rock”

These people are not like us !Different technical and economic

backgroundsSpeak in funny acronymsMotivations that seem strange and

unfathomable

51

The problem domain

52

A moreRealisticProblemdomain

53

““Features”Features”

A service that the system provides to fulfill one or more stakeholder needs

Simple descriptions in the user’s language used as labels to communicate with the user how the system addresses the problem

54

Problem/solution domainsProblem/solution domains

needs

features

Software requirements

Problem domain

solution domain

55

Software as a team activitySoftware 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 Requisite team skills for requirements managementrequirements 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 SkillsDifferent Skills

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

58

Problem AnalysisProblem Analysis

Some applications solve problems Others take advantage of opportunities in

the market (existence of a problem may not be clear)SimCityMyst

Problem analysis; the process of understanding real-world problems and user needs and proposing solutions to meet those needs

59

What is a Problem?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 AnalysisProblem Analysis

The goal of problem analysis is to gain a better understanding of the problem being solved before development beginsGain agreement on the problem definitionUnderstand the root causes – the problem

behind the problemIdentify the stakeholders and the usersDefine the system boundaryIdentify the constraints to be imposed on

the solution

61

1. Gain Agreement on the 1. Gain Agreement on the Problem DefinitionProblem Definition

Write down the problem and see if everyone agreesHave the customer describe the benefits

Seems simple but this step can cause much discussion and emotion

62

Problem Statement FormatProblem Statement Format

Element Description

The problem of Describe the problem

affects Identify stakeholders affected by the problem

the result of which Describe the impact of this problem on stakeholders and business activity

benefits of Indicate the proposed solution and list a few key benefits

63

2. Understand Root Causes2. 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 DiagramFishbone Diagram

Too much scrap

Inaccu

rate

sale

s ord

ers

Dam

aged in

ship

ment

Custo

mer re

turn

s

Fini

shed

goo

ds

Obs

oles

cenc

e

Man

ufac

turing

def

ects

Oth

er

65

Addressing the root causeAddressing the root cause Quality data demonstrates that many root

causes are simply not worth fixing

05

101520253035404550

Inaccuratesales orders

Obsolescence

Contributions

Pareto chart of root causes

Percentage

66

Sales order problem Sales order problem statementstatement

Element Description

The problem of Inaccuracies in sales orders

affects Sales order personnel, customers, manufacturing, shipping, and customer service

the result of which Is increased scrap, excessive handling costs, customer dissatisfaction, and decreased profitability

benefits of A new system to address the problem include;Increased accuracy of sales orders at point of entryImproved reporting of sales data to managementHigher profitability

67

3. Identify the Stakeholders 3. Identify the Stakeholders and the Usersand 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 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 Users and stakeholders of new systemnew system

Users Other stakeholders

Sales and order entry clerks

MIS director and development team

Sales order supervisor Chief financial officer

Production control Production manager

Billing clerk

70

4. Define the solution 4. Define the solution system boundarysystem boundary

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

inputs

system

outputs

71

System boundarySystem boundary

World divided into two partsOur systemThings that interact with our system

72

ActorsActors

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

I/O

users

Our solution

Othersystems

I/O

Systemboundary

73

Finding actorsFinding 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 PerspectiveSystem Perspective

SalesOrderclerk

Billingclerk

Shippingclerk

Productionforeman

New salesOrder entry

LegacySystemWithPricingdata

Systemboundary

75

5. Identify the constraints to 5. Identify the constraints to be imposed on the solutionbe imposed on the solution

Constraints are restrictions on the degrees of freedom we have in providing a solution

Various sources of constraintsScheduleROIBudget for labor and equipmentEnvironmental issuesOperating systems and databasesetc

76

ConstraintsConstraints

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 Potential system constraintsconstraints

Source Sample considerations

Economic What financial or budgetary constraints are applicable?Are there costs of goods sold or any product pricing considerations?Are there any licensing issues?

Political Are there any internal or external political issues that affect potential solutions?Interdepartmental issues?

Technical Are we restricted in the choice of technologies?Are we constrained to work with existing platforms or technologies?Are we prohibited from any new technologies?Are we to use any purchased software packages?

78

Potential system Potential system constraintsconstraints

Source Sample considerations

System Is the solution to be built on our existing systems?Must we maintain compatibility with existing solutions?What operating systems and environments must be supported?

Environmental Are there environmental or regulatory constraints?Legal?Security requirements?

Schedule and resources Is the schedule defined?Are we restricted to existing resources?Can we use outside labor?Can we expand resources?

79

Summary – 5 steps of Summary – 5 steps of problem analysisproblem 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 Constraints

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

81

Project issuesProject issues

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

82

Problem Solving 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 SolvingProblem Solving

Writing software requirements is a form of communication between people

All lot of stakeholders involvedpeople who desire effects from the

softwarepeople who want to perform some taskpeople who design the machine behaviorpeople who configure (program) the

machines

85

Pick up cargos

Haul cargos todestinations

Print reports

interfaces

Database schemas

subroutines

Linked lists

R S

Not programmingInterface design

documents

86

IntroductionIntroduction

Goal of any kind of engineering is to give people ability to do something they currently can’t 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

EngineeringEngineering

Engineering is essentially bridging the gap between requirements and available materialsaeronautical; materials for flightsoftware 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 Materials of a Software EngineerEngineer

Materials are intangibleinstructions that a computer is capable

of executingsubroutine librarieshigh level programming languages

Bridging the requirements/materials gap is not easysponge for cleaning easy to seedishwasher took many years

89

Bridging the GapBridging 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 gapHow to bridge the gap Many theories on how to bridge the gap Functional decomposition

top-down designstepwise decomposition

Stepsengineer identifies function of the system

to be builtif function maps directly to available parts,

allocate function to those parts -> done

91

Functional DecompositionFunctional 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 Problem solving and design patternspatterns

Exhaustive list of all problem solving techniques (order of decreasing effectiveness)Already knowing the solutionAlready knowing the solution to a

similar problemAll other techniques

93

Problem solving and design Problem solving and design patternspatterns

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 How engineering really worksworks

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 PatternsDesign 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


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 twicea brick pattern varies little from

application to applicationa suspension bridge pattern is a more

flexible idea that requires additional intelligence and imagination to apply

97


Patterns were applied by Christopher Alexander in town planning and architecture

Patterns found in towns and buildingsstreet café is a patterncorner grocery is a patterndormer window

Rich vocabulary of words allows you to write well - rich vocabulary of design patterns allows us to design well

98


A pattern is not a reusable componenta 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 HardWhy 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


Mature engineering fieldsengineers 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

engineeringingenuity still required to solve unexpected

problems

101


Invention of entirely new designs still continuesspace shuttle tiles

A large vocabulary of time tested ideas makes for a systematic and reliable engineering disciplinevery few homes collapse from their own

weightfew transformers fail to meet

specification

102


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 Pattern Composition and DecompositionDecomposition

Patterns in software engineeringsortingsearchingmany types of data structuresparsingrendering 3-D images

Allow experienced programmers to make design decisions at a higher level than program code

104


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


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 decompositionFunctional decomposition of Wright brothers airplane of Wright brothers airplane

Subfunction Implementation

Forward propulsion

Four cylinder engine, propellers

Lift Wings

Steering Rudder, bendable wingtips

107

Functional decomposition Functional decomposition of Wright brothers airplaneof Wright brothers airplane

Subfunction Implementation

Up/down propulsion ?

East/west propulsion ?

North/south propulsion

?

108


Wright brothers used wings, an engine, a propeller, rudder was because they had those thingsnobody 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 DecompositionPattern Decomposition

Most of the design came from imitation;idea of wings came from birdssteering 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


Exploratory engineering works the other way aroundcomposing patternsbuild a solution in search of a problemearly computers went this way

we’re still a long way from determining everything we can do with a computer

In orderly engineering pattern decomposition is the rule

111


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