Structured Analysis

Structured Analysis
•During Structured Analysis, various tools and
techniques are used for system development.
They are :
Data Flow Diagrams (Discussed in previous
class)
Decision Trees
Decision Tables
Pseudocode
 Decision Trees
•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.
•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.
Decision Trees (cont’d)
 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.
Decision Tables (cont’d)
 Decision Tables (cont’d)
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.
 Decision Tables (cont’d)
•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.
 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.
Pseudocode (cont’d)
SYSTEM DESIGN
 SYSTEM DESIGN
•System design is the phase that bridges the gap
between problem domain and the existing system
in a manageable way. This phase focuses on the
solution domain, i.e. “how to implement?”
•It is the phase where the SR document is
converted into a format that can be implemented
and decides how the system will operate.
•In this phase, the complex activity of system
development is divided into several smaller sub-
activities, which coordinate with each other to
achieve the main objective of system development
SYSTEM DESIGN
 SYSTEM DESIGN
Inputs to System Design
•Statement of work
•Requirement determination plan
•Current situation analysis
•Proposed system requirements including a
conceptual data model, modified DFDs, and
Metadata (data about data).
 SYSTEM DESIGN
Outputs for System Design
•Infrastructure and organizational changes for the
proposed system.
•A data schema, often a relational schema.
•Metadata to define the tables/files and
columns/data-items.
•A function hierarchy diagram or web page map
that graphically describes the program structure.
•Actual or pseudocode for each module in the
program.
•A prototype for the proposed system.
 SYSTEM DESIGN
Types of System Design
•Logical Design
Logical design pertains to an abstract representation
of the data flow, inputs, and outputs of the system. It
describes the inputs (sources), outputs (destinations),
databases (data stores), procedures (data flows) all in a
format that meets the user requirements.
While preparing the logical design of a system, the
system analyst specifies the user needs at level of detail
that virtually determines the information flow into and
out of the system and the required data sources.
Data flow diagram, E-R diagram modeling are used.
 SYSTEM DESIGN
•Physical Design
Physical design relates to the actual input and output
processes of the system.
It focuses on how data is entered into a system, verified,
processed, and displayed as output.
It produces the working system by defining the design
specification that specifies exactly what the candidate system
does. It is concerned with user interface design, process design,
and data design.
It consists of the following steps −
Specifying the input/output media, designing the database, and
specifying backup procedures.
Planning system implementation.
Devising a test and implementation plan, and specifying any
new hardware and software.
Updating costs, benefits, conversion dates, and system
constraints.
 SYSTEM DESIGN
Architectural Design
•It is also known as high level design that
focuses on the design of system architecture.
• It describes the structure and behavior of the
system.
•It defines the structure and relationship
between various modules of system
development process.
 SYSTEM DESIGN
Documentation Control
Documentation is a process of recording the information for any
reference or operational purpose.
It helps users, managers, and IT staff, who require it.
It is important that prepared document must be updated on
regular basis to trace the progress of the system easily.
After the implementation of system if the system is working
improperly, then documentation helps the administrator to
understand the flow of data in the system to correct the flaws and
get the system working.
Programmers or systems analysts usually create program and
system documentation.
Systems analysts usually are responsible for preparing
documentation to help users learn the system.
 In large companies, a technical support team that includes
technical writers might assist in the preparation of user
documentation and training materials.
 SYSTEM DESIGN
Advantages
•It can reduce system downtime, cut costs, and speed up
maintenance tasks.
•It provides the clear description of formal flow of present
system and helps to understand the type of input data and
how the output can be produced.
•It provides effective and efficient way of communication
between technical and nontechnical users about system.
•It facilitates the training of new user so that he can easily
understand the flow of system.
•It helps the user to solve the problems such as
troubleshooting and helps the manager to take better final
decisions of the organization system.
•It provides better control to the internal or external working
of the system.
 SYSTEM DESIGN
Types of Documentations
•When it comes to System Design, there are
following four main documentations −
Program documentation
System documentation
Operations documentation
User documentation
 SYSTEM DESIGN
Types of Documentations
•When it comes to System Design, there are
following four main documentations −
Program documentation
System documentation
Operations documentation
User documentation
 SYSTEM DESIGN
Program Documentation
•It describes inputs, outputs, and processing
logic for all the program modules.
•The program documentation process starts in
the system analysis phase and continues during
implementation.
•This documentation guides programmers, who
construct modules that are well supported by
internal and external comments and
descriptions that can be understood and
maintained easily.
 SYSTEM DESIGN
Operations Documentation
Operations documentation contains all the
information needed for processing and distributing
online and printed output. Operations
documentation should be clear, concise, and
available online if possible.
•It includes the following information −
Program, systems analyst, programmer, and system
identification.
•Error and informational messages to operators
and restart procedures.
•Special instructions, such as security requirements.
 SYSTEM DESIGN
