Planning Phase of System Development Life Cycle
CHAPTER 1 PLANNING PHASE
TOPIC 1: THE SYSTEMS ANALYST AND INFORMATION
SYSTEMS DEVELOPMENT
The Systems Analyst
▪ the systems analyst is a key person analyzing the business,
identifying opportunities for improvement, and designing
information systems to implement these ideas.
▪ the systems analyst assists and guides the project team, so
the team develops the right system in an effective way.
▪ Systems analysts must understand how to apply
technology in order to solve problems.
▪ Systems analysts may also serve as change agents who
identify the organization improvements needed, design
systems to implement those changes, and train/motivate
others to use the systems.
*The systems analyst plays a key role in information systems
development projects.
What are the skills that a Systems Analyst must possess?
1. Introduces change to the organization and people
2. Leads a successful organization change effort
3. Understands what to change and knows how to change it
4. Must have technical skills, as well as, business skills
5. Communicate effectively and give presentations
6. Must be able to deal fairly, honestly, and ethically with
other project members, managers, and systems users.
Systems Analyst Roles
As organizations and technology have become more
complex, most large organizations now build project teams
that incorporate several analysts with different, but
complementary, roles. In smaller organizations, one person
may play several of these roles. Here we briefly describe
these roles and how they contribute to a systems
development project.
Project Team Specialization
▪ Systems Analyst
▪ Business Analyst
▪ Infrastructure Analyst
▪ Change management Analyst
▪ Project manager
Systems Analyst
➢ focuses on the IS issues surrounding the system
➢ develops ideas and suggestions for ways IT can improve
business process, helps design new business processes,
helps design new business process, designs the new
information system, and ensures that all IS standards are
maintained.
Business Analyst
➢ focuses on the business issues surrounding the system ➢
identifies the business value that the system will create ➢
develops ideas for improving the business processes
➢ helps design new business processes and policies
Infrastructure Analyst
➢ focuses on technical issues surrounding the ways the
system will interact with the organization’s technical
infrastructure
➢ Ensures that the new information system conforms to
organization standards
➢ Identifies infrastructure changes
Change management Analyst
➢ focuses on the people and management issues
surrounding the system installation
➢ ensures that adequate documentation and support are
available to users
➢ Provides user training
➢ Develops strategies to overcome resistance to change
Project Manager
➢ highly experienced systems analyst
➢ ensures that the project is completed on time and within
budget
➢ makes sure the system delivers the expected vale to the
organization
The roles and the names used to describe them may vary
from organization to organization. In addition, there is no
single typical career path through these professional roles.
Some people may enter the field as a more technically-
oriented programmer/analyst. Others may enter as a
business oriented functional specialist with an interest in
applying IT to solve business problems.
Career paths system developers
The Systems Development Life Cycle (SDLC)
All system development projects follow essentially the same
fundamental process called the system development life
cycle (SDLC).
The SDLC is composed of four fundamental phases:
➢ Planning - Why build the system?
➢ Analysis - Who, what, when, where will the system be? ➢
Design - How will the system work?
➢ Implementation - System delivery
Each of the phases include a set of steps, which rely on
techniques that produce specific document files that provide
understanding about the project.
Processes and Deliverables
Process Product
Planning Project plan
Analysis System proposal
Design System Specification
implementation New System and
Maintenance Plan
Phase 1: Planning
▪ This phase is the fundamental process of understanding
why an information system should be built.
▪ The Planning phase will also determine how the project
team will go about building the information system.
▪ The Planning phase is composed of two planning 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.
Phase 2: 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.
▪ This phase has three analysis steps:
1. Analysis strategy: This is developed to guide the projects
team’s efforts. This includes an analysis of the current
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.
▪ the system proposal is the initial deliverable that describes
what business requirements the new system should meet.
▪ the deliverable from this phase is both an analysis and a
high-level initial design for the new system.
Phase 3: Design
▪ In this phase, it is decided 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.
▪ Five Design 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.
Phase 4: Implementation
▪ During this phase, the system is either developed or
purchased (in the case of packaged software).
▪ This phase is usually the longest and most expensive part
of the process.
▪ The phase has three steps:
1. System Construction: The system is built and tested to
make sure it performs as designed.
2. Installation: Prepare to support the installed system.
3. Support Plan: Includes a post-implementation review.
Project Identification and Initiation
Projects are identified when someone recognizes a business
need that can be satisfied through the use of information
technology. Project initiation is the point at which an
organization creates and assesses the original goals and
expectations for a new system. The first step in the process
is to identify the business value for the system by developing
a system request that provides basic information about the
proposed system. Next, the analysts perform a feasibility
analysis to determine the technical, economic, and
organizational feasibility of the system.
System Request
The business value for an information system is identified
and then described in a system request. This form contains
the project’s sponsor, business need, business
requirements, and business value of the information system,
along with any other issues or constraints that are important
to the project. The document is submitted to an approval
committee who determines whether the project would be a
wise investment of the organization’s time and resources.
Feasibility Analysis
Once the need for the system and its business requirements
have been defined, the approval committee may authorize
the systems analyst to prepare a more detailed business
case to better understand the proposed information system
project. Feasibility analysis guides the organization in
determining whether to proceed with the 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, and 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.
TOPIC 2: PROJECT SELECTION AND MANAGEMENT
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.
Finally, the project manager monitors the project and refines
estimates as work proceeds.
Project Selection
Many IT organizations tackle several important initiatives
simultaneously. For example, new software applications
may be under development; new business models may be
under consideration; organizational structures may be
revised; new technical infrastructures may be evaluated.
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 (steering 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.
Ways to Classify Projects
Size What is the size? How many people are
needed to work on the project?
Cost How much will the project cost the
organization?
Purpose What is the purpose of the project? Is it
meant to improve the technical
infrastructure? support a current business
strategy? improve operations? demonstrate
an innovation?
Length How long will the project take before
completion? How much time will go by before
value is delivered to the business?
Risk How likely is it that the project will succeed or
fail?
 Scope How much of the organization is affected by
the system? a department? a division? the
entire corporation?
Economic How much money does the organization
Value expect to receive in return for the amount the
project costs?

Creating the Project Plan

Parallel Development.
Once the project is launched by being selected by the
This methodology evolved to address the lengthy time
approval committee, it is time to carefully plan the project.
frame of waterfall development. Instead of doing the design
The project manager will follow a set of project management
and implementation in sequence, a general design for the
guidelines, sometimes referred to as the project
whole system is performed. Then the project is divided into
management life cycle, as he or she organizes, guides, and
a series of subprojects that can be designed and
directs the project from inception to completion. Generally
implemented in parallel. Once all subprojects are complete,
speaking, the project management phases consist of
there is a final integration of the separate pieces, and the
initiation, planning, execution, control, and closure.
system is delivered. Parallel development reduces the time
Project Methodology Options required to deliver a system, so changes in the business
environment are less likely to produce the need for rework.
As we discussed in Chapter 1, the Systems Development Life
Cycle (SDLC) provides the foundation for the processes used
to develop an information system. A methodology is a
formalized approach to implementing the SDLC (i.e., it is a
list of steps and deliverables). There are many different
systems development methodologies, and they vary in
terms of the progression that is followed through the phases
of the SDLC. Some methodologies are formal standards used
by government agencies, while others have been developed
by consulting firms to sell to clients. V-model.

• Waterfall Development Another variation of waterfall development that pays more

explicit attention to testing. The development process
• Parallel Development proceeds down the left-hand slope of the V, defining
• V-model (variation of the Waterfall Development) requirements and designing system components. At the
base of the V, the code is written. On the upward-sloping
• Rapid Application Development (RAD) - Iterative right side of the model, testing of components, integration
Development - System prototyping testing, and, finally, acceptance testing is performed. A key
concept of this model is that as requirements are specified
• Agile Development
and components designed, testing for those elements is also
Waterfall Development. defined. In this manner, each level of testing is clearly linked
to a part of the analysis or design phase, helping to ensure
Analysts and users proceed sequentially from one phase to
high quality and relevant testing and maximize test
the next. The key deliverables for each phase are typically
effectiveness.
voluminous (often, hundreds of pages) and are presented to
the approval committee and project sponsor for approval as
the project moves from phase to phase. Once the work
produced in one phase is approved, the phase ends and the
next phase begins. As the project progresses from phase to
phase, it moves forward in the same manner as a waterfall.
While it is possible to go backward through the phases (e.g.,
from design back to analysis), it is quite difficult. (Imagine
yourself as a salmon trying to swim upstream in a waterfall)
Rapid Application Development (RAD).

It is a collection of methodologies that emerged in response

to the weaknesses of waterfall development and its
variations. RAD incorporates special techniques and
computer tools to speed up the analysis, design, and
implementation phases in order to get some portion of the
system developed quickly and into the hands of the users for
evaluation and feedback. CASE (computer-aided software
engineering) tools, JAD (joint application development) Throwaway prototyping.
sessions, fourth generation/visual programming languages
It includes the development of prototypes but uses the
(e.g., Visual Basic.NET), and code generators may all play a
prototypes primarily to explore design alternatives rather
role in RAD. While RAD can improve the speed and quality of
than as the actual new system (as in system prototyping).
systems development, it may also introduce a problem in
Throwaway prototyping has a thorough analysis phase that
managing user expectations. As systems are developed
is used to gather requirements and to develop ideas for the
more quickly and users gain a better understanding of
system concept. Many of the features suggested by the
information technology, user expectations may dramatically
users may not be well understood, however, and there may
increase and system requirements may expand during the
be challenging technical issues to be solved. Each of these
project (sometimes known as scope creep or feature creep).
issues is examined by analyzing, designing, and building a
Iterative development design prototype. A design prototype is not intended to be a
working system. It contains only enough detail to enable
Breaks the overall project into a series of versions that are
users to understand the issues under consideration.
developed sequentially. The most important and
fundamental requirements are bundled into the first version
of the system. This version is developed quickly by a mini-
waterfall process, and once implemented, the users can
provide valuable feedback to be incorporated into the next
version of the system.

System prototyping

Performs the analysis, design, and implementation phases

concurrently in order to quickly develop a simplified version
of the proposed system and give it to the users for
evaluation and feedback. The system prototype is a “quick
and dirty” version of the system and provides minimal
features. Following reaction and comments from the users,
the developers reanalyze, redesign, and implement a second
prototype that corrects deficiencies and adds more features.
This cycle continues until the analysts, users, and sponsor
agree that the prototype provides enough functionality to be
installed and used in the organization. System prototyping
very quickly provides a system for users to evaluate and
reassures users that progress is being made.
Agile Development.
It is a group of programming-centric methodologies that
focus on streamlining the SDLC. Much of the modeling and
documentation overhead is eliminated; instead, face-to-face
communication is preferred. A project emphasizes simple,
iterative application development in which every iteration is
a complete software project, including planning,
requirements analysis, design, coding, testing, and
documentation. Extreme programming emphasizes
customer satisfaction and teamwork.
Selecting the Appropriate Development Methodology
As the previous section shows, there are many
methodologies. The first challenge faced by project
managers is to select which methodology to use. Choosing a
methodology is not simple, because no one methodology is
always best. Many organizations have standards and policies
to guide the choice of methodology. You will find that
organizations range from having one “approved”
methodology to having several methodology options to
having no formal policies at all.
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
Estimating the Project Time Frame
As the previous section illustrated, some development
methodologies have evolved in an attempt to accelerate the
project through the SDLC as rapidly as possible while still
producing a quality system. Regardless of whether time is a
critical issue on a project or not, the project manager will
have to develop a preliminary estimate of the amount of
time the project will take. Estimation16 is the process of
assigning projected values for time and effort.
There are two basic ways to estimate the time required to
build a system. The simplest method uses the amount of
time spent in the planning phase to predict the time required
for the entire project. The idea is that a simple project will
require little planning, and a complex project will require
more planning; so using the amount of time spent in the
planning phase is a reasonable way to estimate overall
project time requirements. A more precise approach to
estimation is called the function point approach. This
approach is a more complex—and, it is hoped, more
reliable—way of estimating time and effort for a project.
Developing the Work Plan
▪ Identify Tasks. Remember that the overall objectives for
the system were recorded on the system request, and the
project manager’s job is to identify all the tasks that will be
needed to accomplish those objectives. This is a daunting
task, certainly. The methodology that was selected by the
project manager should be a valuable resource, however.
The methodology that seems most appropriate for the
project provides a list of steps and deliverables.
▪ the Project Work Plan. The project work plan is the
mechanism used to manage the tasks that are listed in the
work breakdown structure. It is the project manager’s
primary tool for managing the project. Using it, the project
manager can tell whether the project is ahead of or behind
schedule, how well the project was estimated, and what
changes need to be made to meet the project deadline.
Staffing the Project
Staffing the project includes determining how many people
should be assigned to the project, matching people’s skills
with the needs of the project, motivating them to meet the
project’s objectives, and minimizing project team conflict
that will occur over time.
▪ 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.
Assigning people to tasks isn’t enough; project managers CASE comes in a wide assortment of flavors in terms of
need to motivate the people to make the project a success. complexity and functionality, and there are many good
Motivation has been found to be the number-one influence programs available in the marketplace, such as the Visible
on people’s performance, 17 but determining how to Analyst Workbench, Oracle Designer, Rational Rose, and the
motivate the team can be quite difficult. Logic Works suite. The benefits of using CASE are numerous.
With CASE tools, tasks are much faster to complete and
▪ Use monetary rewards cautiously
alter; development information is centralized; and
▪ Use intrinsic rewards information is illustrated through diagrams, which typically
are easier to understand. Potentially, CASE can reduce
o Recognition maintenance costs, improve software quality, and enforce
o Achievement discipline; and some project teams even use CASE to assess
the magnitude of changes to the project.
o The work itself
Standards.
o Responsibility
Standards are created to ensure that team members are
o Advancement performing tasks in the same way and following the same
o Chance to learn new skills procedures.

• Formal rules for naming files

• Forms indicating goals reached

• Programming guidelines

Documentation The date and project name should

standards appear as a header on all
documentation. All margins should be
set to 1 inch. All deliverables should be
added to the project binder and
recorded in its table of contents.
Coding All modules of code should include a
standards header that lists the programmer, last
Handling Conflict. date of update, and a short description
of the purpose of the code. Indentation
The third component of staffing is organizing the project to
should be used to indicate loops, if-
minimize conflict among group members.
then-else statements, and case
Conflict Avoidance Strategies: statements. On average, every program
should include one line of comments
for every five lines of code
Procedural Record actual task progress in the work
standards plan every Monday morning by 10 A.M.
Report to project update meeting on
Fridays at 3:30 P.M. All changes to a
requirements document must be
approved by the project manager.
Coordinating Project Activities Specification Name of program to be created
requirement Description of the program’s purpose
CASE (Computer-Aided Software Engineering) tools – A standards Special calculations that need to be
category of software that automate all or part of the computed Business rules that must be
development process. incorporated into the program Due
date
- Upper CASE
User interface Labels will appear in boldface text, left-
- Lower CASE design justified, and followed by a colon. The
standards tab order of the screen will move from
- Integrated CASE
 top left to bottom right. Accelerator
keys will be provided for all updatable
fields.
Documentation.
Another technique that project teams put in place during the
planning phase is good documentation, which includes
detailed information about the tasks of the SDLC. A simple
way to set up your documentation is to get some binders and
use dividers to separate content according to the major
phases of the project. An additional divider should contain
internal communication, such as the minutes from status
meetings, written standards, letters to and from the
business users, and a dictionary of relevant business terms.
• 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.
Refining the Estimates.
The estimates that are produced during the planning phase
will need to be refined as the project progresses. This does
not necessarily mean that estimates were poorly done at the
start of the project; it is virtually impossible to develop an
exact assessment of the project’s schedule before the
analysis and design phases are conducted. A project
manager should expect to be satisfied with broad ranges of
estimates that become more and more specific as the
project’s product becomes better defined.
Managing Scope.
The most common reason for schedule and cost overruns
occurs after the project is underway— scope creep. Scope
creep happens when new requirements are added to the
project after the original project scope was defined and
“frozen.” It can happen for many reasons: Users may
suddenly understand the potential of the new system and
realize new functionality that would be useful; developers
may discover interesting capabilities to which they become
very attached; a senior manager may decide to let this
system support a new strategy that was developed at a
recent board meeting.
Time boxing.
This technique sets a fixed deadline for a project and delivers
the system by that deadline no matter what, even if
functionality needs to be reduced. Time boxing ensures that
project teams don’t get hung up on the final “finishing
touches” that can drag out indefinitely, and it satisfies the
business by providing a product within a relatively fast time
frame.
Managing Risk.
One final facet of project management is risk management,
the process of assessing and addressing the risks that are
associated with developing a project. Many things can cause
risks: weak personnel, scope creep, poor design, and overly
optimistic estimates. The project team must be aware of
potential risks so that problems can be avoided or controlled
well ahead of time.
• Risk assessment
• Actions to reduce risk
• Revised assessment
Systems Analysis and Design
ANALYSIS PHASE
Requirements Determination
Chapter 3 Outline
•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 is involves three steps:
•Understand the existing situation (the as-is system)
•Identify improvements
•Define the requirement for the new system (the to-be
system).

❖The final deliverables of the analysis phase is the system

proposal.

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

The Process of Determining Requirements

REQUIREMENTS DETERMINATION
-Both business and IT perspectives are needed to determine
requirements during the analysis phase.
➢Requirements determination is performed to transform
the system request’s high-level statement of business
-The most effective approach is to have both businesspeople
requirements into a more detailed, precise list of what the
and analysts working together to determine requirements.
new system must do to provide the needed value to the
business
-The analyst must also consider how best to elicit the
requirements from the stakeholders.
What is a Requirement?
-The process of determining requirements continues
•A requirement is a statement of what the system must do
throughout the analysis phase, and the requirements
or what characteristics it needs to have.
definition evolves over time.
•Requirements describe
The requirements definition statement
-what the business needs
(business requirements)
-what the users need to do
(user requirements)

-what the software should do

(functional requirements)

-characteristics the system should have

(non-functional requirements), and

-how the system should be built

(system requirements)

FUNCTIONAL REQUIREMENTS

REQUIREMENTS ELICITATION TECHNIQUES

Requirements Elicitation in Practice
NONFUNCTIONAL REQUIREMENTS
•The analyst should recognize that important side effects of
the process of determining requirements include building
political support for the project and establishing trust •Structured interview
between the project team and the users. • for very specific information

•The analyst should carefully determine who is included in

the process of determining requirements.
Top-down vs. bottom-up interview

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
Preparing for the interview
•Prepare a general interview plan
SELECTING INTERVIEWEES
•Confirm areas of knowledge
•Interview schedule
•Set priorities in case of time shortage

•Prepare the interviewee

• Schedule
• Inform of reason for interview
• Inform of areas of discussion

Conducting the Interview

•Appear to be professional and unbiased.

•Record all information.

•Including people at different levels of the organization •Be sure you understand the issues that are discussed.
• Managers
• Users •Separate facts from opinions.
• Other key stakeholders
DESIGNING INTERVIEW QUESTIONS •Give interviewee time to ask questions, and brief explain
what will happen next.

Post-interview follow-up

•After the interview, the analysts needs to prepare an

interview report.
•The report includes interview notes.
•The report is sent to interviewee with a request to read it
and inform the analyst of clarification and updates.

•Unstructured interview Joint Application Development (JAD)

• for a broad and roughly defined set of information
•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
•Selecting JAD participants in the same basic way as selecting
interview participants.
•Facilitator
• Expert in JAD and e-JAD techniques
• In many cases, the JAD facilitator is a consultant
external to the organization.
Designing the JAD session and Preparing for the JAD sessions
•JAD sessions can run from a half day to several weeks
depending upon the size and scope of the project.
•JAD success depends upon a careful plan.
•Most JAD sessions are designed to collect specific
information from users.
•It is important to prepare the analyst and participants for
the JAD session.
CONDUCTING THE JAD SESSION
•Most JAD sessions follow formal agenda and ground rules.
•The JAD facilitator performs three key functions:
• Keep session on track, following the agenda.
• Help the group understand the technical terms and
jargon.
• Record group’s input on a public display area.
▪The facilitator must remain neutral at all time and help the
group through the process.
Post JAD Follow-up
•Post session report is prepared and circulated among
session attendees
•The report should be completed approximately a week to
two after the JAD session
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.
GOOD QUESTIONNAIRE DESIGN
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
•Type of information
•Depth of information
•Breadth of information
•Integration of information
•User involvement
•Cost
•Combining techniques
Comparison of Requirements Elicitation Techniques
REQUIREMENTS ANALYSIS STRATEGIES
Problem Analysis
▪Asking users to identify problems and solutions
▪Improvements from problem analysis tend to be small and
incremental
▪This type of improvements often is very effective at
improving a system’s efficiency or ease of use; however, it
provides minor improvements in business value.
Root Cause Analysis
Duration Analysis
•Duration analysis requires a detailed examination of
amount of time it takes to perform each process in the as-is
system.
•Compare the total time to complete basic steps and the
total time for the overall process –a significant difference
indicates that the process is badly fragmented.
•Potential solutions:
• Process integration
• Parallelization
Activity-Based Costing
•Activity-based costing examines the cost of each major
process or step in a business process.
•Both direct and indirect costs are considered.
•The analysts identify most costly steps and focus
improvement efforts on them.
Informal Benchmarking
•Benchmarking refers to studying how other organizations
perform a business process.
•Informal benchmarking is common for “customer-facing”
processes.
•The analysts visit other organizations as customers to watch
how the business process is performed.
Outcome Analysis
•Outcome analysis focuses on understanding fundamental
outcomes that provide value to customers.
•Think what the organization could enable the customer to
do
Technology Analysis
•Technology analysis involves two steps:
1. The analysts and managers list important and
interesting technologies.
2. Then, the group identifies how each and every
technology might be applied to the business and
how the business would benefit.
Activity Elimination
The analysts and managers work together to identify
•how the organization could eliminate each and every
activity in the business process,
•how the function could operate without it, and
•what effects are likely to occur.
COMPARING ANALYSIS STRATEGIES
•Each of the requirement analysis strategies has its own
purpose.
•No one strategy is inherently better that the others.
❖The actor refers to a person, another system, or a
hardware device that interacts with the system to achieve a
useful goal.
❖The trigger for the use case –the event that causes the use
case to begin.

•The requirement analysis strategy should be chosen to fit Example

the nature of the project.
This use case is based on the scenario of a lawn care
SUMMARY company that employs specially trained workers to apply
✓Analysis focuses on capturing the business requirements lawn chemicals to customers’ lawns. The company maintains
for the system a chemical supply warehouse where the employees obtain
the needed chemicals for their lawn care assignments. The
✓Requirement Determination is the part of analysis in which
process of obtaining lawn chemicals involves three main
the project team turns the business requirements stated in
steps: authenticating the employee and ensuring he has the
the system request into a precise list of requirements.
required training and credentials; submitting are quest for
✓Five Requirements Elicitation Techniques can be used to the needed chemical; and picking up the chemical from the
elicit business requirements. chemical supply warehouse. The example use case focuses
on the second step of this over all process: requesting a
✓Requirements Analysis Strategies are useful for analysts to
chemical.
help the business users think critically about the new system
requirements.
Preconditions
The pre conditions define the state the system must be in
before the use case commences.
ANALYSIS PHASE
Chapter 4 Normal Course
Use Case Analysis The next part of a use case is the description of the major
steps that are performed to execute the response to the
Chapter 4 Outline event, the inputs used for the steps, and the outputs
-Use Cases produced by the steps.
-Elements of a use case. ***The normal course lists the steps.
-Alternative use case formats.
-Use cases and functional requirements. Alternative Courses
-Use cases and testing. Alternative courses depict branches (alternative paths of
-Building use cases. the steps) in logic that also will lead to a successful
conclusion of the use case.

USE CASES Post conditions

✓Use cases are a means of expressing user requirements.
✓Use cases are used extensively in the analysis phase.
A use case depicts a set of activities that produce some
output result.
Each use case describes how an external user triggers an
event to which the system must respond.
Elements of a Use Case
Basic Information
❖Each use case has a name and number, and brief
description.
❖The priority may be assigned to indicate the relative
significance.
The post conditions section defines the final product of the
use case.
These post conditions also serve to define the preconditions
for the next use case in the series.
Exceptions
A use case should describe any error conditions or
exceptions that may occur as the use case steps are
performed.
Summary of Inputs and Outputs
The final section of the use case summarizes the set of major
inputs and outputs of the use case, along with their source
or destination.
Additional Use Case Issues
Additional sections may be included:
-Frequency of use
-Business rules
-Special requirements
-Assumptions
-Notes and issues

Chain Of Use Cases –An Example

Step 2: Identify the major steps for each use case

Step 3: Identify elements within steps

Alternative Use Case Formats

A full-dressed use case is very thorough, detailed, and highly
structured.
The project team may decide that a more casual use case
Step 4. Confirm the use case
format is acceptable.

Use Cases and the Functional Requirements

❑Use cases are very useful tools to us to understand user
requirements. However, use cases only convey the user’s
point of view.
❑Transforming the user’s view into the developer’s view by Revise Functional Requirements Based On Use Cases
creating functional requirements is one of the important
contributions of system analyst. The functional requirements in the requirements definition
❑The derived functional requirements give more may be modified to reflect the more detailed understanding
information to the developer about what the system must and to provide insight to the development team on some
do. “back-end” processing.

SUMMARY
Example •A use case contains all the information needed to build one
part of a process model, expressed in an informal, simple
way.

•When writing a use case,

-identify the triggering event,

-develop a list of the major steps,
-identify the input(s) and output(s) for every step,
-have the users role-play the use case to verify.

Chapter 5 Process Modelling

Use Cases and Testing Outline

Building Use Cases
Step 1: Identify the major use cases
Data flow diagrams.
-Reading data flow diagrams

-Elements of data flow diagrams

-Using data flow diagrams to define business processes

-Process descriptions

Creating data flow diagrams.

✓A process model can be used to further clarify the

requirements definition and use cases.

✓A process model is a graphical way of representing how a

business system should operate.

✓A process model can be used to document the as-is system
or the to-be system, whether computerized or not.
✓Data flow diagrammingis a technique that diagrams the
business processes and the data that pass among them.
✓Logical process models describe processes without
suggesting how they are conducted.
Elements of Data Flow Diagrams
Process–A process is an activity or a function performed for
some specific business reason.
Data Flow –A data flow is a single piece of data, or a logical
collection of several pieces of information.
Data Store –A data store is a collection of data that is stored
in some way.
External Entity –An external entity is a person, organization,
organization unit, or system that is external to the system,
but interacts with it.
Illustration:

✓Physical process models provide information that is

needed to build the system.

DATA FLOW DIAGRAMS (DFDs)

Reading Data Flow Diagrams

Using DFDs to Define Business Processes

Business processes are too complex to be explained in one
DFD.
One important principle in process modeling with DFDs is
the decomposition of the business process into a series of
DFDs, each representing a lower level of detail.
➢The Level 0 diagram shows all the processes at the first
level the numbering, the data stores, external entities, and
data flows among them.
➢A key concept: Balancing
➢-Ensuring that all information presented in a DFD at one
level is accurately represented in the next-level DFD.
➢A process model has one and only one level 0 DFD.

Level 1 Diagrams

•Each process on the level 0 DFD can be decomposed into a

more explicit DFD called level 1 diagram (or level 1 DFD).

•The set of children and the parent are identical; they are
simply different ways of looking at the same thing.

•It is important to ensure that level 0 and level 1 DFDs are

balanced.

CONTEXT DIAGRAM
•The first DFD in every business process is the context
diagram.

•It shows the entire system in context with its environment.

•The context diagram shows the overall business process as

just one process and shows the data flows to and from
external entities.

Level 0 Diagram
➢The level 0 diagram (or level 0 DFD) shows all the major
high-level processes of the system and how they are
interrelated.

Level 2 Diagrams
❑The next level of decomposition: a level 2 diagram, or
level 2 DFD.
❑A level 2 DFD shows all processes, data flows, and data
stores that comprise a single process on the level 1 diagram.
❑It is important to ensure that level 1 and level 2 DFDs are
balanced.
Alternative Data Flows
❑A process can produce different data flows under different
circumstance.
❑We show both data flows and use the process description
to explain why they are alternatives.
Process Descriptions
❑The purpose of the process descriptions is to explain what
the process does and provide additional information that
the DFD does not provide.
❑Three techniques are commonly used to describe more
complex processing logic:
➢Structured English
➢Decision trees
➢Decision tables
CREATING DATA FLOW DIAGRAMS
DFDs start with the information in the use cases and the
requirements definition.
Generally, the set of DFDs integrates the individual use
cases.
The project team takes the use cases and rewrites them as
DFDs, following the DFD formal rules about symbols and
syntax.
CASE tools are used to draw process models.
CREATING DATA FLOW DIAGRAMS
1. Build the context diagram.
2. Create DFD fragments for each use case.
3. Organize the DFD fragments into level 0 diagram.
4. Develop level 1 DFDs based on the steps with each use
case. In some cases, these level 1 DFDs are further
decomposed into level 2 DFDs, level 3 DFDs, and so on.
5. Validate the set of DFDs to make sure that they are
complete and correct.
Creating the Context Diagram
•The context diagram defines how the business process or
computer system interacts with its environment.
•Draw one process symbol for the business process or
system being modeled (numbered 0 and named for the
process or system).
•Add all inputs and outputs listed on the form of the use
cases as data flows.
•Draw in external entities as the source or destination of the
data flows.
•No data stores are included in the context diagram.
Example of Context Diagram
Creating DFD Fragments
❑A DFD fragment is one part of a DFD that eventually will
be combined with other DFD fragments to form a DFD.

❑Each use case is converted into one DFD fragment using

the information given on the form of the use case: the name,
the ID number, and major inputs and outputs.

❑The information about the major steps that make up each

use case is ignored at this point; it will be used in a later step.

Example of Fragment

•Important changes are often made in converting the use

case into a DFD:
-modifications to the process names
-the addition of data flows.
•Make sure that any information given to the user is
obtained from a data store.

•There are not formal rules covering the layouts; typically

–place the processes in the middle
–inputs start from the left or top
–outputs leave from the right or the bottom
–place data stores below the processes

Creating the Level 0 Diagram

•Combine the set of DFD fragments into one diagram –the
level 0 DFD.
•There are not formal layout rules. Generally,
Additional Example of Fragment
-to put the process that is first chronologically in the upper-
left corner and work the way from top to bottom, left to
right;
-to reduce the number of crossed data flow lines.
•Iteration is the cornerstone of good DFD design.
 Validating the DFD
•There two fundamental types of errors in DFDs:

1. Syntax errors –can be thought of as grammatical errors

Creating Level 1 DFD(and Below)
•Level 1 DFD –lower-level DFDs for each process in the level
0 DFD.
•Each one of the use cases is turned into its own DFD
•Each major step in the use case becomes a process on the
level 1 DFD, with the inputs and outputs becoming the input
and output data flows.
that violate the rules of the DFD language.
2. Semantics errors –can be thought of as
misunderstandings by the analyst in collecting, analyzing,
and reporting information about the system.
•Syntax errors are easier to find and fix than are semantics
errors because there are clear rules that can be used to
identify them.
•Most CASE tools have syntax checkers that will detect
syntax errors.

•Level 1 DFDs include the sources and destinations of data Common Syntax Errors
flows for data stores and data flows to processes.
•Including external entities in level 1 and lower DFDs can
simplify the readability of DFDs.

❑There is no simple answer to the “ideal” level of

decomposition, because it depends on the complexity of the
system or business process being modeled.

❑In general, you decompose a process into a lower-level

DFD whenever the process is sufficiently complex that
additional decomposition can help explain the process.

❑Rules of thumb:
-There should be at least 3, and no more than 7-9, processes
on every DFD.
-Decompose until you can provide a detailed description of
the process in no more than 1 page of process descriptions.
Validating the DFD

Checklist of Common Errors in DFDs

SUMMARY
•Data Flow Diagram Syntax –four symbols are used on data
flow diagrams (processes, data flows, data stores, and
external entities).

•Creating Data Flow Diagrams

-The DFDs are created from use cases. ▪Lines drawn between entities represent relationships
-Every set of DFDs starts with a context diagram. among the data.
-DFDs segments are created for each use case and are then
organized into a level 0 DFD.
-Level 1 DFDs are developed on the basis of the steps within ▪Special symbols communicate high-level business rules.
each use case.
-The set of DFDs are validated to make sure that they are Reading an Entity Relationship Diagram
complete and correct and contain no syntax or semantics
errors.

Chapter 6
Data Modeling
Outline Elements of an Entity Relationship Diagram
The Entity Relationship Diagram (ERD).
-Elements of ERD
-The Data Dictionary and Metadata
Creating an Entity Relationship Diagram.
Validating an ERD.

INTRODUCTION

❖A data model is a formal way of representing the data that

are used and created by a business system.

❖During analysis (this Chapter), analysts draw a Logical

data model which shows the logical organization of data
without indicating how it is stored, created, or manipulated.

❖During design (Chapter 11), analysts draw a physical data

model to reflect how the data will physically be stored in
databases or files.
Topics of this chapter:
✓Creating an entity relationship diagram (ERD).
✓Normalization, a technique that helps analysts validate
the data models.
ENTITY
▪The entity is the basic building block for a data model. It is
a person, place, event, or thing about which data is
collected.
▪Entities represent something for which there exist multiple
instances, or occurrences.
▪-E.g., John Smith could be an instance of the customer
entity.

✓How data models balance, or interrelate, with the process

models.

THE ENTITY-RELATIONSHIP DIAGRAM (ERD)

▪An 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

Attributes
▪An attribute is some type of information that is captured
about an entity.
▪Attributes are nouns that are listed with an entity.
▪One or more attributes can serve as the entity identifier-
the attribute(s) that can uniquely identify one instance of an
entity.
▪Concatenated identifier-several attributes are combined
to uniquely identify an instance.
Modality
▪A relationship has modality of null or not null, which refers
to whether 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.

Choices for Identifiers ▪Not Null means that an instance of a child entity can’t exist
without a related instance in the parent entity.

Relationships
▪Relationships are associations between entities.
▪Every relationship has a parent entity and a child entity.
The Data Dictionary and Metadata
▪A data dictionary contains the information about the
entities, attributes, and relationships on the ERD, or
metadata.

▪Relationships should be labeled with active verbs. ▪Meta data is data about data.

Cardinality ▪Metadata is stored in the data dictionary so it can be shared

by developers and users throughout the SDLC.
▪A relationship has cardinality which is 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.

Example of M:N Relationship

 Step 2. Add two 1:N relationships to the model.
Step 3. Name the intersection entity.

Resolving an M:N Relationship

CREATING AN ENTITY RELATIONSHIP DIAGRAM (ERD)

▪Drawing the ERD is an iterative process of trial and revision.
▪The basic steps in building an ERD:

1. Identify the entities; VALIDATING AN ERD

2. add the appropriate attributes to each entity; and ▪General design guidelines.
3. draw relationships among entities. ▪Normalization.
▪Check the ERD against the process models to make sure
Advanced Syntax that both model balance each other.
Three special types of entities:
▪Independent Entity Design Guidelines
•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.
(E.g., the Chemical Request entity in Figure 6.1).
Normalization
▪Normalization is a technique that can help analysts validate
the data models.
▪Intersection Entity
•It exists in order to capture some information about the
relationship between two other entities. ▪It is a process whereby a series of rules are applied to a
•Typically, intersection entities are added to a data model to logical data model to determine how well it formed is.
store information about two entities sharing an M : N
relationship. Balancing ERDs with DFDs
▪The process models and data models are interrelated.

▪There are three steps involved in adding an intersection

entity: ▪Although the process model focuses on the business
Step 1.Remove the M:N relationship line and insert a new processes, it contains two data components –the data and
entity (intersection entity) in between the two existing ones. the data store.
▪These two data components of the DFDs need to balance
with the ERDs. -Normalization
-CRUD matrix
▪The DFD data components need to correspond with the
ERD’s data stores (i.e., entities) and the data elements that
comprise the data flows (i.e., attributes) depicted on the
data model.

▪Many CASE tools provide features of identifying problems

with balance between DFDs and ERDs; however, it is
important to understand how to identify problems on your
own.

▪Check your DFDs and ERDs to make sure all data

components correspond between DFDs and ERDs.

A Portion of a DFD and the CRUD Matrix

A useful tools to clearly depict the interrelationship between

process and data models is the CRUD matrix (create, read,
update, delete matrix).

SUMMARY
▪Basic Entity Relationship Diagram Syntax

-Entity describes people, places, or things.

-Attribute is some type of information about the entity.
-Relationship conveys the associations between entities.
▪Creating an ERD

-Identify the entities.

-Add the attributes to each entity.
-Draw relationships among entities.
▪Validating an ERD