CSE@HCST

UNIT-II
RCS-402
SOFTWARE ENGINEERING
PART-I

07/07/2025 Software Engineering

Syllabus

CSE@HCST 07/07/2025
REQUIREMENT ENGINEERING

 Requirements of the customer play a key role in

designing a software product.
 A missed or bad requirement can result into a
software error which requires lots of rework and
also lead to financial and legal implications.
 The key component is the requirement
specification document(RSD) or software
requirement specification(SRS) and the process of
developing this document is called requirement
engineering.
CSE@HCST 07/07/2025
REQUIREMENT ENGINEERING

 A Requirement is a feature of the system or a description of

something the system is capable of doing in order to fulfill the
system’s purpose.
 It can be defined as a discipline, which addresses
requirements of objects all along a system-development
process.
 IEEE defines a requirement as:
 A Condition or capability needed by a user to solve a problem
or achieve an objective
 A Condition or capability that must be met by a system to
satisfy a correct, standard, specification document.
 A Document representation of a condition or capability as in
definition (a),(b). CSE@HCST 07/07/2025
REQUIREMENT ENGINEERING

 Requirements describe the “what” of a system, not the “how.”

 Requirements engineering produces one large document,
written in a natural language, and contains a description of
what the system will do without describing how it will do it.
 Requirements engineering is the systematic use of-
 Proven principles.
 Techniques, and language tools.
 Cost-effective analysis.
 Documentation.
 On-going evaluation of the user’s needs.
 Specifications of the external behavior of a system to satisfy those user
needs.
CSE@HCST 07/07/2025
REQUIREMENT ENGINEERING

Fig: The Process of Determining Requirements

CSE@HCST 07/07/2025
REQUIREMENT ENGINEERING

 The Input to Requirements Engineering is the

Problem Statement prepared by the Customer.
 The Output of the Requirements Engineering (RE)
process is a system Requirements Specification
called the Requirement Definition and Description
(RDD).
 The System Requirements Specification forms the
basis for designing software solutions.

CSE@HCST 07/07/2025
 REQUIREMENT ENGINEERING TECHNIQUES

 To solve the requirements problem a wide range of skill

sets and knowledge need to applied, few are defined as-
 Psychology and Sociology (Interviewing Observing Video Recording).
 Marketing.

 Object Oriented Analysis.

 Structured Analysis(DFD,ERD).
 Participative Design(Scandinavian Approach ).

 Human Computer Interaction.

 Quality.

CSE@HCST 07/07/2025
Types of Requirements

 There are various categories of the requirements.

 On the basis of their priority, the requirements are
classified into the following three types-
 Those that should be absolutely met.
 Those that are highly desirable but not necessary.
 Those that are possible but could be eliminated.

CSE@HCST 07/07/2025
Types of Requirements

 On the basis of their functionality, the

requirements are classified into the following two
types:-
 Functional requirements:-
 They define factors, such as I/O formats, storage structure,
computational capabilities, timing, and synchronization.
 Non-functional requirements:-
 They define the properties or qualities of a product
including usability, efficiency, performance, space,
reliability, portability, etc.
CSE@HCST 07/07/2025
Types of Requirements

CSE@HCST 07/07/2025
CSE@HCST 07/07/2025
CSE@HCST 07/07/2025
REQUIREMENTS ENGINEERING PROCESS

Fig: Process Steps of Requirements Engineering

CSE@HCST 07/07/2025
 REQUIREMENTS ENGINEERING PROCESS

 Requirements engineering consists of the following

processes-
A. Requirements Elicitation.
B. Requirements Analysis and Modeling.
C. Requirements Documentation.
D. Requirements Review.
E. Requirements Management.

CSE@HCST 07/07/2025
 A-Requirements Elicitation.

 Requirement Elicitation is a Communication Process

between the parties involved and affected in the
problem situation.
 The Tools in elicitation are- meetings, interviews,
video conferencing, e-mails, and existing documents
study and facts findings.
 More than 90% to 95% elicitation should be complete
in the initiation stage while the remaining 5% is
completed during the development life-cycle.

CSE@HCST 07/07/2025
 Requirements Elicitation

 The Requirements are gathered from various sources

for elicitation.
 The Sources are-
Customer (Initiator).
End Users.
Primary Users.
Secondary Users.
Stakeholders.

CSE@HCST 07/07/2025
 Requirement Elicitation Process
 General Techniques that used in Requirement Elicitation Process
