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.

1. 5-1

2. Presented By:Presented By: Shahban IqbalShahban Iqbal
5-2

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

4. Context of Systems Analysis
5-4

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

6. A Simple Object Model
5-6

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

8. Requirements Discovery
Requirements discovery – the process, used by systems analysts of
identifying or extracting system problems and solution requirements
from the user community.
5-8

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

12. 5-12

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

14. Tasks for the
Scope
Definition
Phase
5-14

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

19. 5-19

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

21. Tasks of the
Problem
Analysis
Phase
5-21

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

26. 5-26

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

30. Requirements
Analysis
Phase Tasks
5-30

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

35. Tasks for
Logical Design
Phase
5-35

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

37. Logical Design Phase Tasks
1. Structure Functional Requirements
2. Prototype Functional Requirements
3. Validate Functional Requirements
4. Define Acceptance Test Cases
5-37

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

39. Tasks for
Decision
Analysis
Phase
5-39

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

44. Thank You
5-44