System Design

After the completion of SRS, the responsibility lies on the developers to work on making the
“required” system a reality as that’s what their forte is. To meddle with “How to pull off the
model of the system” is the problem that needs to be solved in the designing phase. Some
of the unanswered questions of the requirement phase (like why a specific requirement is
needed or to decide on the priority of the requirements) are also answered during design.
As designing is the “how” of the system, it is also a mark-off between the customer and the
developers ( or implementers) of reality and satisfaction.
The output of the design phase is the SDD shortened for the software design document.
Essentially SDD is the blueprint for the coding part as it is the description of all the
requirements. SDD lays out software building mechanisms that translate the SRS into the
finalized product albeit on paper.
Types of software designs:
i. Interface design: This design contains the highest level of abstraction. Here, the
entire system is treated as a black box, and only the interactions with the real-world
entities like users, and others systems in its environment (collectively called agents).
ii. Architectural design: Lower level of abstraction than interface design as it
encompasses the specification and detailed layout of the major components
(modules or classes ) of the software.
iii. Detailed design: It contains detailed representations of the workings of all the
components of the software, and their workings, properties, relationships with each
other, etc.
Designs can also be classified as functional-oriented where the design document is viewed as
a collection of modules interacting with each other from a structural point of view, and
object-oriented where the focus is on the manipulation of data viz a viz objects w are the
models of real-world “things”.

Q: What makes a good design?

 A good design is said to have been strategized when the design document offers
flexibility in the development and updating of the program modules or classes. Often,
due to the length of total lines of codes, it becomes insurmountable to keep the
complexity of the program simple enough. However, effective structure designing
techniques help to deal with the aforementioned problem.
To help the transformation of the human-readable requirements into computer-
readable codes, software designers and analysts use some tools which are as follows:

1. DFDs (Data Flow Diagrams) – As opposed to Flowcharts, DFDs represent the flow
of incoming, outgoing, and stored repository of data in the system. It has no
control or decision characteristics.
DFDs are of various levels:
I. Level 0 DFD:- also known as Context Diagram, it offers the highest level
of abstraction showing only the system and its environment. Everything
else like data flow inside the system is concealed. A context diagram is
usually built while analyzing the requirements.
II. Level 1 DFD:- It allows some sort of depth by showcasing the elementary
modularity and their interdependence inside the system. It is an
efficacious diagram to understand the basic information source and flow
inside the system.
III. Level 2 DFD:- Peeling off even more layers is how you can define this
level of DFD in the design representation. In level 2, we look inside the
individual modules and understand the coherence among functions in a
module.
Here is a level one DFD, given below.

2. Flowchart: Flowcharts are another tool used in software designing and analysis
which takes into account control flow in program modules rather than data. It
deals with various possible situations that may arise while operating the software
and logically provide the flow of operations till the end.

Given below is a flowchart