Transcript Requirements Engineering and Management INFO 627 Analyzing the Problem Glenn Booker INFO 627 Lecture #2 Problems and Opportunities We hinted that most systems are created for two reasons:  1. 2.  INFO.

Requirements Engineering
and Management
INFO 627
Analyzing the Problem
Glenn Booker
INFO 627
Lecture #2
1
Problems and Opportunities
We hinted that most systems are created for
two reasons:

1.
2.

INFO 627
To solve problems; ways in which the current
system doesn’t meet customer needs
To take advantage of opportunities; new product
concepts, new features, new customer markets,
etc.
We’ll focus on problem solving for now
Lecture #2
2
Problem Analysis


Problem analysis is the process of
understanding customer problems and user
needs, and proposing solutions to fulfill
those needs
A problem is the gap between how things are,
and how the customer wants them to be

INFO 627
Hence changing expectations can make some
problems go away!
Lecture #2
3
Problem Analysis Steps
Analyzing a problem can be done in
five steps

1.
2.
3.
4.
5.
INFO 627
Agree on the problem definition
Understand its root causes
Identify stakeholders and users
Define solution system boundary
Identify solution constraints
Lecture #2
4
Agree on the Problem Definition


First need to gain agreement on the
problem definition
Write down what the problem appears to be,
and see if everyone agrees


Or have each type of stakeholder describe the
problem, then compare their views
Identify how fixing the problem will benefit
the customer and users
INFO 627
Lecture #2
5
Agree on the Problem Definition

May help to describe problem using a
standardized format



Search for “problem statement”
Some “white papers” describe problems,
especially those from vendors
Problem statement might include history,
background, and motivation for solving
the problem (example)(another)
INFO 627
Lecture #2
6
Agree on the Problem Definition

Basic problem statement outline is





Describe problem
Identify stakeholders affected by it
Describe impact of problem on stakeholders and
on business activities
Describe proposed solution and key benefits
In short, why should we care about solving
this problem?
INFO 627
Lecture #2
7
Understand its Root Causes



Given the existence of a significant problem,
now we need to solve it
One way is “root cause” or “causal” analysis
– determine why the problem exists
1E p. 37
Can use “fishbone” diagram



INFO 627
Start with the problem, on a horizontal line
Look for causes of the problem
Then look for causes of the causes; repeat
Lecture #2
8
Understand its Root Causes

If you have trouble finding causes, see if there
are any in common types:






INFO 627
Data
Communication
Management
Hardware
Manufacturing
Or whatever else may apply to your problem
Lecture #2
9
Understand its Root Causes

In the context of software defect analysis,
causes can be things like






INFO 627
Variables
Data
Design
Documentation
Interfaces
And so on…
Lecture #2
10
Understand its Root Causes


Then analyze which of the causes are most
significant (does that mean ‘frequent’ or
severe’?)
Graph with a histogram or Pareto diagram

INFO 627
See second half of lecture 4, INFO630
Lecture #2
11
Identify Stakeholders and Users


As discussed last week, we need to identify
who will use the system, and who will be
affected by its existence
Many stakeholders are also users, but not all
INFO 627
Lecture #2
12
Define Solution System Boundary

At its simplest, every system takes in some
form of inputs, and produces outputs
Inputs

System
Outputs
The key at this point is to identify who
or what creates or accepts those inputs
and outputs
INFO 627
Lecture #2
13
Define Solution System Boundary



Most inputs and outputs are initiated by either
an actor (user or stakeholder), or an external
system
So we need to imagine (postulate, for now)
what will and won’t be part of our system
Focus attention only on those things that will
interact directly with our system

INFO 627
Do you use the cash register at the grocery store
Lecture #2
14
Define Solution System Boundary

Other systems might include:



INFO 627
Legacy systems which remain in your
organization (human resources database,
accounting system, etc.)
Vendors’ systems (only if your system
interacts directly with them, such as downloading
updates)
Sensors for system environment (temperature,
power supply, UPS, etc.)
Lecture #2
15
Define Solution System Boundary



Anything obtained automatically from the
Internet (search results, stock quotes, etc.)
Include users of the system from remote
locations (home, customer sites)
Remember that the system boundary only
includes things over which you have control

INFO 627
If you can’t specify its design eventually,
then it’s outside your system
Lecture #2
16
Define Solution System Boundary




Show system as a box with its name 1E p. 43
Actors are stick figures
External systems are little boxes with
their names
Arrows show direction of information flow
End User
INFO 627
Stock
Tracking
System
Lecture #2
Stock
Exchanges
17
Define Solution System Boundary


If new system includes other (e.g. legacy)
systems, show system boundary with
dotted line or oval
Please don’t include users inside the system
boundary! (think about it)
INFO 627
Lecture #2
18
Identify Solution Constraints

Constraints can be anything that limits how or
when the system is provided



INFO 627
Economic constraints, such as system
development cost, or cost of the product
Political, whether corporate, local, national, or
international political issues or laws
Technical, such as technology choices, platforms,
new technology limits, etc.
Lecture #2
19
Identify Solution Constraints


INFO 627
System constraints, such as compatibility with
existing systems or operating systems, installed
size, or internationalization
Environmental, such as legal, security, regulatory,
emissions, or safety constraints
Lecture #2
20
Identify Solution Constraints


