Transcript Requirements Engineering and Management INFO 627 Introduction Glenn Booker INFO 627 Lecture #1 Who Cares?    Requirements guide the development of a system (including its software) Therefore, clear, correct, and.

Requirements Engineering
and Management
INFO 627
Introduction
Glenn Booker
INFO 627
Lecture #1
1
Who Cares?



Requirements guide the development of a
system (including its software)
Therefore, clear, correct, and complete
requirements are essential to producing a
system which fulfills its intended purpose
Requirements are also often a contractual
mechanism to express your customer’s desires
and needs
INFO 627
Lecture #1
2
Who Cares?


Hence it is critical to define and control
(manage) requirements carefully to help make
sure we produce something which will make
our customer happy
Happy customer = Repeat customer = $$$
INFO 627
Lecture #1
3
Huh? What’s a Requirement?


A requirement is some characteristic or
capability which the final product (software
and/or system) should deliver
We’ll refine this definition later…
INFO 627
Lecture #1
4
My Background and Biases



Over 18 years of system development, mostly
for government agencies (defense and FAA),
and 8 years teaching for Drexel
Mostly work with long-lived systems
Tend to focus on the entire system rather than
just its software
INFO 627
Lecture #1
5
Software vs. System


Though most of the really big mistakes occur
in software, while developing requirements
for a product we need to consider all of its
parts (the whole system), which might also
include hardware, networking, staffing,
documentation, training materials, etc.
Software all by itself doesn’t do much 
INFO 627
Lecture #1
6
Who’s the Customer?
We will speak frequently of trying to make
the ‘customer’ happy with the final product
we produce
Typical types of customer represent





INFO 627
Commercial software development,
Custom system development, and
Classic information technology (IT)
development
Lecture #1
7
Who’s the Customer?

So this mythical ‘customer’ might be:



INFO 627
Could be a person or organization looking
to buy a shrink-wrapped commercial
software product
Could be an organization who has hired us to
produce a custom system to meet their needs
Could be a group within our organization
who needs to perform their function using
a tool we develop
Lecture #1
8
Who’s the Customer?


The customer could come from any
industry (banking, retail, manufacturing,
government, pharmaceuticals, entertainment,
etc.)
The customer could be very technology
literate, completely technology illiterate,
or ANYWHERE in between
INFO 627
Lecture #1
9
The Challenge


A major challenge in producing good
requirements is that you must be a liaison
between the customer’s world and the
technology world
You may have to learn their language,
and phrase requirements to help make
the technology meet their needs
INFO 627
Lecture #1
10
Software Life Cycle


Requirements are mostly found early in
the life cycle, then refined throughout
the rest of the product’s life (even
through maintenance)
Hence requirements management occurs
throughout the entire life of the product
INFO 627
Lecture #1
11
Software Life Cycle (Waterfall)
Conceptual
Development
Requirements
Analysis
Architectural
Design
Detailed
Design
Coding &
Unit Test
System
Testing
INFO 627
Lecture #1
12
Motivation



IT projects in the US cost a quarter trillion
dollars each year, with each project averaging
from half a million to two million dollars,
depending on size of the company
Of these, 31% fail to produce a product
And half of them cost at least 90% more than
planned
INFO 627
Lecture #1
13
Why do Projects Fail?

The most common root causes of late
or poor projects are:




Lack of user input (13%)
Incomplete requirements (12%)
Changing requirements (12%)
Hence over a third of all projects get in
trouble for reasons related to requirements
INFO 627
Lecture #1
14
Why do Projects Succeed?

Conversely, projects succeed most often
because of:



INFO 627
User involvement (16%)
Top management support (14%)
Clear requirements (12%)
Lecture #1
15
Requirements Defects



Good projects analyze when defects were
found, and when they were created
Requirements defects typically result in
almost one third of all defects which are
released to the customer
And requirements defects, if caught early, cost
1/10th to 1/100th of fixing them later on
INFO 627
Lecture #1
16
Requirements Defects


Finding defects in requirements later in the
life cycle leads to many corrective actions –
redesign, recoding, retesting, changes in test
procedures and test cases, publication of fixes,
updates to documentation, etc.
That’s why late changes to requirements are
so expensive!
INFO 627
Lecture #1
17
Requirements Management

So to control requirements, we need



A systematic way to find, organize, and document
requirements, and
A process to make sure the customer
and project staff agree on changes to
those requirements
Those constitute requirements management
INFO 627
Lecture #1
18
Requirements Management

Sounds like a simple thing, but the complexity
and interdependency of modern systems can
make this challenging. For any given
requirement:



INFO 627
Who can change or delete that requirement?
If it is changed, what other requirements
are affected?
Has that requirement been implemented, and do
we have test cases to prove we did so correctly?
Lecture #1
19
Req’ts = Requirements … get used to it!
Guidance for Req’ts Management

Industry best practices for requirements
management are contained in process models,
such as:



ISO 9000 – the international standard for quality
management
Software Engineering Institute (SEI) Capability
Maturity Models (CMMs)
Models exist for telecom, health care, etc.
INFO 627
Lecture #1
20
Software Applications


As noted earlier, there are three kinds of
software: commercial, custom, and IT
Software size may range from 10,000 line
simple applications, to 2 million lines for
the Space Shuttle, to 35 million lines for
Windows XP
INFO 627
Lecture #1
21
Software Applications


