5th Semester ECS Software Engineering

Module-2

Requirement Engineering and Modeling

Types of Requirements, Requirement Engineering Task, Software Requirement Specification

(SRS), Developing Use Cases (UML), Requirement Model: Scenario-based model, Class-based
model, Behavioural model.

Requirement Engineering: The process to gather the software requirements from client,
analyze and document them is known as requirement engineering. The goal of requirement
engineering is to develop and maintain sophisticated and descriptive ‘System Requirements
Specification’ document.

Requirements engineering is a broad domain that focuses on being the connector between
modeling, analysis, design, and construction. It is the process that defines, identifies, manages,
and develops requirements in a software engineering design process. This process uses tools,
methods, and principles to describe the system’s behavior and the constraints that
come along with it.
Requirements engineering is the most important part every business must follow, in order to
build and release a project successfully, as it is the foundation to key planning
and implementation.

Main types of software requirement can be of 3 types:

 Functional requirements
 Non-functional requirements
 Domain requirements

 Functional Requirements: These are the requirements that the end user specifically
demands as basic facilities that the system should offer. It can be a calculation, data
manipulation, business process, user interaction, or any other specific functionality which
defines what function a system is likely to perform.
Functional Requirements in Software Engineering are also called
Functional Specification. They are basically the requirements stated by the user which
one can see directly in the final product.
 Non-functional requirements: These are basically the quality constraints that the system
must satisfy according to the project contract. Nonfunctional requirements, not related to
the system functionality, rather define how the system should perform.
They are also called non-behavioral requirements. They basically deal with issues like:

 Portability
 Security
 Maintainability
  Reliability
 Scalability
 Performance
 Reusability
 Flexibility
 Domain requirements: Domain requirements are the requirements which are
characteristic of a particular category or domain of projects. Domain requirements can be
functional or nonfunctional.
These requirements are therefore identified from that domain model and are
not user specific.

Other common classifications of software requirements can be:

 User requirements: These requirements describe what the end-user wants from the
software system. User requirements are usually expressed in natural language and are
typically gathered through interviews, surveys, or user feedback.
 System requirements: These requirements specify the technical characteristics of the
software system, such as its architecture, hardware requirements, software components,
and interfaces. System requirements are typically expressed in technical terms and are
often used as a basis for system design.
 Business requirements: These requirements describe the business goals and objectives
that the software system is expected to achieve. Business requirements are usually
expressed in terms of revenue, market share, customer satisfaction, or other
business metrics.
 Regulatory requirements: These requirements specify the legal or regulatory standards
that the software system must meet. Regulatory requirements may include data privacy,
security, accessibility, or other legal compliance requirements.
 Interface requirements: These requirements specify the interactions between the
software system and external systems or components, such as databases, web services, or
other software applications.
 Design requirements: These requirements describe the technical design of the software
system. They include information about the software architecture, data structures,
algorithms, and other technical aspects of the software.

Advantages of classifying software requirements

 Better organization: Classifying software requirements helps organize them into

groups that are easier to manage, prioritize, and track throughout the development
process.
 Improved communication: Clear classification of requirements makes it easier to
communicate them to stakeholders, developers, and other team members. It also ensures
that everyone is on the same page about what is required.
 Increased quality: By classifying requirements, potential conflicts or gaps can be
identified early in the development process. This reduces the risk of errors, omissions,
or misunderstandings, leading to higher quality software.
  Improved traceability: Classifying requirements helps establish traceability, which is
essential for demonstrating compliance with regulatory or quality standards.

Disadvantages of classifying software requirements

 Complexity: Classifying software requirements can be complex, especially if there are
many stakeholders with different needs or requirements. It can also be time-consuming to
identify and classify all the requirements.
 Rigid structure: A rigid classification structure may limit the ability to accommodate
changes or evolving needs during the development process. It can also lead to a siloed
approach that prevents the integration of new ideas or insights.

 Software Requirement Tasks

Requirements Engineering Tasks: The software requirements engineering process
includes the following steps of activities:

 Inception
 Elicitation
 Elaboration
 Negotiation
 Specification
 Validation
 Requirements Management

 Inception:
