Академический Документы
Профессиональный Документы
Культура Документы
Requirements Analysis
Introduction
Structured Analysis
Data-Flow Diagrams
Data Dictionary
Process Descriptions
Introduction
The Requirements Analysis is the second major step of the system analysis phase of
the systems development life cycle (SDLC).
When analyzing requirements, various structured analysis tools are used to document
the systems requirements, analyze them, and develop a model of the system.
Structured Analysis
Structured analysis examines a system in terms of its inputs, outputs, and processes
and is the most common way to describe the requirements for a new system.
It focuses on the flow of data through the system to convert into useful information.
The end product of structured analysis is a logical model of the system, which shows
what the system does, regardless of how it will be done.
Logical model is also termed as business model, as it describes the business flow of
data.
A physical model describes how the system will function when the logical model is
implemented. In this chapter we describe logical models.
Structured analysis uses three main tools:
Data-Flow Diagrams
Data Dictionary
Process Descriptions
Context-Level Diagram
The context diagram is the highest level in a data flow diagram, containing only one
process representing the entire system. All external entities are shown on the context
diagram as well as major data flow to and from them. The diagram does not contain
any data storage.
Creating Diagram 0
The single process in the context-level diagram, representing the entire system, can be
exploded to include the major processes of the system in the next level diagram, which
is termed as diagram 0.
Next-Level Diagrams
Processes in diagram 0 (with a whole number) can be exploded further to represent
details of the processing activities. Example below shows the next level ((Diagram 1) of
process explosion.
The process name in the context diagram should be the name of the information
system. For example, Grading System, Order Processing System, Registration
System.
Use unique names within each set of symbols. For example, there can be only one
entity CUSTOMER in all levels of the data-flow diagrams. There can be only one
process named CALCULATE OVERTIME among all levels of data-flow diagrams.
Do not cross lines. One way to achieve this is to restrict the number of processes in
a data-flow diagram.
On lower-level data-flow diagrams with multiple processes, one should not have
more than nine (9) process symbols.
Another way to avoid crossing lines is to duplicate an external entity or data store.
Use a special notation such as an asterisk, to denote the duplicate symbol.
Use abbreviated identification for external entities and data-flows. For example, C
for entity CUSTOMER, and D1 for data store STUDENT.
Use a unique reference number for each process symbol. The process number in
the context-level diagram is 0 (zero). Other process numbers are in the hierarchy of
(1, 2, 3,); (1.1, 1.2, 1.3, ., 2.1, 2.2, 2.3,.); (1.1.1, 1.1.2,
1.1.3,).
Balancing refers to the preservation of input and output data flows of the parent
diagram on the child diagrams
Leveling means that the information system is first displayed as a single process,
and then shows more detail in subsequent child diagrams until all processes
become functional primitives
More stable system: Systems formed using a logical data flow diagram are often
more stable than those that are not because they are based on business events and
not on a particular technology or method of implementation.
Flexibility and maintenance: The new system will be more flexible and easier to
maintain if its design is based on a logical model and the business functions are not
subject to frequent change. Physical aspects of the system change more frequently
than do business functions.
Simple to develop: The logical model is easy to create and simpler to use because it
does not often contain data stores other than files or a database.
Easy conversion to physical model: Once the logical data flow diagrams are
created, the creation of physical data flow diagrams becomes easy.
10
When examining the output, determine whether the information must immediately be
displayed or made available to users as reports. Processes that immediately display
output on screens are on-line processes.
Processes that require high volume of transactions, such as billing or check processing,
or a large number of records that need to be summarized are usually batch processes.
Create a process for each distinct output.
Figure below describes what should be included in a physical data flow diagram.
Advantages of Physical Data Flow Diagram
Clarifying which processes are manual and which are automated: Manual
processes require detailed documentation and automated process require computer
programs to be developed.
Describing processes in more detail than do logical DFDs: Describes all steps for
processing of data.
Specifying actual names of files and printouts: Logical data flow diagrams describes
actual filenames and reports, so that the programmers can relate those with the
data dictionary during the developmental phase of the system.
Adding controls to ensure the processes are done properly: These are conditions or
validations of data that are to be met during input, update, delete, and other
processing of data.
11
Timing: if two processes execute at different times, they can not be grouped into
one program.
Similar Tasks: If two processes perform similar tasks and both are batch processes,
they may be grouped into one program.
Efficiency: Several batch processes may be combined into one program for
efficient processing. This can improve computer access time.
Security: Processes may be partitioned into different programs for security reasons.
12