are as follows:
1. Interviews.
2. Brainstorming.
3. Facilitated Application Specification Techniques(FAST).
4. Joint Application Design(JAD).
5. Task Analysis.
6. Quality Function Deployment.
7. Form Analysis.
8. Delphi Techniques.
9. User Scenario

CSE@HCST 07/07/2025
1-Interviews

 Once a Problem statement is received from a

customer, then this stage comes, where the meeting
with a customer is arranged.
 Interview is a one of the most popular method for
understanding the problem domains.
 During interview requirement engineers and
customers interact with each other.
 Requirement engineer must be open minded and
asked the question freely from customer.
CSE@HCST 07/07/2025
Interviews

The following steps in interviews are-

 Create the Questionnaire.
 Select the Interviewer.
 Plan Contacts.
 Conduct the interview(face to face).

CSE@HCST 07/07/2025
2-Brainstorming

 It is used many in business application, is a group

of techniques to promote creative thinking and used
during elicitation process to generate new ideas.
 Promote the creative thinking by group discussions.
 It becomes very popular and it is widely used by
many companies.
 There will not be critic for the ideas.

CSE@HCST 07/07/2025
Brainstorming

 Roles for a Brainstorming Session-

 Leader-(facilitator or moderator).
 Scribe(penman).

 Participant(involved many stakeholders).

CSE@HCST 07/07/2025
3-Facilitated Application Specification Techniques(FAST).

 This technique was developed specifically for

collecting requirements and similar to
brainstorming.
 The objective of this technique is to bridge the
expectation gap- a difference between what
developers think they are suppose to build and what
customers think they are going to get.
 So for reducing the expectation gap, a team oriented
approach is developed for requirements gathering
and is called the FAST.
CSE@HCST 07/07/2025
4-Joint Application Development (JAD)

 Joint application design (JAD) is a process used in the

prototyping life cycle area of the Dynamic Systems Development
Method (DSDM) to collect business requirements while
developing new information systems for a company.
 The JAD process also includes approaches for enhancing user
participation, expediting development, and improving the quality
of specifications.
 It consists of a workshop where knowledge workers and IT
specialists meet, sometimes for several days, to define and review
the business requirements for the system .
 The attendees include high level management officials who will ensure
the product provides the needed reports and information at the end.
CSE@HCST 07/07/2025
4-Joint Application Development (JAD)

Key participants-
 Executive Sponsor: The executive who charters the project, the system owner. They

must be high enough in the organization to be able to make decisions and provide the
necessary strategy, planning, and direction.
 Subject Matter Experts: These are the business users, the IS professionals, and the

outside experts that will be needed for a successful workshop. This group is the backbone
of the meeting; they will drive the changes.
 Facilitator/Session Leader: meeting and directs traffic by keeping the group on the

meeting agenda. The facilitator is responsible for identifying those issues that can be
solved as part of the meeting and those which need to be assigned at the end of the
meeting for follow-up investigation and resolution. The facilitator serves the participants
and does not contribute information to the meeting.
 Scribe/Modeler/Recorder/Documentation Expert: Records and publish the

proceedings of the meeting and does not contribute information to the meeting.
 Observers: Generally members of the application development team assigned to the

project. They are to sit behind the participants and are to silently observe the proceedings.

CSE@HCST 07/07/2025
5-Task Analysis.

 The problem domain is decomposed into hierarchy

of task and subtask.
 The customer approaches to engineer and express
his desire of what software should contribute to the
organization ,how the software should work, what
services should provide and so on.

CSE@HCST 07/07/2025
 6-Quality Function Deployment.

 This is a technique of Quality Management that helps to

incorporate the voice of customers.
 The voice is then translated into technical requirement.
 These technical requirement are documented and result in
the software Requirements Specification(SRS)
documents.
 And these requirement further translated in to design
requirements.
 Customer requirement is prime concerns of this
techniques.
CSE@HCST 07/07/2025
7-Form Analysis

 Form play an important role in any organization

and contain lot of meaningful information about
data objects of the domain as shown in the
employee registration form.
Employee Registration Form
Employee Name:
Address:
Position:
Year of joining:
Salary:
CSE@HCST 07/07/2025
8-Delphi Technique
 The Delphi method is a structured communication technique, originally developed
as a systematic, interactive forecasting method which relies on a panel of experts.
 The experts answer questionnaires in two or more rounds.
 After each round, a facilitator provides an anonymous summary of