Software may be an application (shrinkwrapped commercial software), standalone
system (IT), or embedded in something else
(phone, sewing machine, car, etc.)
Most requirements management activities
apply equally well to any kind of system,
including any kind of software
INFO 627
Lecture #1
22
What is really a Requirement?


As soon as we try to define requirements, we
encounter the need to distinguish
among many kinds of things that could sound
like requirements
A need is some characteristic of the system
that the customer must have to be able to
perform their function
INFO 627
Lecture #1
23
What is really a Requirement?



A feature describes what the system will be
able to accomplish
A requirement describes some capability or
characteristic of the system
A specification describes how a requirement
will be implemented
INFO 627
Lecture #1
24
Varying Level of Detail
More detail
Needs
Describes customer problem
Features
Describes characteristics
of the solution
Requirements
Specifications
INFO 627
Lecture #1
25
What is really a Requirement?



An opportunity is a new feature, type of
product, type of customer, or other way to
expand the usability of a product
A problem is something wrong with the way
the customer currently performs
some activity
A constraint limits our options for how the
system will be designed or implemented
INFO 627
Lecture #1
26
Is it a Requirement?




Or is someone designing the
system prematurely?
Beware of “requirements” or constraints
which aren’t really needed
Is someone describing the solution (the
system) instead of the problem?
Is it too vague to be a requirement?
INFO 627
Lecture #1
27
Priorities

What is the priority or urgency of
a requirement?





INFO 627
High, Medium, or Low
Required, Desired, or Optional
Must-have, want-to-have, or nice-to-have
In contract terminology, shall means required,
should means desired, and may means optional
Or assign numeric value; 1-3, 1-5, etc.
Lecture #1
28
Stakeholders


We spoke of the ‘customer’ as a single entity,
but there may be many conflicting kinds of
people interested in the resulting product
(stakeholders)
The ‘sponsor’ is whoever pays for the
product, and has final say in what are
its requirements (think Golden Rule –
whoever has the gold…)
INFO 627
Lecture #1
29
Stakeholders



The ‘developer’ is generally you, whoever is
designing and creating the product
There may be technical ‘Subject Matter
Experts’ (SMEs) who help define
requirements for part of the system – they
generally know their part, and little else
The ‘end user’ of the system is whoever uses
it on a daily basis to perform their job
INFO 627
Lecture #1
30
Stakeholders


There may be ‘managers’ between sponsor
and end user in the food chain, who use the
product occasionally
There may be ‘administrators’ for the system,
who operate it and take care of it


Could include people who only run backup
Major ‘vendors’ may provide key parts of the
system, and help maintain them
INFO 627
Lecture #1
31
Stakeholders


Each of these kinds of stakeholders may have
separate and/or conflicting requirements for
the system
Another challenge for successful system
development is to reconcile these
requirements so that everyone is happy
INFO 627
Lecture #1
32
Stakeholders

For example, an air traffic control (ATC)
system might have:





INFO 627
Sponsor: Congress
Developer, SME, and Manager: FAA experts
End user: Members of ATC union
Administrator: Site-specific FAA employees
Vendors: IBM, Rational, and Cisco
Lecture #1
33
The Software Team



Everyone involved in developing a system is
affected by requirements management, though
in very different ways
Trouble is, most developers are not people
people (sic)
However the complexity of modern
systems makes it necessary to interact
with *yuck* people
INFO 627
Lecture #1
34
Development Team



Teams can run to hundreds of people, many
of whom could be affected by any particular
requirements change
In fact, team productivity does not depend on
having high individual productivity
Consistent with process models, which
discourage the solo “cowboy” mentality
INFO 627
Lecture #1
35
Six Team Skills
1.
2.
3.
4.
5.
6.
INFO 627
Analyzing the Problem
Understanding User Needs
Defining the System
Managing Scope
Refining the System Definition
Building the Right System
Lecture #1
36
1. Analyzing the Problem


Any system is created to fix some sort of
problem – otherwise, why bother creating the
system?
So the best starting point is to understand the
customer’s motivation for creating a new
system
INFO 627
Lecture #1
37
2. Understanding User Needs



The highest level of requirements come from
figuring out how the problems can
be solved
How can we determine what techniques
will help extract requirements from
the customer?
Like a good carpenter, need several tools from
which to choose
INFO 627
Lecture #1
38
3. Defining the System



Given a herd of requirements, how can we
organize them and produce an overall vision
of what the new system will be?
How can common requirements be shared
across a family of related products?
How can we champion the product’s vision so
it doesn’t become garbled over time?
INFO 627
Lecture #1
39
4. Managing Scope



Requirements are rarely static – they may
change faster than a three-year-old’s
attention span
How do we keep the product’s scope from
growing out of control?
How can we pare down the scope if we can’t
get everything done on time?
INFO 627
Lecture #1
40
5. Refining the System Definition


How can we expand on the requirements
to produce enough detail to guide the
developers – without doing their job
for them?
Detailed requirements need to keep consistent
with the vision, yet extend it until each piece
is solvable
INFO 627
Lecture #1
41
6. Building the Right System



How can we prove the design will
meet the requirements?
How do we know the design will
still meet the customer’s needs?
How do we control changes to
the requirements?
INFO 627
Lecture #1
42
Variety of Team Skills



Like a football team or an orchestra, each
member has different skills to contribute
All aspects of the team must be met
somewhere, or we might be missing a wide
receiver or the French horn section!
No one structure for teams works everywhere,
but we’ll discuss common aspects and
characteristics
INFO 627
Lecture #1
43