UNIT II

SOFTWARE REQUIREMENTS

What is a requirement?
• The requirements for the system are the description of the services provided
by the system and its operational constraints
• It may range from a high-level abstract statement of a service or of a system
constraint to a detailed mathematical functional specification.
• This is inevitable as requirements may serve a dual function:
May be the basis for a bid for a contract - therefore must be open to
interpretation:
May be the basis for the contract itself - therefore must be defined in detail:
Both these statements may be called requirements
Requirements engineering:
• The process of finding out, analysing documenting and checking these
services and constraints is called requirement engineering.
• The process of establishing the services that the customer requires from a
system and the constraints under which it operates and is developed.
• The requirements themselves are the descriptions of the system services and
constraints that are generated during the requirements engineering process.

Software Requirements Definition:

According to IEEE standard 729, a requirement is defined as follows:
A condition or capability needed by a user to solve a problem or achieve an
objective
A condition or capability that must be met or possessed by a system or system
component to satisfy a contract, standard, specification or other formally
imposed documents
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. Defines what
should be implemented so may be part of a contract between client and
contractor.
Definitions and specifications:
User Requirement Definition:
 The software must provide the means of representing and accessing
external files created by other tools.
System Requirement specification:
• The user should be provided with facilities to define the type of external
files.
• Each external file type may have an associated tool which may be
applied to the file.
• Each external file type may be represented as a specific icon on the
user’s display.
Functional requirements
 The functional requirements for a system describe what the system should
do.
 These requirements depend on the type of software being developed, the
expected users of the software, and the general approach taken by the
organization when writing requirements.
 When expressed as user requirements, functional requirements are
usually described in an abstract way that can be understood by system
users.
 However, more specific functional system requirements describe the
system functions, its inputs and outputs, exceptions, etc., in detail.
 Functional system requirements vary from general requirements covering
what the system should do to very specific requirements reflecting local
ways of working or an organization’s existing systems.
 For example where – F1: Search Book function Input: an author’s name
 Output: details of the author’s books and the location of these books in
the library So the function Search Book (F1) takes the author's name and
transforms it into book details.
 Functional requirements actually describe a set of high-level
requirements, where each high-level requirement takes some data from
the user and provides some data to the user as an output.
 FUNCTIONAL REQUIREMENTS
 Should be both complete and consistent
 Completeness -- All services required by the user should be defined
 Consistent -- Requirements should not have contradictory definition
 Difficult to achieve completeness and consistency for large system

Non-functional requirements
Non-functional requirements, as the name suggests, are requirements that
are not directly concerned with the specific services delivered by the
system to its users.
They may relate to emergent system properties such as reliability,
response time, and store occupancy.
Alternatively, they may define constraints on the system implementation
such as the capabilities of I/O devices or the data representations used in
interfaces with other systems.
Non-functional requirements, such as performance, security, or
availability, usually specify or constrain characteristics of the system as a
whole.
Non-functional requirements are often more critical than individual
functional requirements. System users can usually find ways to work
around a system function that doesn’t really meet their needs. However,
 failing to meet a non-functional requirement can mean that the whole
system is unusable.
For example, if an aircraft system does not meet its reliability
requirements, it will not be certified as safe for operation; if an embedded
control system fails to meet its performance requirements, the control
functions will not operate correctly.

classification of non-functional requirements:

Domain requirements:
 Domain requirements are the requirements which are characteristic of a
particular category or domain of projects.
 Domain be functional or nonfunctional.
 For instance, in an academic software that maintains records of a school
or college, the functionality of being able to access the list of faculty and
list of students of each grade is a domain requirement.
Other common classifications of software requirements can be:
 Software Requirement Specifications
The production of the requirements stage of the software development
process is Software Requirements Specifications (SRS) (also called
a requirements document). SRS is a formal report, which acts as a
representation of software that enables the customers to review whether it
(SRS) is according to their requirements. The SRS is a specification for a
specific software product, program, or set of applications that perform
particular functions in a specific environment. It serves several goals
depending on who is writing it. First, the SRS could be written by the
client of a system. Second, the SRS could be written by a developer of the
system. The two methods create entirely various situations and establish
 different purposes for the document altogether. The first case, SRS, is