the experts’ forecasts from the previous round as well as the reasons
they provided for their judgments.
 Thus, experts are encouraged to revise their earlier answers in light
of the replies of other members of their panel.
 It is believed that during this process the range of the answers will
decrease and the group will converge towards the "correct" answer.
 Finally, the process is stopped after a pre-defined stop criterion.
 Delphi is based on the principle that forecasts (or decisions) from a
structured groups or unstructured groups of individuals.
CSE@HCST 07/07/2025
8-Delphi Technique

CSE@HCST 07/07/2025
9-User Scenario(With Help of use case
diagram)
 This technique use for capturing requirements from
point of view.
 A scenario is a story that illustrates how a perceived
system will satisfy a user needs.

CSE@HCST 07/07/2025
 B-Requirement Analysis

 Requirement analysis is a very important and

essential activity after elicitation.
 In this phase, each requirement is analyzed from the
point-of-view of validity, consistency, and feasibility
for consideration in the RDD and then in the SRS.
 Validity confirms its relevance to goals and
objectives and consistently confirms that it does not
conflict with other requirements but supports others
where necessary.

CSE@HCST 07/07/2025
 Requirement Analysis

 The Second portion of Analysis attempts to find for

each requirement, its functionality, features, and
facilities and the need for these under different
conditions and constraints-
 Functionality-“How to achieve the requirement goal.”
 Features- Describe the attributes of functionality,
 Facilities-Provide its delivery, administration, and
communication to other systems.

CSE@HCST 07/07/2025
 Requirement Analysis

 Following question should be made understandable-

 What is the problem.
 Why it is important to solve the problem?
 What are the possible solutions to the problem?
 What are the data input the system?
 What might complexities that arise while solving the
problem?

CSE@HCST 07/07/2025
Process Model of Elicitation and Analysis

 Each organization will have its own version or

representation .
 This general model depending on local factors,
such as the expertise of the staff, the type of system
being developed, the standards used, etc.
 A generic process model of the elicitation and
analysis process is shown as in fig.

CSE@HCST 07/07/2025
Requirements Elicitation and Analysis Process
Model

CSE@HCST 07/07/2025
C-Requirements Documentation

 Requirements documentation is a very important

activity, which is written after the requirements
elicitation and analysis.
 This is the way to represent requirements in a
consistent format.
 The requirements document is called the Software
Requirements Specification (SRS).

CSE@HCST 07/07/2025
Requirements Documentation

 The SRS is a specification for a particular software

product, program, or set of programs that perform
certain functions in a specific environment.
 It serves a number of purposes depending on who is
writing it-
 First, the SRS could be written by the customer of a
system. in this SRS is used to define the needs and
expectations of the users.
 Second, the SRS could be written by a developer of the
system. It serves as a contract document between
customer and developer.
CSE@HCST 07/07/2025
Requirements Documentation
 Thus, Requirements must be written so they are meaningful
not only to the customers but also to designers on the
development team.
 This Requirements definition document (RDD) describes
what the customer would like to see in this-
 First, we outline the general purpose of the system.
 Next, we describe the background and objectives of system development.
 If the customer has a proposed new approach to solving the problem, we
outline a description of the approach.
 Once we record this overview of the problem, we describe the detailed
characteristics of the proposed system.
 Finally, we discuss the environment in which the system will operate.

CSE@HCST 07/07/2025
D-Requirements Review

 A Requirements review is a manual process, which

involves multiple readers from both client and
developer side, checking the. requirements document
for anomalies and omissions.
 A requirements review can be Informal or Formal.
 Informal Review- informal reviews simply involve
developers discussing requirements with as many system
stakeholders as possible. In this review there is no
conformation that the documented requirements are what
the stakeholders really said they wanted.

CSE@HCST 07/07/2025
 Requirements Review

 Formal Review- in this development team should ‘walk’ to

the client through the system requirements, explaining the
implications of each requirement.
 The review team should check each requirement for consistency
and should check the requirements as a whole for completeness.
Reviewers may also check for-
 Verifiability: are the requirements as stated realistically testable?
 Comprehensibility: is the requirement property understood by the
procurers or end-users of the system?
 Traceability: is the origin of the requirement clearly stated? You may have
to go back to the source of the requirement to assess the impact of a change
 Adaptability: is the requirement adaptable?
