UNIT 2 OOSE 23IT1401

UNIT II ANALYSIS OF SOFTWARE REQUIREMENTS AND ESTIMATION

Software Requirements: Functional and Non-Functional requirements- FURPS
– Software Requirement Specification(SRS)- Characteristics for SRS- IEEE
Standard Requirements Documents -Requirements Analysis- Data Flow
Diagrams(DFD)-Estimation of Software Project- The COCOMO Model-Risk
Management - Reliability Models- Jelinski and Moranda

2.INTRODUCTION
Requirement?
• A requirement is a specification of a need or want.
A requirement can range from a high level abstract statement of a
service or a system to a detailed mathematical functional
specifications.

Types of requirements:

2.1 SOFTWARE REQUIREMENTS:

It is a field within software engineering that deals with establishing the needs
of stakeholders that are to be solved by software.
A software requirement can be of 3 types:
1. Functional requirements
2. Non-functional requirements
3. Domain requirements

FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS:

1
UNIT 2 OOSE 23IT1401

Software system requirements can be classified into Functional and Non-

Functional requirements.
(i) Functional Requirements: A functional requirement describes what a
software system should do.

▪ The functional requirement is describing the behavior of the system as it

relates to the system's functionality.
▪ Eg, Withdrawing money from ATM
▪ When expressed as user requirements, functional requirements are
usually described in an abstract way that can be understood by system
users.
▪ More specific functional system requirements describe the system
functions, its inputs and outputs, exceptions, etc., in detail.
▪ There are many ways of expressing functional requirements e.g., natural
language, a structured or formatted language with no rigorous syntax and
formal specification language with proper syntax.

For example,
a) Examples of functional requirements for the MHC-PMS(mental health care
patient management system )used to maintain information about patients
receiving treatment for mental health problems:

♦ A user shall be able to search or book the appointments in various

clinics.
♦ The system shall generate a list of patients who are expected to
attend appointments that day.
♦ Each staff member shall be uniquely identified by his or her eight-
digit employee number.

b) Examples of functional requirements for the LIBSYS (online Library

Management system)

♦ The user shall be able to search the book by author name,

publisher or book title
♦ The system shall provide appropriate book for the user to read or
download from document store.

2
UNIT 2 OOSE 23IT1401

♦ The user shall able to renew the account using his or her account
details
(ii) Non-Functional Requirements:
▪ They are also called non-behavioral requirements.
▪ It specifies properties and constraints of the system.
▪ The definition for a non-functional requirement is that, it essentially
specifies how the system shouldbehave and that it is a constraint upon
the systems behavior.
▪ Non-Functional Requirements are requirements that are not directly
concerned with the specific services delivered by the system to its users.
▪ Eg, Balance Checking from customer Account
▪ They basically deal with issues like:
− Portability
− Security
− Maintainability
− Reliability
− Scalability
− Performance
− Reusability
− Flexibility

3
UNIT 2 OOSE 23IT1401

▪ Non-functional requirements are often more critical than individual

functional requirements.
▪ Non-functional requirements such as reliability, safety, and
confidentiality requirements are particularly important for critical
systems.
▪ However, failing to meet a non-functional requirement can mean that
the whole system is unusable. For example, if an aircraft system does
not meet its reliability requirements, it will not be certified as safe for
operation;

▪ Non-functional requirements arise through user needs, because of

budget constraints, organizational policies, the need for interoperability
with other software or hardware systems, or external factors such as
safety regulations.
Figure given above is a classification of non-functional requirements.
(a) Product requirements:
These requirements specify the behavior of the software. Examples
include performance requirements on how fast the system must execute
and how much memory it requires, reliability requirements that set out
the acceptable failure rate, security requirements, and usability
requirements.
(b) Organizational requirements:
These requirements are broad system requirements derived from
policies and procedures in the customer’s and developer’s organization.
Examples include operational process requirements that define how the
system will be used, development process requirements that specify the
programming language, the development environment or process
standards to be used, and environmental requirements that specify the
operating environment of the system.
(c) External requirements :

4
UNIT 2 OOSE 23IT1401

