Introduction structured analysis: A structured analysis is a set of

techniques and graphical tools that allow the analyst t develop a new kind of
system specifications that are easily understandable to the user One view of
requirements modeling is also called as structured analysis and considers data
and the processes that transform the data as separate entities. Data objects are
modeled in a way that defines their attributes and relationships. Processes that
manipulate data objects are modeled in a manner that shows how they
transform data as data objects flow through the system.

Entity Relationships Diagram: An entity relationship diagram (ERD)

is a picture, which shows the information that is created, stored, and used by a
business system. An analyst can read an ERD discover the individual pieces of
information in a system and how they are organized An analyst can read an
ERD to discover the individual pieces of information in a syste and how they are
organized and related to each other.

Types of DFD: There are two types of data flow diagrams, namely
physical data flow diagrams and logical data flow diagrams and it is important
to distinguish clearly between the two:

A) Physical Data Flow Diagrams: Physical characteristics can include Names

of people, Form and document names or numbers, Names of departments,
Master and transaction files, Equipment and devices used, Locations, Names of
procedures

B) Logical Data Flow Diagrams: It is an implementation-independent view

of a system, focusing on the flow of data between processes without regard for
the specific devices, storage locations or people in the system. The physical
characteristics listed above for physical data flow diagrams will not be
specified.

Output Design: part to both paper and screen outputs. Output design is
often discussed before other feature of design because, from the customer's
point of view, the output is the system. Output is what the customer is buying
when he or she pay for a development of project. Inputs, databases, and
processes are present to provide output. Problems often associated with
business information output are information hold-up, information (data)
overload, paper domination, extreme distribution, and no tailoring.
Types of Output:
1) Turnaround Documents: Tumaround documents trim down the cost
of internal information processing by reducing both data entry and associated
errors.

2) Periodic Reports: Periodic reports have set frequencies such as daily or

weekly; ad hoc reports are produced at irregular intervals.

3) Detail And Summary Reports: Detail and summary reports differ in

the former support day today operation of the business while the latter include
statistics and ratios used by managers to consider the health of operations.

4) Graphs: Charts used in addition to and instead of tables of numbers,

when users need to compare data among several items.

Types of Modules: 1) Modularity and Partitioning:Each system

should consist of a hierarchy of modules. Lower level modules are generally
smaller in scope and size compared to higher - level modules and serve to
partition processes into separate functions.

2) Coupling: Modules should have little dependence on other modules in a

system.

3) Cohesion: Modules should carry out a single processing function.

4) Span of Control: Modules should interact with and manage the of a
limited number of lower. level modules.

5) Size: The number of instructions contained in a module should be limited

to that module size is generally small.

6) Shared Use: Functions should not be duplicated in separate modules,

but established in a single module that can be invoked by any other module
when needed.
Modules Concepts: Modular design, or "modularity in design", is an
approach that subdivides a system into smaller parts (modules or skids) that
can be independently created and then used in different systems to drive
multiple functionalities. A module is defined as a lexically contiguous sequence
of program statements, bounded by boundary elements, having an aggregate
identifier.

Types of Coupling:
1) Data Coupling: The dependency between module A and B is said to be
data coupled if their dependency is based on the fact they communicate by
only passing of data. Other than communicating through data, the two
modules are independent. A good strategy is to ensure that no module
communication contains "tramp data". In above figure student name, address,
course is examples of tramp data that are unnecessarily communicated
between modules. By ensuring that modules communicate only necessary
data, module dependency is minimized.

2) Stamp Coupling: Stamp occurs between module A and B when

complete data structure is passed from one module to another. Since not all
data making up the structure are usually necessary in communication between
the modules, stamp coupling typically involves tramp data. If one procedure
only needs a part of a data structure. Calling module should pass just that, part,
not the complete data structure.

3) Control Coupling: Module A and B are said to be control coupled if

they communicate by passing of control information. This is usually
accomplished by means of flags that are set by one module and reacted upon
by the dependent module.

4) External Coupling: It is a form of coupling in which a module has a

dependency to other module, external to the software being developed or to a
particular type of hardware. This is basically related to the communication to
the external tools and devices.