1

Systems Analysis

Based on Chapter 5 of Whitten, Bentley, andDittman:Systems Analysis and Design for the GlobalEnterprise (7th Ed). McGraw Hill. 2007

Wei-Tsong WangIIM, NCKU

2

3

What is Systems Analysis ?

Systems analysis –a problem-solving technique thatdecomposes a system into its component pieces for thepurpose of studying how well those component parts workand interact to accomplish their purpose.

Systems design –a complementary problem-solvingtechnique (to systems analysis) that reassembles a system’scomponent pieces back into a complete system.

Information systems analysis –those development phasesin an information systems development project the primarilyfocus on the business problem and requirements,independent of any technology that can or will be used toimplement a solution to that problem.

4

Context of Systems Analysis

5

Model-Driven Analysis Methods

Model-driven analysis –a problem-solvingapproach that emphasizes the drawing of pictorialsystem models to document and validate bothexisting and/or proposed systems. Ultimately, thesystem model becomes the blueprint fordesigning and constructing an improved system.

Model –a representation of either reality orvision.

6

Model-Driven Approaches Traditional Approaches

Structured Analysis Focuses on the flow of data through processes Key model: data flow diagram (DFD)

Information Engineering Focuses on structure of stored data Key model: entity relationship diagram (ERD)

Object-Oriented Approach integrates data and process concerns into objects

Object –the encapsulation of the data (calledproperties) that describes a discrete thing.

An object has defined processes (called methods)for data manipulation.

Unified Modeling Language (UML)

7

A Simple Process Model

8

A Simple Data Model

9

A Simple Object Model

10

Accelerated Systems Analysis

Accelerated systems analysis approachesemphasize the construction of prototypes tomore rapidly identify business and userrequirements for a new system.

prototype –a small-scale, incomplete, butworking sample of a desired system.

Two examples of accelerated systems analysisapproaches: Discovery Prototyping Rapid Architected Analysis

11

Accelerated Systems Analysis

Discovery prototyping –a technique used toidentify the users’business requirements by havingthem react to a quick-and-dirty implementation ofthose requirements.

Rapid architected analysis –an approach thatattempts to derive system models (as describedearlier in this section) from existing systems ordiscovery prototypes.

Reverse engineering –the use of technology thatreads the program code for an existing database,application program, and/or user interface andautomatically generates the equivalent systemmodel.

12

Requirements Discovery

Requirements discovery –the process, usedby systems analysts of identifying or extractingsystem problems and solution requirementsfrom the user community.

13

Requirements Discovery Methods

Fact-finding –the process of collectinginformation about system problems,opportunities, solution requirements, andpriorities.However, some fact-finding approaches may be

time-consuming.Alternative: Joint requirements planning (JRP) –

use of facilitated workshops to bring together all ofthe system owners, users, and analysts, and somesystems designer and builders to jointly performsystems analysis.

14

Business Process Redesign

Business process redesign (BPR) –the application of systems analysismethods to the goal of dramaticallychanging and improving thefundamental business processes of anorganization, independent ofinformation technology.

15

Agile MethodsAgile method –integration of variousapproaches of systems analysis and design

Most commercial methodologies do not impose asingle approach (structured analysis, IE, OOA) onsystems analysts.

Instead, they integrate all popular approaches into acollection of agile methods.

System developers are given the flexibility to selectfrom a variety of tools and techniques to bestaccomplish the tasks at hand,

Hypothetical FAST methodology operates this way.

16

FAST Systems Analysis Phases

Scope Definition Phase Is the project worth looking at?

Problem Analysis Phase Is a new system worth building?

Requirements Analysis PhaseWhat do the users need and want from the new

system?Logical Design Phase

What must the new system do?Decision Analysis Phase

What is the best solution?

17

Context of Scope Definition PhaseIs the project worth looking at?

Problems?Opportunities?Motives?Goals?

18

Tasks for the Scope Definition Phase

19

Key Terms for Scope Definition Phase

Steering body –a committee of executive business andsystem managers that studies and prioritizes competingproject proposals to determine which projects will return themost value to the organization and thus should beapproved for continues systems development.Also called a steering committee.

