Transcript Week #1 ** updated 9/22/14

Systems Analysis II
Overview and Requirements Gathering
INFO 355
Glenn Booker
INFO 355
Week #1
1
Review


INFO 355
The goal of systems analysis and
design is to understand and specify
(analysis) the needs of an
information system, and then solve
(design) how to make it happen
Usually this is in the form of a
project that follows some flavor of
Systems Development Life Cycle
(SDLC)
Week #1
2
SDLC core processes

Within a typical SDLC we need to:






INFO 355
Identify the problem
Plan and monitor the project
Clarify the problem (requirements)
Design the components to solve it
Build, test, and integrate those
components
Conduct system level testing and
deploy the system
Week #1
3
Waterfall versus Agile

In the waterfall life cycle, each
process is done once and fully
before going to the next process


INFO 355
Often the plan is set in stone
In the Agile development methods,
we assume we don’t know the
problem very well, so we expect the
plan will change as the project
unfolds iteratively
Week #1
4
Iterative development

INFO 355
In iterative development, the six
processes of the SDLC are repeated
over and over, first focusing more
on early processes, later iterations
doing more development and
testing
Week #1
5
RMO?

The text uses Ridgeline Mountain
Outfitters (RMO) as a running
example of IS development


INFO 355
I’m positive they aren’t based on REI
I won’t focus on the RMO example
Week #1
6
Project Vision document

One way to propose a new project
is to write a System Vision
Document for it



INFO 355
Problem description – why need this?
System capabilities – high level
functional requirements
Business benefits – projected
improvements in process speed and/or
quality, customer base, etc.
Week #1
7
Project Planning

If the vision gets support, next
develop and follow the project plan


Identify major subsystems, interfaces
Plan the first iteration in detail




INFO 355
Break tasks down in a WBS (work
breakdown structure)
Get user feedback
Identify use cases
Identify object classes
Week #1
8
Project Planning




INFO 355
Then develop a use case diagram
and activity diagrams
Define screen layouts (input and
output)
Define database structure (see
INFO 210)
Design the structure of the system
(architecture)
Week #1
9
Project Planning




INFO 355
Then refine the class diagram
Design subsystems in detail
Implement use cases through
system testing
Deploy system when system test
results are ‘good enough’
Week #1
10
INFO 355 versus INFO 200


INFO 355
So in procedural development
(INFO 200) you capture processes
in the DFD and data structure in the
ERD, but the details of
implementation are missing
Here we define requirements in ‘use
cases’ and capture more details of
design in a class diagram and
sequence diagrams
Week #1
11
What is an Object?

INFO 355
“An entity with a well-defined
boundary and identity that
encapsulates state and behavior.
State is represented by attributes
and relationships, behavior is
represented by operations,
methods, and state machines. An
object is an instance of a class.”
(UML 1.5 spec)
Week #1
12
Huh?




INFO 355
Attributes are the data contained by an
object, if any
Relationships describe which objects are
allowed to talk to each other
The operations and methods describe the
ways objects can interact with each other
So objects are a set of data which can
only be acted on in certain prescribed
ways
Week #1
13
What is a Class?


INFO 355
“A description of a set of objects
that share the same attributes,
operations, methods, relationships,
and semantics. A class may use a
set of interfaces to specify
collections of operations it provides
to its environment.” (UML 1.5 spec)
Hence a class is a group of
similar objects
Week #1
14
What is Object Oriented?


The methods isolate the data, so
that it can’t be manipulated directly
Only the methods can create, read,
modify, or delete data
Image from Apple, “Object-Oriented
Programming and the Objective-C Language”
INFO 355
Week #1
15
Investigating System Requirements

To understand an existing
organization, determine their:


INFO 355
Technology architecture – the
hardware, networking, and system
software in use
Application architecture – the
applications running on the technology
architecture used to perform business
processes and run their IS
Week #1
16
Systems Analysis

Five major activities within this
process





INFO 355
Gather detailed information
Define requirements
Prioritize requirements
Develop user-interface dialogs
Evaluate requirements with users
Week #1
17
Requirements

Functional requirements


Non-functional requirements


INFO 355
WHAT can someone do using the
system?
HOW WELL can the system perform
functional requirements?
Usability, reliability, performance,
security, maintainability, etc.
Week #1
18
FURPS+





Design constraints (OS, power,
memory usage, etc.)
Implementation constraints (prog
language, tools used, IDE, etc.)
Interface requirements (export XML
files, get data from NYSE)
Physical requirements (size, weight)
Supportability requirements
(autoupdate)
FURPS = Functionality, Usability, Reliability, Performance and Supportability
INFO 355
Week #1
19
Modeling

In analysis and design, modeling is
critical for communicating the
results of our work


INFO 355
Some models are text, many are
graphic, few mathematical
For object oriented A&D, UML is the
graphic language used
Week #1
20
A Little History



INFO 355
While object oriented programming
has existed since at least 1980
(Smalltalk), there were many ways
to describe and diagram an object
oriented system
Everybody had their own notation –
Booch, Rumbaugh, Jacobson, etc.
Finally unified in 1997 with UML
Week #1
21
What’s UML?

UML, the Unified Modeling
Language, is essentially a drawing
convention to express object
oriented software structure and
functionality

INFO 355
Just like architects use blueprints to
express different aspects of a building
(e.g. plumbing vs. exterior), UML has
different types of drawings
Week #1
22
UML Standard

UML is defined by a standard from
the Object Management Group
(OMG!)


Our goal is to focus on the most
useful parts of UML

INFO 355
Current version is 2.5, dated
September 2013
English has 600,000 words, but you
don’t need to know all of them
Week #1
23
Stakeholders

To get complete requirements, need
to identify and solicit all types of
stakeholders in the project (p. 47)


