Software Engineering

PCC-CS504
Module - 2 Piyali Chandra
Assistant Professor
UEMK
 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.
• Structured analysis is a software engineering technique that uses
graphical diagrams to develop and portray system specifications that
are easily understood by users.
• These diagrams describe the steps that need to occur and the data
required to meet the design function of a particular software.
What is Structured Analysis?
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 −
• Data Flow Diagrams
• Data Dictionary
• Decision Trees
• Decision Tables
• Structured English
• Pseudocode
Structured Analysis Tools
Data Flow Diagram (DFD)
• A Data Flow Diagram (DFD) is a traditional visual representation of the
information flows within a system.
• The flow of data of a system or a process is represented by DFD.
• It also gives insight into the inputs and outputs of each entity and the
process itself.
• DFD does not have control flow and no loops or decision rules are
present.
• It shows how data enters and leaves the system, what changes the
information, and where data is stored.
• The DFD is also called as a data flow graph or bubble chart.
 Components of DFD
The Data Flow Diagram has 4 components:
• Process
Input to output transformation in a system takes place because of process function.
The symbols of a process are rectangular with rounded corners, oval, rectangle or a
circle.
• Warehouse
The data is stored in the warehouse for later use. Two horizontal lines represent the
symbol of the store.
• Terminator
The Terminator is an external entity that stands outside of the system and
communicates with the system. Modeled systems also communicate with terminator.
• Data Flow:
The movement of data in the system is known as data flow. It is represented with the
help of arrow. The tail of the arrow is source and the head of the arrow is destination.
DFD (cont.)
Rules for creating DFD

• The name of the entity should be easy and understandable without

any extra assistance(like comments).
• The processes should be numbered or put in ordered list to be
referred easily.
• The DFD should maintain consistency across all the DFD levels.
• A single DFD can have maximum processes upto 9 and minimum 3
processes.
 Levels of DFD
DFD uses hierarchy to maintain transparency thus multilevel DFD’s can
be created.
Levels of DFD are as follows:
0-level DFD:
• It is also known as a context diagram.
• It represents the entire software requirement as a single bubble with
input and output data denoted by incoming and outgoing arrows.
• Then the system is decomposed and described as a DFD with multiple
bubbles.
Levels of DFD
1-level DFD:
• In 1-level DFD, the context diagram is decomposed into multiple
bubbles/processes.
• In this level, we highlight the main functions of the system and
breakdown the high-level process of 0-level DFD into sub processes.
Levels of DFD
2-level DFD:
• 2-level DFD goes one process deeper into parts of 1-level DFD.
• It can be used to project or record the specific/necessary detail about
the system's functioning.
 logical DFD
• Logical DFDs represent logical information flows in relatively abstract
terms. This means that they will identify general processes, systems and
activities but not provide technology detail.
• Logical DFD focusses on business and business activities. It is the basis for
the physical DFD.
• Logical DFD allows mapping the flow of business actions as it is. It helps to
emphasize the shortcomings and inefficiencies.
• It helps to identify the process steps in order to eliminate or modify them.
• It also helps to identify mistakes and shortcomings.
Physical DFD

• Physical DFDs show more physical information flow detail, particularly

details of information systems, applications and databases.
• The next diagram to draw after creating a logical DFD is physical DFD.
• physical DFD contains the implantation related details such as hardware,
people and other external components required to run the business
processes.

Logical DFD vs Physical DFD

Logical DFD is a type of DFD that depicts how the business operates while
physical DFD is a type of DFD that depicts how the system is implemented.
What is data modelling?

• Data modeling is the process of creating a simplified diagram of a

software system and the data elements it contains, using text and
symbols to represent the data and how it flows.
• Data models provide a blueprint for designing a new database or
reengineering a legacy application.
Data Modelling Examples

• ER (Entity-Relationship) Model: This model is based on the notion of real-

world entities and relationships among them. It creates an entity set,
relationship set, general attributes, and constraints.
• Hierarchical Model: This data model arranges the data in the form of a tree
with one root, to which other data is connected. The hierarchy begins with
the root and extends like a tree. This model effectively explains several real-
time relationships with a single one-to-many relationship between two
different kinds of data.
• Network Model: This database model enables many-to-many relationships
among the connected nodes. The data is arranged in a graph-like structure,
and here ‘child’ nodes can have multiple ‘parent’ nodes. The parent nodes are
known as owners, and the child nodes are called members.
Data Modelling Examples

• Relational Model: This popular data model example arranges the data
into tables. The tables have columns and rows, each cataloging an
attribute present in the entity. It makes relationships between data
points easy to identify.
• Object-Oriented Database Model: This data model defines a
database as an object collection, or recyclable software components,
with related methods and features.
• Object-Relational Model: This model is a combination of an object-
oriented database model and a relational database model. The data
modeling process helps organizations to become more data-driven.
Types of Data Modelling

• Conceptual Model: It is a visual representation of database concepts

