SOFTWARE ENGINEERING

UNT - II
SOFTWARE REQUIREMENTS
 According IEEE standard, Software Requirement is a condition needed by a user to solve a problem
or achieve objective.
 Requirements should be clear, correct and well defined.
SOFTWARE REQUIREMENT TYPES
1. Functional requirements
2. Non-functional requirements
3. User requirements
4. System requirements
1. FUNCTIONAL REQUIREMENTS
 Functional requirements are product features or functions that developers must implement to
enable users to accomplish their tasks.
 So it’s essential to make them clear both for the development team and the stakeholders.
 Generally, functional requirements describe system behavior under specific conditions.
Example
Functional requirements will vary for different types of software.
 The system sends a confirmation email when a new user account is created.
 The system sends an approval request after the user enters personal information.
 A search feature allows users to search content/items by entering the query in the search bar.
 The user can review items in the cart, change their number, or remove them before checkout.
 The app should allow users to create accounts and log in using credentials like email and password
or through social media integration.
 The app can send notifications to users for updates, reminders, or promotional content.
 Users should be able to provide feedback or rate services/products within the app.
 These are some common functional requirements. More specialized software systems will have more
specific requirements. For example, a hotel property management system will include such
requirements as “the user should be able to view and update room status” or “the system must
aggregate bills from all points of service in a folio.”
2. 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 the priority or extent to which these factors are implemented varies from one
project to other.
 They are also called non-behavioral requirements. They basically deal with issues like:
 Portability
 Security
 Maintainability
 Reliability
 Scalability
 Performance
 Reusability
 Flexibility
Example
 The website pages should load in 3 seconds with the total number of simultaneous users <5
thousand.
 The system should be able to handle 20 million users without performance deterioration.
 The payment processing gateway must be PCI DSS compliant.
 A program running on Windows 10 must be able to run on Windows 11 without any change in its
behavior and performance.
FUNCTIONAL REQUIREMENTS vs NON-FUNCTIONAL REQUIREMENTS
3. 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.
4. 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.
INTERFACE SPECIFICATION
 All software systems must operate with existing systems that have already been implemented and
installed in an environment.
 If the new system and existing systems must work together, the interfaces of existing systems have
to be precisely specified.
 These specifications should be defined early in the process and included in the requirements
document.
Types of Interface Specification
There are three types of Interface specification:
1. Procedural interfaces.
2. Data structures.
3. Representations of data.
Procedural interfaces
 Procedural interfaces where existing programs or sub-systems offer a range of services that are
accessed by calling interface procedures.
 In simple words it Is used for calling the existing programs by the new programs.
 These interfaces are sometimes called Application Programming Interfaces (APLs).
Data structures
 Data structures that are passed from one sub- system to another.
 Graphical data models are the best notations for this type of description
Representations of data
 Representations of data (such as the ordering of bits) that have been established for an existing
sub-system.
 These interfaces are most common in embedded, real- time system.
 Some programming languages such as Ada (although not Java) support this level of Specification.
SYSTEM REQUIREMENTS DOCUMENT
 Software Requirement Specification (SRS) Format as the name suggests, is a complete
specification and description of requirements of the software that need to be fulfilled for the
successful development of the software system.
 These requirements can be functional as well as non-functional depending upon the type of
requirement.
 The interaction between different customers and contractors is done because it is necessary to fully
understand the needs of customers.
 Depending upon information gathered after interaction, SRS is developed which describes
requirements of software that may include changes and modifications that is needed to be done to
increase quality of product and to satisfy customer’s demand.
Why Use an SRS Document?
 An SRS gives you a complete picture of your entire project.
 It provides a single source of truth that every team involved in development will follow.
 It is your plan of action and keeps all your teams — from development and testing to maintenance —
