Scribd
Upload
96 views

IT-510 Module 4 Part One

The document discusses logical design modeling concepts including data flow diagrams (DFDs), decision trees, and data dictionaries. It explains that the logical design shows what a system must do, which is then used to design the physical implementation. Process flow diagrams are used to visually represent system processes and help users provide additional requirements details. Data flow diagrams follow standard formats and show data flows between external entities, processes, and data stores. The document provides an example of creating a context DFD and detailed DFDs for a sales reporting system based on requirements from previous modules.

Uploaded by

petetg5172
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
96 views

IT-510 Module 4 Part One

The document discusses logical design modeling concepts including data flow diagrams (DFDs), decision trees, and data dictionaries. It explains that the logical design shows what a system must do, which is then used to design the physical implementation. Process flow diagrams are used to visually represent system processes and help users provide additional requirements details. Data flow diagrams follow standard formats and show data flows between external entities, processes, and data stores. The document provides an example of creating a context DFD and detailed DFDs for a sales reporting system based on requirements from previous modules.

Uploaded by

petetg5172
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

Module Four explores the logical design model concepts,

which are classified as a structured design approach.


Using the requirements discussed in Module Three,
Module Four will explore the use of tools and techniques
such as data flow diagrams (DFDs), decision trees, and
data dictionaries. Each of the tools listed are essential for
the systems analyst to visually design the logical model.

Logical Design Model


The logical design is the process entailing what the
system must do. What the system must do is then
contrasted with the physical design of how the system is
built. The logical design will transform into the physical
design over a series of steps in the upcoming weeks. For
now, students will focus on the logical design.

Process Description
A process description document is a high level flow of the
system. The process description document is used and
referenced often when presenting or discussing the
system at the data and process modeling stage. A flow
chart is built to show the overall process. Refer to the
weekly time reporting system below as an example of
what a flow diagram might look like.
Table 4.1

Even though the process description is purposefully basic


and general, taking a diagram similar to the one above to
a meeting generates a tremendous amount of detailed
discussion that a systems analyst needs to hear. Users
can relate to flow diagrams and will be able to flush out
details that are typically not provided during the fact
finding requirement step. For example, after a user looks
at the time reporting diagram example, it may trigger a
realization allowing the user to communicate that the
project requires a supervisor approval step as soon as the
associate enters his or her first personal-time. Therefore,
the flow chart would be adjusted accordingly.

Table 4.2
Data Flow Diagrams
DFDs are a more technical version of the process
description. The DFD follows a standard in terms of how
each diagram is created. There is a correct version and an
incorrect version of a DFD. Referring back to Module
Three, remember the sale growth report. In Module Three,
the systems analyst created the system requirements
through the fact finding process. Based on the results of
the framed questions, the systems analyst was able to
derive a sketch and feasibility of the system. During the
DFD step, the systems analyst will use that information as
input and continue to refine the model by creating a
context DFD.

Using the system requirements modeling example for a


report project request described in Module Three, the
requirements identified the need to source data from the
transactional system. For this example, the transactional
system is process 0. The data being sourced from the
transaction system will be stored in a reporting database,
which will be listed as data store reports in the DFD.

The users will be the external entities in the systems


analyst’s DFD. From the requirements set in Module
Three, the class reviewed the different types of users
based on the specified management responsibilities. A
user role can be a sales representative that handles
individual accounts. A user role can be a sales manager
that manages the sales representatives. A user role can
be a regional sales manager that manages multiple sales
managers based on the region. Finally, a user role can be
a corporate executive that manages strategic business
models for all sales. There can be multiple processes
created for supporting each of these user roles.

In the context DFD, the systems analyst will create a


reporting process for each of the user roles. These
processes will be numbered 1 through 4, representing the
associated business reporting rules and process for each
user type. Each of the four associated user role entities
will then talk to one of the processes numbered 1 through
4. This completes the systems analyst’s context DFD. The
systems analyst will now move into the detailed DFDs.

In the detailed DFD, the systems analyst will need to


follow the specification rules that a process can talk to a
data store, an entity, or another process. The 0 process is
the transaction system and the process talks to the
reporting data store. The systems analyst will not create
the 0 DFD for this process since it is a sourcing system
and one can assume that it exists for that system. Each
process that has been numbered 1 through 4 will have an
associated 0 DFD. This diagram explodes the process into
a detailed DFD. Each detail will have a reporting process
based on the selection criteria for the user type. For
example, the sales manager process is number 2, and
includes all sales representatives reporting to the sales
manager. The process of “Get Sales Manager Data” would
talk to the reporting database data store, and would also
talk to the sales manager entity. This would be replicated
for each of the other three user types. The process of “Get
Data” for each of the numbered processes 1 through 4 is
where the detail of the specific data selection will occur. As
additional details are discovered and designed for the
process, this is where those changes will be made.

You might also like