This is the first phase of the requirements analysis process. This phase gives an
outline of how to get started on a project. In the inception phase, all the basic
questions are asked on how to go about a task or the steps required
accomplishing a task.
Overall in the inception phase, the following criteria have to be addressed by the
software engineers:
 Understanding of the problem.
 The people who want a solution
 Nature of the solution
 Communication and collaboration between the customer and developer
 Elicitation:
This is the second phase of the requirements analysis process. This phase focuses
on gathering the requirements from the stakeholders. One should be careful in
this phase, as the requirements which are establishes are the key purpose of a
 project. Understanding the kind of requirements needed from the customer is
very crucial for a developer.
The right people must be involved in this phase. The following problems can
occur in the elicitation phase:
 Problem of Scope: The requirements given are of unnecessary detail, ill-
defined, or not possible to implement.
 Problem of Understanding: Not having a clear-cut understanding between
the developer and customer when putting out the requirements needed.
Sometimes the customer might not know what they want or the developer
might misunderstand one requirement for another.
 Problem of Volatility: Requirements changing over time can cause difficulty
in leading a project. It can lead to loss and wastage of resources and time.
 Elaboration: This is the third phase of the requirements analysis process. This
phase is the result of the inception and elicitation phase. In the elaboration
process, it takes the requirements that have been stated and gathered in the first
two phases and refines them.
 Negotiation: This is the fourth phase of the requirements analysis process.
This phase emphasizes discussion and exchanging conversation on what is
needed and what is to be eliminated. In the negotiation phase, negotiation is
between the developer and the customer and they dwell on how to go about the
project with limited business resources.
The following are discussed in the negotiation phase:
 Availability of Resources.
 Delivery Time
 Scope of requirements
 Project Cost
 Estimations on development.
 Specification: This is the fifth phase of the requirements analysis process
This phase specifies the following:
 Written document
 A set of models
 A collection of use cases
 A prototype

 In the specification phase, the requirements engineer gathers all the

requirements and develops a working model.
 This final working product will be the basis of any functions, features or
constraints to be observed.
  The models used in this phase include ER (Entity Relationship) diagrams,
DFD (Data Flow Diagram), FDD (Function Decomposition Diagrams),
and Data Dictionaries.
 A software specification document is submitted to the customer in a
language that he/she will understand, to give a glimpse of
the working model.
 Validation: This is the sixth phase of the requirements analysis process.
This phase focuses on checking for errors and debugging. In the validation
phase, the developer scans the specification document and checks for the
following:

 All the requirements have been stated and met correctly

 Errors have been debugged and corrected
 Work product is built according to the standards

Some of the validation techniques are the following-

 Requirements reviews/inspections
 Prototyping
 Test-case generation
 Automated consistency analysis

 Requirements Management

 This is the last phase of the requirements analysis process.

 Requirements management is a set of activities where the entire team takes part in
identifying, controlling, tracking, and establishing the requirements for the
successful and smooth implementation of the project.
 In this phase, the team is responsible for managing any changes that may occur
during the project.
 Based on this phase, the working model will be analyzed carefully and ready to be
delivered to the customer.

 Software Requirement Specification (SRS)

Software Requirement Specification (SRS) Format as name suggests, is complete specification and
description of requirements of software that needs to be fulfilled for successful development of
software system. These requirements can be functional as well as non-functional depending upon type
of requirement.

In order to form a good SRS, here you will see some points which can be used and should be considered
to form a structure of good SRS. These are as follows:
1. Introduction

 (i) Purpose of this document

 (ii) Scope of this document
 (iii) Overview

2. General description 3. Functional Requirements 4. Interface Requirements 5. Performance

Requirements 6. Design Constraints 7. Non-Functional Attributes 8. Preliminary Schedule and
Budget 9. Appendices

1. Introduction :

 (i) Purpose of this Document – At first, main aim of why this document is necessary and what’s
purpose of document is explained and described.
 (ii) Scope of this document – In this, overall working and main objective of document and what
value it will provide to customer is described and explained. It also includes a description of
development cost and time required.
 (iii) Overview – In this, description of product is explained. It’s simply summary or overall review
of product.