This broad heading covers all requirements that are derived from
factors external to the systemand its development process.
These may include regulatory requirements that set out what must be
done for the system to be approved for use by a regulator, such as a
central bank;
legislative requirements that must be followed to ensure that the
system operates within the law; and ethical requirements that ensure
that the system will be acceptable to its users and the general public.
Metrics for specifying non-functional requirements:
Characteristics used when the system is being tested to check whether
system has met its non functional requirements or not.

Difference between Functional and Non-Functional Requirements

Functional Requirement Non Functional Requirement
Defines functions and features of Define properties and constraints
the software system of the software system
Describes " What the system Describes " How the system
should do?" should do?"
Related to business functionalities Related to performance of the
business

5
UNIT 2 OOSE 23IT1401

Easy to Test Difficult to test

Related to individual system Related to system as a whole
requirements
Failure to meet Functional Failure to meet non Functional
requirement may degrade the requirement will make the
system system unusable.

2.2 FURPS
FURPS provides a comprehensive framework for assessing software quality
from multiple angles, helping teams prioritize areas for improvement and
meet both user and business needs effectively.

FURPS is an acronym representing a model for classifying software quality

attributes (functional and non-functional requirements):

o Functionality: Refers to the features and capabilities of the software,

ensuring it meets the specified requirements and performs the tasks it
was intended for. This includes correctness, appropriateness, and
reliability of features.
o Usability: Describes how easy and intuitive the software is for users to
understand and operate. This includes aspects like user interface design,
accessibility, and documentation.
o Reliability: Refers to the software's ability to perform consistently under
expected conditions without failure. It includes the frequency of errors,
availability, and recovery from failures.
o Performance: Measures how well the software performs under different
conditions, such as speed, responsiveness, and scalability. It includes
factors like resource usage and the system's ability to handle increasing
loads.
o Supportability: Describes the ease with which the software can be
maintained and supported over its lifecycle. This includes aspects like
ease of debugging, extensibility, and the ability to adapt to changes in
requirements or the environment.

6
UNIT 2 OOSE 23IT1401

2.3 SOFTWARE REQUIREMENT SPECIFICATION(SRS) &CHARACTERISTICS

FOR SRS
▪ The software requirements document describesthe specification of the
system.
▪ It should include both the user requirements&system requirements.
▪ The software requirements are the base for creating the Software
Requirements Specifications (SRS).
Use of SRS:
▪ The SRS is useful in estimating cost, planning team activities,
performing tasks, and tracking the team’s progress throughout the
development activity.
▪ Software designers use IEEE STD 830-1998 as the basis for the entire
SRS.

Software Requirements Specification

<TITLE>
Version 1.0 approved
Prepared by <author>
<organization>
<date created>

7
UNIT 2 OOSE 23IT1401

8
UNIT 2 OOSE 23IT1401

9
UNIT 2 OOSE 23IT1401

10
UNIT 2 OOSE 23IT1401

11
UNIT 2 OOSE 23IT1401

12
UNIT 2 OOSE 23IT1401

Characteristics of SRS:
▪ Correctness
▪ Unambiguous
▪ Specific
▪ Completeness
▪ Traceable
▪ Consistent
2.4 REQUIREMENT ANALYSIS
Requirement analysis is significant and essential activity after elicitation.
We analyze, refine, and scrutinize the gathered requirements to make
consistent and unambiguous requirements. This activity reviews all
requirements and may provide a graphical view of the entire system.
After the completion of the analysis, it is expected that the understandability
of the project may improve significantly. Here, we may also use the
interaction with the customer to clarify points of confusion and to

13
 P
A
G
E
understand which requirements are more important than others. It includes
following activities: 2
1
a) Requirement discovery
b) Requirement Classification
c) Requirement Prioritization
d) Requirement documentation

(a)Requirement discovery:
Requirement discovery is a process of Interacting with stakeholders to
discover their requirements. Domain requirements are also discovered
at this stage.
 P
A
G
E
Various methods of requirement discovery:
2
● Interviewing 1
● Viewpoints
● Scenarios
● Use cases &
● Ethnography
Interviewing
In formal or informal interviewing, the RE team puts questions to
stakeholders about the system that they use and the system to be
developed.
● There are two types of interview
● Closed interviews where a pre-defined set of questions are answered.
Defined set of questions areanswered.
● Open interviews where there is no pre-defined agenda and a range of
issues are explored withstakeholders.
Scenarios
Scenarios are real-life examples of how a system can be used. They should
include
● A description of the system
● A description of the starting situation;
● A description of the normal flow of events;
● A description of what can go wrong;
● Information about other concurrent activities;
● A description of the state when the scenario finishes.
Viewpoints:
Viewpoints are a way of structuring the requirements to represent the
perspectives of different stakeholders. Stakeholders may be classified
under different viewpoints.
 P
