The document discusses systems analysis and its various phases. It defines systems analysis as a problem-solving technique that breaks down a system into components to study how well they work and interact. The key phases of systems analysis discussed are: scope definition, problem analysis, requirements analysis, logical design, and decision analysis. Each phase involves various tasks like identifying problems, analyzing requirements, designing logical structures, and selecting solutions. The document provides details on the objectives, techniques, and deliverables involved in each task and phase of the systems analysis methodology.
3. What is Systems Analysis ?
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.
5-3
5. System Analysis ApproachesSystem Analysis Approaches
Model-Driven Analysis Methods
Model-driven architecture (MDA) is a software
design approach for the development of software systems.
It provides a set of guidelines for the structuring of
specifications, which are expressed as models.
• Unified Modeling Language
(UML)
• Object-Oriented Approach
5-5
7. Accelerated Systems Analysis
Accelerated systems analysis is a problem solving
technique that decomposes a system into several
components in order to identify how these
components work and interact
5-7
9. Requirements Discovery Methods
• Fact-finding – the process of collecting information about
system problems, opportunities, solution requirements, and
priorities.
• Joint requirements planning (JRP) –use of facilitated
workshops to bring together all of the system owners, users,
and analysts, and some systems designer and builders to
jointly perform systems analysis.
5-9
10. Business Process Redesign
Business process
reengineering (BPR) is the
practice of rethinking
and redesigning the way work is
done to better support an
organization's mission and
reduce costs.
5-10
11. FAST Systems Analysis Phases
• Scope Definition Phase
• Is the project worth looking at?
• Problem Analysis Phase
• Is a new system worth building?
• Requirements Analysis Phase
• What 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?
5-11
13. The Scope Definition Phase
• Define the scope of the problem, perceived problems, opportunities,
and directives that triggered the project
• Must establish the project plan on terms of scale, development
strategy, schedule, resource requirements and budget.
• Scope Definition Phase consists of five tasks
1.Identify Baseline Problems and Opportunities
2.Negotiate Baseline Scope
3.Assess Baseline Project Worthiness
4.Develop Baseline Schedule and Budget
5.Communicate the Project Plan
5-13
15. Identify Baseline Problems and
Opportunities
• after baseline is established, each problem, opportunity, and
directive is assessed with respect to urgency, visibility, tangible
benefits, and priority.
• Leaders: Senior System Analysts or Project Manager
• Key Deliverable: Preliminary Problem Statement
• Primary Technique: fact-finding and meetings with system owners
5-15
16. Negotiate Baseline Scope
• Preliminary scope can change, potentially effecting budget and
schedule
• Defined in simple list, not concerned with details.
• Participants: System Owners' (includes executive sponsor) managers
of all other organizational units that may be effected.
• Trigger: Preliminary Problem Statement
• Techniques: fact-finding and meetings
5-16
17. Assess Baseline Project Worthiness
• answer "Is this project worth looking at?"
• "Will the value of the project offset costs incurred in development?"
(best guess)
• Leader: System Analyst or Project Manager, BUT the System Owner
(inclusive of exec sponsor) should make the decision
• Trigger: Preliminary Problem Statement with Scope.
• Deliverable: go or no-go.
5-17
18. Develop Baseline Schedule and Budget
• initial project plan should at least consist of a preliminary master
plan (includes schedule and resource assignments for entire project)
and a detailed plan and schedule for completing the next phase of
the project (problem analysis phase)
• Leader: Project Manager
• Participants: Project Team (joint project planning)
• Trigger: go or no-go; Problem Statement with Scope
• Deliverable: Baseline Project Plan and Schedule
• Technique: use of project management software (Microsoft Project)
5-18
20. Communicate the Project Plan
• formally launch the project and communicate the project, goals, and
schedule to the entire business community;
• conduct project kickoff event (open to entire business community) and
create an intranet project Web site;
• Leaders: Executive Sponsor jointly facilitate task with Project Manager
• Techniques: Use of effective interpersonal and communication skills
5-20
22. Problem Analysis Phase
• 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.
• Problem Analysis Phase typically includes 6 tasks
5-22
23. Understand the Problem Domain
• Each team member brings different vocabulary, perceptions, and
opinions
• Must understand problem domain
• Leaders: Project Manager, facilitated by lead System Analyst
• Participants: other System Analysts to conduct interviews, scribe for
meetings, and document findings; representative from owners and users
from all supporting or impacted business units
• Trigger: Approval to Continue the Project
5-23
24. Analyze Problems and Opportunities
• analyze the problem for causes and effects before stating any
possible solution
• Leaders: System Analysts
• Participants: Owners and Users should actively participate in C and E
analysis
• Deliverable: Updated Problem Statements and Cause-And-Effect
Analysis for each problem and opportunity ( Problems,
Opportunities, Objectives, and Constraints Matrix)
• Techniques: fact-finding and JRP
5-24
25. Analyze Business Processes
• Measure value added or subtracted by process as it relates to the
total organization
• owners and users can become defensive of existing business
processes, analysts must keep focus on processes not people who
perform them
• Leader: One or more System Analysts or Business Analysts ideally
trained, experienced, or certified in BPR
• Participants: Owners and Users
• Trigger: Only some Problem Domain knowledge
5-25
27. Establish System Improvement
Objectives
• purpose is to establish the criteria against which any improvements
to the system will be measured (objectives).
• identify any constraints that may limit flexibility in achieving those
improvements;
• objectives establish expectations for any new system.
5-27
28. Update or Refine the Project Plan
• New system may be larger than original expected, may have to
reduce scope to meet deadline
• Deliverable: Updated Project Plan with detailed plan for next phase
to follow
5-28
29. Communicate Findings and
Recommendations
• communicate to entire business community;
• Leaders: Project Manager and Executive Sponsor jointly facilitate
• Trigger: Updated Project Plan
• Deliverable: report , verbal presentation, or inspection and essential
elements combined into the System Improvements Objectives
• Techniques: interpersonal and communications skills
5-29
31. Requirements Analysis Phase
• Requirements analysis, also
called requirements engineering, is the process of
determining user expectations for a new or modified
product.
• These features, called requirements, must be quantifiable,
relevant and detailed. In software engineering,
such requirements are often called functional specifications.
5-31
32. Requirements Analysis Phase Tasks
• Identify and Express System Requirements
• Prioritize System Requirements
• Update or Refine the Project Plan
• Communicate the Requirements Statements
5-32
33. Requirements Analysis Phase
Functional requirement – a description of
activities and services a system must provide.
• inputs, outputs, processes, stored data
Nonfunctional requirement – a description
of other features, characteristics, and
constraints that define a satisfactory system.
5-33
34. Key Terms of Requirements
Analysis Phase
Time boxing – a technique that delivers information systems
functionality and requirements through versioning.
1. The development team selects the smallest subset of the system that, if
fully implemented, will return immediate value to the systems owners
and users.
2. That subset is developed, ideally with a time frame of six to nine months
or less.
3. Subsequently, value-added versions of the system are developed in
similar time frames.
• A mandatory requirement is one that must be fulfilled by the minimal
system, version 1.0
• A desirable requirement is one that is not absolutely essential to version
1.0. It may be essential to the vision of a future version.
5-34
36. Logical Design Phase
• A logical design is a conceptual, abstract design. You do not deal
with the physical implementation details yet
• you deal only with defining the types of information that you need.
• The process of logical design involves arranging data into a series
of logical relationships called entities and attributes.
5-36
38. Logical Design Phase
• The logical design of a system pertains to an abstract representation
of the data flows, inputs and outputs of the system.
• To represent the logical design of a system we can use different
diagrams like Entity Relationship Diagram
5-38
40. Decision Analysis Phase
• Define systems analysis and relate the term to the scope definition,
problem analysis, requirements analysis, logical design.
• Decision analysis phases is a systems development methodology.
Describe a number of systems analysis approaches for solving
business system problems.
5-40
41. Decision Analysis Phase Tasks
1. Identify Candidate Solutions
2. Analyze Candidate Solutions
3. Compare Candidate Solutions
4. Update the Project Plan
5. Recommend a System Solution
5-41
42. Key Terms of Decision Analysis
Phase
• 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?
5-42
43. Typical System Proposal Outline
5-43
I. Introduction
A. Purpose of the report
B. Background of the project leading to this report
C. Scope of the report
D. Structure of the report
II. Tools and techniques used
A. Solution generated
B. Feasibility analysis (cost-benefit)
III. Information systems requirements
IV. Alternative solutions and feasibility analysis
V. Recommendations
VI. Appendices
Teaching Notes
Systems modeling corresponds precisely with this classical definition of systems analysis and design.
Systems design is sometimes called Systems Synthesis
Teaching Notes
This context comes directly from Chapter 3. The blue processes and the blue and black data flows define systems analysis.
Teaching Notes
Some books use the term “computer technology.” We prefer the more contemporary term, “information technology” as a superset of computer technology.
Teaching Notes
It is not the intent to teach the tool in this chapter. Object modeling will be taught in Chapters 10 and 18.
Teaching Notes
Prototypes are “incomplete” in that they lack error checking, data validation, security, and processing completeness
Conversion Notes
In the sixth edition this slide and the following slide were combined. They were split in the seventh edition for the sake of readability.
Teaching Notes
Fact-finding is also called information gathering.
Teaching Notes
BPR is not a competing systems analysis methods. BPR is an application of systems analysis methods.
BPR can be used in redesigning completely manual processes.
It is not uncommon for IS projects to include a study of existing business processes to identify problems, bureaucracy, and inefficiencies that can be addressed in requirements for new and improved information systems.
Changes in processes brought about through BPR generally trigger needed changes in information systems.
No additional notes.
Teaching Notes
This is called a task diagram for a phase. This is a look “inside” a phase. It decomposes the phase into its component tasks .
It is only a guideline. Each project will adapt these tasks to the project at hand. Tasks may be added, split, or deleted according to the methodology and route used.
The dashed line is a control flow (as contrasted to a solid data flow). In this case, it represents a decision that determines whether the next task is necessary.
No additional notes
Teaching Note
Analyze a problem using cause-and-effect analysis.
If you know “fishbone diagrams”, demonstrate cause-and-effect analysis using the diagrams.
Teaching Notes
Some of the tasks are completed in parallel.
Teaching Notes
It is not that functional requirements are mandatory and nonfunctional requirements are optional. The list of example nonfunctional requirements includes mandatory items.
The difference is that functional requirements describe functions that the system must perform. Nonfunctional requirements are not functions to be done but qualities that the system must have if it is to be successful.