Software Requirements

Software Requirements
The software requirements are description of features and
functionalities of the target system. Requirements convey the
expectations of users from the software product. The
requirements can be obvious or hidden, known or unknown,
expected or unexpected from client’s point of view.
The process of establishing what services are required and the
constraints on the system’s operation and development
Requirements engineering help software engineers to better
understand the problem they will work to solve. It encompasses
the set of tasks that lead to an understanding of what the
business impact of the software will be, what the customer wants
and how end-users will interact with the software.
 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 the process of
establishing
 the services that the customer requires from a system
 the constraints under which it operates and is developed
 Requirement Engineering Process
It is a four step process, which includes:
• Feasibility Study
• Requirement Gathering
• Software Requirement Specification
• Software Requirement Validation
The Requirements Engineering Process
Require ments
Feasibility
elicitation and
study
analy sis
Requirements
specification
Feasibility Require ments
report validation

System
models
User and system
requirements

Require ments
document
 Feasibility study
When the client approaches the organization for getting
the desired product developed, it comes up with rough
idea about what all functions the software must perform
and which all features are expected from the software.
Referencing to this information, the analysts does a
detailed study about whether the desired system and its
functionality are feasible to develop.
 Cont…
This feasibility study is focused towards goal of the
organization. This study analyzes whether the software
product can be practically materialized in terms of
implementation, contribution of project to organization, cost
constraints and as per values and objectives of the
organization. It explores technical aspects of the project and
product such as usability, maintainability, productivity and
integration ability.
The output of this phase should be a feasibility study report
that should contain adequate comments and
recommendations for management about whether or not the
project should be undertaken.
 Requirements Elicitation
• It is the practice of obtaining the requirements of a system from
users, customers and other stakeholders. The practice is also
sometimes referred to as Requirement gathering.

• Requirements elicitation practice include the following:

– Interviews
– Questionnaires
– User observation
– Workshops
– Brain storming
– Use cases
– Role playing
– And prototyping
 Requirements Elicitation
• Problems of Requirement Elicitation
– Problems of scope: The boundary of system is ill-
defined. Or unnecessary details are provided.
– Problems of understanding: The users are not
sure of what they need, and don’t have full
understanding of the problem domain.
– Problems of volatility: the requirements change
overtime.
 Requirements Elicitation

• Guidelines of Requirements Elicitation

– Assess the business and technical feasibility for the proposed system
– Identify the people who will help specify requirements.
– Define the technical environment (e.g. computing architecture, operating
system, telecommunication needs) into which the system or product will be
placed
– Identify “domain constraints” (i.e. characteristics of the business environment
specific to the application domain) that limit the functionality or performance
of the system or product to build
– Define one or more requirements elicitation methods (e.g. interviews, team
meetings, ..etc)
– Solicit participation from many people so that requirements are defined from
different point of views.
– Create usage scenarios of use cases to help customers/ users better identify
key requirements.
 Requirements Analysis

• Requirements Analysis, determining whether

the stated requirements are clear, complete,
consistent and unambiguous.
 Requirements Analysis

• Stakeholder Identification
– Stakeholders are people or organizations that have a
valid interest in the system. They may be affected by
it directly or indirectly.
– Stake holders may include:
• Anyone who operates the system
• Anyone who benefits from the system
• Anyone involved in purchasing or procuring the system
• People opposed to the system (negative stakeholders)
• Organizations responsible for the system
 Requirements Analysis

• Stakeholder Interviews
– Interviews are a common technique used in
requirement analysis.
– This technique can serve as a means of obtaining
the highly focused knowledge from different
stakeholders perspectives
 Requirements Analysis

• Types of Requirements:
– Customer Requirements:
• Operational distribution or deployment: Where will the system be
used?
• Mission profile or scenario: How will the system accomplish its mission
objective?
• Performance and related parameters: What are the critical system
parameters to accomplish the mission?
• Utilization environments: how are the various system components to
be used?
• Effectiveness requirements: How effective or efficient must the system
be in performing its mission?
• Operational life cycle: How long will the system be in use by the user?
• Environment: what environments will the system be expected to
operate in an effective manner?
 Requirements Analysis

• Types of Requirements:
– Architectural Requirements:
• A formal description and representation of a system,
organized in a way that support reasoning about the
structure of the system which comprises system
components, the externally visible properties of those
components, the relationships and the behavior
between them, and provides a plan from which
products can be procured and systems developed, that
will work together to implement the overall system.
 Requirements Analysis

• Types of Requirements:
– Functional Requirements:
• Defines functions of a software system or its
components. They may be calculations, technical
details, data manipulation and processing and other
specific functionality that define “what a system is
supposed to accomplish?”
• They describe particular results of a system.
• Functional requirements are supported by Non-
functional requirements.
 Requirements Analysis