A
G
E

2
1

Use cases:
− Use-cases are a scenario-based technique in the UML which
identify the actors in an interaction and which describe the
interaction itself.
− Set of use cases should describe all possible interactions the system.
 P
A
G
E
Ethnography
2
− It is a technique of observation which is used to understand social and 1
organizational requirements.
− Two types:
● Requirements obtained from working style of people
● Requirement obtained from interactivities performed by people.
(b) Requirements classification
• Groups related requirements and organizes them into coherent
clusters.
(c) Requirements Prioritization
• Prioritizing requirements and resolving requirements conflicts.
(d) Requirements documentation
• Requirements are documented and input into the next round of the
spiral.
2.5 DATA FLOW DIAGRAMS (DFD)

A Data Flow Diagram (DFD) is a graphical representation used to visualize the

flow of data within a system.

It is commonly used in systems analysis and design to model the flow of

information and the processes that transform this data in a system.

The DFD also provides information about the outputs and inputs of each
entity and the process itself. DFD is also known as bubble chart .

It is the starting point of the design phase. A DFD consist of a series of bubbles
joined by lines.

The bubbles represent data transformations and the line represents data flow
in the system.

The DFD is presented in a hierarchical fashion. That is, the first data flow

model (sometimes called a level 0 DFD or context diagram) represents the

 P
A
G
E

2
1

system as a whole. Subsequent data flow diagrams(level 1, 2..) refine the

context diagram, providing increasing detail with each subsequent level.
DFD Symbols:
● A Square defines a source or destination of system data. It is an external
entity.
● An arrow identifies data flow, i.e.: data in motion. It is a pipeline through
which information flows.
● A circle represents a process that transforms incoming data flows into
outgoing data. Process can have level mentioned in it.
● An open rectangle is a data store, i e, data at rest or a temporary
repository of data. also called files or databases.
Rules for constructing DFD:
o Processes should be named and numbered for easy reference.
o The direction of flow is from top to bottom and from left to
right. Data flows from source to the destination.
o Process should be numbered, if they are exploded into lower level
details.
o Process should not have only inputs or only outputs. It must have

both inputs and outputs.

o There should not be a direct flow between data store and external
 P
A
G
E
entity.
2
1

o The names of data stores, sources and destination should be in

capital letters.
Process and data flow names first letter should be in capital letter.
o The level 0 data flow diagram should depict the
software/system as a single bubble;
o All arrows and bubbles should be labelled with meaningful names;
o Information flow continuity must be maintained from level to level.

Example 1: Data flow diagram for safe home system:

The SafeHome security function enables the homeowner to configure the

security system when it is installed, monitors all sensors connected to the
security system, and interacts with the homeowner through the Internet, a
PC, or a control panel.
During installation, the SafeHome PC is used to program and configure the
system. Each sensor is assigned a number and type, a master password is
programmed for arming and disarming the system, and telephone
number(s) are input for dialing when a sensor event occurs.
When a sensor event is recognized, the software invokes an audible alarm
attached to the system. After a delay time that is specified by the
homeowner during system configuration activities, the software dials a
telephone number of a monitoring service, provides information about the
 P
A
G
E
location, reporting the nature of the event that has been detected. The
telephone number will be redialed every 20 seconds until telephone 2
connection is obtained. The homeowner receives security information via a 1

control panel, the PC, or a browser, collectively called an interface. The

interface displays prompting messages and system status information on
the control panel, the PC, or the browser window.
Level 0:

Fig: Context-level DFD( Level 0) for the SafeHome Security

function
The level 0 DFD must now be expanded into a level 1 data flow model.
Level 1 DFD :
 P
A
G
E

2
Level 2: 1

Example 2: Automated Railway Reservation

System :
Level 0 DFD:
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