used to define the needs and expectation of the users. The second case,
SRS, is written for various purposes and serves as a contract document
between customer and developer.
Characteristics of a good SRS
 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
REQUIREMENTS ENGINEERING PROCESSES
 The goal of requirements engineering process is to create and maintain a
system requirements document.
 The overall process includes four high-level requirement engineering sub-
processes.
It is a five-step process, which includes
 Feasibility Study
 Requirement Elicitation and Analysis
 Software Requirement Specification
 Software Requirement Validation
 Software Requirement Management

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.
 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
 Legal Feasibility
 In Legal Feasibility study project is analyzed in legality point of view.
 This includes analyzing barriers of legal implementation of project, data
protection acts or social media laws, project certificate, license, copyright
etc.
 Schedule Feasibility
 In Schedule Feasibility Study mainly timelines/deadlines is analyzed for
proposed project which includes how many times teams will take to
complete final project which has a great impact on the organization as
purpose of project may fail if it can’t be completed on time.
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.
 Analysis of requirements starts with requirement elicitation.
 The requirements are analyzed to identify inconsistencies, defects,
omission, etc.
 We describe requirements in terms of relationships and also resolve
conflicts if any
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.
 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 can be the check against the following conditions :
 If they can practically implement
 If they are correct and as per the functionality and specially of software
 If there are any ambiguities
 If they are full
 If they can describe
Requirements elicitation
 After an initial feasibility study, the next stage of the requirements
engineering process is requirements elicitation and analysis.
 In this activity, software engineers work with customers and system end-
users to find out about the application domain, what services the system
should provide, the required performance of the system, hardware
constraints, and so on.
 The process activities are:
Requirements discovery:
 This is the process of interacting with stakeholders of the system to
discover their requirements.
Requirements classification and organization:
 This activity takes the unstructured collection of requirements, groups
related requirements, and organizes them into coherent clusters.
Requirements prioritization and negotiation:
 Inevitably, when multiple stakeholders are involved, requirements will
conflict.
Requirements specification:
 The requirements are documented and input into the next round of the
spiral.
 It can be successful only through an effective customer-developer
partnership.
 It is needed to know what the users really need.
 There are a number of requirements elicitation methods. Few of them are
listed below:
 Interviews
 Brainstorming Sessions
 Facilitated Application Specification Technique (FAST)
 Quality Function Deployment (QFD)
 Use Case Approach
Interviews:
 Objective of conducting an interview is to understand the customer’s
expectations from the software.
 It is impossible to interview every stakeholder hence representatives from
groups are selected based on their expertise and credibility.
 Interviews maybe be open-ended or structured.
 In open-ended interviews there is no pre-set agenda. Context free
questions may be asked to understand the problem.
 In structured interview, agenda of fairly open questions is prepared.
 Sometimes a proper questionnaire is designed for the interview.
Brainstorming Sessions:
 It is a group technique
 It is intended to generate lots of new ideas hence providing a platform to
share views
 A highly trained facilitator is required to handle group bias and group
conflicts.
 Every idea is documented so that everyone can see it.
 Finally, a document is prepared which consists of the list of requirements
and their priority if possible.
Facilitated Application Specification Technique:
 This objective is to bridge the expectation gap –
 The difference between what the developers think they are supposed to
build and what customers think they are going to get.
 A team-oriented approach is developed for requirements gathering.
 Each attendee is asked to make a list of objects that are-
 Part of the environment that surrounds the system
 Produced by the system
 Used by the system
Quality Function Deployment:
 In this technique customer satisfaction is of prime concern, hence it
emphasizes on the requirements which are valuable to the customer.
 3 types of requirements are identified :
Normal requirements :
 In this the objective and goals of the proposed software are discussed
with the customer.
 Example – normal requirements for a result management system may be
entry of marks, calculation of results, etc
Expected requirements :
 These requirements are so obvious that the customer need not explicitly
state them.
 Example: protection from unauthorized access.
Exciting requirements:
 It includes features that are beyond customer’s expectations and prove to
be very satisfying when present.
 Example: when unauthorized access is detected, it should backup and
shutdown all processes.
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.
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.
Prerequisite of Software requirements
 Collection of software requirements is the basis of the entire software
development project.
 Hence they should be clear, correct, and well-defined.