Project charter –the final deliverable for the preliminaryinvestigation phase. A project charter defines the projectscope, plan, methodology, standards, and so on.Preliminary master plan includes preliminary schedule

and resource assignments (also called a baseline plan).Detailed plan and schedule for completing the next

phase of the project.

20

Sample Requestfor SystemServices

21

Sample Problem Statements

22

Context of Problem Analysis Phase

23

Tasks of the Problem Analysis Phase

“Don’t fix itunless youunderstand it!”

SystemImprovementReport (see figure5-13)

24

Key Terms of theProblem Analysis Phase

Cause-and-effect analysis –a technique in whichproblems are studied to determine their causes andeffects.

In practice, effects can be symptomatic of more deeplyrooted problems which, in turn, must be analyzed forcauses and effects until the causes and effects do not yieldsymptoms of other problems.

Context Diagram –a pictorial model that shows howthe system interacts with the world around it andspecifies in general terms the system inputs and outputs.

25

Sample Cause-and-EffectAnalysis

26

Sample Context Diagram

27

Key Terms of theProblem Analysis Phase (cont.)Objective –a measure of success. It is something thatyou expect to achieve, if given sufficient resources.

Reduce the number of uncollectible customeraccounts by 50 percent within the next year.

Constraint –something that will limit your flexibilityin defining a solution to your objectives. Essentially,constraints cannot be changed.

The new system must be operational by April 15.The new system cannot cost more than $350,000.The new system must be web-enabled.The new system must bill customers every 15 days.

28

Context of RequirementsAnalysis Phase

29

Requirements Analysis Phase Tasks

What do the userswant from a newsystem?

30

Key Terms ofRequirements Analysis PhaseFunctional requirement –a description ofactivities and services a system mustprovide.

inputs, outputs, processes, stored data

Nonfunctional requirement –a descriptionof other features, characteristics, andconstraints that define a satisfactory system.

Performance, ease of learning and use,budgets, deadlines, documentation,security, internal auditing controls

31

Key Terms of RequirementsAnalysis Phase (cont.)

Use caseA business scenario or event for which thesystem must provide a defined response.Use cases evolved out of object-orientedanalysis.However, their use has become common inmany other methodologies for systemsanalysis and design.

32

Key Terms of Requirements AnalysisPhase (cont.)Timeboxing –a technique that delivers informationsystems functionality and requirements throughversioning.

1. The development team selects the smallest subset ofthe system that, if fully implemented, will returnimmediate value to the systems owners and users.

2. That subset is developed, ideally with a time frame ofsix to nine months or less.

3. Subsequently, value-added versions of the systemare developed in similar time frames.

33

Key Terms of Requirements AnalysisPhase (cont.)

A mandatory requirement is one that must befulfilled by the minimal system, version 1.0

A desirable requirement is one that is notabsolutely essential to version 1.0. It may beessential to the vision of a future version.

34

Context of Logical Design Phase ofSystems Analysis

35

Tasks for Logical Design Phase

36

Context ofDecisionAnalysis Phase

37

Tasks for Decision Analysis Phase

38

Key Terms of Decision Analysis Phase

Technical feasibility –Is the solution technicallypractical? Does our staff have the technical expertiseto design and build this solution?

Operational feasibility –Will the solution fulfill theusers’requirements? To what degree? How will thesolution change the users’work environment? Howdo users feel about such a solution?

Economic feasibility –Is the solution cost-effective?

Schedule feasibility –Can the solution be designedand implemented within an acceptable time period?

39

Candidate Systems Matrix

40

Candidate Systems Matrix (cont.)

41

Feasibility Matrix

42

Typical System Proposal Outline

I. IntroductionA. Purpose of the reportB. Background of the project leading to this reportC. Scope of the reportD. Structure of the report

II. Tools and techniques usedA. Solution generatedB. Feasibility analysis (cost-benefit)

III. Information systems requirementsIV. Alternative solutions and feasibility analysisV. RecommendationsVI. Appendices