System Analysis

1
Chapter 5

• System Analysis

Sarah El Sehemawy Karim Elsabee Sherine
Meshad Hakim Meshriky Ahmed Zaki Ismail Abou
Hamda
2
System Analysis

• System Analysis
• It is a problem solving technique that decomposes
  a system into component pieces for the purpose of
  studying how well those components work and
  interact to accomplish their purpose.
• It primarily focuses on the business view,
  independent of any technology.
• System Design
• It is a complementary problem solving technique
  to system analysis that reassembles a systems
  components pieces back into a complete system
  hopefully an improved system. This may involve
  adding, deleting and changing pieces relative to
  the original system.

3
System Analysis Approaches

• Model-Driven Analysis Approaches
• Structured Analysis
• Information Engineering
• Object-Oriented Analysis
• Accelerated Analysis Approaches
• Discovery Prototyping
• Reverse Engineering

4
Model-Driven Analysis Approach

• Structured Analysis
• Definition It is a model-Driven,
  Process-centered technique used to analyze an
  existing system, and propose a new one.
  Processes are the primary focus of that system
  model. Data and interface are also modeled.
• Output Process models called Data Flow Diagrams
  (DFDs)
• Information Engineering (IE)
• Definition Also model-Driven, but Data-centered.
  It intends to synchronize the systems data, and
  then processes. It is data centered because it
  focuses on the data requirements of the system.
• Output Data model called Entity Relationship
  Diagram (ERD).
• The two previous approaches differ only in the
  order of drawing the DFD, and the ERD.
• Object-Oriented Analysis (OOA)
• Definition It is a model-driven technique that
  integrates Data and Processes concerns into
  constructs called Objects. OOA modes are
  pictures that illustrate the systems objects.
• Output Unified Modeling Language (UML) depicts
  the OOA models.
• Difference No Database. Data and Processes are
  stored physically on the same layer.

5
Accelerated Analysis Approaches

• Definition Accelerated approaches emphasize the
  construction of prototypes to more rapidly
  identify the business and user requirements for a
  new system.
• Prototype Small-Scale, incomplete, but working
  sample of a desired system.
• Types
• Discovery Prototyping Identifies users business
  requirements by having to react to a quick
  implementation.
• Reverse Engineering Reads the program code for
  an existing database, program, and automatically
  generates system model, which is edited, and
  improved.

6
Project Phases

• Preliminary Investigation Phase
• Problem Analysis Phase
• Requirement Analysis Phase
• Decision Analysis Phase
• Design Phase
• Construction Phase
• Implementation Phase
• Operation and Support Phase

7
Preliminary Investigation Phase 1

• The Preliminary Investigation phase
• First phase of the classic systems development
  process.
• Answers the question Is the project worth
  looking at?.
• It is intended to be quick should not exceed 2
  or 3days for most projects.
• Most of the tasks in this phase are led by a
  senior systems analyst or a project manager and
  include system owners as participants.

8
Phase 1 - Preliminary Investigation Cont

• Preliminary Investigation Consists of the
  following 5 steps

• List problems ,opportunities and directives
• Negotiate preliminary scope
• Assess project worth
• Plan the project
• Present the project and plan

9
Phase 1 - Preliminary Investigation Cont

• 1. List problems, opportunities and directives
• Each problem, opportunity or directive is
  assessed with respect to urgency, visibility,
  benefits and priority.
• The key deliverable of this task is a preliminary
  problem statement.
• Primary techniques include fact-finding meeting
  with system owners.

10
Phase 1 - Preliminary Investigation Cont

• 2. Negotiate preliminary scope
• Scope defines the boundary of the project.
• A projects scope can be described in terms of
• What types of data describe the system being
  studied?
• What business processes are included in the
  system being studied?
• How must the system interface with users,
  locations and other systems?
• This task deliverable is the preliminary problem
  statement with scope.
• Primary techniques to accomplish this task are
  also fact-finding meetings.

11
Phase 1 - Preliminary Investigation Cont

• 3. Assess project worth
• This is where we answer the question
• Will the development of the new system return
  enough value to offset the costs incurred?
• There is no physical deliverable than the go or
  no-go decision.
• The remaining tasks are necessary only if the
  project is approved.

12
Phase 1 - Preliminary Investigation Cont

• 4. Plan the project
• An initial project plan should consist of at
  least the following
• A preliminary master plan that includes schedule
  and resource assignments for the entire project.
• A detailed plan and schedule for completing the
  next phase of the project.
• The deliverable of this task is the project plan.

13
Phase 1 - Preliminary Investigation Cont

• 5. Present the project and plan
• Unless the project is predetermined to be of the
  highest priority, it must be presented to a
  steering body for approval.
• A steering body is a committee of executive
  business and system managers that studies and
  prioritize project proposals to determine which
  projects should be approved or continued.
• Deliverable of this task is the project charter,
  which is usually a document.
