Unit 03

3.1CONSERVATION OF DECISION MAKERS BEHAVIOUR AND OFFICE

ENVIORNMENT
Observing a Decision Maker’s Behavior

Observing decision makers, their physical environment, and their interaction with their physical,
ergonomic environment is an important unobtrusive method for the systems analyst. Through
observing activities of decision makers, the analyst seeks to gain insight about what is actually done,
not just what is documented or explained. In addition, through observation of the decision maker,
the analyst attempts to see firsthand the relationships that exist between decision makers and other
organizational members. Observation of decision makers’ interactions with technologies can also
reveal important clues regarding HCI concerns, such as how well the system fits with the user.

Observing a Typical Manager’s Decision-Making Activities

Managers’ workdays have been described as a series of interruptions punctuated by short bursts of
work. In other words, pinning down what a manager “does” is a slippery proposition even under the
best of circumstances. For the systems analyst to grasp adequately how managers characterize their
work, interactive interviews and questionnaires are used. Observation, however, allows the analyst
to see firsthand how managers gather, process, share, and use information and technology to get
work done.

Although it is possible to describe and document how managers make decisions using boxes and
arrows, we are primarily describing humans and their activities. Therefore, we suggest that systems
analysts use a more humanistic approach to describe what managers do. This method is called the
analyst’s playscript. With this technique the “actor” is the decision maker who is observed “acting”
or making decisions. In setting up a playscript, the actor is listed in the left-hand column and all his or
her actions are listed in the right-hand column, as shown in Figure 5.7. All activities are recorded
with action verbs, so that a decision maker would be described as “talking,” “sampling,”
“corresponding,” and “deciding.”

Playscript is an organized and systematic approach that demands the analyst be able to understand
and articulate the action taken by each observed decision maker. This approach eventually assists
the systems analyst in determining what information is required for major or frequent decisions
made by the observed people. For instance, from the quality assurance manager example in the
playscript, it becomes clear that even though this decision maker is on the middle management
level, he or she still requires a fair amount of external information to perform the required activities
of this specific job.

Observing the Physical Environment

Observing the activities of decision makers is just one way to assess their information requirements.
Observing the physical environment where decision makers work also reveals much about their
human information requirements. Most often, such observing means systematically examining the
offices of decision makers, because offices constitute their primary workplace. Decision makers
influence and are in turn influenced by their physical environments and by their interactions with
the technology that takes place there. Many HCI concerns can be identified through structured
observation and confirmed with other techniques, such as interviews or questionnaires.

Structured Observation of the Environment (STROBE)

Film critics sometimes use a structured form of criticism called mise-en-scène analysis to
systematically assess what is in a single shot of the film. They look at editing, camera angle, set
decor, and the actors and their costumes to find out how they are shaping the meaning of the film as
intended by the director. Sometimes the film’s mise-en-scène will contradict what is said in the
dialogue. For information requirements analysis, the systems analyst can take on a role similar to
that of the film critic. It often is possible to observe the particulars of the surroundings that will
confirm or negate the organizational narrative (also called “stories” or “dialogue”) that is found
through interviews or questionnaires.

The method for Structured Observation of the Environment is referred to as STROBE. Successful
application of STROBE requires that an analyst explicitly observe seven concrete elements commonly
found in offices. The seven observable elements and some key questions that may arise are listed in
the table shown below. These elements can reveal much about the way a decision maker gathers,
processes, stores, and shares information, as well as about the decision maker’s credibility in the
workplace.

Observable Element Questions an Analyst Might Investigate

Office location Who has the corner office? Are the key decision makers
dispersed over separate floors?

Desk placement Does the placement of the desk encourage

communication? Does the placement demonstrate
power?

Stationary equipment Does the decision maker prefer to gather and store
information personally? Is the storage area large or
small?

Props Is there evidence that the decision maker uses a PC,

smartphone, or tablet computer in the office?

