SDLC Planning Analysis Design Implementation

DETAILED DISCUSSION

Planning
The planning phase is the fundamental process of understanding why an information system should be built and
has two steps:

1. During project initiation, the system’s business value to the organization is identified: how will it lower costs o
outside the IS area (from the marketing department, accounting department, etc.) in the form of a system request
need, and it explains how a system that supports the need will create business value. The IS department works to
request (called the project sponsor) to conduct a feasibility analysis.

The feasibility analysis examines key aspects of the proposed project:

■ The idea’s technical feasibility (Can we build it?)

■ The economic feasibility (Will it provide business value?)

■ The organizational feasibility (If we build it, will it be used?)

The system request and feasibility analysis are presented to an information systems approval committee (sometim
project should be undertaken.

2. Once the project is approved, it enters project management. During project management, the project manager
in place to help the project team control and direct the project through the
entire SDLC. The deliverable for project management is a project plan, which
describes how the project team will go about developing the system.

Information system projects are usually complicated.They require a significant time, effort. and economic investm
stated vaguely. which means that the Initial envisioned solution may be premature. For these reasons, system pro
establishes project scope

and the problem solving plan.Thus, we see that system Initiation establishes the project scope,goals,

schedule, and budget required to solve the problem or opportunity represented by the project.

Project scope defines the area of the business to be addressed by the project and the goals to be achieved.

Scope and goals ultimately Impact the resource committmemts. namely. schedule and

budget, that must be made to successfully complete the project.. By establishing a project schedtde and budget

against the inittal scope and goals, you also establish a baseline against which all stakeholders can accept the r
scope or goals wll impact the schedule and budget.

The Planning Phase is the fundamental two-step process of understanding why an information system sho
team will develop it. The deliverables from both steps are combined into the project plan,
which is presented to the project sponsor and approval committee at the end of the Planning Phase. They d
system development project.

CHECKLIST for PLANNING STAGE

Analysis
The analysis phase answers the questions of who will use the system, what the system will do, and where and w
investigates any current system(s), identifies improvement opportunities, and develops a concept for the new syst

This phase has three steps:

1. An analysis strategy is developed to guide the project team’s efforts. Such a strategy usually includes an anal
problems, and then ways to design a new system (called the to-be system).
2. The next step is requirements gathering (e.g., through interviews or questionnaires). The analysis of this info
and many other people—leads to the development of a concept for a new system. The system concept is then used
models, which describe how the business will operate if the new system is developed. The set of models typically
necessary to support the underlying business process.
3. The analyses, system concept, and models are combined into a document called the system proposal, which
makers (e.g., members of the approval committee) who decide whether the project should continue to move forwa

The system proposal is the initial deliverable that describes what business requirements the new system should m
new system, some experts argue that it is inappropriate to use the term analysis as the name for
this phase; some argue a better name would be analysis and initial design. Most organizations continue use to th
book as well. Just keep in mind that the deliverable from the analysis phase is both an analysis and
a high-level initial design for the new system.

System analysis is Intended to provide the project team with a more thorough understanding of the problems and

As such, the business area (scope of the project- as defined during system Initiation) may be studied and analyze
what doesn't, and what"s needed. system analysis requires working with system users to clearly define business
be purchased or developed. Also. business priorities may need to be established In the event that schedule and bu

CHECKLIST for ANALYSIS STAGE

Performing Requirements Determination

you will learn here about various methods that systems analysts use to collect the information needed to determ

In many ways, the requirements determination step is the single most critical step of the entire SDLC. It is here t
During requirements determination, the system is easy to change because little work has been done yet. As the sy
becomes harder and harder to return to requirements determination and make major changes because of all of th

Although many factors contribute to the failure of systems development projects, failing to determine the correct
approaches of many RAD and agile methodologies are so effective—small batches of requirements can be identi
overall system to change and evolve over time. In this lessons, we will focus on the requirements determination s
analysis phase. We begin by explaining what a requirement is and the overall process of requirements analysis a

What Is a Requirement?
A requirement is simply a statement of what the system must do or what characteristics it needs to have. During
perspective of the businessperson, and they focus on what the system does. They focus on business user needs, so
user requirements). Later in the design phase, business requirements evolve to become more technical, and they
in the design phase are written from the developer’s perspective, and they usually are called system requirement

Before we continue, we want to stress that there is no black-and-white line dividing a business requirement and a
interchangeably. The important thing to remember is that a requirement is a statement of what the system must d
moves from analysis to design to implementation. Requirements evolve from detailed statements of the business c
of the technical way in which the capabilities will be implemented in the new system.

Requirements can be either functional or nonfunctional in nature. A functional requirement relates directly to
needs to contain. For example, a process-oriented functional requirement would be that the system must have th
oriented functional requirement would be that the system must include actual and budgeted expenses. (See Table
steps of the analysis process (use cases, process models, data model) because they define the functions that the sy

Nonfunctional requirements refer to behavioral properties that the system must have, such as performance an
browser would be considered a nonfunctional requirement. Nonfunctional requirements may influence the rest o
model), but often do so only indirectly; nonfunctional requirements are primarily used in the design phase when
and software, and the system’s underlying architecture.

Table below lists different kinds of nonfunctional requirements and examples of each kind. Notice that the nonfun
regarding the system: operational, performance, security, and cultural and political. These characteristics do no
very important in understanding what the final system should be like. For example, the project team needs to kno
subsecond response time, or has to reach a multilingual customer base. These requirements will affect design de
architecture design. The goal at this point is to identify any major issues.

As stated earlier and shown in Figure,

the two parts to systems analysis are determining requirements and structuring requirements. We address thes
as somewhat parallel and repetitive. For example, as you determine some aspects of the current and desired syst
prototypes to show users how a system might behave. Inconsistencies and deficiencies discovered through structu
operation of the current system(s) and the future needs of the organization.
Eventually your ideas and discoveries meet on a thorough and accurate depiction of current operations and the r

PART-I: Determining Requirements

At the end of the systems planning and selection phase of the SDLC, management can grant permission to pursue
planned and you begin determining what the new system should do. During requirements determination, you an
should do from as many sources as possible. Such sources include users of the current system, reports, forms, an
documented and made ready for structuring. Structuring means taking the system requirements you find during r
diagrams, and other formats that make them easier to translate into technical system specifications. In many wa
investigation. The characteristics you need to enjoy solving mysteries and puzzles are the same ones you need to
determination. These characteristics include:

. Impertinence: You should question everything. Ask such questions as “Are all transactions processed the same
standard price?” “Might we someday want to allow and encourage employees to work for more than one depart

. Impartiality: Your role is to find the best solution to a business problem or opportunity. It is not, for example, to
insist on incorporating what users think they want into the new system requirements. You must consider issues ra
solution.

. Relaxing of constraints: Assume anything is possible and eliminate the infeasible. For example, do not accept th
continue the practice.” Traditions are different from rules and policies. Traditions probably started for a good r
they may turn into habits rather than sensible procedures.

. Attention to details: Every fact must fit with every other fact. One element out of place means that the ultimate s
definition of who a customer is may mean that you purge customer data when a customer has no active orders; y

. Reframing: Analysis is, in part, a creative process. You must challenge yourself to look at the organization in n
requirements. Be careful not to jump to this conclusion: “I worked on a system like that once—this new system m

Deliverables and Outcomes

The primary deliverables from requirements determination are the types of information gathered during the de
forms: transcripts of interviews; notes from observation and analysis of documents; sets of forms, reports, job
generated output such as system prototypes. In short, anything that the analysis team collects as part of determi
deliverables. Table below lists examples of some specific information that might be gathered at this time.
The deliverables summarized in the Table contain the information you need for systems analysis. In addition, in
following components of an organization:

. The business objectives that drive what and how work is done

. The information people need to do their jobs

. The data handled within the organization to support the jobs

. When, how, and by whom or what the data are moved, transformed and stored

. The sequence and other dependencies among different data-handling activities

. The rules governing how data are handled and processed

. Policies and guidelines that describe the nature of the business, the market, and the environment in which it

. Key events affecting data values and when these events occur

Such a large amount of information must be organized in order to be useful, which is the purpose of the next part

Requirements Structuring
The amount of information gathered during requirements determination could be huge, especially if the scope of
collect and structure a great deal of information can be extensive and, because it involves so much human effort,
the term analysis paralysis has been coined to describe a project that has become bogged down in an abundance
analysis, today’s systems analysts focus more on the system to be developed than on the current system. Later , y
prototyping, techniques developed to keep the analysis effort at a minimum yet still be effective. Other processes
providing an alternative to the SDLC. Many of these are included under the name of Agile Methodologies. Befor
to learn traditional fact-gathering techniques.

Traditional Methods for Determining Requirements

Collection of information is at the core of systems analysis. At the outset, you must collect information about the
find out how users would like to improve the current systems and organizational operations with new or replacem

One of the best ways to get this information is to talk to those directly or indirectly involved in the different parts
Another way is to gather copies of documentation relevant to current systems and business processes. In this cha
directly from those who have the information you need: interviews and direct observation. You learn about colle
organizational operation in the form of written procedures, forms, reports, and other hard copy. These traditiona
Table below.
I - Interviewing and Listening
Interviewing is one of the primary ways analysts gather information about an information systems project. Early
interviewing people about their work, the information they use to do it, and the types of information processing th
understand organizational direction, policies, and expectations that managers have of the units they supervise. D
speculation and observe body language, emotions, and other signs of what people want and how they assess curr

Interviewing someone effectively can be done in many ways, and no one method is necessarily better than anothe
summarized in Table below.
First, prepare thoroughly before the interview. Set up an appointment at a time and for a duration that is conven
should be explained to the interviewee in advance. You may ask the interviewee to think about specific questions
the interview. Spend some time thinking about what you need to find out, and write down your questions. Do not
want the interview to be natural and, to some degree, you want to direct the interview spontaneously as you disco

Prepare an interview guide or checklist so that you know in which sequence to ask your questions and how much
might include some probing questions to ask as follow-up if you receive certain anticipated responses. You can, t
you take during the interview, as depicted in a sample guide in Figure below. This same guide can serve as an ou
interview.
The first page of the sample interview guide contains a general outline of the interview. Besides basic informatio
objectives for the interview. These objectives typically cover the most important data you need to collect, a list of
for certain system reports), and which areas you need to explore. Also, include reminder notes to yourself on key
positions taken on issues, and role with current system). This information helps you to be personal, shows that yo
interpreting some answers. Also included is an agenda with approximate time limits for different sections of the i
the schedule helps you cover all areas during the time the interviewee is available. Space is also allotted for gen
for notes taken during the interview about topics skipped or issues raised that could not be resolved.

On subsequent pages, list specific questions. The sample form in Figure shown above includes space for taking n
may provide information you were not expecting, you may not follow the guide in sequence. You can, however, c
yourself to return to or skip other questions as the interview takes place.

Choosing Interview Questions You need to decide on the mix and sequence of open-ended and closed-ended que

Open-ended questions are usually used to probe for information when you cannot anticipate all possible respon
person being interviewed is encouraged to talk about whatever interests him or her within the general bounds of
thing about the information system you currently use to do your job?” or “List the three most frequently used me
determine whether any followup questions are needed for clarification or elaboration. Sometimes body language
is reluctant to provide certain information. If so, a follow-up question might result in more information. One adv
information can surface. You can then continue exploring along unexpected lines of inquiry to reveal even more
interviewees at ease because they are able to respond in their own words using their own structure. Open-ended
and control in the interview. A major disadvantage of open-ended questions is the length of time it can take for th
summarize.

Closed-ended questions provide a range of answers from which the interviewee may choose. Here is an example
Which of the following would you say is the one best thing about the information system you currently use to do y

a. Having easy access to all of the data you need

b. The system’s response time

c. The ability to run the system concurrently with other applications

Closed-ended questions work well when the major answers to questions are well known. Another plus is that inte
require a large time commitment—more topics can be covered. Closed-ended questions can also be an easy way
ended questions to pursue. You can include an “other” option to encourage the interviewee to add unexpected re
A major disadvantage of closed-ended questions is that useful information that does not quite fit the defined answ
choice instead of providing his or her best answer.

Like objective questions on an examination, closed-ended questions can follow several forms, including these cho

. True or false

. Multiple choice (with only one response or selecting all relevant choices)

. Rating a response or idea on some scale, say, from bad to good or strongly agree to strongly disagree (each po
meaning to each person, and there is usually a neutral point in the middle of the scale)