CSE@HCST 07/07/2025
Requirements Review

 Conflicts, contradictions, errors, and omissions in

the requirements should be pointed out during the
review and formally recorded.
 It is then up to the users, the system developer to
negotiate a solution to these identified problems.

CSE@HCST 07/07/2025
E-Requirements Management

 Requirements define the capability that the software

system solution must deliver and the intended results that
must result on its application to business problems.
 In order to generate such requirements, a systematic
approach is necessary, through a formal management
process called Requirements Management.
 Requirements management is defined as a systematic
approach to eliciting, organizing, and documenting the
requirements of the system, and a process that establishes
and maintains agreement between the customer and project
team on the changing requirements of the system.
CSE@HCST 07/07/2025
 Classes of Requirements Management

 Classes of Management requirements fall into two classes-

 Enduring Requirements-These are relatively stable
requirements which derive from the core activity of the
organization and which relate directly to the domain of the
system.
 Volatile Requirements-These are requirements which are
likely to change during the system development or after the
system has been put into operation.

CSE@HCST 07/07/2025
Requirements Management Planning

 Requirements management is very expensive and,

for each project, the planning stage establishes the
level of requirements management detail required.
 During the requirements management stage, you
have to decide on-
 Requirements identification.
 A change management process.
 Traceability policies.
 CASE tool support.

CSE@HCST 07/07/2025
INFORMATION MODELING

 The Information Flow Model (IFM) is used to

understand the sources and destination of
information flow, which is required to execute the
business process.
 IFM is generally a high-level model showing main
flows, internal flows of information from sources,
such as product catalogs, and manufacturing
schedules.

CSE@HCST 07/07/2025
INFORMATION MODELING

CSE@HCST 07/07/2025
SA/SD METHODOLOGY

 SA/SD methodology consist of two activities-

 Structural Analysis(SA)
 Structural Design(SD)
 The aim of SA/SD is to transform the textual
description of a problem in to a graphical model.
 During SA/SD the functional decomposition of the
system takes place.

CSE@HCST 07/07/2025
Tools For SA

 Data Flow Diagram(DFD)

 Event List
 Data Dictionary
 Process Specification
 Entity Relationship Diagram
 State Transition Diagram

CSE@HCST 07/07/2025
The Structure of the Analysis Model

CSE@HCST 07/07/2025
DATA-FLOW DIAGRAMS

 Data-Flow Diagrams (DFD) are also known as data-flow

graphs or bubble charts.
 A DFD serves the purpose of clarifying system requirements
and identifying major transformations.
 DFDs show the flow of data through a system.
 It is an important modeling tool that allows us to picture a
system as a network of functional processes.
 Data-flow diagrams are well-known and widely used for
specifying the functions of an information system.
 They describe systems as collections of data that are
manipulated by functions.
CSE@HCST 07/07/2025
 Data can be organized in several ways:
 they can be stored in data repositories, they can flow in data flows, and
they can be transferred to or from the external environment.
 One of the reasons for the success of DFDs is that they can be
expressed by means of an attractive graphical notation that makes them
easy to use.

CSE@HCST 07/07/2025
Symbols Used for Constructing DFDs

 There are different types of symbols used to construct DFDs.

 The meaning of each symbol is explained below:

CSE@HCST 07/07/2025
Symbols Used for Constructing DFDs

CSE@HCST 07/07/2025
CSE@HCST 07/07/2025
 General Guidelines and Rules for Constructing
DFDs

 The following guidelines will help avoid

constructing DFDs that are quite simply wrong or
incomplete.

CSE@HCST 07/07/2025
 Example : Trading-House Automation System (TAS)
 A large trading house wants us to develop a software:
 To automate book keeping activities associated with its
business.
 It has many regular customers:

 Who place orders for various kinds of commodities.

 The trading house maintains names and addresses of
its regular customers.
 Each customer is assigned a unique customer
identification number (CIN).
 As per current practice when a customer places order:
 The accounts department first checks the credit-worthiness
of the customer.
Example: Trading-House Automation
System (TAS)
 The credit worthiness of a customer is
determined:
 By analysing the history of his payments
to the bills sent to him in the past.
 If a customer is not credit-worthy:
 His orders are not processed any further
 An appropriate order rejection message is
generated for the customer.
Example: Trading-House Automation
System (TAS)
 If a customer is credit-worthy:
 Items he/she has ordered are checked
against the list of items the trading house
deals with.
 The items that the trading house does
