Software Engineering-Unit 2 "Requirement Engineering" by Adi.pdf

Requirement Engineering
DR. K. ADISESHA

Software Engineering
Unit-2 Introduction
Types of Requirement
Software Requirements
SRS Document
2
Dr. K. Adisesha

Introduction
Dr. K. Adisesha
3
Requirement Engineering:
Requirement engineering is the disciplined application of proven principles, methods,
tools, and notation to describe a proposed system's intended behavior and its associated
constraints.

Introduction
Dr. K. Adisesha
4
Software Requirements:
Requirements are descriptions of the services that a software system must provide and
the constraints under which it must operate.
➢ Requirements can range from high-level abstract statements of services or system
constraints to detailed mathematical functional specifications.
➢ Types of requirement
❖ User requirements: – Statements in natural language
plus diagrams of the services the system provides and its
operational constraints. Written for customers.
❖ System requirements: – A structured document setting
out detailed descriptions of the system’s functions,
services and operational constraints.

Introduction
Dr. K. Adisesha
5
Types of Requirement:
Requirements written as document descriptions of the services that a software system
must provide and the constraints under which it must operate.
➢ User requirements: Statements in natural language plus diagrams of the services that
the systems provides and its operational constraints.
❖ Written for customers
➢ System requirements: A structured document setting out detailed descriptions of the
system services.
❖ Written as a contract between client and contractor.
➢ Software specification: A detailed software description which can serve as a basis for a design
or implementation.
❖ Written for developers

Introduction
Dr. K. Adisesha
6
Requirements Engineering:
Requirements engineering (RE) refers to the process of defining, documenting, and
maintaining requirements in the engineering design process.
➢ Requirements engineering is the process of identifying, eliciting, analyzing, specifying,
validating, and managing the needs and expectations of stakeholders for a software
system.
➢ Requirement Engineering Process:
❖ Feasibility Study
❖ Requirement Elicitation and Analysis
❖ Software Requirement Specification
❖ Software Requirement Validation
❖ Software Requirement Management.

Introduction
Dr. K. Adisesha
7
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:
❖ Technical Feasibility - Technical feasibility evaluates the current technologies,
which are needed to accomplish customer requirements within the time and budget.
❖ Operational Feasibility - Operational feasibility assesses the range in which the
required software performs a series of levels to solve business problems and
customer requirements.
❖ Economic Feasibility - Economic feasibility decides whether the necessary
software can generate financial profits for an organization..

Introduction
Dr. K. Adisesha
8
Requirement Elicitation and Analysis:
This is also known as the gathering of requirements. Here, requirements are identified
with the help of customers and existing systems processes, if available.
➢ The requirements are analyzed to identify inconsistencies, defects, omission, etc.
➢ 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.

Introduction
Dr. K. Adisesha
9
Software Requirement Specification:
Software requirement specification is a kind of document which is created by a
software analyst after the requirements collected from the various sources.
➢ The models used at this stage include ER diagrams, data flow diagrams (DFDs),
function decomposition diagrams (FDDs), data dictionaries, etc.
➢ Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for modeling the
requirements. DFD shows the flow of data through a system.
➢ Data Dictionaries: Data Dictionaries are simply repositories to store information
about all data items defined in DFDs..
➢ Entity-Relationship Diagrams: Entity-relationship diagram, often called an "E-R
diagram." It is a detailed logical representation of the data for the organization.

Introduction
Dr. K. Adisesha
10
Software Requirement Specification:
Software requirement specification is a kind of document which is created by a
software analyst after the requirements collected from the various sources.
➢ No team should enter the development
process without software specification.
It’s a roadmap for stakeholders,
developers, designers.
➢ Here's our full guide on how to make an
SRS document.

Introduction
Dr. K. Adisesha
11
Software Requirement Validation:
After requirement specifications developed, the requirements discussed in this
document are validated. The user might demand illegal, impossible solution or experts
may misinterpret the needs.
➢ Requirements Validation Techniques
❖ Requirements reviews/inspections: systematic manual analysis of the requirements.
❖ Prototyping: Using an executable model of the system to check requirements.
❖ Test-case generation: Developing tests for requirements to check testability.
❖ Automated consistency analysis: checking for the consistency of structured
requirements descriptions.

