0% found this document useful (0 votes)
12 views12 pages

Segment 4 (Part 1)

Uploaded by

galibashraf.ag
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
0% found this document useful (0 votes)
12 views12 pages

Segment 4 (Part 1)

Uploaded by

galibashraf.ag
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/ 12

Segment - 4

What is Structured Analysis?

Structured Analysis is a development method that allows the analyst to understand the system
and its activities in a logical way.

It is a systematic approach, which uses graphical tools that analyze and refine the objectives of
an existing system and develop a new system specification which can be easily understandable
by user.

It has following attributes −

● It is graphic which specifies the presentation of application.


● It divides the processes so that it gives a clear picture of system flow.
● It is logical rather than physical i.e., the elements of system do not depend on vendor or
hardware.
● It is an approach that works from high-level overviews to lower-level details.

Structured Analysis Tools


During Structured Analysis, various tools and techniques are used for system development.

They are −

1. Data Flow Diagrams


2. Data Dictionary
3. Decision Trees
4. Decision Tables
5. Structured English
6. Pseudocode
Data Flow Diagrams (DFD) or Bubble Chart
It is a technique developed by Larry Constantine to express the requirements of system in a
graphical form.

● It shows the flow of data between various functions of system and specifies how the
current system is implemented.
● It is an initial stage of design phase that functionally divides the requirement
specifications down to the lowest level of detail.
● Its graphical nature makes it a good communication tool between user and analyst or
analyst and system designer.
● It gives an overview of what data a system processes, what transformations are
performed, what data are stored, what results are produced and where they flow.

Types of DFD
DFDs are of two types: Physical DFD and Logical DFD. The following table lists the points that
differentiate a physical DFD from a logical DFD.
Note:
(Please look at the other content of DFD is included in “segment-4(part-2)”.pdf file)
Data Dictionary

A data dictionary is a structured repository of data elements in the system. The data dictionary
is a reference work of data about data (that is, metadata), one that is compiled by systems
analysts to guide them through analysis and design. It stores the descriptions of all DFD data
elements that is, details and definitions of data flows, data stores, data stored in data stores,
and the processes.
One important reason for maintaining a data dictionary is to keep clean data. This
means that data must be consistent. If you store data about a man’s sex as “M” in one record,
“Male” in a second record, and as the number “1” in a third record, the data are not clean.
Keeping a data dictionary will help in this regard.

The data dictionary is created by examining and describing the contents of the data
flows, data stores, and processes, as illustrated by Figure. Each data store and data flow should
be defined and then expanded to include the details of the elements it contains. The logic of
each process should be described using the data flowing into or out of the process.

Figure: How data dictionaries relate to data flow diagrams.


A data dictionary improves the communication between the analyst and the user. It plays
an important role in building a database. Most DBMSs have a data dictionary as a standard
feature. For example, refer the following table −

Process Specification Format

Process specifications—sometimes called “minispecs”, because they are a small portion of


the total project specifications—are created for primitive processes on a data flow diagram as
well as for some higher-level processes that explode to a child diagram. These specifications
explain the decision-making logic and formulas that will transform process input data into output.

Process specifications link the process to the data flow diagram, and hence the data dictionary,
as illustrated in Figure.
Figure: How process specifications relate to the data flow diagram.

Decision Trees

Decision trees are used when complex branching occurs in a structured decision process. Trees
are also useful when it is essential to keep a string of decisions in a particular sequence. Decision
trees are a method for defining complex relationships by describing decisions and avoiding the
problems in communication. A decision tree is a diagram that shows alternative actions and
conditions within horizontal tree framework. Thus, it depicts which conditions to consider first,
second, and so on.

Decision trees depict the relationship of each condition and their permissible actions. A square
node indicates an action and a circle indicates a condition. It forces analysts to consider the
sequence of decisions and identifies the actual decision that must be made.

In drawing the tree:

1. Identify all conditions and actions and their order and timing (if they are critical).
2. Begin building the tree from left to right, making sure you list all possible alternatives
before moving to the right.
The major limitation of a decision tree is that it lacks information in its format to describe what
other combinations of conditions you can take for testing. It is a single representation of the
relationships between conditions and actions.

For example, refer the following decision tree −

Decision Tables
Decision tables are a method of describing the complex logical relationship in a precise manner
which is easily understandable.

It is useful in situations where the resulting actions depend on the occurrence of one or several
combinations of independent conditions.

It is a matrix containing row or columns for defining a problem and the actions.
Components of a Decision Table
Condition Stub − It is in the upper left quadrant which lists all the condition to be checked.

Action Stub − It is in the lower left quadrant which outlines all the action to be carried out to
meet such condition.

Condition Entry − It is in upper right quadrant which provides answers to questions asked in
condition stub quadrant.

Action Entry − It is in lower right quadrant which indicates the appropriate action resulting from
the answers to the conditions in the condition entry quadrant.

Figure: The standard format used for presenting a decision table.

The entries in decision table are given by Decision Rules which define the relationships
between combinations of conditions and courses of action. In rules section,

● Y shows the existence of a condition.


● N represents the condition, which is not satisfied.
● A blank - against action states it is to be ignored.
● X (or a check mark will do) against action states it is to be carried out.

For example, refer the following table −


Example-1

Example-2:

Suppose a store wanted to illustrate its policy on noncash customer purchases. The company
could do so using a simple decision table as shown in Figure. Each of the three conditions (sale
under $50, pays by check, and uses credit cards) has only two alternatives. The two alternatives
are Y (yes, it is true) or N (no, it is not true). Four actions are possible:

1. Complete the sale after verifying the signature.


2. Complete the sale. No signature needed.
3. Call the supervisor for approval.
4. Communicate electronically with the bank for credit card authorization.

The final ingredient that makes the decision table worthwhile is the set of rules for each of
the actions. Rules are the combinations of the condition alternatives that precipitate an action.
For example, Rule 3 says:
The foregoing example featured a problem with four sets of rules and four possible actions, but
that is only a coincidence.

Figure: Using a decision table for illustrating a store’s policy of customer checkout with
four sets of rules and four possible actions.

Structured English
Structured English is derived from structured programming language which gives more
understandable and precise description of process. It is based on procedural logic that uses
construction and imperative sentences designed to perform operation for action.

When the process logic involves formulas or iteration, or when structured decisions are not com-
plex, an appropriate technique for analyzing the decision process is the use of structured English.
As the name implies, structured English is based on (1) structured logic, or instructions organized
into nested and grouped procedures, and (2) simple English statements such as add, multiply,
and move. A word problem can be transformed into structured English by putting the decision
rules into their proper sequence and using the convention of IF-THEN-ELSE statements
throughout.
● It is best used when sequences and loops in a program must be considered and the
problem needs sequences of actions with decisions.
● It does not have strict syntax rule. It expresses all logic in terms of sequential decision
structures and iterations.

Examples of logic expressed in a sequential structure, a decision structure, a case


structure, and an iteration.

For example, see the following sequence of actions −


Pseudocode
A pseudocode does not conform to any programming language and expresses logic in plain
English.

● It may specify the physical programming logic without actual coding during and after the
physical design.
● It is used in conjunction with structured programming.
● It replaces the flowcharts of a program.

Guidelines for Selecting Appropriate Tools

Use the following guidelines for selecting the most appropriate tool that would suit your
requirements −

● Use DFD at high or low level analysis for providing good system documentations.
● Use data dictionary to simplify the structure for meeting the data requirement of the
system.
● Use structured English if there are many loops and actions are complex.
● Use decision tables when there are a large number of conditions to check and logic is
complex.
● Use decision trees when sequencing of conditions is important and if there are few
conditions to be tested.

The following guidelines provide you with a way to choose one of the three techniques for a
particular case:

You might also like