External information sources Does the decision maker get much information from
Observable Element Questions an Analyst Might Investigate

external sources such as trade journals or the Web?

Office lighting and color Is the lighting set up to do detailed work or more
appropriate for casual communication? Are the colors
warm and inviting?

Clothing worn by decision Does the decision maker show authority by wearing
makers conservative suits? Are employees required to wear
uniforms?

OFFICE LOCATION. One of the first elements a systems analyst should observe is the location of a
particular decision maker’s office with respect to other offices. Accessible offices tend to increase
interaction frequency and informal messages, whereas inaccessible offices tend to decrease the
interaction frequency and increase task-oriented messages. Offices distributed along the perimeter
of the building usually result in a report or memo being held up in one of the offices, whereas office
clusters encourage information sharing. It is also likely that the people whose offices are separated
from others may tend to view the organization differently and so drift further apart from other
organization members in their objectives.

DESK PLACEMENT. Placement of a desk in the office can provide clues to the exercise of power by
the decision maker. Executives who enclose a visitor in a tight space with the visitor’s back to the
wall while allowing themselves a lot of room put themselves into the strongest possible power
position. An executive who positions his or her desk facing the wall with a chair at the side for a
visitor is probably encouraging participation and equal exchanges. The systems analyst should notice
the arrangement of the office furniture and in particular the placement of the desk. Figure illustrated
below shows an example of desk placement as well as many of the other elements of STROBE, such
as props, stationary office equipment, lighting, color, and external sources of information.
 Observe a decision maker’s office for clues
concerning his or her personal storage, processing, and sharing of information.

STATIONARY OFFICE EQUIPMENT. File cabinets, bookshelves, and other large equipment for storing
items are all included in the category of stationary office equipment. If there is no such equipment, it
is likely the decision maker stores very few items of information personally. If there is an abundance
of such equipment, it is presumed the decision maker stores and values much information.

PROPS. The term props (an abbreviation of the theatre/film term properties) refers to all the small
equipment used to process information, including smartphones, calculators, PCs, pens, pencils, and
rulers. The presence of handhelds, calculators, and PCs suggests that a decision maker who
possesses such equipment is more likely to use it personally than one who must leave the room to
use it.

EXTERNAL INFORMATION SOURCES. A systems analyst needs to know what type of information is
used by the decision maker. Observation of the type of publications stored in the office can reveal
whether the decision maker is looking for external information (found in trade journals, news items
about other companies in the industry, and so on) or relies more on internal information (company
reports, intraoffice correspondence, policy handbooks). The analyst should also observe whether the
decision maker prefers to get external information from the Web.

OFFICE LIGHTING AND COLOR. Lighting and color play an important role in how a decision maker
gathers information. An office lighted with warm, incandescent lighting indicates a tendency toward
more personal communication. An executive in a warmly lit office will gather more information
informally, whereas another organizational member working in a brightly lit, brightly colored office
may gather information through more formal memos and official reports.

CLOTHING WORN BY DECISION MAKERS. Much has been written about the clothing worn by
executives and others in authority. The systems analyst can gain an understanding of the credibility
exhibited by managers in the organization by observing the clothing they wear on the job. The two-
piece suit for a man or the skirted suit for a woman represents the maximum authority, according to
some researchers who have studied perceptions of executive appearance.

Casual dressing by leaders tends to open the door for more participative decision making, but such
attire often results in some loss of credibility in the organization if the predominant culture values
traditional, conservative clothing. Through the use of STROBE, the systems analyst can gain a better
understanding of how managers gather, process, store, and use information. A summary of the
 characteristics exhibited by decision makers and the corresponding observable elements is shown in
the table illustrated below.

Characteristics of Decision Makers Corresponding Elements in the Physical

Environment

Gathers information informally Warm, incandescent lighting and colors

Seeks extraorganizational information Trade journals present in office

Processes data personally PCs, or tablet computers present in office

Stores information personally Equipment/files present in office

