SOFTWARE REQUIREMENTS

ENGINEERING

INTRODUCTIO
N
 Requirement
 Something required, something wanted or needed
 Webster’s dictionary

 There is a huge difference between wanted and needed and it should

be kept
in mind all the time

 Need- something you have to have

 Want -something you would like to have
 Software Requirements
 A complete description of what the software system will do without
describing how it will do it is represented by the software requirements

 Software requirements are complete specification of the desired external

behavior of the software system to be built

Response of
 Software requirements may be: software against
Abstract statements of services the input
Detailed mathematical functions
Part of the bid of contract
The contract itself
Part of the technical document, which describes a
product
 Requirement
Can be
functionalit
constraint
y

 A condition or capability that must be met or possessed by a

system...to satisfy a contract, standard, specif ication, or other
formally imposed document
IEEE Std 729
 Sources of Requirement
 Stakeholders
People affected in some way
by the system

 Documents
 Sources of Requirement
1
2

 Existing
system

 Application
Domain
The Goal of Software Development

 The goal of software development is to

develop quality software—on time and on
budget—that meets customers' real needs.

 A software is good if it MEETS

STAKEHOLDERS EXPECTATIONS:
 it is (at least) correct, reliable, maintainable,
user- friendly …
 the total cost it incurs over all phases of its life cycle
is minimal and within the budget
Context: Stakeholder's
Environment
Importance of Software
Requirements
The hardest single part of building
a software system is deciding what
to build….. No other part of the
work so cripples the resulting
system if done wrong. No other
part is dif ficult to rectify later. (Fred
Brooks)
The Root Causes of Project Success and
Failure
 The first step in resolving any problem is to understand the
root causes.

 The 1994 Standish Group survey study noted the three

commonly cited factors that caused projects to be "challenged":

 Lack of user input: 13 percent of all projects

 Incomplete requirements and specifications: 12 percent of all
projects
 Changing requirements and specifications: 12 percent of all
projects
The Root Causes of Project Success and
Failure
 Thereafter, the data diverges rapidly. Of course, your project
could fail
 Because of an unrealistic schedule or time frame (4 percent of the
projects this),
 inadequate staffing and resources (6 percent),
 inadequate technology skills (7 percent), or various other reasons.

 The survey shows that at least a third of development projects run into
trouble for reasons that are directly related to requirements gathering,
requirements documentation, and requirements management.
The Root Causes of Project Success and
Failure
 Although the majority of projects do seem to experience
schedule/budget overruns, the Standish Group found that 9
percent of the projects in large companies were delivered on time
and on budget; 16 percent of the projects in small companies
enjoyed a similar success. That leads to an obvious question: What
were the primary "success factors" for those projects?

 According to the Standish study, the three most important factors

were
 User involvement: 16 percent of all successful projects
The Root Causes of Project Success and
Failure
Executive management support: 14 percent of all successful
projects
Clear statement of requirements: 12 percent of all
successful projects
 High Cost of Requirement Errors
 If a unit cost of one is assigned to
the effort required
to detect and repair
an error during the coding stage.
 High Cost of Requirement Errors
 The errors discovered during the design of a development project
could fall into one of two categories:

errors that occurred when the development staff created a technical

design from a correct set of requirements or
errors that should have been detected as requirements errors somewhat
earlier in the process but that somehow "leaked" into the design phase of
the project.
 High Cost of Requirement Errors
 It's the latter category of errors that turn
out to be particularly expensive, for
two reasons.

 By the time the requirements-oriented error is

discovered, the development group will have
invested time and effort in building a design
from those erroneous requirements. As a result, the
design will probably have to be thrown away or
reworked.

 The true nature of the error may be disguised;

everyone assumes that they're looking for design
errors during the testing or inspection activities that
take place during this phase, and considerable time
and effort may be wasted until someone says, "Wait
a minute! This isn't a design mistake after all; we've
got the wrong requirements.―
High Cost of Requirement Errors- Defect
Leakage
 whenever a defect is
discovered in a software
application, we're likely to
experience the effect of 50–100
time
s cost.

Re-specification.

Redesign.

Recoding.

Retesting.

Change orders

Corrective action
 Requirements Engineering
Process
 Elicitation: work with the customer on
gathering requirements

 Analysis: process this information to

u n d e r s t a n d i t , cl a s s i f y i n v a r i o u s
categories, and relate the customer
needs to possible software requirements

 Specif ication: Structure the customer input

and derived requirements as written
documents and diagrams

 Validation: you’ll ask your customer to

conf ir m that what you’ve written is
accurate and complete and to correct
errors.
 Requirements Management
 Requirements management i s
the process o f
d
ocumenting, analyzing, tracing, prioritizing and agreeing on requirements and
then controlling change and communicating to relevant stakeholders.
 Types of Software Applications
 Information Systems

 Information systems and other applications developed for use within a company
(such as the payroll system being used to calculate the take-home pay for our
next paycheck). This category is the basis for the information system/information
technology industry, or IS/IT.
 Types of Software Applications
 Commercial Software Applications

 Software developed and sold as commercial products (such as the MS Of fice).

Companies developing this type of software are often referred to as independent
software vendors, or ISVs.
 Types of Software Applications
 Embedded Software's

 Software that runs on computers embedded in other devices, machines, or

complex systems (such as those contained in the airplane, in cell phones, in
washing machines, in ovens, the automobile and many more…….) This type of
software's are known as software embedded-systems applications, or embedded
applications.
 Functional Requirements
 In software engineering, a functional requirement defines a function of a
software
system or its Backbone
component. of