Introduction
Dr. K. Adisesha
12
Requirements Verification and Validation:
Verification: It refers to the set of tasks that ensures that the software correctly
implements a specific function.
Validation: It refers to a different set of tasks that ensures that the software that has
been built is traceable to customer requirements.
➢ If requirements are not validated, errors in the requirement definitions would
propagate to the successive stages resulting in a lot of modification and rework.
➢ The main steps for this process include:
❖ The requirements should be consistent with all the other requirements.
❖ The requirements should be complete in every sense.
❖ The requirements should be practically achievable.

Introduction
Dr. K. Adisesha
13
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.
➢ A complete Software Requirement Specifications should be:
❖ Clear
❖ Correct
❖ Consistent
❖ Coherent
❖ Modifiable
❖ Verifiable
❖ Prioritized
❖ Unambiguous
❖ Traceable

Dr. K. Adisesha
14
Software Requirements:
Largely software requirements must be categorized into two categories.
➢ Functional Requirements: The functional requirements are describing the behavior of
the system as it correlates to the system's functionality.
❖ Statements of services that the system should provide, how the system should react to
particular inputs and how the system should behave in particular situations.
➢ Non-functional Requirements: This can be the necessities that specify the criteria that
can be used to decide the operation instead of specific behaviors of the system.
❖ Constraints on the services or functions offered by the system such as timing
constraints, constraints on the development process, standards, etc.,

Dr. K. Adisesha
15
Functional Requirements:
Describe functionality or system services, depend on the type of software, expected
users and the type of system where the software is used.
➢ Functional user requirements may be high-level statements of what the system should
do, functional system requirements should describe the system services in detail.
➢ Examples
❖ The user shall be able to search either all of the initial set of databases or select a
subset from it/
❖ The system shall provide appropriate viewers for the user to read documents in the
document store.
❖ Every order shall be allocated a unique identifier which the user shall be able to
copy to the account’s permanent storage area.

Dr. K. Adisesha
16
Functional Requirements:
Describe functionality or system services, depend on the type of software, expected
users and the type of system where the software is used.
➢ Functional Requirements includes:

Dr. K. Adisesha
17
Non-functional requirements:
Non-functional requirements in software engineering refer to the characteristics of a
software system that are not related to specific functionality or behavior..
➢ They describe how the system should perform, rather than what it should do.
➢ Non-Functional Requirements are the constraints or the requirements imposed on the
system. They specify the quality attribute of the software.
➢ Every order shall be allocated a unique identifier which the user shall be able to copy
to the account’s permanent storage area.
➢ Non-Functional Requirements deal with issues like: Scalability, Maintainability,
Performance, Portability, Security, Reliability, etc.,

Dr. K. Adisesha
18
software system that are not related to specific functionality or behavior..
➢ Non-functional requirements include:
❖ Performance: This includes requirements related to the speed, scalability, and
responsiveness of the system.
❖ Security: This includes requirements related to the protection of the system and its
data from unauthorized access, as well as the ability to detect and recover from
security breaches.
❖ Usability: This includes requirements related to the ease of use and
understandability of the system for the end-users.

Dr. K. Adisesha
19
software system that are not related to specific functionality or behavior.
❖ Reliability: This includes requirements related to the system’s ability to function
correctly and consistently under normal and abnormal conditions.
❖ Maintainability: This includes requirements related to the ease of maintaining the
system, including testing, debugging, and modifying the system.
❖ Portability: This includes requirements related to the ability of the system to be
easily transferred to different hardware or software environments.
❖ Compliance: This includes requirements related to adherence to laws, regulations,
industry standards, or company policies.

Dr. K. Adisesha
20

Dr. K. Adisesha
21
❖ Product requirements: – Requirements which specify that the delivered product must behave
in a particular way,
o Example: execution speed, reliability etc.
❖ Organisational requirements: – Requirements which are a consequence of organisational
policies and procedures,
o Example: process standards used, implementation requirements etc.
❖ External requirements: – Requirements which arise from factors which are external to the
system and its development process,
o Example: interoperability requirements, legislative requirements etc,.

Dr. K. Adisesha
22
Software Requirements Document:
The software requirements document (called as software requirements specification or
SRS) is an official statement of what the system developers should implement..
➢ It may include both the user requirements for a system and a detailed specification of
the system requirements.
➢ Requirements documents are essential when systems are outsourced for development,
when different teams develop different parts of the system, and when a detailed
analysis of the requirements is mandatory.
➢ The requirements document has a diverse set of users, ranging from the senior
management of the organization that is paying for the system to the engineers
responsible for developing the software.