Exercises power in decision making Desk placed for power

Exhibits credibility in decision making Wears authoritative clothing

Shares information with others Office easily accessible

Applying Strobe

One way to implement STROBE is through the use of an anecdotal checklist with meaningful
shorthand symbols. This approach to STROBE was useful in ascertaining the information
requirements for four key decision makers in a franchise clothing store.

As shown in the last figure in this page, five shorthand symbols were used by the systems analysts to
evaluate how observation of the STROBE elements compared with the organizational narrative
generated through interviews. The five symbols are as follows:

1. A check mark means the narrative is confirmed.

2. An “X” means the narrative is reversed.

3. An oval or eye-shaped symbol serves as a cue for the systems analyst to look further.
4. A square means observation of the STROBE elements modifies the narrative.

5. A circle means the narrative is supplemented by what is observed.

When STROBE is implemented in this manner, the first step is to write down key organizational
themes growing out of interviews. Then the elements of STROBE are observed and recorded. When
narrative and observations are then compared, one of the five appropriate symbols is used to
characterize the relationship. The analyst thus creates a table that first documents and then aids in
the analysis of observations.

3.2PROTOTYPING
Prototyping is defined as the process of developing a working replication of a product or system
that has to be engineered. It offers a small scale facsimile of the end product and is used for
obtaining customer feedback as described below: 
 

The Prototyping Model is one of the most popularly used Software Development Life Cycle Models
(SDLC models). This model is used when the customers do not know the exact project
requirements beforehand. In this model, a prototype of the end product is first developed, tested
and refined as per customer feedback repeatedly till a final acceptable prototype is achieved
which forms the basis for developing the final product. 
In this process model, the system is partially implemented before or during the analysis phase
thereby giving the customers an opportunity to see the product early in the life cycle. The process
starts by interviewing the customers and developing the incomplete high-level paper model. This
document is used to build the initial prototype supporting only the basic functionality as desired
by the customer. Once the customer figures out the problems, the prototype is further refined to
eliminate them. The process continues until the user approves the prototype and finds the
working model to be satisfactory. 
There are four types of models available: 
 
A) Rapid Throwaway Prototyping – 
This technique offers a useful method of exploring ideas and getting customer feedback for each
of them. In this method, a developed prototype need not necessarily be a part of the ultimately
accepted prototype. Customer feedback helps in preventing unnecessary design faults and hence,
the final prototype developed is of better quality. 
 
B) Evolutionary Prototyping – 
In this method, the prototype developed initially is incrementally refined on the basis of customer
feedback till it finally gets accepted. In comparison to Rapid Throwaway Prototyping, it offers a
better approach which saves time as well as effort. This is because developing a prototype from
scratch for every iteration of the process can sometimes be very frustrating for the developers.  
 
C) Incremental Prototyping – In this type of incremental Prototyping, the final expected product is
broken into different small pieces of prototypes and being developed individually. In the end,
when all individual pieces are properly developed, then the different prototypes are collectively
merged into a single final product in their predefined order. It’s a very efficient approach that
reduces the complexity of the development process, where the goal is divided into sub-parts and
each sub-part is developed individually. The time interval between the project’s beginning and
final delivery is substantially reduced because all parts of the system are prototyped and tested
simultaneously. Of course, there might be the possibility that the pieces just do not fit together
due to some lack of ness in the development phase – this can only be fixed by careful and
complete plotting of the entire system before prototyping starts.
D) Extreme Prototyping – This method is mainly used for web development. It is consists of three
sequential independent phases:
D.1) In this phase a basic prototype with all the existing static pages are presented in the HTML
format.
D.2)  In the 2nd phase, Functional screens are made with a simulated data process using a
prototype services layer.
D.3) This is the final step where all the services are implemented and associated with the final
prototype.
This Extreme Prototyping method makes the project cycling and delivery robust and fast, and
keeps the entire developer team focus centralized on products deliveries rather than discovering
all possible needs and specifications and adding unnecessitated features.
 

