UNIT-II

KCS- 01
SOFTWARE
ENGINEERING
PART-I

Software Engineering
Syllabus
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.
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).
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.
REQUIREMENT ENGINEERING

Fig: The Process of Determining

Requirements
REQUIREMENT ENGINEERING

◻ TheInput 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.
 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.
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.
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.
Types of Requirements
REQUIREMENTS ENGINEERING
PROCESS

Fig: Process Steps of Requirements Engineering

REQUIREMENTS ENGINEERING
PROCESS

(Revie
w)
 REQUIREMENTS ENGINEERING PROCESS

◻ Requirements engineering consists of the following

processes-
A. Feasibility study
B. Requirements Elicitation.
C. Requirements Analysis and Modeling.
D. Requirements Documentation.
E. Requirements Review(Validation).
F. Requirements Management.
A. Feasibility Study
Feasibility study can be divided into
following:
1. Economic feasibility
2. Technical feasibility
3. Legal feasibility
4. Organizational feasibility (man power
resources and work culture of organization)
 B-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.
 Requirements Elicitation

◻ The Requirements are gathered from various sources

for elicitation.
◻ The Sources are-
■ Customer (Initiator).
■ End Users.
■ Primary Users.
■ Secondary Users.
■ Stakeholders.
 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
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.
Interviews

The following steps in interviews are-

🞑 Create the Questionnaire.
🞑 Select the Interviewer.
🞑 Plan Contacts.
🞑 Conduct the interview(face to face).
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.
Brainstorming

◻ Roles for a Brainstorming Session-

🞑 Leader-(facilitator or moderator).
🞑 Scribe(penman) (one who writes; a draughtsman)

🞑 Participant(involved many stakeholders).

3-Facilitated Application Specification
Techniques(FAST).

◻ This technique was specifically for

collecting
developedrequirements similar to
brainstorming.
and
◻ 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.
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.
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.
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.
 -Quality Function Deployment.

◻ This is a technique of Quality Management that helps

to incorporate the voice of customers.
◻ Transform the voice of the customer [VOC]
into engineering characteristics for a product.
◻ 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.
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:
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.
8-Delphi Technique
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.
 C-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.
 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.
 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?
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.
Requirements Elicitation and Analysis
Process Model
D-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).
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.
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.
E-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.
 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?
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.
F-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.
 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.
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.
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.
INFORMATION MODELING
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.
Tools For SA

◻ Data Flow Diagram(DFD)

◻ Event List
◻ Data Dictionary
◻ Process Specification
◻ Entity Relationship Diagram
◻ State Transition Diagram
Tools for SD
◻ Structure charts
The Structure of the Analysis Model
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.
◻ 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.
Symbols Used for Constructing DFDs

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

◻ The meaning of each symbol is explained below:
Symbols Used for Constructing DFDs
 General Guidelines and Rules for
Constructing DFDs

1. Synchronous and Asynchronous

Operations

Synchronous(no time
delay)

Asynchronous(time
delay)
► 2. Data Dictionary

► The data dictionary is used to create and store definitions of data,

location, format for storage andother characteristics.

► The data dictionary can be used to retrieve the definition of data that
hasalready been used in an application.

► The data dictionary also stores some of the description of data

► structures, such as entities, attributes and relationships.
► For e.g.

, a:{integer}
etc.
Symbols
used:
► 3. Levels of DFD Model
► 4. Balancing of DFD
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.
Tic-tac-toe: Context
Diagram
Tic-tac-
display software
toe

move
Human Player
 Example 2: RMS Calculating Software.

A software system called RMS calculating software would read three integral
numbers
from the user in the range of -1000 and +1000 and then determine the root
mean
square (rms) of the three input numbers and display it.
The system accepts three integers from the user and returns the result to
him.

Level 0 / Context
diagram
Level
1
Example 3: 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-stockitems 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-
Manager Automation-
statistics System
0
order Generate
response
-indent
Customer Purchase-
Department
Level 1 DFD
Customer-history Item-file
query

Accept- inventory statistics

Customer-file order
Handle-
0.1
query
order Process- 0.3
Accepted-orders
order
Vendor- 0.2
list
Handle-
indent- Sales-statistics
Indent-request
request
Indents 0.4 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}*
◻ customer-address: name+house#+street#+city+pin
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
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.
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.
Precautions while making DFD’s

► 1. Avoid Data cluttering

Decision Tree
Decision Table
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
Display
move -board
0.1 result

Validate Check-
-move winner
board 0.4
0.2

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

◻ board = {integer}9

◻ game = {integer}9

◻ result=string
RELATIONSHI
P
RELATIONSHI
P
 KEY FIELD
RELATIONSHI
P
 In the real world,
primary field names
are often
underlined.
Reading the ERD

A
Teacher
Reading the ERD

supervise
s
Reading the ERD

subject
s
Reading the ERD
Each subject has a
name attribute
Reading the ERD
Reading the
ERD
Reading the ERD
Decision Tables

◻ Decision tables are a precise yet

compact way to
model complicated logic.
◻ Decision tables, if-then-else and switch-case

like
statements, associate conditions with actions
◻ But, unlike the control structures found to in
traditional
perform. programming languages, decision tables
can associate many independent conditions with
several actions in an efficient way.
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 knownas
logic-based testing).
Decision Tables - Structure
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.
Decision Tables
Decision Tables
Decision Table – Example(Printer Troubleshooting)
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.
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.
EN
D