Capstone Courses
Problem Analysis and
Solution Design
Slide 1
Gathering Requirements
Slide 2
Key Ideas
The goal of the analysis phase is to
truly understand the requirements of
the new system and develop a
system that addresses them -- or
decide a new system isn’t needed.
The line between systems analysis
and systems design is very blurry.
Slide 3
Key Definitions
The As-Is system is the current system
and may or may not be
computerized
The To-Be system is the new system
that is based on updated
requirements
The System Proposal is the key
deliverable from the Analysis Phase
Slide 4
What is a Requirement?
A statement of what the system must
do
A statement of characteristics the
system must have
Focus is on business user needs during
analysis phase
Requirements will change over time
as project moves from analysis to
design to implementation
Slide 5
Requirement Types
Functional Requirements
A process the system hast to perform
Information the system must contain
Nonfunctional Requirements
Behavioral properties the system must
have
 Operational
 Performance
 Security
 Cultural and political
Slide 6
Traditional Techniques
•Interviews
•Questionnaires
•Observations & Protocol Analysis
•Document Archeology
Slide 7
Modern Techniques
Prototyping
Use Cases
JAD
Brainstorming
Role Playing
Mind Mapping
Story boarding
Snow cards
Root Cause Analysis
Slide 8
Interviews
Slide 9
Interviews -- Five Basic Steps
Selecting Interviewees
Designing Interview Questions
Preparing for the Interview
Conducting the Interview
Post-Interview Follow-up
Slide 10
Selecting Interviewees
Based on Information Needed
Often Good to Get Different
Perspectives
Managers
Users
Ideally, All Key Stakeholders
Slide 11
Types of Questions
Types of Questions
Closed-Ended Questions
Examples
*
*
*
Open-Ended Questions
*
*
*
Probing Questions
Slide 12
*
*
*
How many telephone
orders are received per day?
How do customers place orders?
What additional information
would you like the new system
to provide?
What do you think about the
current system?
What are some of the problems
you face on a daily basis?
How do you decide what types of
marketing campaign to run?
Why?
Can you give me an example?
Can you explain that in a bit
more detail?
Designing Interview Questions
Unstructured interview
Broad, Roughly Defined Information
Structured interview
More Specific Information
Slide 13
Interview Preparation Steps
Prepare General Interview Plan
List of Question
Anticipated Answers and Follow-Ups
Confirm Areas of Knowledge
Set Priorities in Case of Time Shortage
Prepare the Interviewee
Schedule
Inform of Reason for Interview
Inform of Areas of Discussion
Slide 14
Conducting the Interview
Appear professional and unbiased
Record all information
Check on organizational policy regarding
tape recording
Be sure you understand all issues and terms
Separate facts from opinions
Give interviewee time to ask questions
Be sure to thank the interviewee
End on time
Slide 15
Interview Report
INTERVIEW REPORT
Interview notes approved by: ____________
Person interviewed
Interviewer
Date
Primary Purpose:
Summary of Interview:
Open Items:
Detailed Notes:
Slide 16
______________
_______________
_______________
JOINT APPLICATION DESIGN
(JAD)
Slide 17
JAD Key Ideas
Allows project managers, users,
and developers to work together
May reduce scope creep by 50%
Avoids requirements being too
specific or too vague
Slide 18
Joint Application Design (JAD)
Important Roles
Facilitator
Scribe
Slide 19
Joint Application Design (JAD)
Setting
U-Shaped seating
Away from distractions
Whiteboard/flip chart
Prototyping tools
e-JAD
Slide 20
JAD Meeting Room
JPEG Figure 5-5 Goes Here
Slide 21
The JAD Session
Tend to last 5 to 10 days over a three week period
Prepare questions as with interviews
Formal agenda and groundrules
Facilitator activities
Keep session on track
Help with technical terms and jargon
Record group input
Help resolve issues
Post-session follow-up
Slide 22
Managing Problems in JAD
Sessions
Reducing domination
Encouraging non-contributors
Side discussions
Agenda merry-go-round
Violent agreement
Unresolved conflict
True conflict
Use humor
Slide 23
QUESTIONNAIRES
Slide 24
Questionnaire Steps
Literature Review
Determining key variables and measures
Formulating hypotheses.
Selecting participants
Using samples of the population
Designing the questionnaire
Careful question selection
Administering the questionnaire
Working to get good response rate
Data Collection and Statistical Analysis
Descriptive & Inferential Analysis
Slide 25
Good Questionnaire Design
Begin with non-threatening and interesting questions
Group items into logically coherent sections
Do not put important items at the very end of the questionnaire
Do not crowd a page with too many items
Avoid abbreviations
Avoid biased or suggestive items or terms
Number questions to avoid confusion
Pretest the questionnaire to identify confusing questions
Provide anonymity to respondents
Slide 26
Document Analysis
Provides clues about existing “as-is”
system
Typical documents
Forms
Reports
Policy manuals
Look for user additions to forms
Look for unused form elements
Slide 27
Observation
Users/managers often don’t remember
everything they do
Checks validity of information gathered
other ways
Behaviors change when people are
watched
Careful not to ignore periodic activities
Weekly … Monthly … Annual
Protocol Analysis (Qualitative Analysis)
Slide 28
Criteria for Selecting the
Appropriate Techniques
Type of information
Depth of information
Breadth of information
Integration of information
User involvement
Cost
Combining techniques
Slide 29
Root Cause Analysis (Fishbone
Diagrams)
Root
Cause
Analysis
What is Root Cause Analysis?
Technique to explore complex problems
thoroughly
May utilize Cause & Effect Diagrams
(a.k.a. Fishbone Diagrams) to think
through the causes of a problem
thoroughly
May utilize other sorting and grouping
techniques to think through the causes
of a problem thoroughly
Slide 30
What are the Benefits of Root Cause
Analysis?
Allows full decomposition of a problem
allowing for consideration of all possible
causes, not just the obvious ones
This tool is great for grouping ideas
together and is also beneficial to figure
out what to target next for more detail
It facilitates further analysis and
examination of the identified causes and
aids in prioritization activities
Slide 31
Root Cause Analysis Example
Slide 32
Client Example:
Root
Cause
Analysis
Large-Scale Change @ Hitachi GST
August, 2004 v1.0
Budget
constraints
Strategic Direction
Environmental
Barriers
Fearful of negative
consequences in proactively
mitigating risk
Blame, fingerpointing environment
Highly resistant
to change
Out of touch with
customers
Does not understand
external business
environment
Our business is
overally complex
Unwillingness to
look at how other
depts will be
affected
Poor resource
management
Unwillingness to address
and solve resource
issues
Limited
understanding
of project
impacts
Lack of
Expectation
Management
Misunderstanding of
project initiatives
Undisciplined in
assessing and
communicating impacts
Improper use of
consulting resources
Execution
Slide 33
Too much change
happening without
prioritization from the
business
Too many metrics;
difficult to focus
Accustomed
to highly
customized
environment
Lack of PM
Methodology
and Resources
Too many
projects going
on at the
same time
More focused on winning
internal battles than on
winning the market war
Complexity
Mindset
Lack of
BPR skills
Lack of project
portfolio
management
Too internally focused
Complacent,
passive work
environment
Fighting for the
same internal
resources
Unactionable and
unfocused measures
Lack of short and midterm goals tied to overall
strategic direction
Unclear
Business
Ownership
Same resources in key
roles that failed many
times previously
Lack of business
ownership for
projects
Lack of
decisionmaking or
accountability
Unclear roles and
responsibilities
Frequent reorgs and
executive turnover
Lack of
accountability in
Ineffective
leadership levels
Organizational
- starts at the top
Inability to
understand end to
end due to silos
Siloed structures;
organized around
products, not
channels
Mini, siloed IT
organizations within the
business leading to
duplication of efforts
Lack of MidManagement
Involvement
Accountability
The client
Hitachi
GST consistently
experiences chronic difficulty
with large-scale projects that
require the integration of
people, process and strategy
demanded by our customers
and competitors in the
marketplace.
Lack of
Communication
due to silos
Structure
Leadership
Lack of strong leadership action
enables low accountability levels;
when is the last time an individual
was fired for non-performance?
Strategy is not
articulated in
actionable way
People
IT vs
Business
Selecting the Appropriate
Techniques
Interviews
JAD
Questionnaires
Document
Analysis
Observation
Type of
Information
As-Is
Improve.
To-Be
As-Is
As-Is
Improve. Improve.
To-Be
As-Is
Depth of
Information
High
High
Medium
Low
Low
Breadth of
Information
Low
Medium
High
High
Low
Integration
of Info.
Low
High
Low
Low
Low
User
Medium
Involvement
High
Low
Low
Low
Cost
LowMedium
Slide 34
Medium
Low
Low
As-Is
LowMedium
Requirements as Features
Guiding the Project and the Process
Slide 35
High level features diagram
List Features required
Group Features required
Map Features required
Schedule Features optional
Slide 36
FDD UML Extensions (iii)
CP-1
Overall Status:
Work in progress
Attention (ie, Behind)
Completed
Making
Product
Assessments
(14)
Example:
Feature Set:
Making Product Assess’ts –
Work in Progress
Not yet started
Completion Percentage:
75%
(14) there are fourteen features that make
up this feature set
Progress bar
Completion Status:
Completed
MY Targeted Completion Month
CP-1 is the Chief Programmer’s initials
Dec 2001
75% Feature Set is 75% complete
Target is to complete in Dec 2001
FDD Sample Feature Sets
Product Sale Management (PS)
CP-1
CP-1
CP-3
CP-1
Selling
Products
Shipping
Products
Delivering
Products
Invoicing
Sales
(22)
(19)
(10)
(33)
99%
10%
30%
3%
Nov 2001
Dec 2001
Dec 2001
Dec 2001
CP-2
Setting up
Product
Agreements
(13)
CP-2
Inventory Mgmt (IM)
CP-2
CP-3
Opening
New
Accounts
(11)
Logging
Account
Transactions
(30)
Establishing
Storage Units
95%
100%
82%
Oct 2001
Oct 2001
KEY:
Work In Progress
Dec 2001
Dec 2001
Evaluating
Account
Applications
(23)
Slide 38
Making
Product
Assessments
(14)
75%
Customer A/C Mgmt (CA)
CP-2
CP-1
Nov 2001
Attention
CP-3
CP-3
Moving
Content
(26)
Accepting
Movement
Requests
(18)
100%
97%
82%
Nov 2001
Nov 2001
Completed
Progress Bar
(19)
Nov 2001
Not Started
FDD Plan View
Slide 39
FDD Feature View
Slide 40
Solution Design
The Movement Toward
Objects
Slide 41
Key Definitions
Object-oriented techniques view a
system as a collection of selfcontained objects which include
both data and processes.
The Unified Modeling Language
(UML) has become an object
modeling standard and adds a
variety of techniques to the field of
systems analysis and development.
Slide 42
The Object Approach and
UML
Slide 43
The world is made of objects. Just open your eyes
and ears. They are out there. Bank customers,
students, cats, elephants, cars, balls of string,
atoms, molecules, tubs of ice cream, Madonna,
stars, bureaucrats, Robin Hood. The world is built
of objects. Objects are built of smaller objects, and
so ad infinitum. Objects combine to make bigger
objects. We already live in an object-oriented
world.
Slide 44
Object Concepts
An object is a person, place, event, or thing about which we
want to capture information.
Each object has properties (or attributes).
The state of an object is defined by the value of its
properties and relations with other objects at a point in time.
Objects have behaviors -- things that they can do -- which
are described by methods (or operations).
Objects do not use primary or foreign keys, instead each
instance is assigned a unique identifier (UID) when it is
created.
Slide 45
Slide 46
Slide 47
Slide 48
Slide 49
Slide 50
Slide 51
An Object and Object
Instances
Slide 52
Class
A class is a general template we
use to define and create specific
instances or objects.
Slide 53
Classes and Objects
Slide 54
Inheritance
Classes are arranged in a hierarchy
Superclasses or general classes are at the top
Subclasses or specific classes are at the bottom
 Subclasses inherit attributes and methods