Level 2 DFD:
Estimation of SoftwareProject
● Generally too many variables—human, technical, environmental,
political—can affect the ultimate cost of software and effort applied
to develop it. Software cost, time and effort estimation never be
exactly done till we finish the project.
● Many factors can affect the estimation (human, technical,
environmental, political).

2.6 THE COCOMO MODEL

The Constructive Cost Model (COCOMO) is a software cost estimation model
that helps predict the effort, cost, and schedule required for a software
development project.
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

Developed by Barry Boehm in 1981, COCOMO uses a mathematical formula

based on the size of the software project, typically measured in lines of code
(LOC).
The key parameters that define the quality of any software product, which are
also an outcome of COCOMO, are primarily effort and schedule:
1. Effort: Amount of labor that will be required to complete a task. It is
measured in person-months units.
2. Schedule: This simply means the amount of time required for the
completion of the job, which is, of course, proportional to the effort put in.
It is measured in the units of time such as weeks, and months.
Types of Projects in the COCOMO Model
In the COCOMO model, software projects are categorized into three types
based on their complexity, size, and the development environment. These
types are:
1. Organic: A software project is said to be an organic type if the team size
required is adequately small, the problem is well understood and has been
solved in the past and also the team members have a nominal experience
regarding the problem.
2. Semi-detached: A software project is said to be a Semi-detached type if the
vital characteristics such as team size, experience, and knowledge of the
various programming environments lie in between organic and embedded.
The projects classified as Semi-Detached are comparatively less familiar
and difficult to develop compared to the organic ones and require more
experience better guidance and creativity. Eg: Compilers or different
Embedded Systems can be considered Semi-Detached types.
3. Embedded: A software project requiring the highest level of complexity,
creativity, and experience requirement falls under this category. Such
software requires a larger team size than the other two models and also
the developers need to be sufficiently experienced and creative to develop
such complex models.

2.7 RISK MANAGEMENT:

23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

Risk:A risk is defined as a potential problem or uncertainty which may

occur or may not occur in a software project.
Risk management:.
⮚ Risk management involves anticipating risks that might affect the
project schedule or the quality of the software being developed,
and then taking action to avoid these risks.
Software risk:
● Uncertainty (risk may or may not happen, that is, there are no 100
percent probable risks)
● Loss (if risk occurs it provides some loss or consequence)

Risk strategy:
Reactive: Proactive:
Action that is taken after the Plan is established and risk is
Risk is occurred. When This predicted/ identified before it
reactive strategy fails, Project is occurs.
in danger.

Categories of risk:
1. Project risks threaten the project plan. That is, if project risks become
real, it is likely that the project schedule will slip and that costs will
increase.
Project risks identify potential budgetary, schedule, personnel (staffing
and organization), resource, stakeholder, and requirements problems
and their impact on a software project.
2. Technical risks threaten the quality and timeliness of the software to be
produced. If a technical risk becomes a reality, implementation may
become difficult or impossible. Technical risks identify potential design,
implementation, interface, verification, and maintenance problems
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

3. Business risks threaten the viability of the software to be built and often
jeopardize the project or the product. Candidates for the top five
business risks are
✔ Market risk: building an excellent product or system that no one
really wants
✔ Strategic risk :Building a product that no longer fits into the
overall business policy of the company.
✔ Sales risk: Building a product that the sales force doesn’t
understand how to sell.
✔ Management Risk: Loosing the support of senior management due
to a change in focus or a change in people.
✔ Budget risks: Loosing budgetary or personnel commitment
4. Known risks are those that can be uncovered after careful evaluation of
the project plan. (e.g., unrealistic delivery date, lack of documented
requirements or software scope, poor development environment).
5. Predictable risksare extrapolated from past project experience
(e.g., staff turnover, poor communication with the customer, dilution of
staff effort as ongoing maintenance requests are serviced).
6. Unpredictable risksare the joker in the deck. They can and do occur, but
they are extremely difficult toidentify in advance.
Seven Principles of Risk Management:
1. Maintain a global perspective: view software risks within the context of
a system in which it is acomponent and the business problem that it is
intended to solve.
2. Take a forward-looking view: think about the risks that may arise in the
future (e.g., due to changes inthe software); establish contingency plans
so that future events are manageable.
3. Encourage open communication if someone states a potential risk, don’t
discount it. If a risk is proposed in an informal manner, consider it.
Encourage all stakeholders and users to suggest risks at any time.
4. Integrate- a consideration of risk must be integrated into the software
process.
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

