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.

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

2.1.1 FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS:

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

1
UNIT 2 OOSE 23IT1401

 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.
 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.

2
UNIT 2 OOSE 23IT1401

▪ 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

▪ Non-functional requirements are often more critical than individual

functional requirements.

3
UNIT 2 OOSE 23IT1401

 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 :
This broad heading covers all requirements that are derived from
factors external to the systemand its development process.

4
UNIT 2 OOSE 23IT1401

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 of
the software system the software system

5
UNIT 2 OOSE 23IT1401

Describes " What the system Describes " How the system should
should do?" 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.

2.1.2 DOMAIN REQUIREMENTS:

In software engineering, domain requirements are the expectations for a
software system in a specific industry or application area. They can be
functional or non-functional requirements.
For instance, in an academic software that maintains records of a school or
college, the functionality of being able to access the list of faculty and list of
students of each grade is a domain requirement.

Why are domain requirements important?

 They ensure that the system meets the needs of the users and
stakeholders
 They help ensure that the system meets established standards
 They help ensure that the system is usable and acceptable for
production
They help ensure that the system is safe and reliable
Examples of domain requirements
 For medical equipment, the software must meet IEC 60601 standards
for safety and performance
 For financial software, the software must meet Generally Accepted
Accounting Principles standards
 For train control systems, the system must take into account braking
characteristics in different weather conditions

6
UNIT 2 OOSE 23IT1401

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

7
UNIT 2 OOSE 23IT1401

ease of debugging, extensibility, and the ability to adapt to changes in

requirements or the environment.

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>

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

13
UNIT 2 OOSE 23IT1401

Characteristics of SRS:
- Correctness
- Unambiguous
- Specific
- Completeness
- Traceable
- Consistent

2.4 REQUIREMENT ANALYSIS

REQUIREMENT ELICITATION AND 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.

14
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

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
understand which requirements are more important than others. It includes
following activities:
a) Requirement discovery b)Requirement Classification
c) Requirement Prioritization d) Requirement documentation

15
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

Fig: Requirement Elicitation and Analysis Process

(a)Requirement discovery:
Requirement discovery is a process of Interacting with stakeholders to
discover their requirements. Domain requirements are also discovered
at this stage.
Various methods of requirement discovery:
 Interviewing
 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 are answered.
 Open interviews where there is no pre-defined agenda and a range of
issues are explored with stakeholders.
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.

16
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

Viewpoints: Viewpoints are a way of structuring the requirements to

represent the perspectives of different stakeholders. Stakeholders may be
classified under different viewpoints.

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.
Ethnography
− It is a technique of observation which is used to understand social and
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

17
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

• 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 .
18
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

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

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.

19
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

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
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.

Example 1: Data flow diagram for safe home system:

The SafeHome security function enables the homeowner to configure the

20
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

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
location, reporting the nature of the event that has been detected. The
telephone number will be redialed every 20 seconds until telephone
connection is obtained. The homeowner receives security information via a
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:2 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.

21
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

Level 1 DFD :

Level 1 DFD for SafeHome security function

Level 2:

22
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

Example 2: Automated Railway Reservation System :

Level 0 DFD:

Level 1 DFD

Level 2 DFD:

23
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

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.
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 labour 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.

24
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

3 Types of COCOMO model

i. BASIC
ii. INTERMEDIARY MODEL &
iii. DETAILED MODEL

Types of Projects in the COCOMO Model

In the COCOMO model, any software projects will be categorized into one of
the three types based on their complexity, size, and the development
environment. These types are:

Software Project Types:

1. Organic: Small teams with good experience work on well-understood

problems.
2. Semi-detached: Medium complexity projects needing moderate
experience and creativity (e.g., compilers, embedded systems).
3. Embedded: Highly complex projects requiring large, experienced teams
and high creativity.

25
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

26
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

27
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

28
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

29
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

30
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

31
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

2.7 RISK MANAGEMENT:

Risk:A risk is defined as a potential problem or uncertainty which may
occur or may not occur in a software project.
Risk management:.

32
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

⮚ 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
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.
33
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

 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 risks are 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 risks are the joker in the deck. They can and do occur, but
they are extremely difficult to identify 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 a component 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 in the 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.
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 likely that better risk identification and assessment
will occur.
7. Encourage teamwork -the talents, skills, and knowledge of all
stakeholders should be appreciated.

34
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

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

RISK IDENTIFICATION:
- It is a process of Identifying the risks that could cause major threat to
the software engineering process, the software being developed, or the
development organization.
- By identifying known and predictable risks, the project manager takes a
first step toward avoiding them when possible and controlling them
when necessary.
- One method for identifying risks is to create a risk item checklist.

35
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