Requiremen
A function is described as a set of inputs, the behavior, and outputs.
ts

 Functional requirements may be calculations, technical details, data

manipulation and processing and other specif ic functionality that def ine
what a system is supposed to accomplish.

 Functional requirements are the statements and services that system

should provide in two clearly described external behaviors
 Reaction to particular input (e.g give some input to software and it produces a result)
 Behavior in particular situations (e.g If I click on an exit button then system behaves in a
particular way)
 Functional Requirements
 Functional Requirements can be stated from either static or dynamic
perspective
 The dynamic perspective describes the behavior of the system in terms of results
 The static perspective describes the functions performed by each entity and the way each
interacts with other entities and the environment

 Abnormal behavior is also documented as functional requirements in the

form of exception handling

 Functional requirements should be complete and consistent

 Customers and developers usually focus all their attention on functional

requirements
 Non-Functional Requirements
 In requirements engineering, a non-
functional requirement i
s a re quire me nt that spe cif ie s
criteria that can be used to judge the
operation of a s y s t e m , r a t h e r t h a n
specific behaviors.

 Non-functional requirements are

often called qualities of a system. Other
terms for non-functional requirements
are "constraints", "quality attributes"
, "quality goals", "quality of service
requirements" and "non-behavioral
requirements".
 Non-Functional Requirements

Types Explanation
Product specify that the delivered product must behave in a
requirements: particular way e.g. execution speed, reliability, etc.
are a consequence of organizational policies and
Organizational
pr oce du r e s e .g. pr oce ss st a nda r ds use d,
requirements:
implementation requirements, etc.
arise from factors which are external to the system
External
and its development process e.g. interoperability
requirements:
requirements, legislative requirements, etc.
 Non-Functional Requirements
Non-
functional
requirements

Product Organizationa External

requirement l requirement requirement
s s s

Efficiency Reliability Portability Interoperabilit Ethical

requir requirement requirement yrequirement requirement
ements s s s s

Usability Delivery Implementatio Standards Legislative

requirement requirement n requirement requirement requirement
s s s s s

Performanc Spac Privacy Safet

requirement
e requirement
e requirement requirement
y
s s s s
 Domain Requirements
 Requirements that come from the application domain and reflect
fundamental characteristics of that application domain

 These can be both the functional or non-functional requirements

 These requirements, sometimes, are not explicitly mentioned

 Their absence can cause significant dissatisfaction

 Domain requirements can impose strict constraints on solutions

 Inverse Requirements
 They explain what the system shall not do.

 Inverse requirements describe the constraints on the allowable behaviors

 Many people find it convenient to describe their needs in this

manner

 These requirements indicate the indecisive nature of customers about certain

aspects of a new software product

 Safety and security requirements are usually stated in this

manner
 Design and Implementation
Constraints
 They are development guidelines within which the designer must
work

 These requirements can seriously limit design and

implementation options

 Can also have impact on human resources

 Example:

 The system shall be developed using the Microsoft .Net platform

 The system shall be developed using open source tools and shall run on
Linux operating system
 The System should be implemented using c sharp language
 The software must fit into the memory of a 512Kbyte machine.
 Problem Domain Problem Domain

 Most successful requirements journeys begin with a trip to the land of problem.

 This problem domain is the home of real users and other stakeholders, people whose needs
must be addressed in order for us to build the perfect system.

 This is the home of the people who need the rock or a new sales order entry system or a
configuration management system good enough to blow the competition away.

 In all probability, these people are not like us. Their technical and economic backgrounds
are different from ours.

 On rare occasions, they are just like us. They are programmers looking for a new tool or
system developers who have asked you to develop a portion of the system.
 Problem Domain

 The se use r s ha v e busi ne ss or t e chni ca l

problems that they need our help to solve.

 The r e for e , it be com e s our pr oble m t o

understand their problems, in their culture and
their language, and to build systems that meet
their needs.

 Within the problem domain, we use a set of

team skills to gain an understanding of the
problem and the needs that must be f il led to
address this problem.
 Stakeholder Needs
 Stakeholders are people who have a stake or interest in the
project

 It is also our responsibility to understand the needs of users and

other stakeholders whose lives will be affected by our solution.

 As we elicit those needs, we'll stack them in a little pile called

stakeholder needs, which we represent as a pyramid.

Needs
Moving towards the solution domain
 We move to Solution domain from the problem domain in order to provide a
solution to the problem at hand.

 In the solution space, we focus on def ining a solution to the user's problem;
this is the realm of computers, programming, operating systems, networks,
and processing nodes. Here, we can apply the skills we have learned much
more directly.
Moving towards the solution domain

 Features of the System

 a service provided by the system that fulfills one
or more stakeholder needs.

 This list could consists of such items as the following.

 "The car will have power windows.―

 "The cell provides pattern to lock screen"

 ― The Attendance of students will be enrolled through

face recognition ."

 These are simple descriptions, in the user's language, that

we will use as labels to communicate with the user how
our system addresses the problem.
 Moving towards the solution domain
Software Requirements

Once we have established the feature set and have

gained agreement with the customer, we can move
on to defining the more specific requirements we will
need to impose on the solution.

If we build a sy stem that conf orms to those

requirements, we can be certain that the system we
develop will deliver the features we promised. In turn,
since the features address one or more stakeholder
needs, we will have addressed those needs directly
in the solution.

 These more specif ic requirements are the software

requirements.
 Overview of the Problem Domain
and Solution Domain
 We have moved from the problem domain, represented by the user needs we
discovered, to a def in ition of a system that will constitute the solution domain,
represented by the features of the system and the software requirements that
will drive its design and implementation.