• The project charter defines the project in terms
  of participants, problems, opportunities and
  directives methodology statement of work to be
  completed deliverables quality standards and
  budget.
• If approved, the project can now proceed to the
  problem analysis phase.

14
Phase 2 Problem Analysis Phase

• Answers the questions

•   Are the problems really worth solving?
•   Is a new system really worth building?

Goal
Study and understand the problem domain well
enough to thoroughly analyze its problems,
opportunities and constraints.
Final Deliverables
Produce System Improvement Objectives that
address problems , opportunities and
directives

• Dont try to fix it , unless you understand
  it!

15
The Problem Analysis Phase (6 Steps)
    Study the problem domain

• Learn about the current system in which the
  bus problems opportunities, directives and
  constraints exist.

Learn to truly analyze a problem before
stating any possible solutions Analyze each
perceived problem for cause and effect
Analyze Problems and Opportunities
Analyze Business Processes (Optional)
Appropriate only to business process redesign
examine business process to measure value added
or subtracted by each process as it relates to
the total organization
16
The Problem Analysis Phase (6 Steps)

• Establish System Improvement Objectives

Establish the criteria against which any
improvement to the system will be measured and
identifies any constraints that may limit
flexibility in achieving these improvements.
Update The Project Plan
Reevaluating scope and update the project plan
accordingly
Present findings and recommendations
Appropriate elements are combined into system
improvement objectives , presented in a report or
a verbal presentation
Conclusion Continue , adjust or cancel the
project
17
Phase 3Requirement Analysis Phase

• This phase defines the Business Requirements for
  a new system
• What do the users need and want from a new
  system? WHAT NOT HOW!
• The Requirement Analysis Phase includes the
  following tasks
• 1- Define Requirements 2- Analyze Functional
  Requirements
• 3- Trace and Complete Requirements 4- Prioritize
  Requirements
• 5- Update the Project Plan
• Define Requirements
• This task translate the system improvements
  objectives (established in the problem analysis
  phase) into an outline of Functional and
  Nonfunctional requirements that will be needed to
  meet the objectives

18
Phase 3Requirement Analysis Phase

• Analyze Functional Requirements
• Functional Requirements are analyzed such
  that they can be verified and communicated to
  both
• Users so they can prioritize the needs and
  justify the expenses
• Designers so they can transform them into
  appropriate technical solutions.
• There are 2 approaches to functional requirements
  documentation and validation SYSTEM MODELING
  PROTOTYPING.
• Requirements are analyzed for accuracy, urgency,
  consistency, flexibility and feasibility.
• Trace and Complete Requirements
• Tracing each system model and/or prototype
  back to the functional requirement that it
  fulfills and ensuring that all functional
  requirements are included in the system models or
  prototype.

19
Phase 3Requirement Analysis Phase

• Prioritize Requirements
• System Owners and Users should prioritize
  business because it may be useful to recognize
  which requirements are more important than others
  if a project gets behind schedule or over budget.
  
• Prioritization of business requirements enable
  TIMEBOXING, which is a technique that delivers
  system functionality and requirements through
  versioning.
• All MANDATORY REQURMENTS are included in Version
  1.0 (the System is useless without it)
• All DESIRABLE REQUIRMENTS are included following
  version according to there ranking.
• Update the Project Plan
• Scope Schedule Budget
• Output of this phase is a business requirements
  statement.

20
Project Phase 4Decision Analysis Phase
DECISION ANALYSIS PHASE
Business requirements
System Proposal
21
Project Phase 4Decision Analysis Phase

• The decision analysis phase includes 5 tasks as
  follows
• Identify Candidate Solutions
• (Sources System Owners, Users, analysists ,
  Desginers, technical consultants)
• Analyze Candidate Solution (Feasibility)
• Operational
• Economic
• Schedule
• Technical (done by system designers and builders)

22
Project Phase 4Decision Analysis Phase

• Compare Candidate Solutions
• (Feasibility analysis Matrix)

Feasibility criteria Weight Candidate1 Candidate2 Candidate3
1.Operational
2.Technical
3.Economic
4.Schedule
Ranking 100
23
Project Phase 4Decision Analysis Phase

• Update the project plan
• Recommend a solution

24
Cross Life Cycle Activities

• Cross life cycle activities are activities that
  overlap many or all phases of the methodology.
• Fact Finding
• Formal process of using research, interviews,
  meetings, questionnaires, sampling.
• Also Called data collection.
• Documentation and Presentations
• Activity of recording facts and specifications
  for a system for current and future reference.
• Communicating Findings, recommendations, and
  documentation for review by interested managers

25
Cross Life Cycle Activities

• Feasibility Analysis
• Continuous Analysis of the development of the IS.
• Project Management
• Defining, planning, directing, monitoring, and
  controlling a project to develop an acceptable
  system within the specified time, and budget.