2. General description : In this, general functions of product which includes objective of user, a
user characteristic, features, benefits, about why its importance is mentioned. It also describes
features of user community.
3. Functional Requirements: In this, possible outcome of software system which includes effects
due to operation of program is fully explained. All functional requirements which may include
calculations, data processing, etc. are placed in a ranked order.
4. Interface Requirements: In this, software interfaces which mean how software program
communicates with each other or users both in form of any language, code, or message are
fully described and explained. Examples can be shared memory, data streams, etc.
5. Performance Requirements: In this, how a software system performs desired functions under
specific condition is explained. It also explains required time, required memory, maximum error
rate, etc.
6. Design Constraints: In this, constraints which simply mean limitation or restriction are specified
and explained for design team. Examples may include use of a particular algorithm, hardware
and software limitations, etc.
7. Non-Functional Attributes: In this, non-functional attributes are explained that are required by
software system for better performance. An example may include Security, Portability,
Reliability, Reusability, Application compatibility, Data integrity, Scalability capacity, etc.
8. Preliminary Schedule and Budget: In this, initial version and budget of project plan are
explained which include overall time duration required and overall cost required for
development of project.
9. Appendices: In this, additional information like references from where information is gathered,
definitions of some specific terms, acronyms, abbreviations, etc. are given and explained.
 Good SRS Document includes:
 Complete: The SRS should include all the requirements for the software system, including both
functional and non-functional requirements.
 Consistent: The SRS should be consistent in its use of terminology and formatting, and should be
free of contradictions.
 Unambiguous: The SRS should be clear and specific, and should avoid using vague or imprecise
language.
 Traceable: The SRS should be traceable to other documents and artifacts, such as use cases and
user stories, to ensure that all requirements are being met.
 Verifiable: The SRS should be verifiable, which means that the requirements can be tested and
validated to ensure that they are being met.
 Modifiable: The SRS should be modifiable, so that it can be updated and changed as the
software development process progresses.
 Prioritized: The SRS should prioritize requirements, so that the most important requirements are
addressed first.
 Testable: The SRS should be written in a way that allows the requirements to be tested and
validated.
 High-level and low-level: The SRS should provide both high-level requirements (such as overall
system objectives) and low-level requirements (such as detailed functional requirements).
 Relevant: The SRS should be relevant to the software system that is being developed, and
should not include unnecessary or irrelevant information.
 Human-readable: The SRS should be written in a way that is easy for non-technical stakeholders
to understand and review.
 Aligned with business goals: The SRS should be aligned with the overall business goals and
objectives of the organization, so that the software system meets the needs of the business.
 Agile methodologies: Agile methodologies, such as Scrum and Kanban, provide an iterative
approach to requirements capturing and validation, where requirements are captured and
validated in small chunks of functionality and feedback is gathered from the customer.

Characteristics of a good SRS document

 Correctness:
User review is used to ensure the correctness of requirements stated in the SRS. SRS is said to
be correct if it covers all the requirements that are actually expected from the system.
 Completeness:
Completeness of SRS indicates every sense of completion including the numbering of all the
pages, resolving the to be determined parts to as much extent as possible as well as covering all
the functional and non-functional requirements properly.
 Consistency:
Requirements in SRS are said to be consistent if there are no conflicts between any set of
requirements. Examples of conflict include differences in terminologies used at separate places,
logical conflicts like time period of report generation, etc.
 Unambiguousness:
A SRS is said to be unambiguous if all the requirements stated have only 1 interpretation. Some
of the ways to prevent unambiguousness include the use of modeling techniques like ER
diagrams, proper reviews and buddy checks, etc.
  Ranking for importance and stability:
There should a criterion to classify the requirements as less or more important or more
specifically as desirable or essential. An identifier mark can be used with every requirement to
indicate its rank or stability.
 Modifiability:
SRS should be made as modifiable as possible and should be capable of easily accepting changes
to the system to some extent. Modifications should be properly indexed and cross-referenced.
 Verifiability:
A SRS is verifiable if there exists a specific technique to quantifiably measure the extent to which
every requirement is met by the system. For example, a requirement starting that the system
must be user-friendly is not verifiable and listing such requirements should be avoided.
 Traceability:
One should be able to trace a requirement to design component and then to code segment in
the program. Similarly, one should be able to trace a requirement to the corresponding test
cases.
 Design Independence:
There should be an option to choose from multiple design alternatives for the final system.
More specifically, the SRS should not include any implementation details.
 Testability:
A SRS should be written in such a way that it is easy to generate test cases and test plans from
the document.
 Understandable by the customer:
An end user maybe an expert in his/her specific domain but might not be an expert in computer
science. Hence, the use of formal notations and symbols should be avoided to as much extent as
possible. The language should be kept easy and clear.
 Right level of abstraction:
If the SRS is written for the requirements phase, the details should be explained explicitly.
Whereas, for a feasibility study, fewer details can be used. Hence, the level of abstraction varies
according to the purpose of the SRS.

Advantages of having a good Software Requirements Specification (SRS)

document include:
 Improved communication and understanding between stakeholders and developers, as the SRS
clearly defines the requirements for the software system
 Increased efficiency in the software development process, as a well-written SRS can help to
reduce the need for rework and change requests.
 Improved quality of the final software system, as a well-written SRS helps to ensure that all
requirements are met
 Increased stakeholder satisfaction, as a well-written SRS helps to ensure that the software
system meets the needs of the business and its users
 Improved traceability and verifiability, as a well-written SRS can be traced to other documents
and artifacts and its requirements can be tested and validated.
 Clarity and Completeness: A good SRS document provides clear and complete specifications for
the software project, which ensures that all stakeholders have a common understanding of the
requirements and objectives.
  Traceability: A good SRS document includes detailed requirements and specifications, which
enables traceability throughout the software development process.
 Testability: A good SRS document can serve as a basis for test cases and verification, which can
ensure that the software meets the requirements and specifications.
 Improved Communication: A good SRS document can serve as a communication tool between
different stakeholders, such as project managers, developers, testers, and customers.
 Reduced Rework: A good SRS document can help to identify and resolve issues early in the
development process, which can reduce the need for rework and improve the overall quality of
the software.

Disadvantages of having a poorly written SRS include:

 Confusion and misunderstandings between stakeholders and developers, as the requirements

are not clearly defined.
 Reduced quality of the final software system, as a poorly written SRS can result in requirements
being missed or not fully met.
 Reduced stakeholder satisfaction, as a poorly written SRS does not accurately capture the needs
of the business and its users
 Reduced traceability and verifiability, as a poorly written SRS can’t be traced to other
documents and artifacts and its requirements can’t be tested and validated.
 It is important to note that, regardless of the quality of the SRS, gathering and validating
requirements is an iterative process that should be continuously reviewed and updated
throughout the software development process.
 Time-consuming: Creating a good SRS document can be a time-consuming process, especially
for complex software projects, which can delay the development process.
 Changes and Updates: Changes or updates to the SRS document can cause delays in the
software development process and can be difficult to manage.
 Lack of Flexibility: A detailed SRS document can restrict the flexibility of the development
process, which can be challenging for projects that require agile development methodologies.
 Limited Stakeholder Involvement: The process of creating an SRS document can limit the
involvement of stakeholders in the software development process, which can lead to a lack of
collaboration and input from different perspectives.
 Ambiguity: A poorly written SRS document can lead to ambiguity and misunderstandings, which
can cause issues throughout the software development process.

 Requirement Models

 Scenario-based model
 Class-based model
 Behavioral model

 Scenario-based model
Scenario-based modeling is one of the sub-stages of requirements modeling. It's also typically
the first stage of requirements modeling, since it identifies the primary use cases for the
 proposed software system or application, to which later stages of requirements modeling will
refer.
Using a scenario-based approach, system is described from user’s point of view. For example,
basic use cases and their corresponding use-case diagrams evolve into more elaborate
template-based use cases. Figure 1(a) depicts a UML activity diagram for eliciting requirements
and representing them using use cases. There are three levels of elaboration.

Figure 1(a): UML activity diagrams for eliciting requirements

 Class-basedModel
A collection of things that have similar attributes and common behaviors i.e., objects are
categorized into classes. For example, a UML case diagram can be used to depict a Sensor
class for the Safe Home security function. Note that diagram lists attributes of sensors and
operations that can be applied to modify these attributes. In addition to class diagrams, other
analysis modeling elements depict manner in which classes collaborate with one another and
relationships and interactions between classes.

