Systems Analysis and Design

- The systems development life cycle (SDLC) is the process of

determining how an information system (IS) can support business needs,
designing the system, building it, and delivering it to users.
- The key person in the SDLC is the systems analyst, who analyzes the
business situation, identifies the opportunities for improvements, and
designs an IS to implement the improvements.
Systems Analyst Skills
 Technical – Must understand the technical environment,
technical foundation, and technical solution.
 Business – Must understand how IT can be applied to business
situations.
 Analytical – Must be problem solvers.
 Interpersonal – Need to communicate effectively.
 Management – Need to manage people and to manage
pressure and risks.
 Ethical - Must deal fairly, honestly, and ethically with other
project members, managers, and systems users.
Systems Analyst Roles

 Business analyst - Focuses on the IS issues surrounding the

system.
 Systems analyst - Focuses on the business issues surrounding
the system.
 Infrastructure analyst - Focuses on technical issues
 Change management analyst - Focuses on the people and
management issues surrounding the system installation.
 Project manager - Ensures that the project is completed on
time and within budget, and that the system delivers the
expected vale to the organization.
THE SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC):
Planning
 This phase is the fundamental process of understanding why
an information system should be built, and determining how
the project team will go about building it.
Has two steps:
1. During project initiation, the system’s business value
to the organization is identified (How will it lower costs or
increase revenues?).
2. During project management, the project manager
creates a work plan, staffs the project, and puts techniques in
place to help the project team control and direct the project
through the entire SDLC.
Analysis:
 The analysis phase answers the questions of who will use the
system, what the system will do, and where and when it will
be used.
 During this phase the project team investigates any current
system(s), identifies improvement opportunities, and develops
a concept for the new system.

Has three steps:

1. Analysis strategy: This is developed to guide the
projects team’s efforts. This includes a study of the current
system and its problems, and envisioning ways to design a new
system.
2. Requirements gathering: The analysis of this
information leads to the development of a concept for a new
system. This concept is used to build a set of analysis models.
3. System proposal: The proposal is presented to the
project sponsor and other key individuals who decide whether the
project should continue to move forward.
Design:

 The design phase decides how the system will operate, in

terms of the hardware, software, and network infrastructure;
 the user interface, forms, and reports that will be used; and the
specific programs, databases, and files that will be needed.

Has four steps:

1. Design Strategy: This clarifies whether the system will be
developed by the company or outside the company.
2. Architecture Design: This describes the hardware,
software, and network infrastructure that will be used.
3. Database and File Specifications: These documents define
what and where the data will be stored.
4. Program Design: Defines what programs need to be written
and what they will do.
Implementation:
 During the implementation phase, the system is either
developed or purchased (in the case of packaged software) and
installed.
 This phase is usually the longest and most expensive part of
the process.
Has three steps:
1. System Construction: The system is built and tested to
make sure it performs as designed.
2. Installation: The old system is turned off and the new
one is turned on.
3. Support Plan: Includes a post-implementation review as
well as a systematic way for identifying changes needed for the
system.

PROJECT IDENTIFICATION AND INITIATION

 A project is identified when someone in the organization
identifies a business need to build a system.
 A need may surface when an organization identifies unique
and competitive ways of using IT.
 To leverage the capabilities of emerging technologies such as
cloud computing, RFID, Web 2.0
Business Process Management (BPM):
 Nowadays many new IS projects grow out of BPM.
 BPM is a methodology used by organizations to continuously
improve end-to-end business processes.
BPM Process:
 Defining and mapping the steps in a business process.
 Creating ways to improve on the steps in the process that add
value
 Finding ways to eliminate or consolidate steps in the process
that do not add value
 Creating and adjusting electronic workflows to match the
improved process maps.
 Business process automation (BPA) – technology
components are used to complement or substitute manual
process.
 Business process improvement (BPI) – creating new, re-
designed processes to improve the workflows, and/or utilizing
new technologies enabling new process structures.
 Business process reengineering (BPR) – changing the
fundamental way in which the organization operate.
Project sponsor:

 The project sponsor is a person (or group) who has an interest in

the system’s success
 The project sponsor will work throughout the SDLC to make
sure that the project is moving in the right direction from the
perspective of the business.
 The project sponsor serves as the primary point of contact for
the project team.
 The size or scope of the project determines by the kind of
sponsor that is involved.
 The project sponsor has the insights needed to determine the
business value that will be gained from the system.
 Tangible value can be quantified and measured easily
(reduction in operating costs).
 An intangible value results from an intuitive belief that the
system provides important, but hard-to-measure benefits to the
organization.
System Request:
 The document that describes the business reasons for building
