1 5 C H A P T E R SYSTEMS ANALYSIS. 2 Chapter Five Systems Analysis Define systems analysis and relate the term to the scope definition, problem analysis,

1

5C H A P T E R

SYSTEMS ANALYSIS

2

Chapter Five Systems Analysis

Define systems analysis and relate the term to the scope definition, problem analysis, requirements analysis, logical design, and decision analysis phases of this book’s systems development methodology.

Describe a number of systems analysis approaches for solving business system problems.

Describe the scope definition, problem analysis, requirements analysis, logical design, and decision analysis phases in terms of your information system building blocks.

Describe the scope definition, problem analysis, requirements analysis, logical design, and decision analysis phases in terms of purpose, participants, inputs, outputs, techniques, and steps.

Identify those chapters and modules in this textbook that can help you learn specific systems analysis tools and techniques.

3

Chapter Map

4

Systems Analysis Overview

Systems Analysis vs. Systems DesignSystems Analysis Approaches Systems Analysis Phases (purposes, participants, inputs,

outputs, techniques, and steps)– Scope Definition– Problem Analysis– Requirements Analysis– Logical Design– Decision Analysis

User Requirements Discovery

5

Systems Analysis vs. Systems Design

Systems analysis: a problem-solving technique that decomposes a system into its component pieces for the purpose of studying how well those component parts work and interact to accomplish their purpose.

Describe the early stages (next slide) of systems development (25% of project time)

Decomposition and hierarchy chart for abstraction

Systems design: a complementary problem-solving technique to systems analysis that reassembles a system’s component pieces back into a complete system

6

Context of System Analysis

7

Model-Driven Analysis

Use model-driven methodology (strategy or approach)

Model-driven analysis emphasizes the drawing of graphical system models to document and validate both existing and/or proposed systems.

Ultimately, the system model becomes the blueprint for designing and constructing a system.

8

Model-Driven

Structured analysis (methodology): a model-driven, PROCESS-centered technique to analyze an existing system and define business requirements for a new system.

The models illustrate the system’s components: processes (functions, tasks) and their associated inputs, outputs, and files.

Data Flow Diagram (DFD)

9

A Simple Process Model

10

Model-Driven

Information engineering (IE) (methodology): a model-driven and DATA-centered, but process-sensitive (context specific) technique to plan, analyze, and design information systems.

IE illustrate and synchronize the system’s data and processes.

Entity-Relationship Diagram (ERD)

11

A Simple Data Model

12

Model-Driven

Object-oriented analysis (OOA) (methodology): a model-driven technique that integrates data and process concerns into constructs called OBJECTS.

OOA illustrate the system’s objects from various perspectives such as structure and behavior.

Encapsulation Diagram of data and process in an object

Use Case Diagram was an initial methodology of OOA

13

A Simple Object Model

+Admit()+Regsiter for Classes()+Withdraw()+Change Address()+Calculate GPA()+Graduate()

-ID Number-Name-Grade Point Average

STUDENT

+Create a Course()+Delete from Course Master()+Change in Course Master()

-Subject-Number-Title-Credit

COURSE

+Add()+Drop()+Complete()+Change Grade()

-Semester-Division-Grade

TRANSCRIPT COURSE

11

has record for>0..*

0..*

14

Automated Tools and Technology

Computer-aided systems engineering (CASE)

Application development environments (ADEs)

Process and project managers

15

Computer-Aided Software Engineering (CASE)

Computer-aided systems engineering (CASE) – the use of automated software tools that support the drawing and analysis of system models and associated specifications. Some CASE tools also provide prototyping and code generation capabilities.

CASE repository – a system developers’ database where developers can store system models, detailed descriptions and specifications, and other products of system development. Synonyms include dictionary and encyclopedia.

16

CASE Tool Architecture

17

Application Development Environments

Application development environments (ADEs) – an integrated software development tool that provides all the facilities necessary to develop new application software with maximum speed and quality (Visual Studio.Net). A common synonym is integrated development environment (IDE)

– ADE facilities may include (read textbook): Programming languages or interpreters Interface construction tools Middleware Testing tools Version control tools Help authoring tools Repository links

18

CASE tools

Each different model can be drawn using general-purpose graphics SW – Sybase PowerDesigner 9.5

– Oracle Designer 2000

19

Accelerated Systems Analysis

• Accelerated systems analysis approaches emphasize the construction of prototypes to more rapidly identify business and user requirements for a new system. (Discovery) Prototyping Rapid Architected Analysis

20

(Discovery) Prototyping