5. Emphasize a continuous process the team must be vigilant throughout

the software process,modifying identified risks as more information is
known and adding new ones as better insight is achieved.
6. Develop a shared product vision if all stakeholders share the same vision
of the software, it is likelythat better risk identification and assessment
will occur.
7. Encourage teamwork -the talents, skills, and knowledge of all
stakeholders should be appreciated.
Risk Management Process:
The risk management process is an iterative processthat continues
throughout the project.
i. Risk identification
ii. Risk projection
iii. Risk refinement
iv. Risk mitigation, monitoring and mitigation

Fig: The Risk Management Process

2.8 RELIABILITY MODELS- JELINSKI AND MORANDA
The Jelinski and Moranda model is one of the early software reliability
models developed to predict the number of remaining faults in a software
system as it undergoes testing. It is a non-homogeneous Poisson process
(NHPP) model, meaning that it models the occurrence of faults over time (or
test cycles) as a process that can change its rate of occurrence.
Jelinski-Moranda Model :

1. Fault Occurrence: The occurrence of faults during testing follows a

Poisson process, meaning the faults are randomly distributed over time.
2. Fault Removal: Once a fault is found and fixed, it does not appear again.
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

3. Non-Homogeneous Rate: The rate of fault occurrence can change over

time, typically decreasing as more faults are detected and fixed.
4. Constant Fault Detection Rate: The model assumes that during testing,
the probability of detecting a fault is constant for any test cycle.
5. Finite Number of Faults: There is a finite number of faults in the
software, and the goal is to estimate how many faults remain in the
system at any given time.

Estimating Faults Remaining:

The Jelinski-Moranda model can be used to estimate the number of remaining
faults N(t)N(t)N(t) after a certain number of test cycles or time, helping
software engineers assess the reliability of the software during the testing
phase.
Applications:

● Software Testing: The model helps estimate the remaining number of

faults as testing progresses, aiding decision-making about when to
release the software.
● Reliability Prediction: It can be used to predict the future reliability of
the software system after a certain number of test cycles.

*******************
PART A
1. Write distinct steps in requirement engineering process (M/J 2006)
♦ Feasibility studies ( if the system is useful to the business)
♦ Requirement elicitation and analysis (discovering requirements)
♦ Requirement validation (converting these requirements into some
standard form)
♦ Requirement management (checking that the requirements actually
define the system that the customer wants)
2. Define Software Requirements.
It is a field within software engineering that deals with establishing the
needs of stakeholders that are to be solved by software.
A software requirement can be of 3 types:
o Functional requirements
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

o Non-functional requirements
o Domain requirements
3. Why SRS must be traceable? What is traceability requirement? (N/D
2005)
There may be chances of having new requirements during development
of the software. traceability is concerned with relationship between
requirements their sources and system design. thus change in
requirements is manageable if SRS is traceable.
4. List the characteristics of Good SRS. (M/J 2016)

Characteristics of SRS:
▪ Correctness
▪ Unambiguous
▪ Specific
▪ Completeness
▪ Traceable
▪ Consistent
5. Differentiate between Functional and Non Functional Requirements
Functional Requirement Non Functional Requirement
Defines functions and features of Define properties and constraints
the software system of the software system
Describes " What the system should Describes " How the system
do?" should do?"
Related to business functionalities Related to performance of the
business
Easy to Test Difficult to test
Related to individual system Related to system as a whole
requirements
Failure to meet Functional Failure to meet non Functional
requirement may degrade the requirement will make the system
system unusable.
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

6. Write the difference between user and system requirements. (M/J

2016)
User Requirements System Requirements
Focus on Problem domain Focus on Solution Domain
Tells what the application should do Tells the system should have to do
to satisfy user needs to run the program

7. Define DFD? Draw the notations for DFD.

A data-flow diagram (DFD) is a way of representing a flow of
a data of a process or a system (usually an information system). The
DFD also provides information about the outputs and inputs of each
entity and the process itself. DFD is also known as bubble chart .
Notations :

8. Write down the Rules for designing DFD?

Rules for drawing DFD:

o Processes should be named and numbered for easy reference.