not deal with:
 Are not processed any further
 An appropriate message for the customer
for these items is generated.
Example: Trading-House Automation
System (TAS)
 The items in a customer's order that
the trading house deals with:
 Are checked for availability in inventory.
 If the items are available in the
inventory in desired quantities:
 A bill with the forwarding address of the
customer is printed.
 A material issue slip is printed.
Example: Trading-House Automation
System (TAS)
 The customer can produce the
material issue slip at the store
house:
 Take delivery of the items.
 Inventory data adjusted to reflect
the sale to the customer.
Example: Trading-House Automation
System (TAS)
 If an ordered item is not available

in the inventory in sufficient

quantity:
 To be able to fulfill pending orders
store details in a "pending-order"
file :
out-of-stock items along with quantity
ordered.
customer identification number
Example: Trading-House Automation
System (TAS)
 The purchase department:
would periodically issue commands

to generate indents.
 When generate indents command is

issued:
 The system should examine the
"pending-order" file
 Determine the orders that are pending
 Total quantity required for each of the
items.
Example: Trading-House Automation
System (TAS)
 TAS should find out the
addresses of the vendors who
supply the required items:
 Examine the file containing
vendor details (their address, items they
supply etc.)
 Print out indents to those
vendors.
Example: Trading-House Automation
System (TAS)
 TAS should also answers
managerial queries:
 Statistics of different items sold
over any given period of time
 Corresponding quantity sold and
the price realized.
Context Diagram
indent
query
Trading-
House-
Manage Automation-
r statistics System
0

order Generat
response e-indent

Custome Purchase-
r Departmen
t
Level 1 DFD
Customer-history Item-file
query

Accept- inventory statistics

Customer-file order
0.1 Handle-
query
0.3
order Process-
Accepted-orders
order
Vendor-list 0.2

Handle-
indent- Sales-statistics
Indent-request request
0.4
Indents pending-order Material-issue-slip +
bill
 Example: Data Dictionary
 response: [bill + material-issue-slip, reject-message]
 query: period /* query from manager regarding sales
statistics*/
 period: [date+date,month,year,day]
 date: year + month + day
 year: integer
 month: integer
 day: integer
 order: customer-id + {items + quantity}*
 accepted-order: order /* ordered items available in
inventory */
 reject-message: order + message /* rejection message
*/
 pending-orders: customer-id + {items+quantity}*
Example: Data Dictionary
 item-name: string
 house#: string
 street#: string
 city: string
 pin: integer
 customer-id: integer
 bill: {item + quantity + price}* + total-amount + customer-
address
 material-issue-slip: message + item + quantity + customer-
address
 message: string
 statistics: {item + quantity + price }*
 sales-statistics: {statistics}*
 quantity: integer
 Level-0

Level-1

CSE@HCST 07/07/2025
How is Structured Analysis Performed?

 Initially represent the software at

the most abstract level:
 Called the context diagram.
 The entire system is represented as
a single bubble,
 This bubble is labelled according to
the main function of the system.
Tic-tac-toe: Context
Diagram
Tic-tac-
display toe
software

move
Human
Player
Context Diagram
 A context diagram shows:
 Data input to the system,
 Output data generated by the

system,
 External entities.
Context Diagram
 Context diagram captures:
 Various entities external to the
system and interacting with it.
 Data flow occurring between the
system and the external entities.
 The context diagram is also called
as the level 0 DFD.
Context Diagram
 Establishes the context of
the system, i.e.
 Represents:
Data sources.
Data sinks.
Level 1 DFD
 Examine the SRS document:
 Represent each high-level function
as a bubble.
 Represent data input to every high-
level function.
 Represent data output from every
high-level function.
 Higher Level DFDs
 Each high-level function is separately
decomposed into sub-functions:
 Identify the sub-functions of the function
 Identify the data input to each sub-
function
 Identify the data output from each sub-
function
 These are represented as DFDs.
 Decomposition
 Decomposition of a bubble:
 Also called factoring or exploding.

 Each bubble is decomposed to

 Between 3 to 7 bubbles.
 Too few bubbles make decomposition
superfluous:
 If a bubble is decomposed to just one or two
bubbles:
 Then this decomposition is redundant.
 Too many bubbles:
 More than 7 bubbles at any level of a DFD.
 Make the DFD model hard to understand.
Decompose How Long?
 Decomposition of a bubble