• Types of Requirements:
– Non-Functional Requirements:
• They are requirements that specify criteria that can be used to judge
the operation of a system, rather than specific behavior.
• Functional requirements define what the system is supposed to do,
whereas non-functional requirements define how a system is
supposed to be.
• Non-functional requirements can be divided into two main categories:
– Execution qualities, such as security and usability, which are
observable at runtime.
– Evolution qualities, such as testability, maintainability and scalability.
 Requirements Specifications
• Requirements Specification is the direct result
of a requirement analysis and can refer to:
– Software Requirements Specification
– Hardware Requirements Specification
Software Requirement Specification
A software requirements specification (SRS) is a
description of a software system to be developed. A
software requirements specification (SRS) is a document
that captures complete description about how the
system is expected to perform. It is usually signed off at
the end of requirements engineering phase. The
software requirements specification lays out functional
and non-functional requirements, and it may include a
set of use cases that describe user interactions that
the software must provide.
 Requirements Specifications
• A Software Requirements Specification (SRS) – a
requirements specification for a software system –
is a complete description of the behavior of a
system to be developed. It includes a set of use
cases that describe all the interactions the users
will have with the software. In addition to use
cases, the SRS also contains non-functional
requirements (such as performance requirements,
quality standards, or design constraints)
 Requirements Specifications
• A Software Requirements Specification (SRS)
– The software requirement specification document enlists all necessary
requirements for project development. To derive the requirements we
need to have clear and thorough understanding of the products to be
developed.
– A general organization of an SRS is as follows:
• Introduction
– Purpose, Scope, Definitions, System Overview, References
• Overall Description
– Product Perspective, Product functions, User characteristics,
constraints, assumptions and dependencies.
• Specific Requirements
– External Interface requirements, functional requirements,
performance requirements, design constraints, logical database
requirement, software system attributes.
 Requirements Validation and Verification

• Validation (& Verification), is the process of

checking whether the requirements, as
identified, do not contradict the expectations
about the system of various stakeholders and
do not contradict each other.
• It is Requirements Quality Control
 Validation Vs. Verification
• Validation: “Am I building the right product?” checking a
work product against higher-level work products or
authorities that frame this particular product.
– Requirements are validated by stakeholders

• Verification: “Am I building the product right?” checking

a work product against some standards and conditions
imposed on this type of product and the process of its
development.
– Requirements are verified by the analysts mainly
Requirements Engineering

Requirements Engineering

Requirements Elicitation Requirements Analysis

Requirements Specification Requirements Verification

Requirements Management
 Requirements Engineering
• Stakeholder identification
• Stakeholder interviews
• Contract-style requirement lists
• Measurable goals
• Prototypes
• Use cases
 Requirements Engineering
• Eliciting requirements: the task of communicating
with customers and users to determine what their
requirements are. This is sometimes also called
requirements gathering.
• Analyzing requirements: determining whether the
stated requirements are unclear, incomplete,
ambiguous, or contradictory, and then resolving
these issues.
• Recording requirements (specification):
Requirements might be documented in various
forms, such as natural-language documents,
use cases, user stories, or process specifications.
 Eliciting Requirements
• Analysts can employ several techniques to
elicit the requirements from the customer.
– interviews,
– focus groups (requirements workshops) and
creating requirements lists.
– prototyping, and use cases.
– combination of these methods
 Requirement Elicitation Techniques
Detailed
Interviews:
Interviews are strong medium to collect requirements. Organization
may conduct several types of interviews such as:
• Structured (closed) interviews, where every single information to
gather is decided in advance, they follow pattern and matter of
discussion firmly.
• Non-structured (open) interviews, where information to gather is
not decided in advance, more flexible and less biased.
• Oral interviews
• Written interviews
• One-to-one interviews which are held between two persons across
the table.
• Group interviews which are held between groups of participants.
They help to uncover any missing requirement as numerous people
are involved.
 Cont…
Surveys:
Organization may conduct surveys among various
stakeholders by querying about their expectation and
requirements from the upcoming system.
Questionnaires:
A document with pre-defined set of objective questions
and respective options is handed over to all stakeholders
to answer, which are collected and compiled.
A shortcoming of this technique is, if an option for some
issue is not mentioned in the questionnaire, the issue
might be left unattended.
 Cont…
Task analysis:
Team of engineers and developers may analyze the
operation for which the new system is required. If the
client already has some software to perform certain
operation, it is studied and requirements of proposed
system are collected.
Domain Analysis:
Every software falls into some domain category. The
expert people in the domain can be a great help to
analyze general and specific requirements.
 Cont…