(Discovery) prototyping – a technique used to identify the users’ business requirements by having them react to a quick-and-dirty implementation of those requirements.– Advantages

Prototypes cater to the “I’ll know what I want when I see it” way of thinking that is characteristic of many users and managers.

– Disadvantages Can become preoccupied with final “look and feel” prematurely Can encourage a premature focus on, and commitment to, design Users can be misled to believe that the completed system can be built

rapidly using prototyping tools

21

Rapid Architected Analysis

Rapid architected analysis (in real world: Reverse engineering) – derive system models from existing systems or discovery prototypes.

Blending of model-driven and accelerated approach Reverse engineering – the use of technology that reads the

program code for an existing database, application program, and/or user interface and automatically generates the equivalent system model.

– First IBM compatible PC by Compaq

– Data modeling by reverse engineering

22

Systems Analysis Phases

Scope Definition Phase : WHAT PROBLEM– Is the project worth looking at ?

Problem Analysis Phase: WHAT ISSUES– Is the new system worth building

Requirements Analysis Phase: WHAT REQUIREMENTS– What do users need and want from the new system?– Details in chapter 6

Logical Design Phase: WHAT TO DO– What the new system must do

Decision Analysis Phase: WHAT SOLUTION– What is the best available solution ?

Rest of slides are self-explanatory…..

23

1. Scope Definition Phase

Objective– Preliminary investigation step– Determine the value of the project– Create a plan to complete those projects deemed worthy

of a detailed study and analysisWork with systems owners and usersDetail tasks

– see following slides…Deliverable

– A project charter that is approved by the steering committee

24


25

1. Scope Definition Tasks

Next

26


Task 1.1: Identify Problems, Opportunities, and Directives (apply PIECES framework)

• Input: Request for System Service

• Deliverable: Problem Statement

− Urgency, Visibility, Benefits, Priority, Possible Solutions

• primary technique: fact-finding with system users

27

Problem Statements

28

1. Scope Definition Phase ...

Task 1.2: Negotiate Baseline Scope

•Deliverable: Statement of Project Scope (boundary of the project)

•What types of DATA to be studied

•What business PROCESSES to be included

•How the system INTERFACE with users, locations, and other systems

•Note: if later the scope changes, the budget and schedule should be changed accordingly

29

1. Scope Definition Phase …

Task 1.3: Assess Baseline Project Worthiness

•“Is this project worth looking at ?”

•Cost/benefit analysis

•Decision

•Approve project

•Cancel project

•Renegotiate the scope of project (with adjusted budget and schedule)

30


Task 1.4: Develop Baseline Schedule and Budget

• Deliverables: Project Charter

• Master plan for the whole project: schedule and resource assignments

• Detail plan and schedule for completing the next phase

31


Task 1.5: Communicate the Project Plan

• Present and defend the project and plan before steering committee

• Formally launch the project and announce the project, goals, and schedule

• Deliverable: Project Charter (participants, problems, scope, methodology, statement of work to be completed, deliverables, quality standards, schedule, budget)

32

2. Problem Analysis Phase

Objective– Are the problems really worth solving?

– Is a new system really worth building?

Continue to work with systems owners and users and other IS management and staff

Detail tasks– See following slides…

Deliverable– Systems improvement objectives (next slide)

33

System Improvement Objectives

• Objective – a measure of success. It is something (measurable) that we expect to achieve, if given sufficient resources.

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

Increase by 25 percent the number of loan applications that can be processed during an eight-hour shift.

Decrease by 50 percent the time required to reschedule a production lot when a workstation malfunctions.

• Constraint – something that will limit our flexibility in defining a solution to our 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.

34


35

2. Problem Analysis Tasks

Next

36


Task 2.1: Understand the Problem Domain

•Understanding of the problem domain and business vocabulary

•DATA: currently stored data, their business terms

•PROCESSES: current business events

•INTERFACES: current locations and users

•Deliverables: definition of system domain / models of current systems

37

2. Problem Analysis Phase …

Task 2.2: Analyze Problems and Opportunities

•Study causes and effects of each problem (Note: an effect may be the cause of other problems)

•Deliverables: updated problem statements and the cause-effect analyses for each problem and opportunities (Fig 5.11)

38


Task 2.3: Analyze Business Processes (for BPR)

•Measure the value added or subtracted by each process as it relates to the total organization

•Volume of throughput, response time, bottlenecks, cost, value added, consequences of eliminating or streamline of the process

•Deliverable: current business process models

39


Task 2.4: Establish System Improvement Objectives