Advantages – 
 
 The customers get to see the partial product early in the life cycle. This ensures a greater level
of customer satisfaction and comfort.
 New requirements can be easily accommodated as there is scope for refinement.
 Missing functionalities can be easily figured out.
  Errors can be detected much earlier thereby saving a lot of effort and cost, besides enhancing
the quality of the software.
 The developed prototype can be reused by the developer for more complicated projects in the
future. 
 
 Flexibility in design.
Disadvantages – 
 
 Costly w.r.t time as well as money.
 There may be too much variation in requirements each time the prototype is evaluated by the
customer.
 Poor Documentation due to continuously changing customer requirements.
 It is very difficult for developers to accommodate all the changes demanded by the customer.
 There is uncertainty in determining the number of iterations that would be required before
the prototype is finally accepted by the customer.
 After seeing an early prototype, the customers sometimes demand the actual product to be
delivered soon.
 Developers in a hurry to build prototypes may end up with sub-optimal solutions.
 The customer might lose interest in the product if he/she is not satisfied with the initial
prototype.
Use – 
The Prototyping Model should be used when the requirements of the product are not clearly
understood or are unstable. It can also be used if requirements are changing quickly. This model
can be successfully used for developing user interfaces, high technology software-intensive
systems, and systems with complex algorithms and interfaces. It is also a very good choice to
demonstrate the technical feasibility of the product. 
3.3Users’ Reaction in Prototyping
The users’ role in prototyping can be summed up in two words: honest involvement. Without user
involvement there is little reason to prototype. The precise behaviors necessary for interacting with
a prototype can vary, but it is clear that the user is pivotal to the prototyping process. Realizing the
importance of the user to the success of the process, the members of the systems analysis team
must encourage and welcome input and guard against their own natural resistance to changing the
prototype.

There are three main ways a user can be of help in prototyping:

1. Experimenting with the prototype.

2. Giving open reactions to the prototype.
3. Suggesting additions to or deletions from the prototype.

Users should be free to experiment with the prototype. In contrast to a mere list of systems
features, the prototype allows users the reality of hands-on interaction. Mounting a prototype on an
interactive Web site is one way to facilitate this interaction.

Another aspect of the users’ role in prototyping requires that they give open reactions to the
prototype. Analysts need to be present at least part of the time when experimentation is occurring.
They can then observe users’ interactions with the system, and they are bound to see interactions
they never planned. A filled-in form for observing user experimentation with the prototype is shown
in the figure illustrated below. Some of the variables you should observe include user reactions to
 the prototype, user suggestions for changing or expanding the prototype, user innovations for using
the system in completely new ways, and any revision plans for the prototype that aid in setting
priorities.

An important step in prototyping is to properly record user reactions, user suggestions, innovations,
and revision plans.
A third aspect of the users’ role in prototyping is their willingness to suggest additions to or deletions
from the features being tried. The analyst’s role is to elicit such suggestions by assuring users that
the feedback they provide is taken seriously, by observing users as they interact with the system,
and by conducting short, specific interviews with users concerning their experiences with the
prototype. Although users will be asked to articulate suggestions and innovations for the prototype,
in the end it is the analyst’s responsibility to weigh this feedback and translate it into workable
changes where necessary. To facilitate the prototyping process, the analyst must clearly
communicate the purposes of prototyping to users, along with the idea that prototyping is valuable
only when users are meaningfully involved.

3.5Developing a Prototype:
Prototyping is a superb way to elicit feedback about the proposed system and about how readily it is
fulfilling the information needs of its users, as depicted in the figure illustrated below. The first step
of prototyping is to estimate the costs involved in building a module of the system. If costs of
programmers’ and analysts’ time as well as equipment costs are within the budget, building of the
prototype can proceed. Prototyping is an excellent way to facilitate the integration of the
information system into the larger system and culture of the organization.

Analysts should modify their original screen

