Introduction to Information Systems Analysis Systems Analysis Joint Application Development

1
Introduction to InformationSystems
AnalysisSystems AnalysisJoint Application
Development

• INFO 503
• Glenn Booker

2
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 thats ours!

3
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

4
Systems Analysis Methods

• Model-Driven Analysis Approaches
• Structured Analysis
• Information Engineering
• Object-Oriented Analysis (OOA)
• Accelerated Analysis Approaches
• Discovery Prototyping
• Rapid Architected Analysis

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

6
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
• Both structured analysis and information
  engineering create an ERD and a DFD the
  difference is which model is done first

7
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

8
Discovery Prototyping

• Prototyping develops partial, but working,
  versions of a system or application
• Feasibility prototyping is to test the
  technologys 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

9
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

10
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

11
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

12
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

13
JAD Champion

• JAD sessions are typically all-consuming, and may
  take from 1-10 days
• Sponsor champions the JAD session
• Plans the attendees
• Picks the JAD Leader
• Chooses the time and place of the session
• Kicks off and closes the session

14
JAD Leader

• The JAD Leader may be an outsider who
• 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

15
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

16
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

17
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!

18
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

19
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

20
FAST Analysis Approach

• Now well start to outline the contents of the
  FAST methodology in detail
• Scope Definition Phase
• Problem Analysis Phase
• Requirements Analysis Phase
• Logical Design Phase

21
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

22
1.1 Identify baseline problems and opportunities

• Evaluate each problem, opportunity, and
  directive write a Problem Statement
• Done by system owner, user, and analysts using
  fact finding methods and keen interpersonal
  skills
• Determine urgency, visibility, benefits,
  priority, and optionally, possible solutions

p. 196 (132)
23
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

24
1.3 Assess baseline project worthiness

• Based on the projects 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

25
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

26
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

27
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

28
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

29
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

30
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?

31
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?

32
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 its done)
• Add results to the cause and effect analysis
  (Fig. 5-11 on page 207 (Fig. 4.12))

33
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

34
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

35
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

36
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

37
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

38
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

39
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

40
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

41
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

42
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 owneror sponsor

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

44
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

45
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

46
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

47
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

48
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

49
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

50
Next FAST Phases

• The Decision Analysis Phase will be discussed in
  week 5 with the other design phases