Requirements Engineering
and Management
INFO 627
Defining the System and
Managing Scope
Glenn Booker
INFO 627
Lecture #5
1
Organizing Requirements



Requirements must be captured and
documented. Period. No excuses.
For that to happen, the stakeholders must
reach agreement on what are the requirements
It is rare for all requirements to be fulfilled in
the first release of a system, so need to agree
on their priority, too
INFO 627
Lecture #5
2
Organizing Requirements


The requirements specification defines the
external behavior of the system
A single document rarely can capture
all requirements


INFO 627
Might separate system requirements from
software requirements
Could use a high level Vision document, vs. a
lower level software requirements specification
Lecture #5
3
Organizing Requirements



Might use product family versus
software requirements
Could separate business requirements from
software requirements
The systems engineering approach can lead us
to defining system requirements, then define
subsystem requirements
INFO 627
Lecture #5
4
Organizing Requirements


Then each subsystem’s requirements could be
divided into hardware, software, and interface
requirements (1E p. 163)
Product families, or product lines, are sets
of systems which share some common
subsystems

INFO 627
Like different cars using the same model starter
Lecture #5
5
Product Families


In those cases, the vision for each system
is based in part on a vision for the whole
family, and the shared software requirements
For any system, need to distinguish
requirements which are being implemented
from those saved for future releases
INFO 627
Lecture #5
6
Business Requirements

Some organizations use a Marketing
Requirements Document (MRD) to
capture business issues




INFO 627
Market release windows
Target market or audience
Distribution and marketing issues
Profit margin and investment amortization
Lecture #5
7
Vision Document


The vision document combines some
marketing and product requirements
Use of the Vision document is
highly recommended


Also known as the scope or business blueprint
Can define vision for an organization too

INFO 627
Joint Vision 2020
Lecture #5
8
Vision Document



Challenge in writing the Vision is to
keep everything understandable by all
major stakeholders
Write at a low level of detail, and use
plain language
The vision captures what the system
will do, and won’t do
INFO 627
Lecture #5
9
Vision Document


The Vision document gives a synopsis
of the problem to be addressed, and the
solution proposed
The Vision describes:


INFO 627
The users of the system; their demographics,
profile, and environment
Alternative solutions and competition
Lecture #5
10
Vision Document





INFO 627
The product, including its benefits, differences
from the competition, capabilities, dependencies,
and cost
Key features
Key use cases
Non-functional requirements
Documentation, installation, and help
Lecture #5
11
Delta Vision Document (DVD?)


As a product concept matures during
development, a “Delta Vision” document can
be used to reflect improved understanding
Hence the basic product information from the
first Vision document isn’t repeated

INFO 627
Instead, focus on changes
Lecture #5
12
Delta Vision Document 2.0+

The second and later major releases could use
a delta vision with




New features in version 2
Removed features from version 1
Planned features for future releases
The delta vision document is kind of like
a release’s Version Description Document
(VDD), but at a higher level
INFO 627
Lecture #5
13
Delta Vision for Legacy Systems



Fully defining requirements for a large legacy
system is often too time consuming
Can then use a delta vision document to
capture what changes you want to make
in the system features
This avoids documenting stuff which
isn’t changing
INFO 627
Lecture #5
14
Champion

No, not a mushroom, that’s a champignon

The project vision is maintained by a product
champion
The champion maintains the vision, and
makes sure that changes to it are negotiated
fairly among the various stakeholders
The champion is fully focused on what this
product will become, and makes it that way


INFO 627
Lecture #5
15
Champion

In contrast, some projects are marked by:




Inability to refuse a new feature
Inability to accept a reasonable schedule to create
the desired features
Inability to balance the product’s features (like a
car with a 1000 HP engine and stock tires)
These are all signs of a weak or nonexistent
champion
INFO 627
Lecture #5
16
Champion



The champion could be a lead engineer,
project manager, or have other titles
Depending on industry, the champion might
be closely tied to marketing, to ensure the
product remains desirable by the customer
Champion must balance market, customer,
technology, and profit all at once
INFO 627
Lecture #5
17
Champion


For internal IT development, the champion
might be from almost any area
Champion needs to play a key role in feature
change decisions (e.g. participate in the
configuration control board)
INFO 627
Lecture #5
18
Team Skill 3 Summary

So we’ve




Started to structure requirements by subsystem,
Captured the vision for the product, and
Identified a champion to keep the vision from
going out of focus
*ouch*
Now it’s time to get concerned about
managing scope
INFO 627
Lecture #5
19
Project Scope

The scope of a project consists of
three parts:




The functionality (features) to be delivered
The resources available (people, facilities, tools,
money, etc.)
The time to complete implementation
Given enough resources and time, most
projects are easy!
INFO 627
Lecture #5
20
Project Scope