designs based on user reactions to the prototype.

Guidelines for Developing a Prototype

Once the decision to prototype has been made, four main guidelines must be observed when
integrating prototyping into the requirements determination phase of the SDLC:

1. Work in manageable modules.

2. Build the prototype rapidly.
3. Modify the prototype in successive iterations.
4. Stress the user interface.

As you can see, the guidelines suggest ways of proceeding with the prototype that are necessarily
interrelated. Each guideline is explained in the following subsections.

Working in manageable modules

When prototyping some of the features of a system into a workable model, it is imperative that the
analyst work in manageable modules. One distinct advantage of prototyping is that it is not
necessary or desirable to build an entire working system for prototype purposes.

A manageable module is one that allows users to interact with its key features but can be built
separately from other system modules. Module features that are deemed less important are
purposely left out of the initial prototype. As you will see later in this chapter, this is very similar to
the agile approach that emphasizes small releases.

Building the prototype rapidly

Speed is essential to the successful prototyping of an information system. Recall that one complaint
voiced against following the traditional SDLC is that the interval between requirements
determination and delivery of a complete system is far too long to address evolving user needs
effectively.

Analysts can use prototyping to shorten this gap by using traditional information-gathering
techniques to pinpoint salient information requirements, and then quickly make decisions that bring
forth a working model. In effect the user sees and uses the system very early in the SDLC instead of
waiting for a finished system to gain hands-on experience.

Putting together an operational prototype both rapidly and early in the SDLC allows the analyst to
gain valuable insight into how the remainder of the project should go. By showing users very early in
the process how parts of the system actually perform, rapid prototyping guards against
overcommitting resources to a project that may eventually become unworkable. Later, when RAD is
discussed, you again see the importance of rapid systems building. In addition, agile modeling also
builds on the practice of quick turnaround times.

Modifying the prototype

A third guideline for developing the prototype is that its construction must support modifications.
Making the prototype modifiable means creating it in modules that are not highly interdependent. If
this guideline is observed, less resistance is encountered when modifications in the prototype are
necessary.

The prototype is generally modified several times, going through several iterations. Changes in the
prototype should move the system closer to what users say is important. Each modification
necessitates another evaluation by users.
 The prototype is not a finished system. Entering the prototyping phase with the idea that the
prototype will require modification is a helpful attitude that demonstrates to users how necessary
their feedback is if the system is to improve.

Stressing the user interface

The user’s interface with the prototype (and eventually the system) is very important. Because what
you are really trying to achieve with the prototype is to get users to further articulate their
information requirements, they must be able to interact easily with the system’s prototype. They
should be able to see how the prototype will enable them to accomplish their tasks. For many users
the interface is the system. It should not be a stumbling block.

Although many aspects of the system will remain undeveloped in the prototype, the user interface
must be well developed enough to enable users to pick up the system quickly and not be put off.
Online, interactive systems using GUI interfaces are ideally suited to prototypes. Chapter 14
describes in detail the considerations that are important in designing HCI.

3.6Data Flow Approach to Requirements

When systems analysts attempt to understand the information requirements of users, they must be
able to conceptualize how data move through the organization, the processes or transformation that
the data undergo, and what the outputs are. Although interviews and the investigation of hard data
provide a verbal narrative of the system, a visual depiction can crystallize this information for users
and analysts in a useful way.

Through a structured analysis technique called data flow diagrams (DFDs), the systems analyst can
put together a graphical representation of data processes throughout the organization. By using
combinations of only four symbols, the systems analyst can create a pictorial depiction of processes
that will eventually provide solid system documentation.

Advantages of the Data Flow Approach

The data flow approach has four chief advantages over narrative explanations of the way data move
through the system:

1. Freedom from committing to the technical implementation of the system too early.
2. Further understanding of the interrelatedness of systems and subsystems.
3. Communicating current system knowledge to users through data flow diagrams.
4. Analysis of a proposed system to determine if the necessary data and processes have been defined.