. Ranking items in order of importance

Interview Guidelines
Firstly, with either open- or closed-ended questions, do not phrase a question in a way that implies a right or wr
opinions and perspectives and trust that their ideas will be considered. Avoid questions such as “Should the syst
value, even though most users now do not like the feature?” because such wording predefines a socially accepta

Secondly, listen carefully to what is being said. Take careful notes or, if possible, record the interview on a tape
contain extremely important information for the project. Also, this may be your only chance to get information fr
need more information from the person you are talking to, ask to schedule a follow-up interview.

Thirdly, once the interview is over, go back to your office and key in your notes within forty-eight hours with a w
numerical data, you can use a spreadsheet program such as Microsoft Excel. If you recorded the interview, use t
your memory of the interview will fade quickly. As you type and organize your notes, write down any additional q
ambiguous information. Separate facts from your opinions and interpretations. Make a list of unclear points that
answers to these new questions. Use the phone call as an opportunity to verify the accuracy of your notes. You m
person you interviewed to check your notes for accuracy. Finally, make sure to thank the person for his or her tim
interviewee will be a user of your system or is involved in some other way in the system’s success, you want to le

Fourthly, be careful during the interview not to set expectations about the new or replacement system unless you
Let the interviewee know that there are many steps to the project. Many people will have to be interviewed. Choi
possible alternatives. Let respondents know that their ideas will be carefully considered. Because of the repetitiv
premature to say now exactly what the ultimate system will or will not do.

Fifthly, seek a variety of perspectives from the interviews. Talk to several different people: potential users of the
new system, managers and superiors, information systems staff, and others. Encourage people to think about cur
services might better serve the organization. You want to understand all possible perspectives so that later you w
design decision that everyone can accept.

II - Directly Observing Users

Interviewing involves getting people to recall and convey information they have about organizational processes a
however, are not always reliable, even when they try to be and say what they think is the truth. As odd as it may s
appreciation of what they do or how they do it, especially when infrequent events, issues from the past, or issue
Because people cannot always be trusted to interpret and report their own actions reliably, you can supplement w
situations.
The intent behind obtaining system records and direct observation is the same, however, and that is to obtain mo
with information systems. In some cases, behavioral measures will more accurately reflect reality than what emp
information will substantiate what employees have told you directly. Although observation and obtaining objecti
information, such methods are not always possible in real organizational settings. Thus, these methods are not to
unbiased.

III - Analyzing Procedures and Other Documents

As previously noted, interviewing people who use a system every day or who have an interest in a system is an ef
systems. Observing current system users is a more direct way of seeing how an existing system operates. Both in
determining system requirements can be enhanced by examining system and organizational documentation to dis
organization they support. What can the analysis of documents tell you about the requirements for a new syste

. Problems with existing systems (e.g., missing information or redundant steps)

. Opportunities to meet new needs if only certain information or information processing were available (e.g., ana

. Organizational direction that can influence information system requirements (e.g., trying to link customers and

. Titles and names of key individuals who have an interest in relevant existing systems (e.g., the name of a sales m
customers)

. Values of the organization or individuals who can help determine priorities for different capabilities desired by
means lower short-term profits)

. Special information-processing circumstances that occur irregularly that may not be identified by any other req
needed for a few large-volume customers who require use of customized customer ordering procedures)

. The reason why current systems are designed as they are, which can suggest features left out of current softwar
a customer’s purchase of competitors’ products not available when the current system was designed; these data

. Data, rules for processing data, and principles by which the organization operates that must be enforced by the
one sales department staff member as primary contact if customer has any questions)

One type of useful document is a written work procedure for an individual or a work group. The procedure descr
data and information used and created in the process of performing the job. For example, the procedure shown i
advantages, drawings, inventor name, and witness names) required to prepare an invention disclosure. It also in
research, the department head, and the dean must review the material and that a witness is required for any filin
what data must be kept, to whom information must be sent, and the rules that govern valid forms.
Procedures are not trouble-free sources of information, however. Sometimes your analysis of several written pro
jobs. You should call such duplication to the attention of management as an issue to be resolved before system de
the organization before the redesign of an information system can achieve its full benefits. Another problem you
job to create a document for a missing procedure—that is up to management. A third and common problem happ
realize in your interview of the person responsible for performing the task described in the procedure. Once agai
matches reality is made by management, but you may make suggestions based upon your understanding of the or
that the formal procedures may contradict information you collected from interviews, questionnaires, and observ
information is required. As in the other cases, resolution rests with management.

All of these problems illustrate the difference between formal systems and informal systems. A formal system is o
the way in which the organization actually works. Informal systems develop because of inadequacies of formal p
resistance to control. It is important to understand both formal and informal systems because each provides insig
convert from present to future systems.

A second type of document useful to systems analysts is a business form, illustrated in Figure below. Forms are u
order to acknowledging the payment of a bill to indicating what goods have been shipped. Forms are important f
what data flow in or out of a system. In the sample invoice form in Figure below, we see space for data such as in
ordered, their descriptions, rates, and amounts.
A printed form may correspond to a computer display that the system will generate for someone to enter and mai
users. The most useful forms contain actual organizational data that allow you to determine the data characteris
people use forms change over time, and data that were needed when a form was designed may no longer be requ

A third type of useful document is a report generated by current systems. As the primary output for some types of
backward from the information on the report to the data that must have been necessary to generate it. Figure bel
report, the statement of cash flows. You analyze such reports to determine which data need to be captured over w
necessary to produce each field on the report.
If the current system is computer based, a fourth set of useful documents is one that describes the current informa
and how they work. Several different types of documents fit this description, everything from flowcharts to data d
such documents is fortunate because many in-house-developed information systems lack complete documentation
along with interviewing and distributing questionnaires, are the methods used most for gathering system require

This TABLE below summarizes the comparative features of observation and analysis of organizational documen
Modern Methods for Determining System Requirements
Even though we called interviews, questionnaires, observation, and document analysis traditional methods for d
still used by analysts to collect important information. Today, however, additional techniques are available to co
organizational area requesting the new system, and what the new system should be like.

In this section, you learn about two modern information-gathering techniques for analysis: joint application
support effective information collection and structuring while reducing the amount of time required for analysis.