If we ignore facilities and tools for now,
people and money can be equated to restrict
our focus to two issues – people and time
Number
of
People
Project
Scope
Deadline
INFO 627
Lecture #5
Time
21
Project Scope

Can’t just add resources (people) to make a
project finish sooner




INFO 627
Too many interdependencies among their work
Learning curve for project characteristics
Proven by Brooks in 1975
Only works if enough time for people to become
productive, and productivity still goes down with
project size
Lecture #5
22
Project Scope

Time may or may not be a flexible constraint

May – Windows Server 2003 (first due for release
in 2001)


INFO 627
And Windows Vista, known as Longhorn in 2003?
May not – The Year 2000 Problem, any
fixed regulatory constraint, or known competitive
constraint
Lecture #5
23
Project Scope


The functionality which gets delivered is
limited by the available time and resources
Yet on average, projects will start based
on completing 200% of the features in the
scope available


Maybe that’s why projects average 89% late!
Result is that half of the features don’t work,
or all features half work – yuck!
INFO 627
Lecture #5
24
Project Scope


This leads to the development team’s dilemma
of chopping the scope in half, without ticking
off the customer
Otherwise the customer becomes an unofficial
part of the test team, which is generally not
appreciated

INFO 627
Old line – release 1.0 means “beta” test
Lecture #5
25
Establishing Scope


The key to defining the scope of a project
is to create the requirements baseline
The requirements baseline defines what
requirements will be delivered in which
version of the application


Assumes incremental development of features
Must be agreed to by customer
INFO 627
Lecture #5
26
Requirements Baseline


The requirements baseline must also have
a reasonable chance of being implemented
on time
Start to define the requirements baseline by
making a list of the features


INFO 627
Need to keep a consistent, low level of detail
Remember the guideline of 25-99 features
Lecture #5
27
Requirements Baseline

Then assign priorities to each feature



Critical/Important/Useful or H/M/L is enough
Could vote on priorities like we saw earlier
Now estimate the amount of effort needed to
accomplish each feature



INFO 627
Rough order of magnitude is okay here
At least do Critical/Important/Useful or H/M/L
Do more refined estimates if possible
Lecture #5
28
Requirements Baseline

Now define the risk in implementing each
element – how technically challenging is it
to implement?


Again, use three level scale, at least
Now look at candidates for reducing scope,
if necessary
INFO 627
Lecture #5
29
Reducing Scope


Make sure that the critical priority features are
really the core of the system
First look for high priority, then balance effort
and risk


INFO 627
High effort and high risk might call for immediate
risk mitigation
Assign resources to high effort features first
(unless system architecture dictates otherwise)
Lecture #5
30
Assigning Resources to Features
Middle
resources
Risk
Risk mitigation
and immediate
resources
For critical
priority
features
Last
resources
INFO 627
Immediate
resources
Effort
Lecture #5
31
Reducing Scope

Then look at how much scope reduction is
needed, and reduce resource allocation to
lower priority features accordingly


INFO 627
For slight scope reduction, might shift immediate
resources to middle, middle to low, and eliminate
low completely
For more drastic scope reduction, might drop all
medium and low priority features
Lecture #5
32
Reducing Scope

The keys to successful reduction are:



INFO 627
Make sure the customer is happy with what will
get implemented
The features implemented still form a coherent
product – not a hodgepodge of unrelated features
Keep the vision intact
Lecture #5
33
Requirements Baseline

The requirements baseline is formed
when the time and effort match the features
to be developed


The requirements baseline defines the expected
features to be developed
Then if any lower priority features can be
included in time, they’re a bonus
INFO 627
Lecture #5
34
Managing the Customer



It often helps to maintain a supportive
position with your customer
Want to help them meet their commitments
and do so with a product which will fulfill
their needs
Remember the product belongs to the
customer, not the development team!
INFO 627
Lecture #5
35
Managing the Customer

Customer needs to be a direct participant in
all decisions affecting the product scope


This gets buy-in from the customer, and alleviates
responsibility for the developer
Negotiating is critical for scope discussions


INFO 627
“Getting to Yes” is a classic guide
See Dale Carnegie, Zig Ziglar, and Dr. Norman
Vincent Peale for negotiation and sales skills
Lecture #5
36
Managing the Customer

Try to underpromise and overdeliver when
negotiating, because of the inevitable risks
of development




INFO 627
Unexpected technical risks
Delays in getting hardware or software
Emergencies among your staff
And a thousand other things which might
go wrong
Lecture #5
37
Managing the Customer


Margins for error also allow for feature creep,
which can run 30-100% after the start of
the project
Need to continually balance desire for
more features with the needs for schedule
and cost accuracy and product quality
INFO 627
Lecture #5
38
Managing Feature Changes


Changes need to be recorded and tracked
using our change control system
Added features will result in some effect:




Change in cost, schedule, and/or resources
Lower priority for some other feature(s)
Higher risk for completing one or more features
Customer needs to be clear about the impact
INFO 627
Lecture #5
39
Software Development Process

The software development process (life cycle)
model describes the sequence in which all
major activities will occur

Defines who does what when
Whether formal or not, some model is always
being used – just not necessarily the ones
shown here
(See lecture 3 of INFO 638 for more models)

INFO 627
Lecture #5
40
Waterfall Life Cycle Model





One of the first models used, circa 1970
Covers all major software development
activities in a logical sequence
Based on an assembly-line mentality
Transitions between activities often called
“throwing it over the wall”
Little or no communication among life
cycle phases
INFO 627
Lecture #5
41
Waterfall Model
Problem
Analysis
Requirements
Analysis
Architectural
Design
Detailed
Design
Coding &
Unit Test
System
Testing
INFO 627
Lecture #5
42
Waterfall Model

Works well for:




Known requirements AND known technologies
Weak or inexperienced staff
Clearly defined requirements (must have!)
Problems:



INFO 627
Often hard to define requirements adequately
Expensive and time consuming
Few signs of progress
Lecture #5
43
Spiral Life Cycle Model


Focuses on addressing major risk areas for
a project (requirements, architecture, etc.)
Each “mini-project” addresses one or more
risk areas, then start the next mini-project


A.k.a. the cinnamon roll model 
Developed by Barry Boehm, USC, 1988
INFO 627
Lecture #5
44
Spiral Model

Each mini-project has six steps





INFO 627
Determine objectives, alternatives, and
constraints for this mini-project
Identify and resolve risks
Evaluate alternatives (possibly
through prototyping)
Develop and verify the deliverables
for the next iteration
...
Lecture #5
45
Spiral Model





Plan the next iteration
Review progress to date; obtain commitment for
next mini-project
Go on to the next mini-project
Repeat until project is completed,
or major risks are under control
Then another life cycle model must be used
INFO 627
Lecture #5
46
Spiral Model


Is often combined with other life cycle models
within each mini-project too
Pros


Handles risk very well
Cons



INFO 627
Very complicated
Hard to define and resolve many mini-projects
Hard to stay focused on overall project goals
Lecture #5
47
Waterfall with Subprojects




After Requirements and Architectural Design of
project, break out [Detailed Design, Coding, and
Unit Testing] for several subprojects
Then integrate the whole system and complete
system testing for a single release of the product
Pros include faster development of known tasks, and
possibly better use of resources
Cons include unforeseen dependencies
between subprojects
INFO 627
Lecture #5
48
Waterfall with Subprojects
Conceptual
Development
Requirements
Analysis
Sub-Project A
Architectural
Design
C
B
Detailed Design, Coding,
Unit Test, Subsystem Testing
Detailed Design, Coding,
Unit Test, Subsystem Testing
INFO 627
Detailed Design, Coding,
Unit Test, Subsystem Testing
Lecture #5
System
Testing
49
Staged Delivery

Like Waterfall model for Requirements
Analysis and Architectural Design; then
[Design, Code, Test, and Deliver] the product
in stages



INFO 627
Project fully defined from the start and is
delivered in stages, based on feature priorities
Increases chance of getting key features
into product
Good for maintenance environment
Lecture #5
50
Staged Delivery
Conceptual
Development
Requirements
Analysis
Architectural
Design
Stage 1: Detailed Design, Coding,
Unit Test, Test, and Deliver
…
Stage 2: Detailed Design, Coding,
Unit Test, Test, and Deliver
Stage n: Detailed Design, Coding,
Unit Test, Test, and Deliver
INFO 627
Lecture #5
51
Iterative Approach

The iterative life cycle model breaks life cycle
phases apart from the features of
the product




Used by the Rational Unified Process
See also INFO 620’s text by Larman, Ch. 2
Each phase has one or more iterations
Each iteration produces an executable system
(or some defined release)
INFO 627
Lecture #5
52
Iterative Approach

Phases are:




INFO 627
Inception, to define scope of an issue
Elaboration, to define requirements, structure,
and resolve highly risky parts of this issue
Construction, to implement less risky parts
of this issue
Transition, to get issue ready for beta testing
and deployment
Lecture #5
53
Iterative Approach



Each iteration has a clear time limit
(timeboxed), such as 2 or 4 weeks duration
Hence this model is heavily risk-focused, like
the spiral model, but has overall
phases more like a waterfall model
Goal is to blend risk reduction with a mix
of design and development activities

INFO 627
Iterations build on each others’ functionality
Lecture #5
54
Iterative Approach



Approach gets rid of many “Yes, But”
objections due to many releases
Helps manage scope through frequent
estimation and effort cycles
No matter which development process model
is used, get a prototype to the customer!
INFO 627
Lecture #5
55