info 627lecture #21 requirements engineering and management info 627 analyzing the problem glenn...
TRANSCRIPT
INFO 627 Lecture #2 1
Requirements Engineeringand ManagementINFO 627
Analyzing the Problem
Glenn Booker
INFO 627 Lecture #2 2
Problems and Opportunities We hinted that most systems are created for
two reasons:1. To solve problems; ways in which the current
system doesn’t meet customer needs
2. To take advantage of opportunities; new product concepts, new features, new customer markets, etc.
We’ll focus on problem solving for now
INFO 627 Lecture #2 3
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 Hence changing expectations can make some
problems go away!
INFO 627 Lecture #2 4
Problem Analysis Steps Analyzing a problem can be done in
five steps1. Agree on the problem definition
2. Understand its root causes
3. Identify stakeholders and users
4. Define solution system boundary
5. Identify solution constraints
INFO 627 Lecture #2 5
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 6
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 7
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 8
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 Can use “fishbone” diagram
Start with the problem, on a horizontal line Look for causes of the problem Then look for causes of the causes; repeat
1E p. 37
INFO 627 Lecture #2 9
Understand its Root Causes If you have trouble finding causes, see if there
are any in common types: Data Communication Management Hardware Manufacturing Or whatever else may apply to your problem
INFO 627 Lecture #2 10
Understand its Root Causes In the context of software defect analysis,
causes can be things like Variables Data Design Documentation Interfaces And so on…
INFO 627 Lecture #2 11
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 See second half of lecture 4, INFO630
INFO 627 Lecture #2 12
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 13
Define Solution System Boundary At its simplest, every system takes in some
form of inputs, and produces outputs
The key at this point is to identify who or what creates or accepts those inputs and outputs
SystemInputs Outputs
INFO 627 Lecture #2 14
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 Do you use the cash register at the grocery store
INFO 627 Lecture #2 15
Define Solution System Boundary Other systems might include:
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.)
INFO 627 Lecture #2 16
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 If you can’t specify its design eventually,
then it’s outside your system
INFO 627 Lecture #2 17
Define Solution System Boundary Show system as a box with its name Actors are stick figures External systems are little boxes with
their names Arrows show direction of information flow
StockTrackingSystemEnd User
StockExchanges
1E p. 43
INFO 627 Lecture #2 18
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 19
Identify Solution Constraints Constraints can be anything that limits how or
when the system is provided 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.
INFO 627 Lecture #2 20
Identify Solution Constraints 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
INFO 627 Lecture #2 21
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 22
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 23
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? That forms the heart of business modeling
INFO 627 Lecture #2 24
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 25
Business Modeling Business modeling helps answer higher level
questions like: 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?
INFO 627 Lecture #2 26
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
Here we focus on “use cases”
INFO 627 Lecture #2 27
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 ‘Ship Order’, ‘Analyze Customer Trends’,
‘Process Returned Shipment’, ‘Create Invoice’
INFO 627 Lecture #2 28
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 29
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 30
Use Cases To draw a use case diagram:
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
INFO 627 Lecture #2 31
Sample Use Case Diagram
AccountingSystem
Radiator Service System
Buy PartsCounter Clerk
Overhaul Parts
Sell Parts
OverhaulFacility
Administrator
Manage Users
Technician
Generally show only significant use cases.
INFO 627 Lecture #2 32
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 33
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 34
Systems Engineering For example, a car has subsystems like:
Powertrain Engine, Transmission Axle, Differential
Suspension Wheels Tires Shocks or Struts Springs
INFO 627 Lecture #2 35
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 36
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 37
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 These detailed requirements are derived, as in
derived from overall requirements
INFO 627 Lecture #2 38
Systems Engineering For examples, derived requirements can be
used to guide selection of commercial components for your system Servers Database vendor Networking hardware And so on…
INFO 627 Lecture #2 39
Systems Engineering Many industries have recently started
incorporating software into things which didn’t have any 20 years ago Hence they have to care about allocated software
requirements Software is now the dominant cost in many
systems, and controls whether it will succeed
INFO 627 Lecture #2 40
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 Many had focused only on development costs Cost of upgrades and product evolution are harder
to predict for software
INFO 627 Lecture #2 41
Systems Engineering How can this help us define requirements?
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