on the same page.
How to Write an SRS Document
Creating a clear and effective SRS document can be difficult and time-consuming. But it is critical to the
efficient development of a high quality product that meets the needs of business users.
Here are five steps you can follow to write an effective SRS document.
1. Define the Purpose with an Outline (Or Use an SRS Template)
Your first step is to create an outline for your software requirements specification. This may be
something you create yourself, or you can use an existing SRS template.
If you’re creating the outline yourself, here’s what it might look like:
1. Introduction
1.1 Purpose
1.2 Intended Audience
1.3 Intended Use
1.4 Product Scope
1.5 Definitions and Acronyms
2. Overall Description
2.1 User Needs
2.2 Assumptions and Dependencies
3. System Features and Requirements
3.1 Functional Requirements
3.2 External Interface Requirements
3.3 System Features
3.4 Nonfunctional Requirements
This is a basic outline and yours may contain more (or fewer) items.
2. Define your Product’s Purpose
This introduction is very important as it sets expectations that we will come back to throughout the SRS.
Some items to keep in mind when defining this purpose include:
Intended Audience and Intended Use
Define who in your organization will have access to the SRS and how they should use it. This may include
developers, testers, and project managers. It could also include stakeholders in other departments,
including leadership teams, sales, and marketing. Defining this now will lead to less work in the future.
Product Scope
What are the benefits, objectives, and goals we intend to have for this product? This should relate to
overall business goals, especially if teams outside of development will have access to the SRS.
Definitions and Acronyms
Clearly define all key terms, acronyms, and abbreviations used in the SRS. This will help eliminate any
ambiguity and ensure that all parties can easily understand the document.
3. Describe What You Will Build
 Your next step is to give a description of what you’re going to build. Why is this product needed?
Who is it for? Is it a new product? Is it an add-on to a product you’ve already created? Is this going to
integrate with another product?
 Understanding and getting your team aligned on the answers to these questions on the front end
makes creating the product much easier and more efficient for everyone involved.
User Needs
 Describe who will use the product and how. Understanding the various users of the product and their
needs is a critical part of the SRS writing process.
 Who will be using the product? Are they a primary or secondary user? What is their role within their
organization? What need does the product need to fulfill for them?
 Do you need to know about the purchaser of the product as well as the end user? For the
development of medical devices and med device software, you may also need to know the needs of
the patient.
Assumptions and Dependencies
 What are we assuming will be true? Understating and laying out these assumptions ahead of time
will help with headaches later. Are we assuming current technology? Are we basing this on a
Windows framework? We need to take stock of these technical assumptions to better understand
where our product might fail or not operate perfectly.
 Finally, you should note if your project is dependent on any external factors. Are we reusing a bit of
software from a previous project? This new project would then depend on that operating correctly
and should be included.
4. Detail Your Specific Requirements
In order for your development team to meet the requirements properly, we must include as much detail
as possible. This can feel overwhelming but becomes easier as you break down your requirements into
categories. Some common categories are functional requirements, interface requirements, system
features, and various types of nonfunctional requirements:
Functional Requirements
These describe what the software system should do. They specify the functionality that the system
must provide, such as input validation, data storage, and user interface.
External Interface Requirements
External interface requirements are specific types of functional requirements. These are especially
important when working with embedded systems. They outline how your product will interface with
other components.
There are several types of interfaces you may have requirements for, including:
 User
 Hardware
 Software
 Communications
System Features
System features are a type of functional requirements. These are features that are required in order for
a system to function.
Nonfunctional Requirements
These describe how well the software system should do it. They specify the quality attributes of the
system, such as performance, reliability, usability, and security.
REQUIREMENTS ENGINEERING PROCESS
 Requirements engineering (RE) refers to the process of defining, documenting, and maintaining
requirements in the engineering design process.
 A systematic and strict approach to the definition, creation, and verification of requirements for a
software system is known as requirements engineering.
It is a four-step process, which includes –
1. Feasibility Study
2. Requirements elicitation
3. Requirements specification
4. Requirements for verification and validation
5. Requirements management

1. 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 - Technical feasibility evaluates the current technologies, which are needed
to accomplish customer requirements within the time and budget.

2. Operational Feasibility - Operational feasibility assesses the range in which the required software
performs a series of levels to solve business problems and customer requirements.
3. Economic Feasibility - Economic feasibility decides whether the necessary software can generate
financial profits for an organization.
2. Requirement Elicitation
 This is also known as the gathering of requirements. Here, requirements are identified with the
help of customers and existing systems processes, if available.
 It is related to the various ways used to gain knowledge about the project domain and requirements.
Several techniques 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.
3. Requirements 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 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 ER diagrams, data flow diagrams(DFDs), function
decomposition diagrams(FDDs), data dictionaries, etc.
Several types of requirements are commonly specified in this step, including
Functional Requirements: These describe what the software system should do. They specify the
functionality that the system must provide, such as input validation, data storage, and user interface.
Non-Functional Requirements: These describe how well the software system should do it. They
specify the quality attributes of the system, such as performance, reliability, usability, and security.
Constraints: These describe any limitations or restrictions that must be considered when developing
the software system.
Acceptance Criteria: These describe the conditions that must be met for the software system to be
considered complete and ready for release.
4. 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.
5. Requirements 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.