Perhaps the biggest advantage lies in the conceptual freedom found in the use of the four symbols.
None of the symbols specifies the physical aspects of implementation. DFDs emphasize the
processing of data or the transforming of data as they move through a variety of processes. In logical
DFDs, there is no distinction between manual or automated processes. Neither are the processes
graphically depicted in chronological order. Rather, processes are eventually grouped together if
further analysis dictates that it makes sense to do so. Manual processes are put together, and
automated processes can also be paired with each other. This concept, called partitioning, is taken
up in a later section.
 Conventions Used in Data Flow Diagrams

Four basic symbols are used to chart data movement on data flow diagrams: a double square, an
arrow, a rectangle with rounded corners, and an open-ended rectangle (closed on the left side and
open ended on the right), as shown in the figure illustrated below. An entire system and numerous
subsystems can be depicted graphically with these four symbols in combination.

The four basic symbols used in data flow

diagrams, their meanings, and examples.
a) The double square is used to depict an external entity (another department, a business, a person,
or a machine) that can send data to or receive data from the system. The external entity, or just
entity, is also called a source or destination of data, and it is considered to be external to the system
being described. Each entity is labeled with an appropriate name.Although it interacts with the
system, it is considered as outside the boundaries of the system. Entities should be named with a
noun. The same entity may be used more than once on a given data flow diagram to avoid crossing
data flow lines.

b) The arrow shows movement of data from one point to another, with the head of the arrow
pointing toward the data’s destination. Data flows occurring simultaneously can be depicted doing
just that through the use of parallel arrows. Because an arrow represents data about a person, place,
or thing, it too should be described with a noun.

c) A rectangle with rounded corners is used to show the occurrence of a transforming process.
Processes always denote a change in or transformation of data; hence, the data flow leaving a
process is always labeled differently than the one entering it. Processes represent work being
performed in the system and should be named using one of the following formats. A clear name
makes it easier to understand what the process is accomplishing.

1. When naming a high-level process, assign the process the name of the whole system. An example is
INVENTORY CONTROL SYSTEM.
2. When naming a major subsystem, use a name such as INVENTORY REPORTING SUBSYSTEM or
INTERNET CUSTOMER FULFILLMENT SYSTEM.
3. When naming detailed processes, use a verb-adjective-noun combination. The verb describes the
type of activity, such as COMPUTE, VERIFY, PREPARE, PRINT, or ADD. The noun indicates what the
major outcome of the process is, such as REPORT or RECORD. The adjective illustrates which specific
output, such as BACK-ORDERED or INVENTORY, is produced. Examples of complete process names
are COMPUTE SALES TAX, VERIFY CUSTOMER ACCOUNT STATUS, PREPARE SHIPPING INVOICE, PRINT
BACK-ORDERED REPORT, SEND CUSTOMER EMAIL CONFIRMATION, VERIFY CREDIT CARD BALANCE,
and ADD INVENTORY RECORD.

A process must also be given a unique identifying number indicating its level in the diagram. This
organization is discussed later in this chapter. Several data flows may go into and out of each
process. Examine processes with only a single flow in and out for missing data flows.

d)The last basic symbol used in data flow diagrams is an open-ended rectangle, which represents a
data store. The rectangle is drawn with two parallel lines that are closed by a short line on the left
side and are open-ended on the right. These symbols are drawn only wide enough to allow
identifying lettering between the parallel lines. In logical data flow diagrams, the type of physical
storage is not specified. At this point the data store symbol is simply showing a depository for data
that allows examination, addition, and retrieval of data.

The data store may represent a manual store, such as a filing cabinet, or a computerized file or
database. Because data stores represent a person, place, or thing, they are named with a noun.
Temporary data stores, such as scratch paper or a temporary computer file, are not included on the
data flow diagram. Give each data store a unique reference number, such as D1, D2, D3, and so on.

3.7Developing Data Flow Diagrams (DFDs)