Brainstorming:
An informal debate is held among various stakeholders and all their inputs
are recorded for further requirements analysis.
Prototyping:
Prototyping is building user interface without adding detail functionality
for user to interpret the features of intended software product. It helps
giving better idea of requirements. If there is no software installed at
client’s end for developer’s reference and the client is not aware of its own
requirements, the developer creates a prototype based on initially
mentioned requirements. The prototype is shown to the client and the
feedback is noted. The client feedback serves as an input for requirement
gathering.
Observation:
Team of experts visit the client’s organization or workplace. They observe
the actual working of the existing installed systems. They observe the
workflow at client’s end and how execution problems are dealt. The team
itself draws some conclusions which aid to form requirements expected
from the software.
 Software Requirement Analysis
• Determining the needs or conditions to meet for a new or
altered product,

• In other words, process of studying and analyzing the

customer and the user/stakaholder needs to arrive at a
definition of software reqiurements.

• Requirements must be actionable, measurable, testable,

related to identified business needs or opportunities, and
defined to a level of detail sufficient for system design.

• Requirements can be functional and non-functional.

 Types of Requirements
• Functional requirements
• Performance requirements
– Speed, accuracy, frequency, throughput
• External interface requirements
• Design constraints
– Requirements are usually about “what”, this is a “how”.
• Quality attributes
– i.e. reliability, portability, maintainability, supportability
 Types of Requirements
The below diagram depicts the various types of requirements
that are captured during SRS.
 Requirements vs. Design
Requirements Design
Describe what will be delivered Describe how it will be done

Primary goal of analysis: Primary goal of design:

UNDERSTANDING OPTIMIZATION
There is more than one solution There is only one (final)
solution
Customer interested Customer not interested (Most
of the time) except for external
 Software Quality Attributes
 Correctness
 Reliability
 Rating = 1 – (Num Errors/ Num LOC)

 Can be allocated to subsystems

 Efficiency
 Integrity
 Usability
 Survivability
 Maintainability
 Verifiability
 Flexibility
 Portability
 Reusability
 Expandability
 Requirements Analysis
Defining Stakeholder profiles

• Description - brief description of the stakeholder type

• Type - Qualify , expertise, technical background, degree of
sophistication
• Responsibilities - List key responsibilities with regard to the
system being developed - why a stakeholder?
• Success Criteria - How does the stakeholder define success?
How rewarded?
• Involvement - involved in the project in what way?
Requirements reviewer, system tester, ...
• Deliverables* - required by the stakeholder
• Comments/Issues - Problems that interfere w/ success, etc.
 Requirements Analysis
Defining User Profiles

• Description - of the user type

• Type - qualify expertise, technical background, degree of
sophistication
• Responsibilities - user’s key resp.’s w.r.t. system being
developed
• Success Criteria - how this user defines success? rewarded?
• Involvement - How user involved in this project? what role?
• Deliverables - Are there any deliverables the user produces?
For whom?
• Comments/Issues - Problems that interfere w/ success, etc.
– This includes trends that make the user’s job easier or harder
 Requirements Analysis
Defining User Work Environment

• Number of people involved in doing this now?

Changing?
• How long is a task cycle now? Changing?
• Any unique environmental constraints: mobile,
outdoors, in-flight, etc.
• Which system platforms are in use today? future?
• What other applications are in use? Need to
integrate?
 Requirements Analysis
Product Overview

Put the product in perspective to other related

products and the user’s environment.
Independent?
Component of a larger system?
How do the subsystems interact with this?
Known interfaces between them and this
component?
 Requirements Analysis
Other Product Requirements

• hardware platform requirements --

• system requirements -- supported host, peripherals,
companion software
• environmental requirements -- temperature, shock,
humidity, radiation, usage conditions, resource
availability, maintenance issues, type of error
recovery
• applicable standards -- legal, regulatory,
communications
 Software Requirement Specification
• A software requirements specification (SRS) is a complete
description of the behavior of the system to be developed

• A document that clearly and precisely describes, each of the

essential requirements of the software and the external
interfaces.
– (functions, performance, design constraint, and quality attributes)

• Each requirement is defined in such a way that its

achievement is capable of being objectively verified by a
prescribed method; for example inspection, demonstration,
analysis, or test.
 Requirements Analysis
• Fundamental Techniques (Views)
• functional view
– hierarchy - function tree
– process  use cases
– information  data flow diagram (DFD)
• data oriented view
– data structures  data dictionary (DD), syntax diagram,
– relations between entities  entity relationship diagram
(ER)
• object-oriented view
– class structure  class diagram
 Requirements Analysis

• algorithmic view
– control structures
– pseudo code, structogram, flow diagram
– conditions  rules, decision table
• state-oriented view
– state machines
– Petri nets
– sequence charts
 Data Dictionary

• A data dictionary is a collection of data about

data.
• It maintains information about the definition,
structure, and use of each data element that
an organization uses.