o The direction of flow is from top to bottom and from left to right.
Data flows from source to the destination.
o Process should be numbered, if they are exploded into lower level
details.
o Process should not have only inputs or only outputs. It must have
both inputs and outputs.
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

o There should not be a direct flow between data store and external
entity.
o The names of data stores, sources and destination should be in
capital letters. Process and data flow names first letter should be
in capital letter.
o The level 0 data flow diagram should depict the software/system as a
single bubble;
o All arrows and bubbles should be labelled with meaningful names;
o Information flow continuity must be maintained from level to level.
o List the notations used in data flow models. ( M/J 2014)
9. What is context level in DFD? Draw the context flow graph of ATM
automation system (N/D 2017)
Level 0 DFD is called context level DFD

10. What are the linkages between data flow and ER diagram.(M/J
2016)
- Both ER diagram and DFD diagrams are system modeling
diagrams.
- But ER diagram is used to represent Data Model
- DFD is used to represent Functional Model
11. Draw use case diagram for an online shopping which should
provide provisions for registering , authenticating the customers
and also for online payment through any payment gateway like
paypal.(N/D'17)
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

12. Classify the following functional and non functional requirements

for a banking system. (N/D 2016)
▪ Verifying bank balance
▪ Withdrawing money from bank
▪ Completion of transactions in less than one second
▪ Extending the system by providing more tellers for customers

Part B:
1. Explain the metrics used for specifying non functional requirements(8).
(M/J 2013)

2. List the stakeholders and all types of requirements for an online train
reservation system. (N/D 17)
3. i) Differentiate between user and system requirements. (4)
ii) Describe the requirements change management process in detail
(12) (M/J 2016)/
4. What is SRS? Explain in detail the various components of an SRS?
(M/J 2018)/ What are the components of the standard structure for
the software requirements document? Explain in detail. (M/J 2014)/
Write the software requirement specification for a system of your
choice.
5. (i) Explain the organization of SRS and highlight the importance of
each subsection.
(ii) Requirement analysis is unquestionably the most communication
intensive step in the software engineering (M/J 2016)
6. What is Requirement engineering? Explain in detail the various
processes in requirement engineering. (13) (M/J 2017) Explain
Software requirement engineering process with neat diagram. (N/D
2015)/ Write about the following requirement engineering activities
(Inception, Elicitation, Elaboration, Negotiation, Specification,
Validation, Requirement management) (M/J 2015)
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