Data Flow Diagram (DFD)  of a system represents how input data is converted to output data
graphically. Level 0 also called context level represents most fundamental and abstract view of the
system. Subsequently other lower levels can be decomposed from it. DFD model of a system
contains multiple DFDs but there is a single data dictionary for entire DFD model. Data dictionary
comprises definitions of data items used in DFD. 

Context diagram : It demonstrates entire data flow of a system in a single process/ bubble. Bubble
is annotated with ‘Noun’ representing whole system. This is only bubble in DFD where a noun, (in
the form of name of a system) is used. It is named since purpose of context diagram is to grab the
context of system and not functionality. All other bubbles have a verb according to main function
performed by it. Context diagram shows three main things : users, data flow to system and from
system. It captures various external entities interacting with system, data to and from system as
incoming and outgoing arrows. Context diagram requires analysis of SRS document. Data flow is
represented with data names on top of arrow.
 Construction of Level 1 and other lower level diagrams : Level 1 DFD contains 3 to 7 bubbles
representing functions. There are processes that can be broken down into sub – process each
representing a bubble. Every Bubble has a verb demonstrating functionality of that process. To
create level1/level 2 or other level DFDs, a bubble is broken into sub-parts containing 3-7
functionalities. If there are more than 7 sub process then some related information can be
combines together. If there are less than 3 sub-process, it can be further decomposed to create
more bubbles.
 Decomposition : Bubbles are decomposed into sub functions at successive levels of DFD level.
Decomposition is called exploding/factoring a bubble. Each bubble at any level can be broken to
anything between 3 and 7 bubbles. But a bubble should not be decomposed further once it is
found to represent simple set of instructions. Too many bubbles at any level makes dfd hard to
understand. Very less bubble makes decomposition redundant and trivial.
 Numbering : Each process symbol must utilize a unique reference number to differentiate from
one other. When a bubble x is decomposed, its children are numbered as x.1, x.2 and so on. It can
help determine its ancestors, successors, and precisely its level. For example level 0 DFD is
numbered as 0. Level 1 are numbered as 0.1, 0.2, 0.3 or 1, 2, 3 and so on. Level 2 are marked as
1.1, 1.2, 1.3 etc. 

Balancing DFD : Parent dfd having inflow and out flow of data should match data flow at next child
level. This is known as balancing a DFD. Concept is illustrated in figure :

Level 1 DFD

Level 2 DFD decomposing P2

In Level 1 DFD, data items D1 flow out of bubble 2 and item D2 flows into bubble 2. In next level,
bubble 2 is decomposed into three sub process(2.1, 2.2, 2.3). It has data item D1 flowing out and
D2 flowing in. So DFD is balanced here. A bubble representing a process should have minimum one
input and one output flow. When a bubble has input flow without any output flow, it is known as
“black hole”. When a process has output flows but no input flows, it is called a “miracle”. A
processing step may have outputs that are greater than sum of its inputs is called Grey holes.  
Common mistakes to avoid while constructing DFDs :
 DFDs should always represent data flow and there should be no control flow.
 All external entities should be represented at context level.
 All functionality of system must be captured in dfd and none should be overlooked. Also, only
those functions specified in SRS should be represented.
 Arrows connecting to data store need not be annotated with any data name.
 DataStore arrow has no annotation

 DFDs should always be balanced at all levels. Dataflow in and out of parent process must be
present in child diagram.

Unbalanced DFD (No receipt generation in child)

 Context level bubble always contains name of entire system in form of noun and no verb can
be used in its representation. Whereas all other levels only have verb in bubble
representation.

Context Level having Noun as system name

 There should not be any database in level 0. Level 0 contains only one bubble and external
entities.
 Incorrect Level 0 with datastore

 No cluttering should be depicted in DFD. When too many data flowing occurs in and out of
DFD, combine these data item into high level item.

DFD with cluttering

 All bubbles having unique process in DFDs should be connected to another process or to a