Class diagram for sensor

Method for representing behavior of a system by depicting its states and events that cause
system to change state is state diagram. A state is an externally observable mode of behavior. In
addition, state diagram indicates actions taken as a consequence of a particular event.
 Behavioral Model is specially designed to make us understand behavior and factors
that influence behavior of a System. Behavior of a system is explained and represented
with the help of a diagram. This diagram is known as State Transition Diagram. It is a
collection of states and events. It usually describes overall states that a system can have
and events which are responsible for a change in state of a system.
In software engineering, behavioral model describe the overall behavior of the system.
There are two types of behavioral models that are used to describe the system
behavior, one is data processing model and another is state machine models. Data
processing models are also known as DFD (Data Flow Diagram) which is used to show
how data is processed as it moves through the system. State machine model is also
known as State diagram which is used to show how the system will react with external
events.

 Data Flow Diagram

 Data flow diagram is used to model the system’s data processing.

 It is also cay as the Functional model as it is a graphical representation of an
enterprise function within a defined scope. Data flow diagram shows end to end
data processing.
 It can be easily converted into software as they just represent flow of the data
objects. DFD diagram enable Software engineer to develop a model of the
information domain and Functional domain at the same time.
 It provides a logical model of the system and shows the flow of the data and the
flow of logic involved.

 Characteristics of Data Flow Diagram

 It shows the process that transforms incoming data flows into outgoing data
flows.
 Process that performs this transformation normally creates as well as uses data.
 External entities send and receive data flow from the systems.
 It is also called a bubble chart.
 Data flow diagram support a top-down approach for analysis.

 Guidelines for Data Flow Diagram

 Level 0 DFD should depict software system as single bubble.
 Primary input and output are carefully noted.
 Refinement should begin by isolating candidate processes, data objects, and data
stores to be represented at the next level.
 All arrows and bubbles should be labeled with full names.
  Information flow continuity must be maintained from level to level. That means the
data objects that flow into the system of any transformation at one level must be
the same. Data objects that flow into transformation at the more refined level.

 Data Flow Diagram Notation

Data flow diagram consists of a series of symbols joined together by a line. Data objects are
represented by circles which are also called bubble charts. Data flow diagram is represented in
hierarchical order. The first level data flow model is also called as DFD 0 level or context
diagrams which represents the system as a whole. Second level data flow model refines the
context diagram and provides more details of first-level DFD. In a similar way, third level DFD
refines the second level DFD, and so on. Data flow analysis models are developed by two
organizations – Yourdon incorporation and Gane and Sarson

Notations used are as follows:

 Data Flow: It represents the movement of data flow from a specific origin to a destination.
 Process: It represents the users, procedures, or devices that use the data.
 Entity: It represents the source of data or destination data external sources or destination of
data which may be users, programs, organizations or other entities that interact with the system
but are outside its boundary.
 Data Store: There can be a single DFD diagram or can be exploded into various levels lime level
1, level 2, level 3, etc.
  State Diagram
State diagram is a dynamic model which represents the changes of state that an object goes through
during the lifetime in response to events. It is used to help the developer better understand any
complex functionality of specialized areas of the system.

Notations used in state diagram:

1. Initial State
It represents the start point of the diagram. It is also called as pseudo state where state has no variables
and no activities.
2. Final State
It represents the end point of the diagram. It is also pseudo state as it doesn’t have any variable or
activities. State diagram can have zero or more final states.
3. State
It represents the state of the object at an instant of time. State is a recognizable situation and exists over
an interval of time.
4. Transition
It represents the changes from one state to other. It is denoted by an arrow. The event or action causing
the transition is written beside the arrow, separated by slash. Triggerless transition occurs when the
state completed an activity.
5. Event and Action
Trigger that causes a transition to occur and changes the state is called event or action.
6. History State
A flow may require that the object go into a wait state and on the occurrence of a certain event, go back
to the state it was in, in this situation this notation is used.
7. Signal
When even causes the trigger to be sent to a state that causes the transition, then that message sent by
the event is called a signal.
8. Self-Transition
A state that has a transition that returns to itself is called self-transition.