7. (i) How will you classify the requirement types for a project , give
example (3)
(ii) List the stake holders and all types of requirements for online
train reservation system (7) (N/D'17)
Soln:
Stake holders:
▪ Passenger
▪ Database Administrator
▪ Booking clerk
▪ Bank

Functional Requirements:
▪ The system should allow the passenger to register and login.
▪ The system should provide search option to the user so that user can
search for required train and for required number of reservations.
▪ Online booking made by the customer must be associated with
customer account registered.
▪ Booking confirmation must be sent to passenger on specified contact
details/ mail id.
▪ The system should allow the user to make online payments.
▪ The system should allow the user to cancel the booking and half of
the amount paid by the customer must be refunded to him/her.
Non Functional Requirements:
▪ The system should be available to the user for 24/7 (availability)
▪ The system should accept the payments via different payment
options like paypal, wallet, cards, net banking etc.
▪ Use of captcha and encryption to avoid bots from booking tickets for
security purpose.
▪ The response time of the system should be less while searching,
booking or cancellation operations.
▪ User Interface should be simple and easy
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

8. What is the purpose of data flow diagrams? What are the notations used
for the same. Explain by constructing a context flow diagram level -0 DFD
and level-1 DFD for a library management system? (NOV/DEC 2016)
Soln: DFD level 0:

DFD Level 2
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

9. Draw Use case and Dataflow diagrams for "Restaurant System". The
Activities of Restaurant System are listed below:
Receive the customer food orders, produce the customer ordered foods,
Serve the customer with ordered foods, Collect payment from customers,
Store customer payment details, Order raw materials for food products, pay
for raw materials and pay for labor. (16) (M/J 2015, N/D 2016)
Soln:
Usecase Diagram for "Restaurant System” :
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

DFD for Restaurant Food Ordering system:

Level 0 DFD
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

Level 1 DFD: In this level bubble 0.0 is shown more in detail:

Level 1 DFD for Update for inventory file:

23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

Level 2 DFD:
Here we elaborate “generate management report” activity more in
detail.
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

10. Consider an online railway reservation system which allows the

user to select route , book, cancel tickets using net banking/credit/debit
cards. The site also maintains the history of the passengers. For the
above system, list and draw the use case scenario and model the above
specification using dataflow diagram. (16) (N/D 2015)
Soln:
The usecase for the given scenario are:
● Login
● Select route
● Book or cancel ticket
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

● View status
● Logout
Use Case Diagram:

Level 0 DFD:
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

Level 1 DFD:

11. Tamil Nadu Electricity Board (TNEB) would like to automate its billing
process. Customers apply for a connection( domestic/commercial). EB
staff take readings and update the system each customer is required to
pay charges bu-monthly according to the artes for the type of connection.
Customers can choose to pay either by cash / card. A bill is generated on
payment. Monthly reports are provided to the EB manager. (N/D 2013)
(i) Give a name for the system (1)
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

(ii) Draw the level 0 DFD( context Flow Diagram) (5)

(iii) Draw the level 1 DFD (10)
Soln:
Name: Electricity Bill Management system
Level 0 DFD:

Level 1 DFD:
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

12. Design DFD for Hotel reservation system

Level 0:

Level 1:
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

Level 2:

13. Prepare a CFD for Books order processing system:

Level 0:
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

Level 1:

Level 2 DFD:
We can further decompose the system by elaborating the process Assemble
Order.
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

13. Develop a dataflow diagram for burglar alarm system along with entity
relationship diagram (8)
Level 0 DFD:

Level 1 DFD:
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

ER Diagram for Burglar Alarm System:

ER – Entiry Relationship diagram is based on a perception of a real world that consists
of a collection of basic objects called entities and of relationships among these objects.
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

14. Consider the process of ordering a pizza over the phone. Draw the use
case diagram and sketch the activity diagram representing each step of
the process, from the moment you pick up the phone to the point where
you start eating the pizza. Include activities that others need to perform.
Add exception handling to the activity diagram you developed. Consider
at least two exceptions. (Ex: Delivery person wrote down wrong address,
deliver person brings wrong pizza(13). (N/D 2017)
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

Activity Diagram:
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

Use case diagram for Pizza ordering system:

23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

Part C:
1. Model a Dataflow diagram for "Library Management system". State
the functional requirements you are considering(15) (N/D 2017) /
Design DFD for library management system for level 0 and level 1 DFD
(N/D 2016)

2. What is the purpose of DFD? What are the components of DFD?

Construct DFD for the following system:
An Online shopping system for XYZ provides many services and
benefits to its members and staffs. Currently, XYZ staffs manually handle
the purchasing information with the use of basic office software, such as
Microsoft office word and Excel. It may result in having mistakes easily
and the process is very inconvenient. XYZ needs an online shopping
system at their Intranet based on the requirements of users. XYZ online
shopping system has five key features:
i) to provide the user friendly online shopping cart function to members to
replace hardcopy ordering form;
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

ii) to store inventory and sales information in database to reduce the

human mistakes, increase accuracy and enhance the flexibility of
information processing;
iii) to provide an efficient inventory system which can help the XYZ staffs
to gain enough information to update the inventory;
iv) to be able to print invoices to members and print a set of summary
reports for XYZ's internal usage;
v) to design the system that is easy to maintain and upgrade (15) (M/J
2018)
Level 0 DFD:

Level 1 DFD:
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

Level 2: For manage order

Level 2 DFD for manage items:

23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

3. Consider an online book stores. It accepts individuals/bulk orders

, process payments, triggers delivery of the books. Some of the major
features of the system include:
order books
i.User friendly online shopping cart function
ii.Create, view, modify and delete books to be
iii. To store inventory and sales information in database
iv. To provide an efficient inventory system
v. Register for book payment options
vi. Request book delivery
vii. Add a wish list
viii. Place request for books not available
ix. To be able to print invoices to members and print a set of summary
reports
x. Internet access
Analyze the system using the context diagram and level 1 DFD for the
system. Explain the components of DFD. (15) (A/M 2017)
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

Level 0 DFD:

Level 1 DFD:
23IT1401OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II