The following is a list of typical JAD participants:

. JAD session leader: The JAD leader organizes and runs the JAD. This person has been trained in group manag
JAD leader sets the agenda and sees that it is met. He or she remains neutral on issues and does not contribute i
the group on the agenda, resolving conflicts and disagreements, and soliciting all ideas.
. Users: The key users of the system under consideration are vital participants in a JAD. They are the only ones w
daily basis.
. Managers: Managers of the work groups who use the system in question provide insight into new organizationa
systems, and support for requirements determined during the JAD.
. Sponsor: As a major undertaking, because of its expense, a JAD must be sponsored by someone at a relatively
executive officer. If the sponsor attends any sessions, it is usually only at the beginning or the end.
. Systems analysts: Members of the systems analysis team attend the JAD, although their actual participation ma
managers, not to run or dominate the process.
. Scribe: The scribe takes notes during the JAD sessions, usually on a personal computer or laptop. .

IS staff: Besides systems analysts, other IS staff, such as programmers, database analysts, IS planners, and data
to learn from the discussion and possibly
to contribute their ideas on the technical feasibility of proposed ideas or on the technical limitations of current sy

Radical Methods for Determining System Requirements

Whether traditional or modern, the methods for determining system requirements that you have read about in thi
regardless of its motivation. Yet, most of what you have learned has traditionally been applied to systems develop
Analysts use system requirements determination to understand current problems and opportunities, as well as wh
current way of doing things has a large impact on the new system. In some organizations, though, management i
These ways may be radically different from how things are done now, but the payoffs may be enormous: Fewe
with customers may improve dramatically; and processes may become much more efficient and effective, all of w
which current methods are replaced with radically new methods is referred to as business process reengineerin

A first step in any BPR effort is to understand what processes need to change, what are the key business process
structured set of measurable activities designed to produce a specific output for a particular customer or mark
processes are focused on some type of organizational outcome such as the creation of a product or the delivery o
focused. In other words, key business processes would include all activities used to design, build, deliver, suppor
BPR, therefore, requires you first to understand those activities that are part of the organization’s key business p
activities to achieve radical improvements in speed, quality, and customer satisfaction. The same techniques you
be applied to discovering and understanding key business processes: interviewing key individuals, observing act
conducting JAD sessions.

Disruptive Technologies
Once key business processes and activities have been identified, information technologies must be applied to imp
suggest that organizations think “inductively” about information technology. Induction is the process of reasoni
managers must learn about the power of new technologies and think of innovative ways to alter the way work is d
which problems are first identified and solutions then formulated.

Hammer and Champy suggest that managers especially consider disruptive technologies when applying deductiv
the breaking of long-held business rules that inhibit organizations from making radical business changes. For
and electronic data interchange (EDI)—an information system that allows companies to link their computers dir
Saturn were one company. Suppliers do not wait until Saturn sends them a purchase order for more parts but sim
shipments as needed. Table below shows several long-held business rules and beliefs that constrain organization
the first rule suggests that information can appear in only one place at a time. However, the advent of distributed
database, has “disrupted” this long-held business belief.
PART-2: Structuring Requirements.

In this lessons, we continue our focus on the systems analysis part of the SDLC, which is highlighted in Figure b

Note the two parts to the analysis phase, determining requirements and structuring requirements. We focus on
diagrams (DFDs). Data-flow diagrams allow you to model how data flow through an information system, the rel
stored at specific locations. Data-flow diagrams also show the processes that change or transform data.
Because data-flow diagrams concentrate on the movement of data between processes, these diagrams are calle
diagram is a graphical tool that allows analysts (and users) to show the flow of data in an information system. T
based. In this lesson, you learn the mechanics of drawing and revising data-flow diagrams, as well as the basic s
to pitfalls. You learn two important concepts related to data-flow diagrams: balancing and decomposition. At t
diagrams as part of the analysis of an information system and as a tool for supporting business process reengine
modeling the logic inside processes, decision tables.

Process Modeling
Process modeling involves graphically representing the processes, or actions, that capture, manipulate, store, an
among components within a system. A common form of a process model is a data-flow diagram (DFD). A data-f
graphic that illustrates the movement of data between external entities and the processes and data stores within a
developed for process modeling, we focus solely on data-flow diagrams because they are useful tools for process
structured analysis techniques used to increase software development productivity. Although not all organization

use each structured analysis technique, collectively, these techniques, like dataflow diagrams, have had a signifi
development process.

Modeling a System’s Process

The analysis team begins the process of structuring requirements with an abundance of information gathered du
structuring, you and the other team members must organize the information into a meaningful representation of
the requirements desired in a replacement system. In addition to modeling the processing elements of an informa
must also model the structure of data within the system. Analysts use both process and data models to establish t
tool, such as a CASE tool, process and data models can also provide the basis for the automatic generation of an

Deliverables and Outcomes

In structured analysis, the primary deliverables from process modeling are a set of coherent, interrelated data-fl
of deliverables that result from studying and documenting a system’s process. First, a context data-flow diagram
are inside and outside the system. Second, data-flow diagrams of the current system specify which people and te
transform data, accepting inputs and producing outputs. The detail of these diagrams allows analysts to understa
convert the current system into its replacement. Third, technology-independent, or logical, data-flow diagrams s
the new system. Finally, entries for all of the objects in all diagrams are included in the project dictionary or CA
This logical progression of deliverables helps you to understand the existing system. You can then reduce this sys
new system should meet its information processing requirements, as they were identified during requirements de
cycle, you and other project team members make decisions on exactly how the new system will deliver these new
Because requirements determination and structuring are often parallel steps, data-flow diagrams evolve from the
replacement systems are better understood.

Even though data-flow diagrams remain popular tools for process modeling and can significantly increase softw
systems development methodologies. Some organizations, such as EDS, have developed their own type of diagra
application development (RAD), do not model processes separately at all. Instead, RAD builds processes—the w
or distributed—into the prototypes created as the core of its development life cycle. However, even if you never f
they remain a part of systems development’s history. DFDs illustrate important concepts about the movement of
depict work flow in an organization. DFDs continue to benefit information systems professionals as tools for bo

Data Flow Diagrams (may be included in Requirements Document) Data Flow Modeling represents the flow of i
take a ‘top-down’ approach, expanding the system description into more and more detail via a series of ‘levels’,