should be carried on until:
 A level at which the function
of the bubble can be
described using a simple
algorithm.
Example 1: RMS Calculating Software

 Consider a software called RMS

calculating software:
 Reads three integers in the range
of -1000 and +1000
 Finds out the root mean square
(rms) of the three input numbers
 Displays the result.
Example: RMS Calculating Software

 The context diagram is

simple to develop:
 The system accepts 3 integers
from the user
 Returns the result to him.
 Example : RMS Calculating
Software
Data-
items Comput
e- RMS
0

User result

Context Diagram
Example : RMS Calculating Software
 From a cursory analysis of the problem
description:
 We can see that the system needs to perform
several things.
 Accept input numbers from the user:
 Validate the numbers,
 Calculate the root mean square of the
input numbers
 Display the result.
Example : RMS Calculating
Software
number
s
Read- Validate-
number numbers
s 0.2
Valid -
Data- 0.1 number
items error s

Display Comput
0.4 e-rms
0.3
result RMS
Example : RMS Calculating
Software
Square
Calculate d-sum
-squared- Calculate
sum -mean
0.3.1 0.3.2

Valid - Mean-
number square
s Calculate
-root
0.3.3

RMS
Example: RMS Calculating
Software
b
a c
Squar Squar Squar
e e e
0.3.1. 0.3.1. 0.3.1.
1 2 3
bsq
asq csq
Sum
0.3.1.
4

Squared-sum
Example: RMS Calculating Software

 Decomposition is never carried

on up to basic instruction level:
 A bubble is not decomposed any
further:
Ifit can be represented by a
simple set of instructions.
Data Dictionary
 A DFD is always accompanied by a data
dictionary.
 A data dictionary lists all data items
appearing in a DFD:
 Definition of all composite data items in terms
of their component data items.
 All data names along with the purpose of the
data items.
 For example, a data dictionary entry may
be:
 grossPay = regularPay+overtimePay
Importance of Data Dictionary
 Provides all engineers in a project with
standard terminology for all data:
 A consistent vocabulary for data is very
important
 Different engineers tend to use different
terms to refer to the same data,
 Causes unnecessary confusion.
Importance of Data Dictionary
 Data dictionary provides the definition of
different data:
 In terms of their component elements.
 For large systems,
 The data dictionary grows rapidly in size and
complexity.
 Typical projects can have thousands of data
dictionary entries.
 It is extremely difficult to maintain such a
dictionary manually.
Data Dictionary
 CASE (Computer Aided Software
Engineering) tools come handy:
 CASE tools capture the data
items appearing in a DFD
automatically to generate the
data dictionary.
Data Dictionary
 CASE tools support queries:
 About definition and usage of data items.
 For example, queries may be made to find:
 Which data item affects which processes,
 A process affects which data items,
 The definition and usage of specific data items,
etc.
 Query handling is facilitated:
 If data dictionary is stored in a relational
database management system (RDBMS).
Data Definition
 Composite data are defined in terms of
primitive data items using following
operators:
 +: denotes composition of data items, e.g
 a+b represents data a and b.
 [,,,]: represents selection,
 i.e. any one of the data items listed inside the
square bracket can occur.
 For example, [a,b] represents either a occurs
or b occurs.
Data Definition
 ( ): contents inside the bracket
represent optional data
 which may or may not appear.
 a+(b) represents either a or a+b
occurs.
 {}: represents iterative data
definition,
 e.g. {name}5 represents five name
data.
Data Definition
 {name}* represents
 zero or more instances of name data.
 = represents equivalence,
 e.g. a=b+c means that a represents b
and c.
 * *: Anything appearing within *
* is considered as comment.
Data Dictionary for RMS Software
 numbers=valid-numbers=a+b+c
 a:integer * input number *
 b:integer * input number *
 c:integer * input number *
 asq:integer
 bsq:integer
 csq:integer
 squared-sum: integer
 Result=[RMS,error]
 RMS: integer * root mean square value*
 error:string * error message*
Balancing a DFD
 Data flowing into or out of a bubble:
 Must match the data flows at the next level of
DFD.
 In the level 1 of the DFD,
 Data item c flows into the bubble P3 and the
data item d and e flow out.
 In the next level, bubble P3 is decomposed.
 The decomposition is balanced as data item c
flows into the level 2 diagram and d and e flow
out.
Balancing a DFD
c
b c

c1
d1