data store. It cannot exist by itself, unconnected to rest of system.
3.8Logical and Physical Data Flow Diagrams
Data flow diagrams are categorized as either logical or physical.

A logical data flow diagram focuses on the business and how the business operates. It is not
concerned with how the system will be constructed. Instead, it describes the business events that
take place and the data required and produced by each event.

Conversely, a physical data flow diagram shows how the system will be implemented, including the
hardware, software, files, and people involved in the system. The chart shown below contrasts the
features of logical and physical models. Notice that the logical model reflects the business, whereas
the physical model depicts the system.
Design Feature Logical Physical

What the model How the business How the system will be implemented (or
depicts operates. how the current system operates).

What the processes Business activities. Programs, program modules, and manual
represent procedures.

What the data Collections of data Physical files and databases, manual files.
stores represent regardless of how
the data are stored.

Type of data stores Show data stores Master files, transition files. Any processes
representing that operate at two different times must be
permanent data connected by a data store.
collections.

System controls Show business Show controls for validating input data, for
controls. obtaining a record (record found status),
for ensuring successful completion of a
process, and for system security (example:
journal records).

Features common to both logical and physical data flow diagrams.

Ideally, systems are developed by analyzing the current system (the current logical DFD) and then
adding features that the new system should include (the proposed logical DFD). Finally, the best
methods for implementing the new system should be developed (the physical DFD). This progression
is shown in the figure illustrated below.
 The progression of models from logical to physical

Physical and Logical DFD: Example 1

Logical DFD eliminates physical processes that refer to physical activities only and do not
transform data.

Physical and Logical DFD: Example 2

The logical DFD describes what the system does by including the essential sequence of
business activities. It model the business data and activities instead of actual forms,
location and roles.
3.9 EXAMPLE OF DFDS

Data Flow Diagram (DFD) provides a visual representation of the flow of information (i.e. data)

within a system. By drawing a Data Flow Diagram, you can tell the information provided by and

delivered to someone who takes part in system processes, the information needed to complete

the processes and the information needed to be stored and accessed. This article describes and

explains the Data Flow Diagram (DFD) by using a food ordering system as an example.

The Food Ordering System Example

Context DFD
A context diagram is a data flow diagram that only shows the top level, otherwise known as Level
0. At this level, there is only one visible process node that represents the functions of a complete
system in regards to how it interacts with external entities. Some of the benefits of a Context
Diagram are:

1. Shows the overview of the boundaries of a system

2. No technical knowledge is required to understand with the simple notation
3. Simple to draw, amend and elaborate as its limited notation

The figure below shows a context Data Flow Diagram that is drawn for a Food Ordering System. It
contains a process (shape) that represents the system to model, in this case, the " Food Ordering
System". It also shows the participants who will interact with the system, called the external
entities. In this example, the Supplier, Kitchen, Manager, and Customer are the entities who will
interact with the system. In between the process and the external entities, there is data flow
(connectors) that indicate the existence of information exchange between the entities and the
system.

Context DFD is the entrance of a data flow model. It contains one and only one process and does
not show any data store.

Level 1 DFD
The figure below shows the level 1 DFD, which is the decomposition (i.e. break down) of the Food
Ordering System process shown in the context DFD. Read through the diagram and then we will
introduce some of the key concepts based on this diagram.

The Food Order System Data Flow Diagram example contains three processes, four external
entities, and two data stores.
Based on the diagram, we know that a Customer can place an Order. The Order Food process
receives the Order, forwards it to the Kitchen, store it in the Order data store, and store the
updated Inventory details in the Inventory data store. The process also delivers a Bill to
the Customer.

The Manager can receive Reports through the Generate Reports process, which takes Inventory

details and Orders as input from the Inventory and Order data store respectively.

The Manager can also initiate the Order Inventory process by providing Inventory order. The

process forwards the Inventory order to the Supplier and stores the updated Inventory details in
the Inventory data store.