DFDs show how information flows around a system, they:

• Represent a situation from the viewpoint of the data;

• Is a technique to assist analysis of the processes of the system.

Objectives:

• To graphically document boundaries of a system;

• To provide hierarchical breakdown of the system;

• To show movement of information between a system and its environment;

• To document information flows within the system;

• To aid communication between users and developers.

Data-Flow Diagramming Mechanics

A data flow diagram is a logical model of the flow of data through a system that shows how the system’s bounda

A data flow diagram is an excellent tool for summarizing and organizing detailed information about a system’s b
analyst with a logical map of the system. Documenting the system’s boundaries by drawing a context diagram he
visualize alternative high-level logical system designs. The elements of a data flow diagram lead directly into ph
procedures, data flows suggesting composites, and data stores suggesting data entities, files, and databases.

Creating a data flow diagram is a process driven task. Consequently, it is relatively easy to overlook key data ele
verifies the model’s internal consistency, but does not necessarily reveal missing elements. Attempting to balance
(such as CASE software) is at best difficult and can be misleading. Beginners and users often confuse data flow d

A data flow diagram is a logical model that shows the flow of data through a system.

Data-flow diagrams are versatile diagramming tools. With only four symbols, data-flow diagrams can represent
symbols used in DFDs represent data flows, data stores, processes, and sources/sinks (or external entities). The
Gane and Sarson (1979) and is illustrated in Figure below.

A data flow is data that are in motion and moving as a unit from one place in a system to another. A data flow c
check. It could also represent the results of a query to a database, the contents of a printed report, or data on a
composed of many individual pieces of data that are generated at the same time and that flow together to commo

A data store is data at rest. A data store may represent one of many different physical locations for data, includin
notebook. To understand data movement and handling in a system, the physical configuration is not really impor
students, customer orders, or supplier invoices.

A process is the work or actions performed on data so that they are transformed, stored, or distributed. When mo
whether a process is performed manually or by acomputer.
A source/sink is the origin and/or destination of the data. Source/sinks are sometimes referred to as external ent
data or information leave the system and go to some other place. Because sources and sinks are outside the syste
interest to us. In particular, we do not consider the following:

. Interactions that occur between sources and sinks

. What a source or sink does with information or how it operates (i.e., a source or sink is a “black box”)

. How to control or redesign a source or sink because, from the perspective of the system we are studying, the da

source provides are fixed

. How to provide sources and sinks direct access to stored data because, as external agents, they cannot directly
is, processes within the system must receive or distribute data between the system and its environment.

