INFO 355 Week #1 1

Systems Analysis IIOverview and Requirements Gathering

INFO 355Glenn Booker

Review

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)

INFO 355 Week #1 2

SDLC core processes

Within a typical SDLC we need to: 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

INFO 355 Week #1 3

Waterfall versus Agile

In the waterfall life cycle, each process is done once and fully before going to the next process 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

INFO 355 Week #1 4

Iterative development

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

INFO 355 Week #1 5

RMO?

The text uses Ridgeline Mountain Outfitters (RMO) as a running example of IS development I’m positive they aren’t based on REI I won’t focus on the RMO example

INFO 355 Week #1 6

Project Vision document

One way to propose a new project is to write a System Vision Document for it Problem description – why need this? System capabilities – high level

functional requirements Business benefits – projected

improvements in process speed and/or quality, customer base, etc.

INFO 355 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

Break tasks down in a WBS (work breakdown structure)

Get user feedback Identify use cases Identify object classes

INFO 355 Week #1 8

Project Planning

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)

INFO 355 Week #1 9

Project Planning

Then refine the class diagram Design subsystems in detail Implement use cases through

system testing Deploy system when system test

results are ‘good enough’

INFO 355 Week #1 10

INFO 355 versus INFO 200

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

INFO 355 Week #1 11

INFO 355 Week #1 12

What is an Object?

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

INFO 355 Week #1 13

Huh?

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

INFO 355 Week #1 14

What is a Class?

“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

INFO 355 Week #1 15

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”

Investigating System Requirements

To understand an existing organization, determine their: 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

INFO 355 Week #1 16

Systems Analysis

Five major activities within this process Gather detailed information Define requirements Prioritize requirements Develop user-interface dialogs Evaluate requirements with users

INFO 355 Week #1 17

Requirements

Functional requirements WHAT can someone do using the

system? Non-functional requirements

HOW WELL can the system perform functional requirements?

Usability, reliability, performance, security, maintainability, etc.

INFO 355 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)

INFO 355 Week #1 19

FURPS = Functionality, Usability, Reliability, Performance and Supportability

Modeling

In analysis and design, modeling is critical for communicating the results of our work Some models are text, many are

graphic, few mathematical For object oriented A&D, UML is the

graphic language used

INFO 355 Week #1 20

INFO 355 Week #1 21

A Little History

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

INFO 355 Week #1 22

What’s UML?

UML, the Unified Modeling Language, is essentially a drawing convention to express object oriented software structure and functionality Just like architects use blueprints to

express different aspects of a building (e.g. plumbing vs. exterior), UML has different types of drawings

INFO 355 Week #1 23

UML Standard

UML is defined by a standard from the Object Management Group (OMG!) Current version is 2.5, dated

September 2013 Our goal is to focus on the most

useful parts of UML English has 600,000 words, but you

don’t need to know all of them

Stakeholders

To get complete requirements, need to identify and solicit all types of stakeholders in the project (p. 47) Internal stakeholders – employees,

volunteers, students External stakeholders – suppliers,

government agencies (regulators)

INFO 355 Week #1 24

Stakeholders

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

INFO 355 Week #1 25

Information-Gathering Techniques

Interviewing stakeholders Questionnaires Review legacy system inputs,

outputs, documentation Observe and document existing

business processes and procedures Research vendor solutions Collect user comments, suggestions

INFO 355 Week #1 26

INFO 355 Week #8 27

Activity Diagrams

Activity Diagrams are a type of flowchart used to describe a business process or workflow 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

INFO 355 Week #8 28

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) An activity diagram can show the

logical decisions of a process that the use case diagram can’t show

INFO 355 Week #8 29

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 Decisions are shown by diamonds

INFO 355 Week #8 30

Activity Diagram Simple Example

Fill Order Delay Order

[normal order] [urgent order]

Receive Order

Same start shape as State Diagram

Same end shape as State Diagram

Transition line with Guard condition

Process (same shape as a state)

Decision

Merge

INFO 355 Week #8 31

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 Merge

INFO 355 Week #8 32

Concurrent Flow

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 Join

INFO 355 Week #8 33

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 Prepare a release description Start packaging the release Notify customer of impending release Lock the contents of the release

INFO 355 Week #8 34

Concurrency ExampleApprove Release

Prepare Release Description

Package Release

Notify Customer

Lock Release Contents

Review Release Description

Audit Package ContentsUnlock Next Release

Execute Release

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 Week #8 35

Partitions

Notice that activities are often performed by different organizations within your project 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’)

INFO 355 Week #8 36

Partition Example

Receive Order

Fill Order

Deliver Order

Send Invoice

Receive Payment

Close Order

Order Fulfillment

Customer Service Finance

INFO 355 Week #8 37

Adding Details - Decomposing

Each step in an activity diagram could correspond to (or be decomposed into) a process or procedure which is documented elsewhere For example, Prepare Release

Description could follow a procedure to explain it in more detail

INFO 355 Week #8 38

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 Follow Life Cycle Phases Perform Support ActivitiesBecomes

INFO 355 Week #8 39

Adding Details - Decomposing

Perform Inception Phase

Perform Elaboration Phase

Perform Construction Phase

Perform Transition Phase

Manage Project

Manage Configuration

Manage Quality

Which in turn becomes

Notice similarity to the project schedule (WBS)

INFO 355 Week #8 40

Timing and Signals

So far the sense of time has been pretty vague 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

INFO 355 Week #8 41

Signals

A Time Signal can be used to indicate when a process waits for a specific timed event before it begins 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)

Wait 48 hours

INFO 355 Week #8 42

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 receive action><no send action>

INFO 355 Week #8 43

Signals

A signal can be split by a ‘fork’ symbol Fig 11.6, p. 123 (Send and receive

labels overwrittenmanually)

Reserve Itinerary

<no send action>

<no receive action>

Wait 48 hours

Send Itinerary

Cancel Itinerary

Book Itinerary

Itinerary Confirmed

INFO 355 Week #8 44

Tokens

To help follow a process, it sometimes helps to imagine physical tokens being passed along the paths A fork creates two or more tokens

to follow each path separately A join waits for all tokens to arrive

before proceeding

Summary

So this week we: 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

INFO 355 Week #1 45