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

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

3. Chapter Map
No additional notes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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
No additional notes
Extension of Business Requirements – DFD, ER, user interface, OD….

51. 4. Logical Design Phase

52. 4. Logical Design Tasks
Next
No additional notes.

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

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

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

56. 5. Decision Analysis Phase

57. 5. Decision Analysis Tasks
No additional notes.

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

59. Candidate Systems Matrix
No additional notes

60. Candidate Systems Matrix..
No additional notes

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

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

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

64. Feasibility Matrix
No additional notes

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

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