Introduction to Information
Systems Analysis
Systems Analysis
Joint Application Development
INFO 503
Glenn Booker
INFO 503
Lecture #3
1
What is System Analysis?
• System Analysis (logical design) is the
dissection of a system into pieces
(subsystems), and the study of how those
pieces interact and work
• It is followed by System Design
(Synthesis), where you take the pieces
and put them back together
• Terminology varies, but that’s ours!
INFO 503
Lecture #3
2
FAST & Systems Analysis
• The FAST model covers systems analysis in
the first four phases
– Scope Definition: Survey and plan system scope
– Problem Analysis: Study the existing system
and similar ones
– Requirements Analysis: Definition of
requirements for the new system
– Logical Design: to verify the requirements
INFO 503
Lecture #3
3
Systems Analysis Methods
• Model-Driven Analysis Approaches
– Structured Analysis
– Information Engineering
– Object-Oriented Analysis (OOA)
• Accelerated Analysis Approaches
– Discovery Prototyping
– Rapid Architected Analysis
INFO 503
Lecture #3
4
Structured Analysis
p. 188
(122)
• Structured analysis focuses on examining
the processes which are used by the system
to model business requirements
• Models include processes, inputs,
outputs, and files - such as a Data
Flow Diagram (DFD)
• Models describe how the system responds
to various actions (such as placing an order)
INFO 503
Lecture #3
5
Information Engineering
•
•
Information Engineering focuses more on
the data for an organization, with lesser
concern for processes
Develops the data model first (Entity
Relationship Diagram, or ERD) then will
create the process model (e.g. a DFD) and
deal with communication issues
–
INFO 503
Both structured analysis and information
engineering create an ERD and a DFD;
the difference is which model is done first
Lecture #3
6
Object Oriented Analysis
• In contrast, object oriented analysis defines
objects, who may contain data
• Data is only obtained or manipulated
through methods
– Methods are little programs, associated with a
class, which perform a very specific function
• Object oriented languages include C++, C#,
Java, Smalltalk (the first!), and Ada
INFO 503
Lecture #3
7
Discovery Prototyping
• Prototyping develops partial, but working,
versions of a system or application
– Feasibility prototyping is to test the
technology’s capabilities
(Is this tool capable of doing what we want?)
– Discovery prototyping is to refine the
requirements by presenting them visually
(Is this content correct?)
– Must accompany other design methods
INFO 503
Lecture #3
8
Rapid Architected Analysis
• Uses existing systems to develop
system models
• May use reverse engineering to
determine what the existing system
does (i.e. create models from code),
then improve on the existing system
based on its current structure
• Often involves CASE tools
INFO 503
Lecture #3
9
Requirements Discovery
Methods
• All analysis methods depend on
determining system requirements, using
one or more of the following methods:
– Fact-Finding Techniques (see last week)
– Joint Requirements Planning (JRP)
• Part of Joint Application Design (JAD)
• Uses trained facilitator to run a JRP workshop
– Business Process Redesign
INFO 503
Lecture #3
10
Joint Application Development
• JAD uses participative development, and
complements both model-driven and
accelerated development
• Joint Requirements Planning (JRP) is that
part of JAD which helps to define the
requirements through collaborative
discussion among stakeholders
INFO 503
Lecture #3
11
Joint Application Development
• Joint Application Development (JAD) is an
intense, structured group activity to reach
agreement on system requirements and high
level design
• Like any other tool, it may be used or not
• Blends disparate views to help reach
agreement, and reduces fact-finding time
INFO 503
Lecture #3
12
JAD Champion
• JAD sessions are typically all-consuming,
and may take from 1-10 days
• Sponsor “champions” the JAD session;
–
–
–
–
INFO 503
Plans the attendees
Picks the JAD Leader
Chooses the time and place of the session
Kicks off and closes the session
Lecture #3
13
JAD Leader
• The JAD Leader may be an outsider who:
–
–
–
–
–
–
INFO 503
Can communicate well
Can negotiate and resolve conflict
Understands the business environment
Can organize and manage a group
Is impartial
Does not report to any of the JAD participants
Lecture #3
14
JAD Participants
• The Leader facilitates the session
• Users, analysts, and managers are
common participants
• Someone is appointed “scribe” to record
what was discussed and distribute it quickly
• IS people may help provide a sanity check
of the ideas discussed
INFO 503
Lecture #3
15
Planning JAD
• Planning a JAD session must include
definition of high level scope and
requirements for each session
• Select a remote location for the sessions, to
improve focus on the task at hand
• Select participants who can contribute
specific relevant knowledge
INFO 503
Lecture #3
16
JAD Agenda
• Agenda must define the scope of discussion
and how much time is allocated to each
– Opening to define ground rules
and expectations
– Body to actually get the work done
– Conclusion to summarize the key points and
decisions, and remind all of unresolved issues
• Stay focused, yet strive for consensus!
INFO 503
Lecture #3
17
JAD Benefits
• Encourages ownership of the
decisions reached
• Reduces time for early development,
primarily by working out different needs
and perspectives together
• May blend prototyping benefits as well
INFO 503
Lecture #3
18
Business Process Redesign
• Business process redesign (or
reengineering) focuses on improving the
business processes, regardless of existing
computer technology usage
• Study each process for bottlenecks,
value added, wasted effort, and chances
for streamlining
• Often adds automation of processes
INFO 503
Lecture #3
19
FAST Analysis Approach
• Now we’ll start to outline the contents of
the FAST methodology in detail
–
–
–
–
INFO 503
Scope Definition Phase
Problem Analysis Phase
Requirements Analysis Phase
Logical Design Phase
Lecture #3
20
Scope Definition (Study) Phase
1.1 Identify baseline problems
and opportunities
1.2 Negotiate baseline scope
(may be concurrent with 1.1)
1.3 Assess baseline project worthiness
1.4 Develop baseline schedule and budget
1.5 Communicate the project plan
INFO 503
Lecture #3
21
1.1 Identify baseline problems
and opportunities
• Evaluate each problem, opportunity, and
p. 196
directive; write a Problem Statement
(132)
• Done by system owner, user, and analysts
using fact finding methods and keen
interpersonal skills
• Determine: urgency, visibility, benefits,
priority, and optionally, possible solutions
INFO 503
Lecture #3
22
1.2 Negotiate baseline scope
• Determine the preliminary scope of the
system and the project
• Involves system owner and analysts, others
as needed
• Write a Prelim. Problem Statement with
Scope: identify types of data and existing
business functions affected, system context
for interfaces, and operating locations
INFO 503
Lecture #3
23
1.3 Assess baseline project worthiness
• Based on the project’s Problem Statement,
system owners determine if project is
worth continuing
• Full feasibility analysis not yet possible
• Result is a Yes/No decision whether
to proceed, or negotiation of the scope
before approval is given
INFO 503
Lecture #3
24
1.4 Develop baseline
schedule and budget
• Develop a project plan, containing an
overall plan for the entire project, and a
detailed plan for the first phase of the
project (See also INFO 638)
• Done by project manager
• Define phases for the project, key activities
for each phase, and the personnel needed
INFO 503
Lecture #3
25
1.5 Communicate the project plan
• Present the project plan to an executive
‘steering body’ or whoever is needed to
approve it
• This activity also presents the project plan
(except sensitive parts) to all who will be
involved in it, often via a kickoff meeting
• Results in a project charter, containing the
results of all previous tasks
INFO 503
Lecture #3
26
Problem Analysis
(Study) Phase
2.1 Understand the problem domain
2.2 Analyze problems and opportunities
2.3 Analyze business processes (BPR only)
2.4 Establish system improvement objectives
2.5 Update or refine the project plan
2.6 Communicate findings and
recommendations
INFO 503
Lecture #3
27
2.1 Understand the problem domain
• Create models of the existing system
• Define the data, processes, interfaces, and
geography of the existing system in 1-2
page diagrams or short descriptions
• Avoid too much detail (analysis paralysis)
by avoiding perfectionism
• Ensure everyone agrees on the models
INFO 503
Lecture #3
28
2.2 Analyze problems and
opportunities
• Identify every problem, opportunity
(including existing good features you want
to keep) and directive
– This refines and expands on the earlier problem
and opportunity analysis
• Conduct cause and effect analysis of each
problem and opportunity, without seeking a
solution yet, using the PIECES structure
INFO 503
Lecture #3
29
2.2 Analyze problems and
opportunities
• Consider what has caused each problem,
and describe the effect of the problem on
your business
• Focus on business functions and system
capabilities – no technology yet!
• Define effects of new opportunities; how
will they affect the system?
INFO 503
Lecture #3
30
2.3 Analyze business processes
• This task applies to BPR projects only
• Lead by an analyst; no builders or designers
• Create process analysis models (like DFD)
– Show the volume of data and response or
processing times
– Identify bottlenecks by looking at the cost
and value-added of each function
– What loss if a process were removed?
INFO 503
Lecture #3
31
2.4 Establish system
improvement objectives
• Define objectives to measure system
improvement and development constraints
• Predict the effect of fixing each problem,
and taking advantage of each opportunity
• Remember not to describe specific
implementation technology (how it’s done)
• Add results to the cause and effect analysis
(Fig. 5-11 on page 207 (Fig. 4.12))
INFO 503
Lecture #3
32
2.4 Establish system
improvement objectives
• Make sure you can measure the amount of
improvement or benefit
– Objectives describe system success criteria
• Avoid writing detailed requirements for the
system at this point (“generate blah report”)
– Focus on what type of system capability will be
created or enhanced, and how that will help
improve the business value of the system
INFO 503
Lecture #3
33
2.4 Establish system
improvement objectives
– Avoiding specific requirements here allows
more flexibility later
• Identify constraints, which may be due
to schedule, cost, technology, or policy
(including legal directives)
– The only place system technology details
might belong in Fig. 5-11 (4.12) is under
the constraints column
INFO 503
Lecture #3
34
2.5 Update or refine the project plan
• Based on better understanding of project
goals and objectives, update the project plan
• Re-assess the scope; determine if all
objectives can be met
• Re-estimate time for each activity, and
refine the overall project plan
• If needed, re-negotiate project scope with
system owner
INFO 503
Lecture #3
35
2.6 Communicate findings and
recommendations
• The System Improvement Objectives and
Recommendations report should be written,
and presented to the system owners
– Summarize all analysis results so far
– The owners make the final decision as to the
scope of the project, or cancel it
• Then communicate the decision to all
affected project team members
INFO 503
Lecture #3
36
Requirements Analysis
(Definition) Phase
3.1 Identify and express system requirements
3.2 Prioritize system requirements
3.3 Update or refine the project plan
3.4 Communicate the requirements statement
INFO 503
Lecture #3
37
3.1 Identify and express
system requirements
• Describe all system requirements, based
on system improvement objectives
• Include both functional and
non-functional requirements
– Functional requirements are the activities and
services performed by the system, such as
inputs, outputs, processes, and stored data
needed to meet the system objectives
INFO 503
Lecture #3
38
3.1 Identify and express
system requirements
• For each system objective:
– Identify events or inputs to which the
system must respond
– Identify how the inputs are processed, and
what decisions need to be made
– Identify outputs which result, and any other
information which is produced along the way
– Identify data which needs to be stored
INFO 503
Lecture #3
39
3.1 Identify and express
system requirements
• Nonfunctional requirements are other
features and constraints – performance (e.g.
speed, throughput), cost, schedule, controls,
documentation, training, and constraints
• Look out for growth in the system scope
• Introduce system architect as new analyst
• Creates a draft requirements statement
INFO 503
Lecture #3
40
3.2 Prioritize system requirements
• Categorize requirements as mandatory,
desirable, or optional, then rank each within
those categories
• Stage (timebox) the requirements to ensure
the highest priority ones are built first
• Define system version history to implement
features in order of descending priority
INFO 503
Lecture #3
41
3.3 Update or refine the project plan
• Update the project plan to:
– Reflect changes in project scope, and
having prioritized requirements
– Include the detailed schedule for
implementation of features
• Create a Requirements Statement
• Get approval to proceed from owner
or sponsor
INFO 503
Lecture #3
42
3.4 Communicate the
requirements statement
• Once the requirements have been agreed
upon, communicate them to affected
members of the project team and the user or
customer community (if applicable)
INFO 503
Lecture #3
43
Requirements Management
• Requirements are never static!
• Need to have clear processes for
managing requirements
– Is it a new requirement, or refinement of an
old one?
– Analyzing and prioritizing new requirements
– Approving new requirements
– Communicating new requirements
INFO 503
Lecture #3
44
Logical Design Phase
• [Is part of Requirements Analysis phase in
4th edition of text]
4.1a Structure functional requirements and/or
4.1b Prototype functional requirements
4.2 Validate functional requirements
4.3 Define acceptance test cases
INFO 503
Lecture #3
45
4.1a Structure functional
requirements
• Create a logical (essential) model of the
proposed system
– Often use existing models as foundation for the
new ones
• May need to create data, process, interface,
and distribution models; or object models,
depending on the analysis strategy
INFO 503
Lecture #3
46
4.1b Prototype functional
requirements
• Prototyping is sometimes an alternative or a
prerequisite to system modeling (step 4.1a)
• Typically includes preparing sample inputs
and outputs, then having users review them
• Usually helps most with definition of
functional requirements
INFO 503
Lecture #3
47
4.2 Validate functional requirements
• Trace system models back to the
requirements, to ensure every requirement
is implemented somewhere
• Also look for duplication and redundancy
• Check where nonfunctional requirements
apply to functional requirements
• Review with owners and users
INFO 503
Lecture #3
48
4.3 Define acceptance test cases
• While not required this early, outlining the
test cases for system testing can help verify
that the requirements will fulfill the
intended functions
• System test cases often mimic user
activities, such as use cases or scenarios
• Test cases should be able to help prove
whether objectives were met
INFO 503
Lecture #3
49
Next FAST Phases
• The Decision Analysis Phase will be
discussed in week 5 with the other
design phases
INFO 503
Lecture #3
50