and the relationships between them identifying the high-level user
view of data.
• Logical Model: This model further defines the structure of the data
entities and their relationships.
• Physical Model:This is a schema or framework defining how data is
physically stored in a database.
ER diagram
• ER-modeling is a data modeling method used in software engineering
to produce a conceptual data model of an information system.
• Diagrams created using this ER-modeling method are called Entity-
Relationship Diagrams or ER diagrams or ERDs.
• An Entity Relationship Diagram (ERD) is a visual representation
of different entities within a system and how they relate to each
other.
Entity Relationship Diagram (ERD) Symbols and Notations

• There are three basic elements in an ER Diagram: entity, attribute,

relationship. There are more elements which are based on the main
elements. They are weak entity, multi-valued attribute, derived
attribute, weak relationship, and recursive relationship.
• Cardinality and ordinality are two other notations used in ER
diagrams.
ERD Symbols and Notations (cont..)
• Entity:
An entity can be a person, place, event, or object that is relevant to a given system.
Entities are represented in ER diagrams by a rectangle and named using singular
nouns.
For example, a school system may include students, teachers, major courses,
subjects, fees, and other items.
• Weak Entity:
A weak entity is an entity that depends on the existence of another entity.
In more technical terms it can be defined as an entity that cannot be identified by
its own attributes.
It uses a foreign key combined with its attributed to form the primary key.
ERD Symbols and Notations (cont..)
• Attribute:
An attribute is a property, trait, or characteristic of an entity, relationship, or
another attribute.
An entity can have as many attributes as necessary. Meanwhile, attributes
can also have their own specific attributes.
• Multivalued Attribute:
If an attribute can have more than one value it is called a multi-valued
attribute.
It is important to note that this is different from an attribute having its own
attributes.
• Derived Attribute:
An attribute based on another attribute. This is found rarely in ER diagrams.
ERD Symbols and Notations (cont..)
• Relationship: A relationship describes how entities interact.
Relationships are represented by diamond shapes and are labeled
using verbs.
• Recursive Relationship: If the same entity participates more than
once in a relationship it is known as a recursive relationship.
 Cardinality
Cardinality describes the number of entities in one entity set, which can be associated with the
number of entities of other sets via relationship set.
Types of Cardinalities:
• One to One: One entity from entity set A can be contained with at most one entity of entity
set B and vice versa. Let us assume that each student has only one student ID, and each
student ID is assigned to only one person. So, the relationship will be one to one.
• One to many: When a single instance of an entity is associated with more than one instances
of another entity then it is called one to many relationships. For example, a client can place
many orders; a order cannot be placed by many customers.
• Many to One: More than one entity from entity set A can be associated with at most one
entity of entity set B, however an entity from entity set B can be associated with more than
one entity from entity set A. For example - many students can study in a single college, but a
student cannot study in many colleges at the same time.
• Many to Many: One entity from A can be associated with more than one entity from B and
vice-versa. For example, the student can be assigned to many projects, and a project can be
assigned to many students.
Software Requirement Specification
• A software requirements specification (SRS) is a document that
describes what the software will do and how it will be expected to
perform.
• It is complete specification and description of requirements of
software that needs to be fulfilled for successful development of
software system.
• These requirements can be functional as well as non-functional
depending upon type of requirement.
Following are the features of a good SRS
document
• Correctness: User review is used to provide the accuracy of requirements
stated in the SRS. SRS is said to be perfect if it covers all the needs that are truly
expected from the system.
• Completeness: The SRS is complete if, and only if, it includes the following
elements:
(1) All essential requirements, whether relating to functionality,
performance, design, constraints, attributes, or external interfaces.
(2) Definition of their responses of the software to all realizable classes of
input data in all available categories of situations.
(3)Full labels and references to all figures, tables, and diagrams in the SRS
and definitions of all terms and units of measure.
Good SRS document (cont..)
• Consistency: The SRS is consistent if, and only if, no subset of individual
requirements described in its conflict. There are three types of possible conflict in the
SRS:
(1)The specified characteristics of real-world objects may conflicts. For example,
(a) The format of an output report may be described in one requirement as
tabular but in another as textual.
(b) One condition may state that all lights shall be green while another states
that all lights shall be blue.
(2)There may be a reasonable or temporal conflict between the two specified actions.
For example,
(a) One requirement may determine that the program will add two inputs, and
another may determine that the program will multiply them.
(b) One condition may state that "A" must always follow "B," while other
requires that "A and B" co-occurs.
Good SRS document (cont..)
(3) Two or more requirements may define the same real-world object but use
different terms for that object. For example, a program's request for user input may
be called a “A" in one requirement's and a “B" in another. The use of standard
terminology and descriptions promotes consistency.
• Unambiguousness: SRS is unambiguous when every fixed requirement has
only one interpretation. This suggests that each element is uniquely interpreted.
In case there is a method used with multiple definitions, the requirements report
should determine the implications in the SRS so that it is clear and simple to
understand.
Good SRS document (cont..)
• Modifiability: SRS should be made as modifiable as likely and should be
capable of quickly obtain changes to the system to some extent. Modifications
should be perfectly indexed and cross-referenced.
• Ranking for importance and stability: Typically, all requirements are not
equally important. Some prerequisites may be essential, especially for life-critical
applications, while others may be desirable. Each element should be identified to
make these differences clear and explicit. Another way to rank requirements is to
distinguish classes of items as essential, conditional, and optional.
 THANK YOU & HAPPY
LEARNING