Object Oriented Software Engineering

(OOSE)
24CSE0210

Requirement Engineering Process

Prepared By:
Dr. Shikha

1
 Index

• Requirement Engineering
• Feasibility Study
• Requirement Elicitation and Analysis
• Software Requirement Management
• Classification of Software Requirements
• Building Analysis Model
• Flow Oriented Modelling

2
Requirement Engineering
• Before you begin any technical work, it’s a good idea to apply a set of
requirements engineering tasks.
• These tasks lead to an understanding of what the business impact of the
software will be, what the customer wants, and how end users will interact
with the software.
• Requirement Engineering is the process of defining, documenting and
maintaining the requirements.
• It includes the following processes:
– Feasibility Study
– Requirement Elicitation and Analysis
– Software Requirement Specification
– Software Requirement Validation
– Software Requirement Management

3
Requirement Engineering

Figure 1: Process of Requirements engineering

4
Feasibility Study
• The objective behind the feasibility study is to create the reasons for developing
the software that is acceptable to users, flexible to change and conformable to
established standards.

Types of Feasibility:

1. Technical Feasibility - It evaluates the current technologies, which are needed to

accomplish customer requirements within the time and budget.
2. Operational Feasibility - It assesses the range in which the required software
performs a series of levels to solve business problems and customer
requirements.
3. Economic Feasibility - It decides whether the necessary software can generate
financial profits for an organization.

5
Requirement Elicitation and Analysis

• Requirements Elicitation: This is the process of gathering information about

the needs and expectations of stakeholders for the software system. This step
involves interviews, surveys, focus groups, and other techniques to gather
information from stakeholders.

• Requirements Analysis: This step involves analyzing the information

gathered in the requirements elicitation step to identify the high-level goals and
objectives of the software system. It also involves identifying any constraints
or limitations that may affect the development of the software system.

6
Requirement Elicitation and Analysis
There are several techniques that can be used to elicit requirements, including:

✔ Interviews: These are one-on-one conversations with stakeholders to gather

information about their needs and expectations.

✔ Surveys: These are questionnaires that are distributed to stakeholders to gather

information about their needs and expectations.

✔ Focus Groups: These are small groups of stakeholders who are brought together
to discuss their needs and expectations for the software system.

✔ Observation: This technique involves observing the stakeholders in their work

environment to gather information about their needs and expectations.

✔ Prototyping: This technique involves creating a working model of the software

system, which can be used to gather feedback from stakeholders and to validate
requirements.
7
Requirement Elicitation and Analysis

Figure 2: Elicitation and Analysis

8
Problems of Elicitation and Analysis

• Getting all, and only, the right people involved.

• Stakeholders often don't know what they want.
• Stakeholders express requirements in their terms.
• Stakeholders may have conflicting requirements.
• Requirement change during the analysis process.
• Organizational and political factors may influence system requirements.

9
Software Requirement Specification
(SRS)

• Software requirement specification is a kind of document which is created by a

software analyst after the requirements are collected from the various sources -
the requirement received by the customer written in ordinary language.
• It is the job of the analyst to write the requirement in technical language so that
they can be understood and beneficial by the development team.
• The models used at this stage include Entity-Relationship (ER) diagrams, data
flow diagrams (DFDs), function decomposition diagrams (FDDs), data
dictionaries.

10
Software Requirement Specification
(SRS)
1. Data Flow Diagrams (DFDs):
• They are used widely for modeling the requirements.
• DFD shows the flow of data through a system.
• The system may be a company, an organization, a set of procedures, a computer
hardware system, a software system, or any combination of the preceding.
• The DFD is also known as a data flow graph or bubble chart.

11
Software Requirement Specification
(SRS)
2. Data Dictionaries:
• They are simply repositories to store information about all data items defined in
DFDs.
• At the requirements stage, the data dictionary should at least define customer
data items, to ensure that the customer and developers use the same definition
and terminologies.

12
Software Requirement Specification
(SRS)
3. Entity-Relationship Diagrams:
• Another tool for requirement specification is the entity-relationship diagram,
often called an "E-R diagram."
• It is a detailed logical representation of the data for the organization and uses
three main constructs i.e. data entities, relationships, and their associated
attributes.

13
Features of SRS

• User Requirements are expressed in natural language.

• Technical requirements are expressed in structured language, which is used
inside the organization.
• Design description should be written in Pseudo code.
• Format of Forms and GUI screen prints.
• Conditional and mathematical notations for DFDs etc.

14
Software Requirement Validation
• After requirement specifications are developed, the requirements mentioned in
this document are validated.
• The user might demand illegal, impossible solution or experts may misinterpret
the needs.
• Requirements can be checked against following conditions -
✔ If they can be practically implemented
✔ If they are valid and as per functionality and domain of software
✔ If there are any ambiguities
✔ If they are complete
✔ If they can be demonstrated

15
Software Requirement Validation -
Techniques
1. Requirements reviews/inspections: systematic manual analysis of the
requirements.
2. Prototyping: Using an executable model of the system to check requirements.
3. Test-case generation: Developing tests for requirements to check testability.
4. Automated consistency analysis: Checking for the consistency of structured
requirements descriptions.

16
Software Requirement Management
• Requirement management is the process of managing changing requirements
during the requirements engineering process and system development.
• New requirements emerge during the process as business needs a change, and a
better understanding of the system is developed.
• The priority of requirements from different viewpoints changes during
development process.
• The business and technical environment of the system changes during the
development.

17
Classification of Requirements

Figure 3: Classification of Software requirements

18
 Functional Requirements
1. Functional Requirements

Definition: Functional requirements describe what the software should do. They
define the functions or features that the system must have.
Examples:

● User Authentication: The system must allow users to log in using a

