C H A P T E R

1. C H A P T E R 5 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 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

5. Systems Analysis vs. Systems Design Systems analysis: a problem-solving technique that decomposesa system into its component pieces for the purpose of studyinghow 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. STUDENT COURSE -ID Number -Name -Subject -Grade Point Average -Number 0..* has record for> -Title -Credit +Admit() 0..* +Regsiter for Classes() +Withdraw() +Create a Course() +Change Address() +Delete from Course Master() 1 +Calculate GPA() +Change in Course Master() 1 +Graduate() TRANSCRIPT COURSE -Semester -Division -Grade +Add() +Drop() +Complete() +Change Grade() A Simple Object Model

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

24. 1. Scope Definition Phase

25. 1. Scope Definition Tasks Next

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

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

31. 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)

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

35. 2. Problem Analysis Tasks Next

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

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

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

40. PROBLEMS, OPPORTUNITIES, OBJECTIVES, AND CONSTRAINTS MATRIX

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

42. 2. Problem Analysis Phase … • 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. 3. Requirements Analysis Phase

45. 3. Requirements Analysis Tasks Next

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

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

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