softwareengineering-2byadi-240115152309-0244b82d (1).pptx

Software Engineering
Unit-2
2
Requirement
Engineering

Introduction
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
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, Dr.sK.eArdivseishcaes and operational constraints.

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

Software Requirements
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.,

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.

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:

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

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.

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.

20

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,
Example: interoperability requirements, legislative requirements etc,.

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.

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.

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:

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
ting changes to the system to some extent.

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.

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

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

29
 Introduction

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.

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.

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,
dAdeisfeisnhaitions of some specific terms, acronyms, abbreviations, etc. are given and explained.

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
34
Queries ?
Reference: Sommerville, Software Engineering, 10 ed.,
Dr. K. Adisesha

softwareengineering-2byadi-240115152309-0244b82d (1).pptx

More Related Content

Similar to softwareengineering-2byadi-240115152309-0244b82d (1).pptx (20)

More from Parameshwar Maddela (13)

Recently uploaded (20)

softwareengineering-2byadi-240115152309-0244b82d (1).pptx