Schedule and resources; are there predefined
limits on completion date, what resources are
available for the project, can we get outsourced
people (hire temps)?
Constraints can be added to the
problem statement, with their rationale
INFO 627
Lecture #2
21
Problem Analysis



Make sure customer agrees with problem
analysis and its resulting statement
Now have a framework for defining the
customer’s problem and needs, and started
sketching the scope and constraints on the
system we’ll create to meet those needs
This gives structure to begin
defining requirements
INFO 627
Lecture #2
22
Business Modeling



The system boundary outline gave us a
start on understanding who and what will use
our system
Now we want to expand on that and
determine how they will use the system
What kind of activities will users and systems
need to perform?

INFO 627
That forms the heart of business modeling
Lecture #2
23
When to do Business Modeling


Basic business modeling can help identify
types of activities to be performed using
the system
Detailed business modeling is good for very
complex systems, especially with many types
of users and/or many interfaces
INFO 627
Lecture #2
24
Business Modeling

Business modeling helps answer higher level
questions like:




INFO 627
Where should the system be located?
What kind of activities are performed in different
locations and facilities?
Do we need to reorganize our organization?
What processes need to be automated?
Lecture #2
25
Modeling Techniques

Many techniques can be used for
business modeling



Process modeling can help understand each
activity in detail
SAP uses “scenarios” to model activities
Some aspects of UML directly support it

INFO 627
Here we focus on “use cases”
Lecture #2
26
Use Cases


Use cases are simply names for activities
which users need to perform using
your system
Each use case is a set of activities with a clear
start and finish, which performs some
significant function using your system

INFO 627
‘Ship Order’, ‘Analyze Customer Trends’,
‘Process Returned Shipment’, ‘Create Invoice’
Lecture #2
27
Use Cases

There are also trivial use cases, which are
complete activities which aren’t very
important by themselves


‘Validate User’, ‘Print Mailing Labels’, etc.
Think of a new employee who will need to
use your system – what kind of activities
would you need to teach them? Those might
be use cases…
INFO 627
Lecture #2
28
Use Cases

To decide between significant and trivial use
cases:



Ask whether the user would brag to their boss
how many times they performed that activity
If they might brag about it, it’s a significant use
case; otherwise it’s probably trivial
Also consider how to write a user’s job
description or user’s manual; each task
described may be a use case
INFO 627
Lecture #2
29
Use Cases

To draw a use case diagram:




INFO 627
Each actor is a stick figure
Each use case is labeled in an oval
Each external system is labeled in a box
Lines connect actors to use cases, and
actors to external systems, to show lines
of communication
Lecture #2
30
Sample Use Case Diagram
Radiator Service System
Overhaul Parts
Counter Clerk
Buy Parts
Overhaul
Facility
Sell Parts
Manage Users
Technician
Administrator
INFO 627
Accounting
System
Lecture #2
Generally show only
significant use cases.
31
Documenting Use Cases


Many formats may be used to describe
use cases; see http://www.usecases.org/
for Alistair Cockburn’s* template
The use case description captures key aspects
of the business process – what happens, who
does it, what is used or created as a result,
when does it occur, etc.
* The ‘ck’ in his name is silent, BTW – “CO-burn”
INFO 627
Lecture #2
32
Systems Engineering of Software


The systems engineering approach works well
for software-based systems too
How do you solve a big problem?


Break it into little problems!
Main emphasis is on breaking the system
down into subsystems, and determining what
each subsystem needs to do
INFO 627
Lecture #2
33
Systems Engineering

For example, a car has subsystems like:

Powertrain



Suspension




INFO 627
Engine, Transmission
Axle, Differential
Wheels
Tires
Shocks or Struts
Springs
Lecture #2
34
Systems Engineering


Often applied for embedded (built-in)
software systems
See INCOSE for more info on this approach


Or WWISA for software architecture
Parts of a software system might be called
configuration items, components, packages,
modules, or units
INFO 627
Lecture #2
35
Systems Engineering

Several layers of subsystems can be designed
to organize specific functions

User Interface

Shipping and Receiving Module


Shipment Verification Screen
Each subsystem can then have specific
functions to perform using a specific set
of inputs
INFO 627
Lecture #2
36
Systems Engineering



One person or small team can then design that
subsystem in detail
This approach can help allocate (assign)
requirements to different parts of the system
This leads to detailed requirements for each
subsystem or interface between subsystems

INFO 627
These detailed requirements are derived, as in
derived from overall requirements
Lecture #2
37
Systems Engineering

For examples, derived requirements can be
used to guide selection of commercial
components for your system




INFO 627
Servers
Database vendor
Networking hardware
And so on…
Lecture #2
38
Systems Engineering

Many industries have recently started
incorporating software into things which
didn’t have any 20 years ago


INFO 627
Hence they have to care about allocated software
requirements
Software is now the dominant cost in many
systems, and controls whether it will succeed
Lecture #2
39
Systems Engineering

Another influence of the systems engineering
approach has been greater emphasis on the
entire life cycle cost for
a system – including maintenance and
disposal costs


INFO 627
Many had focused only on development costs
Cost of upgrades and product evolution are harder
to predict for software
Lecture #2
40
Systems Engineering

How can this help us define requirements?




INFO 627
Consider how use cases might interact
with subsystems
Hide information that isn’t needed to
perform the task
Isolate interfaces to external systems
Plan for more features and capabilities
than needed this minute
Lecture #2
41