Dr. K. Adisesha
23
Software Requirements Document:
The software requirements document (called as software requirements specification or
SRS) is an official statement of what the system developers should implement.
➢ Figure shows possible users of the document and how they use it.

Dr. K. Adisesha
24
Characteristics of good SRS:
The SRS is a specification for a specific software product, program, or set of
applications that perform particular functions in a specific environment.
➢ Characteristics of good SRS:

Dr. K. Adisesha
25
➢ Following are the characteristics of a good SRS document:
❖ Correctness: User review is used to ensure the correctness of requirements stated in the SRS.
❖ Completeness: Completeness of SRS indicates every sense of completion 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.
❖ Unambiguousness: A SRS is said to be unambiguous if all the requirements stated have only 1
interpretation.
❖ Modifiability: SRS should be made as modifiable as possible and should be capable of easily
accepting changes to the system to some extent.

Dr. K. Adisesha
26
➢ 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.
➢ Traceability: One should be able to trace a requirement to design component and then to code
segment in the program.
➢ Design Independence: There should be an option to choose from multiple design alternatives
for the final system.
➢ 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.

Dr. K. Adisesha
27
Properties of a good SRS document:
The SRS is a specification for a specific software product, the essential properties of a
good SRS document are the following.
➢ Concise: The SRS report should be concise and at the same time, unambiguous, consistent, and
complete.
➢ Structured: It should be well-structured. A well-structured document is simple to understand
and modify.
➢ Black-box view: SRS document should define the external behavior of the system and not
discuss the implementation issues.
➢ Conceptual integrity: It should show conceptual integrity so that the reader can merely
understand it. Response to undesired events.
➢ Verifiable: All requirements of the system, as documented in the SRS document, should be
correct.

Dr. K. Adisesha
28
Software Requirement Specification (SRS):
In order to form a good SRS, here you will see some points that can be used and should
be considered to form a structure of good Software Requirements Specification (SRS).
➢ These are below mentioned in the table of contents and are well explained below..
❖ Introduction
❖ General description
❖ Functional Requirements
❖ Interface Requirements
❖ Performance Requirements
❖ Design Constraints
❖ Non-Functional Attributes
❖ Preliminary Schedule and Budget
❖ Appendices

Dr. K. Adisesha
29
➢ Introduction

Dr. K. Adisesha
30
➢ Introduction
❖ Purpose of this Document – At first, main aim of why this document is necessary
and what’s purpose of document is explained and described.
❖ 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.
❖ Overview – In this, description of product is explained. It’s simply summary or
overall review of product.

Dr. K. Adisesha
31
In order to form a good SRS, here you will see some points that can be used:
➢ General description: In this, general functions of product which includes objective of user, a
user characteristic, features, benefits, about why its importance is mentioned.
➢ 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.
➢ Interface Requirements: In this, software interfaces which mean how software program
communicates with each other or users either in form of any language, code, or message are
fully described and explained.
➢ 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.

Dr. K. Adisesha
32
➢ Design Constraints: In this, constraints which simply means limitation or restriction are
specified and explained for design team. Examples may include use of a particular algorithm,
hardware and software limitations, etc.
➢ 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.
➢ 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.
➢ Appendices: In this, additional information like references from where information is gathered,
definitions of some specific terms, acronyms, abbreviations, etc. are given and explained.

Dr. K. Adisesha
33
➢ Uses of SRS document
❖ Development team require it for developing product according to the need.
❖ Test plans are generated by testing group based on the describe external behaviour.
❖ Maintenance and support staff need it to understand what the software product is supposed
to do.
❖ Project manager base their plans and estimates of schedule, effort and resources on it.
❖ customer rely on it to know that product they can expect.
❖ As a contract between developer and customer.
❖ in documentation purpose.

Discussion
Dr. K. Adisesha
34
Queries ?
Prof. K. Adisesha
9449081542
Reference: Sommerville, Software Engineering, 10 ed.,

Software Engineering-Unit 2 "Requirement Engineering" by Adi.pdf

More Related Content

What's hot (20)

Similar to Software Engineering-Unit 2 "Requirement Engineering" by Adi.pdf (20)

More from Prof. Dr. K. Adisesha (20)

Recently uploaded (20)

Software Engineering-Unit 2 "Requirement Engineering" by Adi.pdf