from the superclasses above them
Classes with instances are concrete classes
Abstract classes only produce templates for
more specific classes
Slide 55
Class Hierarchy
Slide 56
Inheritance
Slide 57
Messages
Messages are information sent to
objects to trigger methods
Slide 58
Polymorphism
Slide 59
Encapsulation
The message is sent without
considering how it will be
implemented
The object can be treated as a
“black-box”
Slide 60
Benefits of an Object
Approach
Benefits of an Object Approach
An Object
A class
Inheritance
Polymorphism
Encapsulation
Slide 61
What Do the
Concepts
Support
and Lead
To?
UML
Defines a set of nine object
diagramming techniques
The key building block is the use case
Diagrams are tightly integrated
syntactically and conceptually to
represent an integrated whole
Application of UML can vary among
organizations
Slide 62
Adaptation of the Phased
Development Method
Slide 63
Use-Case Diagram
Slide 64
Use-Case Diagram Concepts
Summarizes all use cases (for the
part of the system being
modeled) together in one picture
Typically drawn early in the SDLC
Shows the associations between
actors and use cases
Slide 65
Integration of four UML
Diagrams
Slide 66
Use Case Diagram for
Appointment System
Slide 67
Syntax for Use-Case Diagram
Slide 68
Use-Case Diagram for
Specialized Actor
Slide 69
Extends or Uses Associations
Slide 70
Steps in Creating the Use Case
Diagram
1. Identify use cases
2. Draw the system boundary
3. Place use cases on the diagram
Group use cases into packages
Add special use case associations
4. Identify the actors
5. Add Associations
Slide 71
Use-Case Diagram Example
Slide 72
Sequence Diagram
Slide 73
Sequence Diagram Concepts
Illustrates the classes that participate in a
use case
Shows the messages that pass between
classes over time for one use case
Can be a generic sequence diagram, but
more frequently one is drawn for a single
scenario within the use case
Design diagrams are implementation
specific -- database objects or specific GUI
components serve as classes
Slide 74
Use Diagram for CD Selections
Internet Sales System
Slide 75
Sequence Diagram
Slide 76
Steps in Creating a Sequence
Diagram
1. Identify classes
2. Add messages
3. Place lifeline and focus of
control
Slide 77
Syntax for Sequence Diagram
Slide 78
Steps of the Customer Places
Order Scenario
Slide 79
Sequence Diagram for Customer
Places Order Scenario
Slide 80
Class Diagram
Slide 81
Class Diagram Concepts
A static model that shows the classes and
relationships among classes that remain
constant in the system over time
Resembles the ERD, but depicts classes
which include both behaviors and states,
while entities in the ERD include only
attributes
Scope not system wide, but pertaining to a
single use-case
Slide 82
Class Diagram for Manage
Appointment
Slide 83
Class Diagram Syntax
Slide 84
Method Types
Constructor methods create new instances
of a class
Query methods determine the state of an
object and make information about that
state available to the system
Update methods will change the value of
some or all of the object’s attributes,
resulting in a change of state
Slide 85
Multiplicity
Slide 86
Association Class
Slide 87
Aggregation and
Generalization Associations
Slide 88
Steps in Creating a Class
Diagram
1. Identify classes
2. Identify attributes and
operations
3. Draw relationships between
classes
Inheritance
Associations
Aggregations
Slide 89
Class Diagram for Customer
Places Order (1)
Slide 90
Class Diagram for Customer
Places Order (2)
Slide 91
Class Diagram for Customer
Places Order (3)
Slide 92
Statechart Diagram
Slide 93
Statechart Concepts
A dynamic model showing changes
of state of a single class over time in
response to events along with its
responses and actions
Typically not used for all classes, but
just to help simplify the design of
algorithms for methods of complex
classes
Slide 94
Statechart Diagram for a
Hospital Patient
Slide 95
Syntax for Statechart Diagram
Slide 96
The Life of an Order
Slide 97
Steps for Creating a Statechart
Diagram
1. Identify the states
2. Identify the transitions
Slide 98
Statechart Diagram for an
Order
Slide 99
Slide 100
Slide 101
Summary
Many organizations are moving to the use
of object-oriented techniques
Objects are grouped into classes that
share common properties and methods
and arranged in a hierarchy
Objects communicate by sending
messages which trigger methods
Slide 102
Summary
Major object-oriented modeling
techniques include:
Use case diagrams
Sequence diagrams
Class diagrams
Statechart diagrams
Slide 103