username and password.
● Search Functionality: The software should enable users to search for
products by name or category.
● Report Generation: The system should be able to generate sales reports for
a specified date range.

19
Non-Functional Requirements
2. Non-functional Requirements

Definition: Non-functional requirements describe how the software performs a

task rather than what it should do. They define the quality attributes,
performance criteria, and constraints.
Examples:

● Performance: The system should process 1,000 transactions per second.

● Usability: The software should be easy to use and have a user-friendly
interface.
● Reliability: The system must have 99.9% uptime.
● Security: Data must be encrypted during transmission and storage.

20
 Domain Requirements
3. Domain Requirements

Definition: Domain requirements are specific to the domain or industry in which

the software operates. They include terminology, rules, and standards relevant to
that particular domain.
Examples:

● Healthcare: The software must comply with HIPAA regulations for

handling patient data.
● Finance: The system should adhere to GAAP standards for financial
reporting.
● E-commerce: The software should support various payment gateways
like PayPal, Stripe, and credit cards.

21
Building Analysis Model

22
Analysis Modelling
• At a technical level, software engineering begins with a series of modelling
tasks that lead to a complete specification of requirements and a comprehensive
design representation for the software to be built.
• Analysis Model is a technical representation of the system. It acts as a link
between system description and design model.
Objectives of Analysis Modelling:

• It must establish a way of creating software design.

• It must describe the requirements of the customer.
• It must define a set of requirements that can be validated, once the software is
built.

23
Elements of Analysis Model

Figure 4: Analysis Model

24
Elements of Analysis Modelling
1. Data Dictionary:
• It is a very crucial element of the analysis model.
• It is a repository that consists of a description of all data objects used or
produced by the software.
• It stores the collection of data present in the software.
• It acts as a centralized repository and also helps in modeling data objects defined
during software requirements.

25
Elements of Analysis Modelling
2. Entity Relationship Diagram (ERD):
• It depicts the relationship between data objects and is used in conducting data
modeling activities.
• The attributes of each object in the Entity-Relationship Diagram can be
described using Data object description.
• It provides the basis for activity related to data design.

26
Elements of Analysis Modelling
3. State Transition Diagram:
• It shows various modes of behavior (states) of the system and also shows the
transitions from one state to another state in the system.
• It also provides the details of how the system behaves due to the consequences of
external events.
• It represents the behavior of a system by presenting its states and the events that
cause the system to change state.
• It also describes what actions are taken due to the occurrence of a particular
event.

27
Elements of Analysis Modelling
4. Data Flow Diagram (DFD):
• It depicts the functions that transform data flow and it also shows how data is
transformed when moving from input to output.
• It provides the additional information which is used during the analysis of the
information domain and serves as a basis for the modeling of function.
• It also enables the engineer to develop models of functional and information
domains at the same time.

28
Elements of Analysis Modelling
5. Process Specification (PSPEC):
• It stores the description of each function present in the data flow diagram.
• It describes the input to a function, the algorithm that is applied for the
transformation of input, and the output that is produced.
• It also shows regulations and barriers imposed on the performance characteristics
that are applicable to the process and layout constraints that could influence the
way in which the process will be implemented.

29
Elements of Analysis Modelling
6. Control Specification (CSPEC):
• It stores additional information about the control aspects of the software.
• It is used to indicate how the software behaves when an event occurs and which
processes are invoked due to the occurrence of the event.
• It also provides the details of the processes that are executed to manage events.

30
Elements of Analysis Modelling
7. Data Object Description:
• It stores and provides complete knowledge about a data object present and used
in the software.
• It also gives us the details of attributes of the data object present in the Entity
Relationship Diagram.
• Hence, it incorporates all the data objects and their attributes.

31
Flow Oriented Modelling
• It shows how data objects are transformed by processing the function.

The Flow oriented elements are:

1. Data flow model:

– It is a graphical technique. It is used to represent information flow.
– The data objects are flowing within the software and transformed by
processing the elements.
– The data objects are represented by labeled arrows. Transformation are
represented by circles called as bubbles.
– DFD shown in a hierarchical fashion. The DFD is split into different
levels. It also called as 'context level diagram.

32
Flow Oriented Modelling
2. Control flow model:
– Large class applications require a control flow modeling.
– The application creates control information instead of reports or displays.
– The applications process the information in specified time.
– An event is implemented as a boolean value.
– For example, the boolean values are true or false, on or off, 1 or 0.

3. Control Specification (SPEC):

– It represents the behavior of the system.
– The state diagram in CSPEC is a sequential specification of the behavior.
– The state diagram includes states, transitions, events and activities.
– The state diagram shows the transition from one state to another state if a
particular event has occurred.

33
Flow Oriented Modelling

4. Process Specification (PSPEC):

– The process specification is used to describe all flow model processes.
– The content of process specification consists narrative text, Program
Design Language(PDL) of the process algorithm, mathematical
equations, tables or UML activity diagram.

34
 Practice Questions

• What do you mean by Flow Oriented Modeling ?

• What do you mean by Data Flow Diagram? Explain its external entity.
• What is the purpose of Open ended box and Parallel lines in Data Flow
Diagram.
• Which are the primary objectives in the Analysis model?
• What are the various element models of Analysis model?

35
 Practice Questions
1. What are the types of requirements ?
a) Availability b) Reliability
c) Usability d) All of the mentioned
2. Which one of the following is not a step of requirement engineering?
a) elicitation b) design
c) analysis d) documentation
3. The user system requirements are the parts of which document ?
a) SDD b) SRS
c) DDD d) SRD
4. Select the developer-specific requirement ?
a) Portability b) Maintainability
c) Availability d) Both Portability and Maintainability

36
THANKS

37