INFO 355
Internal stakeholders – employees,
volunteers, students
External stakeholders – suppliers,
government agencies (regulators)
Week #1
24
Stakeholders




INFO 355
Operational stakeholders – interact
with the system
Executive stakeholders – don’t interact
with the system
The client or sponsor pays for the
project, may or may not actually use it
Technical or support staff are also
stakeholders, help maintain the system
Week #1
25
Information-Gathering Techniques






INFO 355
Interviewing stakeholders
Questionnaires
Review legacy system inputs,
outputs, documentation
Observe and document existing
business processes and procedures
Research vendor solutions
Collect user comments, suggestions
Week #1
26
Activity Diagrams

Activity Diagrams are a type of
flowchart used to describe a
business process or workflow


INFO 355
They support parallel tasks, which
a traditional flowchart can’t handle
They are derived from state
diagram notation, so don’t be
surprised by the similarities
Week #8
27
Scope of Activity Diagrams

An activity diagram might show
the logic for a complex use case
(and all its extensions), or show
the interaction among several
use cases (such as when
included use cases apply)

INFO 355
An activity diagram can show the
logical decisions of a process that
the use case diagram can’t show
Week #8
28
Activity Diagram Notation

Activity diagram notation includes


The processes to be performed, which
appear as boxes with rounded corners
The processes are connected by lines
with arrows, to show the direction of
process flow
Arrows are always directional
in an activity diagram
 Use the Guard field for conditions


INFO 355
Decisions are shown by diamonds
Week #8
29
Activity Diagram Simple Example
Same start shape as
State Diagram
Process (same shape
as a state)
Receive Order
Decision
[urgent order]
Fill Order
Transition line with
Guard condition
[normal order]
Delay Order
Merge
Same end shape as
State Diagram
INFO 355
Week #8
30
Decisions


Notice that the diamond symbol is
used to show a split in the process
flow due to a decision
And the same symbol is used to
show when the process flows merge
afterwards
[condition]
[not condition]
Decision
INFO 355
Week #8
Merge
31
Concurrent Flow


INFO 355
Notice the implied assumption of
time going forward down the page
Concurrent, or parallel flows can be
shown by using a ‘fork’ symbol
when the flows split, and a ‘join’
symbol when they reconnect
Fork
Week #8
Join
32
Uses for Concurrent Flow


Several parallel activities might take
place after a single decision
For example, approval of a release
might initiate parallel activities to




INFO 355
Prepare a release description
Start packaging the release
Notify customer of impending release
Lock the contents of the release
Week #8
33
Concurrency Example
Shows four
concurrent
activity
threads to
prepare for a
new baseline
release; this
might all be
part of a
process called
Prepare
Release
INFO 355
Approve Release
Prepare Release Description
Notify Customer
Package Release
Audit Package Contents
Lock Release Contents
Unlock Next Release
Review Release Description
Execute Release
Week #8
34
Partitions

Notice that activities are often
performed by different
organizations within your project



INFO 355
You could add the organization to the
activity name, e.g. ‘Program Control
Notifies Customer’
Or use the approach on the next slide
Here is another variation on the
“swimlane” approach (each
organization has its own ‘lane’)
Week #8
35
Partition Example
Order
Fulfillment
Customer Service
Finance
Receive Order
Fill Order
Send Invoice
Deliver Order
Receive Payment
Close Order
INFO 355
Week #8
36
Adding Details - Decomposing

Each step in an activity diagram
could correspond to (or be
decomposed into) a process or
procedure which is documented
elsewhere

INFO 355
For example, Prepare Release
Description could follow a procedure
to explain it in more detail
Week #8
37
Adding Details - Decomposing

For that matter, the whole
development process could be
described in a single step, then
broken down to any desired level
of detail
Develop Product
INFO 355
Becomes
Week #8
Follow Life Cycle Phases
Perform Support Activities
38
Adding Details - Decomposing
Which in turn
becomes
Manage
Configuration
Perform Inception Phase
Notice
similarity to
the project
schedule
(WBS)
INFO 355
Manage
Quality
Perform Elaboration Phase
Manage
Project
Perform Construction Phase
Perform Transition Phase
Week #8
39
Timing and Signals

So far the sense of time has been
pretty vague




INFO 355
Time goes forward down the page
Forks and joins indicate when
concurrent processes collectively begin
and end
Decisions and merges reflect the start
and end of conditional process paths
To be more precise, use signals
Week #8
40
Signals

A Time Signal can be used to
indicate when a process waits for a
specific timed event before it begins


Wait 48
hours
INFO 355
E.g. end of month to start generating
a report
The Time Signal is like an
hourglass, labeled to show what
event for which it waits

(I made this one manually)
Week #8
41
Signals


Send Signals are triggered by
some process to start a timer
Receive Signals accept a signal as
input, and usually sound like an
event more than a process

‘Taxi arrives,’ ‘Itinerary confirmed,’ etc.
<no send action>
INFO 355
<no receive action>
Week #8
42
Signals

A signal can be split
by a ‘fork’ symbol


Fig 11.6, p. 123
(Send and receive
labels overwritten
manually)
Reserve Itinerary
<no
action>
Sendsend
Itinerary
<noItinerary
receive action>
Confirmed
Wait 48
hours
Book Itinerary
Cancel Itinerary
INFO 355
Week #8
43
Tokens

To help follow a process, it
sometimes helps to imagine
physical tokens being passed
along the paths


INFO 355
A fork creates two or more tokens
to follow each path separately
A join waits for all tokens to arrive
before proceeding
Week #8
44
Summary

So this week we:




INFO 355
Reviewed basic concepts of system
analysis and design
Added how our perspective changes for
object oriented A&D
Introduced UML
Showed how an activity diagram can be
used to document business processes
Week #1
45