5 SYSTEMS ANALYSIS C H A P T E R This repository of slides is intended to support the named chapter. The slide repository should be used as follows: Copy the file to a unique name for your course and unit. Edit the file by deleting those slides you don’t want to cover, editing other slides as appropriate to your course, and adding slides as desired. Print the slides to produce transparency masters or print directly to film or present the slides using a computer image projector. Each slide includes instructor notes. To view those notes in PowerPoint, click-left on the View Menu; then click left on Notes View sub-menu. You may need to scroll down to see the instructor notes. The instructor notes are also available in hardcopy as the Instructor Guide to Accompany Systems Analysis and Design Methods, 6/ed.

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. Teaching Notes Although some of the tools and techniques of systems analysis are previewed in this chapter, it is not the intent of this chapter to teach those tools and techniques. This chapter teaches only the process of systems analysis. The tools and techniques will be taught in the subsequent six chapters.

Chapter Map No additional notes

Systems Analysis Overview Systems Analysis vs. Systems Design Systems 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 No additional notes

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

Context of System Analysis

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.

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)

A Simple Process Model

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)

A Simple Data Model

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

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 1 has record for> 0..*

Automated Tools and Technology Computer-aided systems engineering (CASE) Application development environments (ADEs) Process and project managers No additional notes.

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. Teaching Notes Different CASE tools may refer to their repository as a dictionary or encyclopedia. Some CASE tools maintain a repository at a project-by-project level. Others provide or integrate into a project-independent repository to promote sharing of models and specifications between projects. Most CASE tools interface with one or more ADEs to provide round-trip engineering that supports the full life cycle.

CASE Tool Architecture Teaching Notes Map your course’s CASE (and ADE) environment into this diagram to help your students better understand the automated tools that will be taught in your course.

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 Teaching Notes ADE is compatible with both model-driven and rapid application development methodologies. In contemporary literature, it is the basis for all RAD methodologies. Many ADEs provide links to a repository to support sharing of program code. Most ADEs either interface with one or more CASE tool repositories or they provide rudimentary CASE-like modeling tools within the ADE. This allows developers to integrate RAD and MDD techniques as was demonstrated in the first hybrid route presented earlier in the chapter.

CASE tools Each different model can be drawn using general-purpose graphics SW Sybase PowerDesigner 9.5 Oracle Designer 2000

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

(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

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

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…..

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 analysis Work with systems owners and users Detail tasks see following slides… Deliverable A project charter that is approved by the steering committee

1. Scope Definition Phase

1. Scope Definition Tasks Next

1. Scope Definition Phase 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

Problem Statements

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

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)

1. Scope Definition Phase … 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

1. Scope Definition Phase … 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)

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)

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.

2. Problem Analysis Phase

2. Problem Analysis Tasks Next No additional notes

2. Problem Analysis Phase 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 No additional notes

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) No additional notes

2. Problem Analysis Phase … 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 No additional notes

2. Problem Analysis Phase … 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 No additional notes

PROBLEMS, OPPORTUNITIES, OBJECTIVES, AND CONSTRAINTS MATRIX No additional notes

2. Problem Analysis Phase … 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 No additional notes

2. Problem Analysis Phase … Task 2.6: Communicate Findings and Recommendations Deliverable: system improvement objectives Decision: continue/adjust/cancel current project No additional notes

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

3. Requirements Analysis Phase

3. Requirements Analysis Tasks Next

3. Requirements Analysis Phase 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

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.

3. Requirements Analysis Phase … 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)

3. Requirements Analysis Phase … Task 3.4: Communicate the Requirements Statement On-going task…

4. Logical Design (Modeling) Phase No additional notes Extension of Business Requirements – DFD, ER, user interface, OD….

4. Logical Design Phase

4. Logical Design Tasks Next No additional notes.

4. Logical Design Phase 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.

4. Logical Design Phase 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

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 system Work with appropriate participants System designers/builders, vendors, consultants…. Detail tasks See following slides… Deliverable System proposal

5. Decision Analysis Phase

5. Decision Analysis Tasks No additional notes.

5. Decision Analysis Phase Task 5.1: Identify Candidate Solutions Identify all possible candidate solutions Deliverable: candidate systems (solutions) matrix (Fig 5.19) No additional notes

Candidate Systems Matrix No additional notes

Candidate Systems Matrix.. No additional notes

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 No additional notes

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? No additional notes

5. Decision Analysis Phase … 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 No additional notes

Feasibility Matrix No additional notes

5. Decision Analysis Phase … Task 5.4: Update the Project Plan Input: recommended solution Review and update the latest project schedule and resource assignments Deliverable: updated project plan No additional notes

5. Decision Analysis Phase … Task 5.5: Recommend a Solution Deliverable: System Proposal No additional notes