User Documentation
•It includes instructions and information to the users who will interact with the system. For
example, user manuals, help guides, and tutorials.
•User documentation is valuable in training users and for reference purpose. It must be clear,
understandable, and readily accessible to users at all levels.
•The users, system owners, analysts, and programmers, all put combined efforts to develop a
user’s guide.
A user documentation should include −
•A system overview that clearly describes all major system features, capabilities, and limitations.
•Overview of menu and data entry screen options, contents, and processing instructions.
•Examples of reports that are produced regularly or available at the user’s request, including
samples.
•Security and audit trail information.
•Explanation of responsibility for specific input, output, or processing requirements.
•Procedures for requesting changes and reporting problems.
•Examples of exceptions and error situations.
•Frequently asked questions (FAQs).
•Explanation of how to get help and procedures for updating the user manual.
 SYSTEM DESIGN
System Documentation
•System documentation serves as the technical specifications for the IS and how the
objectives of the IS are accomplished.
• Users, managers and IS owners need never reference system documentation. System
documentation provides the basis for understanding the technical aspects of the IS when
modifications are made.
•It describes each program within the IS and the entire IS itself.
•It describes the system’s functions, the way they are implemented, each program's
purpose within the entire IS with respect to the order of execution, information passed to
and from programs, and overall system flow.
•It includes data dictionary entries, data flow diagrams, object models, screen layouts,
source documents, and the systems request that initiated the project.
•Most of the system documentation is prepared during the system analysis and system
design phases.
•During systems implementation, an analyst must review system documentation to verify
that it is complete, accurate, and up-to-date, and including any changes made during the
implementation process.
 DESIGN STRATEGIES
Top-Down Strategy
•The top-down strategy uses the modular approach to develop the design of a system.
•It is called so because it starts from the top or the highest-level module and moves
towards the lowest level modules.
•In this technique, the highest-level module or main module for developing the software is
identified.
•The main module is divided into several smaller and simpler submodules or segments
based on the task performed by each module.
• Then, each submodule is further subdivided into several submodules of next lower level.
This process of dividing each module into several submodules continues until the lowest
level modules, which cannot be further subdivided, are not identified.
 DESIGN STRATEGIES
Bottom-Up Strategy
•Bottom-Up Strategy follows the modular approach to develop the design of the system.
• It is called so because it starts from the bottom or the most basic level modules and
moves towards the highest level modules.

In this technique,
•The modules at the most basic or the lowest level are identified.
•These modules are then grouped together based on the function performed by each
module to form the next higher-level modules.
•Then, these modules are further combined to form the next higher-level modules.
•This process of grouping several simpler modules to form higher level modules continues
until the main module of system development process is achieved.
 DESIGN STRATEGIES
Factors Affecting System Complexity
•To develop good quality of system software, it is
necessary to develop a good design.
•A good quality software design is the one, which
minimizes the complexity and cost expenditure in software
development.
•The two important concepts related to the system
development that help in determining the complexity of a
system are :
coupling
cohesion.
 DESIGN STRATEGIES
Coupling
•Coupling is the measure of the independence of
components.
•It defines the degree of dependency of each module of
system development on the other.
• In practice, this means the stronger the coupling
between the modules in a system, the more difficult it is to
implement and maintain the system.
•Each module should have simple, clean interface with
other modules, and that the minimum number of data
elements should be shared between modules.
 DESIGN STRATEGIES
Coupling Types: High and Low Coupling
High Coupling
•These type of systems have interconnections with
program units dependent on each other. Changes to one
subsystem leads to high impact on the other subsystem.
 DESIGN STRATEGIES
Coupling Types: High and Low Coupling
Low Coupling
•These type of systems are made up of components which
are independent or almost independent. A change in one
subsystem does not affect any other subsystem.
 DESIGN STRATEGIES
Coupling Measures
•Content Coupling − When one component actually modifies
another, then the modified component is completely dependent on
modifying one.
•Common Coupling − When amount of coupling is reduced
somewhat by organizing system design so that data are accessible
from a common data store.
•Control Coupling − When one component passes parameters to
control the activity of another component.
•Stamp Coupling − When data structures is used to pass information
from one component to another.
•Data Coupling − When only data is passed then components are
connected by this coupling.
 DESIGN STRATEGIES
Cohesion
•Cohesion is the measure of closeness of the relationship
between its components. It defines the amount of dependency
of the components of a module on one another.
• In practice, this means the systems designer must ensure that
−
They do not split essential processes into fragmented
modules.
They do not gather together unrelated processes
represented as processes on the DFD into meaningless
modules.
The best modules are those that are functionally cohesive.
The worst modules are those that are coincidentally cohesive.
 DESIGN STRATEGIES
The worst degree of cohesion
•Coincidental cohesion is found in a component whose parts are
unrelated to another. e.g:
Logical Cohesion − It is where several logically related functions or
data elements are placed in same component.
Temporal Cohesion − It is when a component that is used to
initialize a system or set variables performs several functions in
sequence, but the functions are related by timing involved.
Procedurally Cohesion − It is when functions are grouped together
in a component just to ensure this order.
Sequential Cohesion − It is when the output from one part of a
component is the input to the next part of it.