Using Gane and Sarson’s notation,4 four primary symbols are used to create a data flow diagram (Figures abov
(shaded) square. Sources and destinations define the system’s boundaries; each one represents a person, organi
data from the system, or both. A process, or transform, (a round-cornered rectangle) identifies an activity that ch
(an open-ended,
horizontal rectangle) represents data at rest and implies that the data are held (for some logical reason) between
motion. Additionally, Gane and Sarson use thick arrows to show physical or material flows.

Using Yourdon7 and DeMarco’s2 notation, sources and sinks are represented as rectangles, processes as circles
(two parallel horizontal lines). Data flows are shown as arrows. There is no symbol for a material flow.

All About Data Flow Diagrams (DFDs)

This guide provides everything you need to know about data flow diagrams, including definitions, history, and sy
DFD, the difference between a logical and a physical DFD and tips for making a DFD.

What is a data flow diagram?

A data flow diagram (DFD) maps out the flow of information for any process or system. It uses defined symbols
show data inputs, outputs, storage points and the routes between each destination. Data flowcharts can range from
multi-level DFDs that dig progressively deeper into how the data is handled. They can be used to analyze an exis
and charts, a DFD can often visually “say” things that would be hard to explain in words, and they work for both
CEO. That’s why DFDs remain so popular after all these years. While they work well for data flow software and
interactive, real-time or database-oriented software or systems.

History of the DFD

Data flow diagrams were popularized in the late 1970s, arising from the book Structured Design, by computing p
on the “data flow graph” computation models by David Martin and Gerald Estrin. The structured design concept
method took off with it. It became more popular in business circles, as it was applied to business analysis, than in

Also contributing were two related concepts:

Object Oriented Analysis and Design (OOAD), put forth by Yourdon and Peter Coad to analyze and design an ap
Structured Systems Analysis and Design Method (SSADM), a waterfall method to analyze and design informatio
with modern agile approaches such as Scrum and Dynamic Systems Development Method (DSDM.)

Three other experts contributing to this rise in DFD methodology were Tom DeMarco, Chris Gane and Trish Sar
main definers of the symbols and notations used for a data flow diagram.

Symbols and Notations Used in DFDs

Two common systems of symbols are named after their creators:

Yourdon and Coad

Yourdon and DeMarco

Gane and Sarson

One main difference in their symbols is that Yourdon-Coad and Yourdon-DeMarco use circles for processes, wh
sometimes called lozenges. There are other symbol variations in use as well, so the important thing to keep in mi
you use to communicate and collaborate with others.

Using any convention’s DFD rules or guidelines, the symbols depict the four components of data flow diagrams.

External entity: an outside system that sends or receives data, communicating with the system being diagramme
entering or leaving the system. They might be an outside organization or person, a computer system or a business
sinks or actors. They are typically drawn on the edges of the diagram.

Process: any process that changes the data, producing an output. It might perform computations, or sort data bas
short label is used to describe the process, such as “Submit payment.”

Data store: files or repositories that hold information for later use, such as a database table or a membership form

Data flow: the route that data takes between the external entities, processes and data stores. It portrays the interfa
typically labeled with a short data name, like “Billing details.”
Notation Yourdon and Coad Gane and Sarson

External Entity

Process

Data Store

Data Flow

DFD rules and tips ( Conventions )

Each process should have at least one input and an output.

Each data store should have at least one data flow in and one data flow out.

Data stored in a system must go through a process.

All processes in a DFD go to another process or a data store.

Data stored in a system must go through a process.

Legal and illegal data flows --- All data flows must begin and/or end with a process (Figure below). Data canno
between a source/destination and a data store unless they pass through an intermediate process.
Data flow lines
Multiple data flows between two components can be shown by two data flow lines or by a two-headed arrow. Som
the input and output data flows are different and a single two-headed arrow when they are the same. For exampl
updates the data, and then sends the same data elements back to the store calls for a two-headed arrow.
Naming
A process name consists of a verb followed by a noun. By convention, the names of the sources, destinations, and
process names and data flows are shown mixed case.

Numbering
By convention, the processes in a level 1 data flow diagram are numbered 1, 2, 3, and so on. The numbers do no
The sub-processes in an exploded data flow diagram are assigned numbers starting with the parent process’s nu
level 2 processes 4.1, 4.2, 4.3, and so on, while level 2 process 4.3 might be decomposed into level 3 processes 4
Many analysts use the letter D followed by a number to identify the data stores. For example, in an inventory sys
on. Some analysts identify the sources and destinations as well.

Duplicate symbols
Symbols can be repeated if doing so makes the diagram easier to read. For example, duplicating a symbol might
crossing data flows. Duplicate symbols are usually marked in some way; for example, source/destinations might
corner and data stores might be marked with an extra vertical line.

DFD levels and layers: From context diagrams to pseudocode

A data flow diagram can dive into progressively more detail by using levels and layers, zeroing in on a particular
go to even Level 3 or beyond. The necessary level of detail depends on the scope of what you are trying to accom

DFD Level 0 is also called a Context Diagram. It’s a basic overview of the whole system or process being analyz
showing the system as a single high-level process, with its relationship to external entities. It should be easily und
business analysts, data analysts and developers.
DFD Level 1 provides a more detailed breakout of pieces of the Context Level Diagram. You will highlight the m
the high-level process of the Context Diagram into its subprocesses.
DFD Level 2 then goes one step deeper into parts of Level 1. It may require more text to reach the necessary leve
Progression to Levels 3, 4 and beyond is possible, but going beyond Level 3 is uncommon. Doing so can create c
or model effectively.

Using DFD layers, the cascading levels can be nested directly in the diagram, providing a cleaner look with easy

By becoming sufficiently detailed in the DFD, developers and designers can use it to write pseudocode, which is
language. Pseudocode facilitates the development of the actual code.

Examples of how DFDs can be used

Data flow diagrams are well suited for analysis or modeling of various types of systems in different fields.

DFD in software engineering: This is where data flow diagrams got their main start in the 1970s. DFDs can pro
which more research is done up front to get to coding.

DFD in business analysis: Business analysts use DFDs to analyze existing systems and find inefficiencies. Diag
be missed or not fully understood.

DFD in business process re-engineering: DFDs can be used to model a better, more efficient flow of data thro
help organizations cut operational costs, improve customer service and better compete in the market.

DFD in agile development: DFDs can be used to visualize and understand business and technical requirements
tool for communication and collaboration to focus rapid development.

DFD in system structures: Any system or process can be analyzed in progressive detail to improve it, on both a

DFD vs. Unified Modeling Language (UML)

While a DFD illustrates how data flows through a system, UML is a modeling language used in Object Oriented
may still provide a good starting point, but when actually developing the system, developers may turn to UML di
achieve the required specificity.

Logical DFD vs. Physical DFD

These are the two categories of a data flow diagram. A Logical DFD visualizes the data flow that is essential for
information needed, not on how the system works or is proposed to work. However, a Physical DFD shows how
For example, in a Logical DFD, the processes would be business activities, while in a Physical DFD, the process
Design
The design phase decides how the system will operate, in terms of the hardware, software, and network infrastru
programs, databases, and files that will be needed. Although most of the strategic decisions about the system wer
analysis phase, the steps in the design phase determine exactly how the system will operate.

The design phase has four steps:

1. The design strategy is first developed. It clarifies whether the system will be developed by the company’s own
another firm (usually a consulting firm), or whether the company will buy an
existing software package.
2. This leads to the development of the basic architecture design for the system,
which describes the hardware, software, and network infrastructure to be used. In
most cases, the system will add or change the infrastructure that already exists
in the organization. The interface design specifies how the users will move through
the system (e.g., navigation methods such as menus and on-screen buttons) and
the forms and reports that the system will use.
3. The database and file specifications are developed. These define exactly what data
will be stored and where they will be stored.
4. The analyst team develops the program design, which defines the programs that
need to be written and exactly what each program will do.

This collection of deliverables (architecture design, interface design, database and file specifications, and progra
programming team for implementation. At the end of the design phase, the feasibility analysis

and project plan are reexamined and revised, and another decision is made by the project sponsor and approval
continue

The system design phase develops the technical blueprints and specifications required to Implement the final solu
Implement required databases, programs, user interfaces, and networks for the information system. In the case w
it, the blueprints specify how the purchased software wlll he Integrated Into the business and with other Informa

The design phase decides how the system will operate. This collection of deliverables is the system specificatio
implementation. At the end of the design phase, the feasibility analysis and project plan are reexamined and r
and approval committee about whether to terminate the project or continue.

CHECKLIST for DESIGN STAGE

Implementation
The final phase in the SDLC is the implementation phase, during which the system is actually built (or purchased
phase that usually gets the most attention, because for most systems it is the longest and most expensive single pa

This phase has three steps:

1. System construction is the first step. The system is built and tested to ensure it performs as designed. Because t
critical steps in implementation. Most organizations give more time and attention to testing than to writing the p
2. The system is installed. Installation is the process by which the old system is turned off and the new one is turn
the new system immediately replaces the old system), a parallel conversion approach (in which both the old and
that there are no bugs in the new system), or a phased conversion strategy (in which the new system is installed i
gradually installed in others). One of the most important aspects of conversion is the development of a training p
manage the changes caused by the new system.
3. The analyst team establishes a support plan for the system. This plan usually includes a formal or informal po
identifying major and minor changes needed for the system.

System implementatlon constructs the new lnfonnation system and puts lt Into operation. It is during 'system Imp
lnstalled and tested. Any purchased applicatlon software and databases are Installed and configured. And any cu
are constructed using the technicalblueprints and specifications developed during system design.

The final phase in the SDLC is the implementation phase, during which the system is actually built (or purcha
of implementation, the final system is put into operation and supported and maintained.

CHECKLIST for IMPLEMENTATION STAGE

SDLC - SUMMARY TABLE

For now, there are two important points to understand about the SDLC. First, you should get a general sense of
of the techniques that produce certain deliverables. Second, it is important to understand that the SDLC is a proc
analysis phase provide a general idea of the shape of the new system. These deliverables are used as input to the
deliverables that describes in much more detailed terms exactly how the system will be built. These deliverables
actual system. Each phase refines and elaborates on the work done previously.

CONCEPTS

Consumer electronics is a very competitive business. What might be the success story of the year one year is a
forgotten item two years later. Rapid product commoditization makes the consumer electronic marketplace very
competitive. Getting the right products to market at the right time with the right components is an ongoing challe
companies.

Questions
1. What external data analysis should a consumer
electronics company use to determine marketplace
needs and its abilities to compete effectively in a
marketplace?
2. Staying one step ahead of competitors requires a
corporate strategy and the support of information
systems. How can information systems and systems
analysts contribute to an aggressive corporate strategy?

Project Identification and Initiation

Projects are identified when someone recognizes a business need that can be satisfied through the use of informa
supporting a new marketing campaign, reaching out to a new type of customer, or improving interactions with su
organization creates and assesses the original goals and expectations for a new system. The first step in the proc
developing a system request that provides basic information about the proposed system. Next, the analysts perfor
economic, and organizational feasibility of the system.

The project sponsor is someone who recognizes the strong business need for a system and has an interest in seein
SDLC to make sure that the project is moving in the right direction from the perspective of the business. The pro
system. Usually, the sponsor of the project is from a business function such as marketing, accounting, or finance
cosponsor a project.

Once the project sponsor identifies a project that meets an important business need and he or she can identify th
is time to formally initiate the project. In most organizations, project initiation begins with a technique called a s

System Request
The business value for an information system is identified and then described in a system request. This form cont
business requirements, and business value of the information system, along with any other issues or constraints t
to an approval committee who determines whether the project would be a wise investment of the organization’s t

A system request is a document that describes the business reasons for building a system and the value that the s
completes this form as part of a formal system project selection process within the organization. Most system req
business requirements, business value, and special issues. (See
Figure below.) The sponsor describes the person who will serve as the primary contact for the project, and the b

EXAMPLE -------------->
The business requirements of the project refer to the business capabilities that the system will need to have, and t
the organization should expect from the system. Special issues are included on the document as a catchall catego
in assessing the project. For example, the project may need to be completed by a specific deadline. Project teams
affect the outcome of the system.
The completed system request is submitted to the approval committee for consideration. This approval committee
regularly to make information systems decisions, a senior executive who has control of organizational resources
business resources. The committee reviews the system request
and makes an initial determination, based on the information provided, of whether to investigate the proposed pr
analysis.

Feasibility Analysis

Once the need for the system and its business requirements have been defined, the approval committee may autho
case to better understand the opportunities and limitations associated with the proposed project. Feasibility anal
proceed with a project. Feasibility analysis also identifies the important risks associated with the project that mu
request, each organization has its own process and format for the feasibility analysis, but most include technique
feasibility, economic feasibility, and organizational feasibility. The results of these techniques are combined into
committee at the end of project initiation.
A feasibility analysis is then used to provide more detail about the risks associated with the proposed system, and
organizational feasibilities. The technical feasibility focuses on whether the system can be built, by examining th
with the application, familiarity with the technology, project size, and compatibility with existing systems. The ec
built. It includes a cost–benefit analysis of development costs, operational costs, tangible benefits, and intangible
feasibility analysis assesses how well the system will be accepted by its users and incorporated into the ongoing
the project and a stakeholder analysis can be used to assess this feasibility dimension.

Technical Feasibility
The first technique in the feasibility analysis is to assess the technical feasibility of the project, the extent to whic
installed by the IT group. Technical feasibility analysis is, in essence, a technical risk analysis that strives to ans
Familiarity with the technology is another important source of technical risk. When a system will use technology
is a greater chance that problems will occur and delays will be incurred because of the need to learn how to use
Project size is an important consideration, whether measured as the number of people on the development team,
number of distinct features in the system. Larger projects present more risk, because they are more complicated
important system requirements will be overlooked or

misunderstood. The extent to which the project is highly integrated with other systems (which is typical of large s
increased when many systems must work together.
Finally, project teams need to consider the compatibility of the new system with the technology that already exist
they are built in organizations that have numerous systems already in place. New technology and applications ne
many reasons. They may rely on data from existing systems, they may produce data that feed other applications,
communications infrastructure. A new CRM system, for example, has little value if it does not use customer data
marketing applications, and customer service systems.
The assessment of a project’s technical feasibility is not cut and dried, because in many cases, some interpretatio
does a project need to grow before it becomes less feasible?). One approach is to compare the project under con
the organization. Another option is to consult with experienced IT professionals in the organization or with exter
a project is feasible from a technical perspective.

Economic Feasibility
The second element of a feasibility analysis is to perform an economic feasibility
analysis (also called a cost–benefit analysis) that identifies the financial risk associated with the project. This att
system?” Economic feasibility is determined by identifying costs and benefits associated with the system, assigni
and return on investment for the project. The more expensive the project, the more
rigorous and detailed the analysis should be. Figure below lists the steps to perform a
cost–benefit analysis; each step will be described in the upcoming sections.
Identify Costs and Benefits The first task when developing an economic feasibility
analysis is to identify the kinds of costs and benefits the system will have and list
them along the left-hand column of a spreadsheet. Figure below lists examples of costs
and benefits that may be included.
The costs and benefits can be broken down into four categories:

(1) development costs, (2) operational costs, (3) tangible benefits, and (4) intangibles.

Development costs are those tangible expenses that are incurred during the creation of the system, such as sal
consultant fees, training, and office space and equipment. Development costs are usually thought of as one-tim
required to operate the system, such as the salaries for operations staff, software licensing fees, equipment upg
are usually thought of as ongoing costs. Tangible benefits include revenue that the system enables the organizati
may enable the organization to avoid certain costs, leading to another type of tangible benefit: cost savings. For
staff, lower salary costs result. Similarly, a reduction in required inventory levels due to the new system produ
in costs is a tangible benefit of the new system.
Of course, a project also can affect the organization’s bottom line by reaping intangible benefits or incurring int
to incorporate into the economic feasibility analysis because they are based on intuition and belief rather than o
spreadsheet along with the tangible items.

Assign Values to Costs and Benefits Once the types of costs and benefits have been identified, you will need to a
seem impossible—How can someone quantify costs and benefits that haven’t happened yet? And how can those p
difficult, you have to do the best you can to come up with reasonable numbers for all of the costs and benefits. O
decision about whether or not to move ahead with the project.
The most effective strategy for estimating costs and benefits is to rely on the people who have the best understand
to the technology or the project itself can be provided by the company’s IT group or external consultants, and bu
business (e.g., sales projections, order levels). The company also can consider past projects, industry reports, an
be a bit less accurate. Likely, all of the estimates will be revised as the project proceeds

Figure below shows costs and benefits along with assigned dollar values. In this example, for simplicity, all dev
2009, and all benefits and operational costs are assumed to begin when the system is implemented at the start of
service intangible benefit has been quantified, based on a decrease in customer complaint phone calls. The intan
currently offer was not quantified, but it was listed so that the approval committee will consider the benefit when

Determine Cash Flow A formal cost–benefit analysis usually contains costs and benefits over a selected number
time. (See Figure Above.) With this cash flow method, the years are listed across the top of the spreadsheet to re
entered in the appropriate cells within the spreadsheet’s body. Sometimes, fixed amounts are entered into the col
customer complaint calls, inventory costs, hardware, and software for all four years. Often, amounts are augme
business improvements, as shown by the 6% increase that is added to the sales numbers in the sample spreadshe
rate each year. Finally, totals are added to determine what the overall benefits will be, and the higher the overal
economic feasibility
Determine Return on Investment The return on investment (ROI) is a calculation that measures the average rat
high ROI suggests that the project’s benefits far outweigh the project’s cost. ROI is a simple calculation that divi
the total costs.. Although ROI is commonly used in practice, it suffers from several important limitations and sho
Figure Above includes the ROI calculation for our example project.

Determine Break-Even Point Another common approach to measuring a project’s worth is the break-even point
defined as the number of years it takes a firm to recover its original investment in the project from net cash flows
“pay back” the initial investment during the fourth year; this is the year in which the cumulative cash flow figure
year’s cash flow and its cumulative cash flow by that year’s cash flow determines how far into the year the break
The break-even point is easy to calculate and understand and does give an indication of a project’s liquidity or t
Also, projects that produce higher returns early in the project’s life are thought to be less risky, since we can ant
long-term events. The break-even point does ignore cash flows that occur after the break-even point has been rea

Determine Net Present Value The simple cash flow method, return on investment, and break-even point, as show
the time value of money. In these analyses, the timing of cash flows is ignored. A dollar in year 3 of the project is
(NPV) is used to compare the present value of all cash
inflows and outflows for the project in today’s dollar terms. The key to understanding present values is to recogn
receive some rate of return on your investment. Therefore, a dollar received in the future is worth less than a dol
Appendix 1A shows the present value of a dollar received in the future for different numbers of years and rates o
but instead gives you that dollar in three years—you’ve been had!
Given a 10% rate of return on an investment, you’ll be receiving the equivalent of 75 cents in today’s terms.
In Figure Below, the present value of the costs and benefits has been calculated and added to our example sprea
difference between the total present value of the benefits and the total present value of the costs. As long as the N
economically feasible.
Organizational Feasibility
The final technique used for feasibility analysis is to assess the organizational feasibility of the system: how well
incorporated into the ongoing operations of the organization. There are many organizational factors that can ha
that organizational feasibility can be the most difficult feasibility dimension to assess. In essence, an organizatio
we build it, will they come?”

One way to assess the organizational feasibility of the project is to understand how well the goals of the project a
between the project and business strategy—the greater the alignment, the less risky the project will be, from an o
marketing department has decided to become more customer
focused, then a CRM project that produces integrated customer information would have strong strategic alignme
department initiates them, because there is little or no alignment with business-unit or organizational strategies.
A second way to assess organizational feasibility is to conduct a stakeholder analysis. 5 A stakeholder is a perso
by) a new system. In general, the most important stakeholders in the introduction of a new system are the project
(see Figure Below), but systems sometimes affect other stakeholders as well. For example, the IS department can
be changed significantly after the system’s implementation. One key stakeholder—outside of the champion, users
Internet Explorer as a standard part of Windows was the U.S. Department of Justice.

Stakeholders for Organizational Feasibility

The champion is a high-level executive and is usually, but not always, the project sponsor who created the system
time and resources (e.g., money) and by giving political support within the organization by communicating the im
makers. More than one champion is preferable because if
the champion leaves the organization, the support could leave as well.

While champions provide day-to-day support for the system, organizational management also needs to support th
the organization the belief that the system will make a valuable contribution and that necessary resources will be
people in the organization to use the system and to accept the many changes that the system will likely create.
A third important set of stakeholders is the system users who ultimately will use the system once it has been insta
with users at the beginning of a project and then disappears until after the system is created. In this situation, rar
of those who are supposed to use it, because
needs change and users become savvier as the project progresses. User participation should be promoted throug
system will be accepted and used, by getting users actively involved in the development of the system (e.g., perfor

The final feasibility study helps organizations make wiser investments regarding IS because it forces project team
factors that can affect their projects. It protects IT professionals from criticism by keeping the business units edu
decision-making process. Remember—the feasibility study should be revised several times during the project at p
the system (e.g., before the design begins). The final feasibility study can be used to support and explain the criti

Applying the Concepts at Tune Source

The steering committee met and placed the digital music download project high on its list of projects. The next s
analysis. Figure Below presents the executive summary page of the feasibility study: The report itself was about
supporting documentation. As shown in Figure Below, the project is somewhat risky from a technical perspective
application and the technology. One solution may be to hire a consultant to work with the IT department and to o
The economic feasibility analysis includes the assumptions that Carly made in the system request. The summary
has been included in Appendix 1B. Development costs are expected to be about $280,000. This is a very rough es
the amount of time it will take to design and program the system. Nonetheless, the digital music download system
The organizational feasibility is presented in Figure Below. There is a strong champion, well placed in the organ
business or functional side of the company, not the IS department, and support for the project among the senior m
Additional stakeholders in the project are the management team responsible for the operations of the traditional
supportive, given the added service that they now can offer. Carly and Jason need to make sure that they are incl
appropriately incorporate it into their business processes.