a system and the value that system is expected to provide.
 The project sponsor usually completes this form as part of a
formal system selection process within the organization.
  The business requirements of the project refer to the business
capabilities that the system will need to have.
 The business value describes the benefits that the organization
should expect from the system.
 Special issues are included on the document as a catchall
category for other information that should be considered in
assessing the project.
FEASIBILITY ANALYSIS:
 Feasibility analysis guides the organization in determining
whether to proceed with a project.
 Feasibility analysis also identifies the important risks
associated with the project that must be managed if the project
is approved.
 As with the system request, each organization has its own
process and format for the feasibility analysis, but most
include techniques to assess three areas:
– Technical feasibility
– Economic feasibility
– Organizational feasibility
 The results of evaluating these three feasibility factors are
combined into a feasibility study deliverable that is submitted
to the approval committee at the end of project initiation.
Technical Feasibility:
 Technical feasibility is the extent to which the system can be
successfully designed, developed, and installed by the IT
group.
 It is, in essence, a technical risk analysis that strives to answer
the question: “Can we build it?”
Risks can endanger the successful completion of a project.
The following aspects should be considered:
– Users’ and analysts’ should be familiar with the
application.
– Familiarity with the technology
– Project size
– Compatibility of the new system with the
technology that already exists
Economic Feasibility:
  Economic feasibility analysis is also called a cost-benefit
analysis that identifies the costs and benefits associated with
the system.
 This attempts to answer the question: “Should we build the
system?”
Steps to conduct an economic feasibility analysis:
1. Identify Costs and Benefits
2. Assign Values to Costs and Benefits
3. Determine Cash Flow
4. Assess Project’s Economic Value
- ROI return on investment
- BEP Break even point
net present value
- NPV
Identify Costs and Benefits:
 The costs and benefits and be broken down in to four
categories:
– Development costs
– Operational costs
– Tangible benefits
– Intangibles

Organizational Feasibility:

 Organizational feasibility of the system is how well the system

ultimately will be accepted by its users and incorporated into
the ongoing operations of the organization.
 There are many organizational factors that can have an impact
on the project, and seasoned developers know that
organizational feasibility can be the most difficult feasibility
dimension to assess.
 In essence, an organizational feasibility analysis is to answer
the question “If we build it, will they come?”
 One way to assess the organizational feasibility is to
understand how well the goals of the project align with the
business objectives and organizational strategies.
 A second way to assess the organizational feasibility is to
conduct stakeholder analysis.
 A stakeholder is a person, group, or organization that can
affect a new system
 - Project champion
- System users
- Organizational management

Systems Analyst Skills

Technical

Business

Analytical

Interpersonal

Management

Ethical

Systems Analyst Roles

Systems Analyst Roles

Business analyst

Systems analyst Infrastructure analyst

Change management analyst

Project manager
THE SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)
 Chapter 2
Project Selection
and Management

 Project selection
 Creating the project plan
 Managing and
controlling the project

INTRODUCTION:
 CIOs (chief information officers) are challenged to select
projects that will provide highest return on the IT investments.
  Project portfolio management has become a critical success
factor for IT departments.
 A selected system development project must undergo a
thorough process of project management.
 A critical success factor for project management is to start
with a realistic assessment of the work and then manage the
project according to the plan.
PROJECT SELECTION:
 Systems projects today are evaluated in the context of an
entire portfolio of projects.
 Determination of a project’s contribution to an entire portfolio
of a project reinforces the need for a feasibility study.
 Portfolio management takes into consideration the different of
projects that exist in an organization.

An approval committee must be selective about where to
allocate resources as most organizations have limited funds.
 If there are several potentially high-payoff projects, and they
all have the same risk, then maybe only one of the projects
will be selected.
CREATING THE PROJECT PLAN:
 Project management phases consist of

initiation

planning

execution

control

enclosure
 Project Methodology Options:
-A methodology is a formalized approach to implementing the SDLC.

Waterfall Development

Parallel Development

V-model (variation of the

Waterfall
Development)

Rapid Application Iterative Development •

Development (RAD) System prototyping •

Agile Development

Waterfall Development:
Parallel Development:

V-model:
Rapid Application Development:
Iterative Development

System Prototyping:

Throwaway prototyping:
 Agile Development:
A group of programming-centric methodologies that focus on
streamlining the SDLC.

 Includes face-to-face communication

 Extreme programming – emphasizes customer satisfaction
and teamwork.
Extreme Programming:

‫الجدول اللى جاى دة مهم جدا جدا نركز عليه‬

Selecting the Appropriate Development Methodology:
  Important factors to consider in selecting the development