•Define specific system improvement objectives and constraints for each problem

•Objectives to be precise, measurable

•Constraints in terms of schedule, cost, technology, policy

•Deliverable: System Improvement Objectives and Recommendations Report

40

PROBLEMS, OPPORTUNITIES, OBJECTIVES, AND CONSTRAINTS MATRIX

41


Task 2.5: Update or Refine the Project Plan

•Update project:

•Reduce the scope to keep only higher priority objectives to meet a deadline/budget

•Expanse the scope and adjust schedule and budget accordingly

•Deliverable: updated project plan

42


Task 2.6: Communicate Findings and Recommendations

•Deliverable: system improvement objectives

•Decision: continue/adjust/cancel current project

43

3. Requirements Analysis Phase

Objective– Identify what the new system is to do without the

consideration of technology

Actively work with systems owners and users and other IS professionals

Detail tasks– See following slides…

Deliverable– Business requirements statement

44


45

3. Requirements Analysis Tasks

Next

46


Task 3.1: Identify and Express System Requirements

• Functional requirements: activities and services providing by a system: business functions, inputs, outputs, stored data.

• Nonfunctional requirements: features, characteristics defining a satisfactory system: performance, documentation, budget, ease of use and learn, cost saving, time saving, security

•Deliverable: draft functional and nonfunctional requirements: improvement objectives and related input, output, processes, stored data to fulfill the objectives

47

3. Requirements Analysis Phase …

Task 3.2: Prioritize System Requirements

• Mandatory vs. desirable requirements

• Time boxing: deliver the system in a set of subsequent versions in a time frame. The first version satisfies essential and highest prioritized requirements.

48


Task 3.3: Update or Refine the Project Plan

•If requirements exceed original vision: reduce the scope or increase the budget

•Deliverable: consolidated system requirements (completed requirements and priorities)

49


Task 3.4: Communicate the Requirements Statement

• On-going task…

50

4. Logical Design (Modeling) Phase

Extension of Business Requirements – DFD, ER, user interface, OD….

51

4. Logical Design Phase

52

4. Logical Design TasksNext

53


• Task 4.1: Analyze Functional Requirements

•Logical systems models: WHAT the system must do (not HOW)

•Separation of business concerns from technical solutions will help considering many different ways for business processes improvement and alternative technical solutions

•Build prototypes to establish user interface requirements

•Deliverables: Data models (ERD), Process models (DFD), Interfaces models (Context diagram, Use case diagram), Object models (UML diagrams) of the proposed system.

54


• Task 4.2: Validate Functional Requirements

•Completeness check, revisit, make changes and additions to system models and prototypes to assure that requirements are adequately defined.

•Associate nonfunctional requirements with functional requirements

55

5. Decision Analysis Phase

Objective– Transition the project from business concerns to technical

identifying, analyzing, and recommending a technical system solution.

– Borderline between business and technical systemWork with appropriate participants

– System designers/builders, vendors, consultants….Detail tasks

– See following slides…Deliverable

– System proposal

56


57

5. Decision Analysis Tasks

58


Task 5.1: Identify Candidate Solutions

•Identify all possible candidate solutions

•Deliverable: candidate systems (solutions) matrix (Fig 5.19)

59

Candidate Systems Matrix

60

Candidate Systems Matrix..

61

5. Decision Analysis Phase …

Task 5.2: Analyze Candidate Solutions

•Feasibility analysis is performed on each individual candidate without regard to the feasibility of other candidates

•Technical, operational, economic, schedule feasibilities

62

Feasibility Analyses

Technical feasibility. Is the solution technically practical? Does our staff have the technical expertise to design and build this solution?

Operational feasibility. Will the solution fulfill the users’ requirements? To what degree? How will the solution change the users’ work environment? How do users feel about such a solution?

Economic feasibility. Is the solution cost-effective?

Schedule feasibility. Can the solution be designed and implemented within an acceptable time period?

63


Task 5.3: Compare Candidate Solutions

•Select the candidate solution having the “best overall” combination of technical, operational, economic, and schedule feasibilities

•Feasibility matrix

•Deliverable: recommended solution

64

Feasibility Matrix

65


Task 5.4: Update the Project Plan

•Input: recommended solution

•Review and update the latest project schedule and resource assignments

•Deliverable: updated project plan

66


Task 5.5: Recommend a Solution

•Deliverable: System Proposal

1 5 C H A P T E R SYSTEMS ANALYSIS. 2 Chapter Five Systems Analysis Define systems analysis and relate the term to the scope definition, problem analysis,

Documents