SOFTWARE REQUIREMENTS

ENGINEERING

INTRODUCTI
ON
 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
functionali
constraint
ty
 A condition or capability that must be met or possessed by a
system...to satisfy a contract, standard, specification, or other
formally imposed document
🞑 IEEE Std 729
 Sources of Requirement
 Stakeholders
🗸People affected in some way
by the system

 Documents
 Sources of Requirement
12

 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
difficult 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 discoveredin a software application,
we're likely to experience the effect of 50–100 times 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

understand it, classify in various
categories, and relate the customer
needs to possible software requirements

 Specification: Structure the customer input

and derived requirements as written
documents and diagrams

 Validation: you’ll ask your customer to

confirm that what you’ve written is
accurate and complete and to correct
errors.
 Requirements Management
 Requirements management is the process
of documenting, 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 Office).

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
 Requireme
A function is described as a set of inputs, the behavior, and outputs.
nts
 Functional requirements may be calculations, technical details, data
manipulation and processing and other specific functionality that define 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
is a requirement
that specifies criteria that
can be used to judge the operation
of a system, rather
than 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
requirements: a
particular way e.g. execution speed, reliability, etc.
are a consequence of organizational policies and
Organizational
procedures e.g. process standards used, implementation
requirements:
requirements, etc.
arise from factors which are external to the system and its
External
development process e.g. interoperability requirements,
requirements:
legislative requirements, etc.
 Non-Functional Requirements
Non-functional
requirements

Product Organizational External

requirements requirements requirements

Efficiency Reliability Portability Interoperability Ethical

requir ements requirements requirements requirements requirements

Usability Delivery Implementation Standards Legislative

requirements requirements requirements requirements requirements

Performance Space Privacy Safety

requirements requirements requirements requirements
 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
 These users have business or technical
problems that they need our help to solve.

 Therefore, it becomes our problem to

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 filled 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 defining 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 system that conforms 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 specific 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 definition 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.