info 627lecture #21 requirements engineering and management info 627 analyzing the problem glenn...

INFO 627 Lecture #2 1

Requirements Engineeringand ManagementINFO 627

Analyzing the Problem

Glenn Booker


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


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!


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


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


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)


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?


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


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


Understand its Root Causes In the context of software defect analysis,

causes can be things like Variables Data Design Documentation Interfaces And so on…


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


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


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


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


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.)


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


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


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)


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.


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


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


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


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


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


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?


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”


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’


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…


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


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


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.


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”


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


Systems Engineering For example, a car has subsystems like:

Powertrain Engine, Transmission Axle, Differential

Suspension Wheels Tires Shocks or Struts Springs


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


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


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


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…


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


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


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

info 627lecture #21 requirements engineering and management info 627 analyzing the problem glenn...

Documents