RISK ASSESSMENT:
The following questions have been derived from risk data obtained by
surveying experienced software project managers
1. Have top software and customer managers formally committed to
support the project?
2. Are end users enthusiastically committed to the project and the
system/product to be built?
3. Are requirements fully understood by the software engineering team
and its customers?
4. Have customers been involved fully in the definition of requirements?
5. Do end users have realistic expectations?
6. Is the project scope stable?
7. Does the software engineering team have the right mix of skills?
8. Are project requirements stable?
RISK REFINEMENT:
- It is possible to refine the risk into a set of more detailed risks, each
somewhat easier to mitigate, monitor, and manage.
- One way to do this is to represent the risk in Condition-Transition
Consequence (CTC) format.

36
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

RISK MITIGATION, MONITORING, AND MANAGEMENT(RMMM):

Risk Mitigation means preventing the risk from occurring( Risk
Avoidance)
Risk mitigation measures can be directed towards reducing the
severity of risk consequences, reducing the risk materializing, or
reducing the organizations exposure to the risk.
Risk Monitoring And Control:
 It is the process of identifying, analyzing, and planning for newly
discovered risks and managing identified risks.
 Following things need to be monitored by the project manager:
- Behaviour of the team members when they are under pressure
- Spirit of team members for 'team work'
- Types of problems occurring among team members
- Availability of jobs within or outside the organization
Objective of risk monitoring is,
- To check whether the predicted risk really occur or not
- To ensure that the steps that are already defined to
avoid risk are applied properly or not
Risk Management:
 It is the identification, assessment, and prioritization of risks.
 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.
Example: Risk Management During Estimation for a Credit Card
Processing System:
1. Identify Risks: Spot technical (e.g., security compliance), project (e.g.,
tight deadlines), and external risks (e.g., legal changes).
2. Assess Risks: Evaluate likelihood and impact using tools like a Risk
Matrix.
3. Plan Mitigation: Allocate extra time/resources for high-risk areas and
design modular components.
4. Add Buffers: Use contingency buffers and PERT for more accurate
estimates.

37
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

5. Communicate: Keep stakeholders informed about risks and their effect

on timelines and costs.
6. Monitor: Regularly review risks and adjust plans as needed

2.8 RELIABILITY MODELS- JELINSKI AND MORANDA

The Jelinski-Moranda (J-M) model is one of the earliest software reliability
models. Many existing software reliability models are variants or extensions
of this basic model. It is developed to predict the number of remaining faults
in a software system as it undergoes testing. The Jelinski-Moranda (JM)
Software Reliability Model is a mathematical model developed in 1972 by M.A.
Jelinski and P.A. Moranda. It is used to predict the reliability of software
systems, particularly during the testing and debugging phases.
This model assumes that software failures occur randomly over time and that
the likelihood of these failures decreases as bugs are found and fixed.
The model represents the software as a series of independent components,
each with a constant failure rate, and uses an exponential distribution to
model the rate at which faults are detected. By understanding these patterns,
software engineers can estimate the number of remaining faults and the time
required to reach a desired level of reliability. 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.
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.

38
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

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.

One limitation of the Jelinski-Moranda model is that it assumes a constant

fault detection rate, which may not be accurate in practice. Additionally, the
model does not take into account factors such as software complexity,
hardware reliability, or user behavior, which can also affect the reliability of
the software system.

The Jelinski-Moranda model is a useful tool for predicting software reliability,

but it should be used in conjunction with other techniques and methods for
software testing and quality assurance.

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.

Advantages of the Jelinski-Moranda (JM) Software Reliability Model

 Simple, easy to understand and widely used in software engineering
 provide valuable insights into the reliability of software systems over
time
 Flexible and can be used to model different types of software systems.
 The JM model can be implemented using basic statistical tools.
 Relies on empirical data to make predictions
 Cost-effective tool for software testing and maintenance
*******************

39
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

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
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

40
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

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.

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 :

41
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

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.
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)

42
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

- 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)
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)

43
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

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)

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.

44
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

▪ 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
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:

45
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

DFD Level 2

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” :

46
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

47
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

DFD for Restaurant Food Ordering system:

Level 0 DFD

48
23IT1401 OBJECT 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:

49
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

Level 2 DFD:
Here we elaborate “generate management report” activity more in
detail.

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:

50
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

● Login
● Select route
● Book or cancel ticket
● View status
● Logout
Use Case Diagram:

Level 0 DFD:

51
23IT1401 OBJECT 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)
52
23IT1401 OBJECT 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:

53
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

12. Design DFD for Hotel reservation system

Level 0:

Level 1:

Level 2:

54
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

13. Prepare a CFD for Books order processing system:

Level 0:

Level 1:

55
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

Level 2 DFD:
We can further decompose the system by elaborating the process Assemble
Order.

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

56
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

Level 1 DFD:

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
57
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

at least two exceptions. (Ex: Delivery person wrote down wrong address,
deliver person brings wrong pizza(13). (N/D 2017)
Activity Diagram:

58
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

Use case diagram for Pizza ordering system:

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:

59
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

i) to provide the user friendly online shopping cart function to members to

replace hardcopy ordering form;
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:

60
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

Level 2: For manage order

Level 2 DFD for manage items:

61
23IT1401 OBJECT 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)

Level 0 DFD:

62
23IT1401 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT II

Level 1 DFD:

63