methodology
- Clarity of User Requirements
- Familiarity with Technology
- System Complexity
- System Reliability
- Short Time Schedules
- Schedule Visibility
STAFFING THE PROJECT

 Staffing Plan
- Staffing levels will change over a project’s lifetime
- Adding staff may add more overhead than additional labor
- Using teams of 8-10 reporting in a hierarchical structure can
reduce complexity
Reporting structure

 The staffing plan describes the kinds of people working on the

project
 The project charter describes the project’s objectives and
rules
 A functional lead manages a group of analysts
 A technical lead oversees progress of programmers and
technical staff members
Motivation
 Use monetary rewards cautiously
Use intrinsic rewards
– Recognition
– Achievement
– The work itself
– Responsibility
– Advancement
– Chance to learn new skills
Handling Conflict
 Clearly define plans for the project.
 Recognize project importance to organization.
 Project charter listing norms and ground rules.
 Develop schedule commitments ahead of time.
 Forecast other priorities and their possible impact on the
project.

Coordinating Project Activities

 CASE (computer-aided software engineering) tools – A
category of software that automate all or part of the
development process.
- Upper CASE
- Lower CASE
- Integrated CASE
 Standards
– Formal rules for naming files
– Forms indicating goals reached
– Programming guidelines

Documentation
– Project binder
– Table of contents
– Continual updating
MANAGING AND CONTROLLING THE PROJECT
 The science (or art) of project management is in making
trade-offs among three important concepts:
- the size of the system,
- the time to complete the project, and
 - The cost of the project.

Managing Scope
 Scope creep – the most common reason for schedule and cost
overruns occurs after the project is underway.
 The project manager should allow only absolutely necessary
requirements to be added after the project begins.
Timeboxing
 Set a fixed deadline for a project
 Reduce functionality, if necessary
 Don’t get hung up on the final “finishing touches”
Timeboxing steps

Managing Risk
- Risk assessment
- Actions to reduce risk
-Revised assessment
 Chapter 3
Requirements
Determination
 The analysis phase.

 Requirement determination.

 Requirement elicitation techniques.

 Requirement analysis strategies

THE ANALYSIS PHASE:
 Analysis: refers to breaking a whole into its parts with the intent of
understanding the parts’ nature, functions, and interrelationships.
 The planning phase deliverables are the key inputs into the analysis
phase.
 The basic process of analysis involves three steps:
1. Understand the existing situation (the as-is system)
2. Identify improvements
3. Define the requirement for the new system (the to-be system).
System proposal: The final deliverables of the analysis phase
- The system proposal is presented to the approval committee in the
form of a system walk-through to explain the system in moderate
detail.
- The deliverables from the analysis phase are the first step in the
design of the new system

REQUIREMENTS DETERMINATION:

 Requirements determination is performed to transform the

system request’s high-level statement of business
requirements into a more detailed, precise list of what the new
system must do to provide the needed value to the business.
 What is a Requirement?
A requirement is a statement of what the system must do or what
characteristics it needs to have.
 Requirements types:

1) (Business requirements)
2)(user requirements)
3) (Functional requirements)
4) (Non-functional requirements)
5) (System requirements)
Functional requirements:

Nonfunctional requirements:

Functional Requirements
What the Software Should do
‫تنقسم لنوعين‬:
Process oriented
‫مثال عليها‬
- The system should allow students to view a course schedule while registering for
classes
‫النوع الثاني‬
Information oriented
‫مثال عليها‬
 the system must retain customer order history for three years
Nonfunctional Requirements
Characteristics the system should be built
‫تشمل اربع نقط‬
1) Operational
The system should be able to work on any web browser
2) Performance
The system should be available for use 24 hours per day 365 days per year
3) Security
Only direct managers can see personal records of staff
4) Culture and political

Interviews:
 The most commonly used requirements elicitation technique
 Basic steps:
 – Selecting Interviewees
– Designing Interview Questions
– Preparing for the Interview
– Conducting the Interview
– Post-Interview Follow-up
Joint Application Development (JAD):
- JAD is an information gathering technique that allows the
project team, users, and management to work together to identify
requirements for the system.
- It can reduce scope creep by 50%,
- JAD is a structure process in which 10 to 20 users meet under
the direction of a facilitator skilled in JAD techniques.
Selecting participants:

1)Selecting JAD participants in the same basic way as selecting

interview participants.
2)Facilitator
a. Expert in JAD and e-JAD techniques
b. In many cases, the JAD facilitator is a consultant external
to the organization.
Questionnaires:
 A questionnaire: is a set of written questions for obtaining
information from individuals.
 Selecting participants - using a sample of people who are
representative of the entire group.
 Designing the questionnaire – following good practice guidelines.
 Administering the questionnaire – improving the response rates.
 Questionnaire follow-up – developing a report.