a d
e
Level 1 d
e1
e
Level 2
Numbering of Bubbles
 Number the bubbles in a DFD:
 Numbers help in uniquely identifying any
bubble from its bubble number.
 The bubble at context level:
 Assigned number 0.
 Bubbles at level 1:
 Numbered 0.1, 0.2, 0.3, etc
 When a bubble numbered x is
decomposed,
 Its children bubble are numbered x.1, x.2, x.3,
etc.
Example 2: Tic-Tac-Toe Computer
Game
 A human player and the computer make
alternate moves on a 3 X 3 square.
 A move consists of marking a previously
unmarked square.
 The user inputs a number between 1 and
9 to mark a square
 Whoever is first to place three consecutive
marks along a straight line (i.e., along a
row, column, or diagonal) on the square
wins.
Example: Tic-Tac-Toe Computer
Game
 As soon as either of the human player or
the computer wins,
 A message announcing the winner should be
displayed.
 If neither player manages to get three
consecutive marks along a straight line,
 And all the squares on the board are filled up,
 Then the game is drawn.
 The computer always tries to win a game.
Context Diagram for
Example
Tic-tac-
toe
display software
0

move
Human
Player
Level 1 DFD
game
Displa
move y-
board result
0.1
Validat Check-
e-move winner
boar 0.4
0.2 d

Play-
move
0.3
Data Dictionary
 Display=game + result
 move = integer

 board = {integer}9

 game = {integer}9

 result=string
CSE@HCST 07/07/2025
CSE@HCST 07/07/2025
CSE@HCST 07/07/2025
CSE@HCST 07/07/2025
 IT Y
T
EN
 IT Y
T
EN

RELATIONSHI
P
 IT Y
T
EN

RELATIONSHI
P

T E
B U
T RI
AT
 IT Y
T
EN

RELATIONSHI KEY FIELD

P

T E
B U
T RI
AT
In the real world,
primary field
names are often
underlined.
Reading the ERD

A Teacher
Reading the ERD

supervises
Reading the ERD

subjects
 Reading the ERD
Each subject has a
name attribute
 Reading the ERD

Th
e
ea pri
ch ma
Su sub ry k
bje jec ey
ctI t is fo
D r
fie the
ld
Reading the ERD

A
su tea
pe
rvi cher
se
s c also
la s
se
s
Reading the ERD

St
be uden
lo t
cla ng s
ss t o
es
Decision Tables

 Decision tables are a precise yet compact way to

model complicated logic.
 Decision tables, like if-then-else and switch-case
statements, associate conditions with actions to
perform.
 But, unlike the control structures found in
traditional programming languages, decision tables
can associate many independent conditions with
several actions in an efficient way.

CSE@HCST 07/07/2025
Decision Tables - Usage

 Decision tables make it easy to observe that all

possible conditions are accounted for.
 Decision tables can be used for-
 Specifying complex program logic.
 Generating test cases (Also known as logic-based
testing).

CSE@HCST 07/07/2025
Decision Tables - Structure

CSE@HCST 07/07/2025
Decision Tables

 Each condition corresponds to a variable, relation or

predicate.
 Possible values for conditions are listed among the
condition.
 Alternatives-
 Boolean values (True / False) – Limited Entry Decision Tables.
 Several values – Extended Entry Decision Tables.
 Don’t care value.
 Each Action is a procedure or operation to perform.
 The entries specify whether (or in what order) the action is
to be performed.
CSE@HCST 07/07/2025
Decision Tables

CSE@HCST 07/07/2025
Decision Tables

CSE@HCST 07/07/2025
Decision Table – Example(Printer Troubleshooting)

CSE@HCST 07/07/2025
Advantages of Decision Tables

The various advantages of decision tables include-

 Decision rules are clearly structured.
 Mangers can be relieved from decision-making.
 Consistency in decision-making.
 Communication is easier between managers and analysts.
 Documentation is easily prepared, changed, or updated.
 Easy to use.
 Easier to draw or modify compared to flowcharts.
 Facilitate more compact documentation.
 Easier to follow a particular path down one column than
through complex and lengthy flowcharts.
CSE@HCST 07/07/2025
Disadvantages of Decision Tables

 The various disadvantages of decision tables

include-
 Impose an additional burden.
 Do not depict the flow.
 Not easy to translate.
 Cannot list all the alternatives.

CSE@HCST 07/07/2025
END

CSE@HCST 07/07/2025