Document Analysis:

 Document analysis : is used to understand the as-is system.

 Forms, reports, policy manuals, organization charts describe
the formal system that the organization uses.
  The “real” or informal system differs from the formal one,
and reveals what needs to be changed.
 The indication that system needs to be changed is when users
create new forms or make changes to the existing
forms/reports.
Observation:

– Observation – the act of watching processes being performed.

– It is a powerful tool to gain insight into the as-is system, and to
check the validity of information gathered from other sources.
– Nonetheless, people tend to be extremely careful in their behaviors
when they are being watched.

Selecting the Appropriate Techniques:

1)Type of information
2)Depth of information
3)Breadth of information
4)Integration of information
5)User involvement
6)Cost
7)Combining techniques
Comparison of Requirements Elicitation Techniques
REQUIREMENTS ANALYSIS STRATEGIES:
 Problem Analysis
 Root Cause Analysis
 Duration Analysis
 Activity-Based Costing
 Informal Benchmarking
 Outcome Analysis
 Technology Analysis
 Activity Elimination
 Comparing Analysis Strategies
Chapter 6
Data
Modeling
1. The Entity Relationship
Diagram (ERD)
- Elements of ERD
2. Creating an Entity
Relationship Diagram.
3. Validating an ERD
Intro
-Data model describes the data that flow through the business processes
in an
organization. During the analysis phase, the data model presents the
logical
organization of data without indicating how the data are stored, created,
or manipulated
so that analysts can focus on the business without being distracted by
technical details.
Later, during the design phase, the data model is changed to reflect
exactly how the data
will be stored in databases and files. This chapter describes entity
relationship diagramming, one of the most common data modeling
techniques used in industry.

A data model is a formal way of representing the data that are used and
created by a business system.
Logical data model shows the logical organization of data without
indicating how it is stored, created, or manipulated.
Physical data model during design analysts draw to reflect how the data
will physically be stored in databases or files.
Normalization: a technique that helps analysts validate the data models.
How data models balance, or interrelate, with the process models.
Entity-relationship diagram (ERD): is a picture showing the
information that is created, stored, and used by a business system.
Entities: lists similar kinds of information
Relationships: Lines drawn between entities represent among the
data.
Business rules Special symbols communicate high-level.
Entity-relationship diagram (ERD) Example:
Elements of an Entity Relationship Diagram:

Entity Attributes Relationships

The entity: is the basic building block for a data model. It is a person,
place, event, or thing about which data is collected

An attribute: is some type of information that is captured about an entity.

Relationships: are associations between entities.

Every relationship has a parent entity and a child entity.
Cardinality: A relationship has the ratio of parent instances to child
instances.
The 1:1 relationship means that one instance of the parent entity is
associated with one instance of the child entity.
The 1: N relationship means that a single instance of a parent entity is
associated with many instances of a child entity.
The M: N relationship means that many instances of a parent entity can
relate to many instances of a child entity.

Modality: A relationship has two value null or not null, which refers to
whether or not an instance of a child entity can exist without a related
instance in the parent entity.
Null means that an instance of a child entity can exist without a related
instance in the parent entity.
Not Null means that an instance of a child entity can’t exist without a
related instance in the parent entity.
Data dictionary: contains the information about the entities, attributes,
and relationships on the ERD, or metadata.
Metadata: is data about data.
Metadata is stored in the data dictionary so it can be shared by developers
and users throughout the SDLC.

CREATING AN ENTITY RELATIONSHIP DIAGRAM (ERD):

 The basic steps in building an ERD:
1. Identify the entities
2. Add the appropriate attributes to each entity; and
3. Draw relationships among entities
Three special types of entities:
Independent Entity
– Can exist without the help of another entity.
– The identifiers is created from the entity’s own
attributes.
– Attributes from other entities are not needed to
uniquely identify instances of these entities.

Dependent Entity
– There are situations when a child entity does
require attributes from the parent entity to
uniquely identify an instance. In these cases, the
 child entity is called a dependent entity, and its
identifier consists of at least one attributes from
the parent entity.
Intersection Entity
– It exists in order to capture some information
about the relationship between two other entities.
Typically, intersection entities are added to a data
model to store information about two entities
sharing an M: N relationship.

There are three steps involved in adding an intersection entity:

Step 1. Remove the M: N relationship line and insert a new entity
(intersection entity) in between the two existing ones.
Step 2. Add two 1:N relationships to the model.
Step 3. Name the intersection entity

VALIDATING AN ERD:

 General design guidelines.

 Normalization.
 Check the ERD against the process models to make sure that both
model balance each other