SWE2003 - Requirements

Engineering and Management

Dr. B.Valarmathi
Associate Professor Senior, Dept. of SSE,
SITE, VIT, Vellore.
valarmathi.b@vit.ac.in

M.Tech. (SE) 5 Year Integrated Programme

Fall Semester 2021 - 2022
School of Information Technology and Engineering
VIT University, Vellore

24-Aug-21 SWE2003 - Requirements Enginering and 1

Management
 1.2 Introduction to
Requirements Management
 Software requirements
 Requirements management
 The problem domain
 The solution domain

24-Aug-21 SWE2003 - Requirements Enginering and 2

Management
Software Requirements (SRs)
 The SRs are description of features and
functionalities of the target system.
 Requirements are specific descriptions of the
client's needs.
 Example

24-Aug-21 SWE2003 - Requirements Enginering and 3

Management
Contd….
 Requirements convey the expectations of users
from the software product.
 The requirements can be obvious or hidden from
client’s point of view.
 SRs are usually expressed as a statements.
 SR is a Functional or Non-functional need that has
to be implemented into the system.

24-Aug-21 SWE2003 - Requirements Enginering and 4

Management
 Functional and non-functional
requirements Analysis with example
 Functional means providing particular service to
the user.
 For example, in context to banking application the
functional requirement will be when customer selects
"View Balance" they must be able to look at their
latest account balance.
 .
Software requirement can also be a non-functional,
it can be a performance requirement.
 For example, a non-functional requirement is where
every page of the system should be visible to the
users within 5 seconds.

24-Aug-21 SWE2003 - Requirements Enginering and 5

Management
 Difference between functional and
non-functional requirements
FUNCTIONAL NON FUNCTIONAL
REQUIREMENTS REQUIREMENTS
A functional requirement A non-functional requirement defines
defines a system or its the quality attribute of a software
component. system. (Portability, Security,
Maintainability, Reliability, Scalability,
Performance, Reusability, Flexibility)
Specified by User. Specified by technical peoples e.g.
Architect, Technical leaders and
software developers.
It is mandatory. It is not mandatory.

24-Aug-21 SWE2003 - Requirements Enginering and 6

Management
Example – Functional and non
functional requirements
FUNCTIONAL
REQUIREMENTS
1) Authentication of user whenever
he/she logs into the system.
2) System shutdown in case of a
cyber attack.
NON FUNCTIONAL
REQUIREMENTS
1) Emails should be sent with a latency
of no greater than 12 hours from such
an activity.
2) The processing of each request
should be done within 10 seconds

3) A Verification email is sent to user 3) The site should load in 3 seconds

whenever he/she registers for the when the number of simultaneous users
first time on some software system. are > 10000

24-Aug-21 SWE2003 - Requirements Enginering and 7

Management
What is a Software Requirement? -
(Dorfman and Thayer [1990])
It is a software capability that
 is needed by the user to solve a problem to
achieve an objective
 must be met or possessed by a system or
system component to satisfy a contract,
standard, specification, or other formally
imposed documentation.

24-Aug-21 SWE2003 - Requirements Enginering and 8

Management
What is Requirements Management (RM)?

 A systematic approach for

 Eliciting,
 Organizing, and
 Documenting
the requirements of the system, and
 a process that establishes and maintains
agreement between the customer and the
project team on the changing requirements
of the system.
24-Aug-21 SWE2003 - Requirements Enginering and 9
Management
Key Concepts in RM
 The ability to elicit the requirements from users and
stakeholders is a crucial skill.

24-Aug-21 SWE2003 - Requirements Enginering and 10

Management
Key Concepts in RM
 Since hundreds, if not thousands, of
requirements are likely to be associated with
a system, it's important to organize them.

24-Aug-21 SWE2003 - Requirements Enginering and 11

Management
Key Concepts in RM
 documenting the requirements is necessary to support
effective communication among the various stakeholders.
The requirements have to be recorded in an accessible
medium: a document, a model, a database, or a list on the
whiteboard.

24-Aug-21 SWE2003 - Requirements Enginering and 12

Management
Example of RM activities
 Which project team member is responsible
for requirement # 125, (analyze, modify,
change, ....etc)
 If requirement # 125 is modified what other
requirements will be affected?
 Which part of the software will satisfy
requirement #125 …. who is going to do that
....how do we test it?

24-Aug-21 SWE2003 - Requirements Enginering and 13

Management
Formal Requirements Management
Organized and formal processes of
requirements management can be found in
 Capability Maturity Model (CMM) – [5 levels -
initial, managed, defined, quantitatively
managed and optimizing)
 ISO 9000 for quality management standards

24-Aug-21 SWE2003 - Requirements Enginering and 14

Management
Capability Maturity Model (CMM)
Levels
 Maturity Level 1: Initial
Unpredictable and reactive. Work gets completed but is
often delayed and over budget.
 Maturity Level 2: Managed
Managed on the project level. Projects are planned,
performed, measured, and controlled.
 Maturity Level 3: Defined
Proactive, rather than reactive. Organization-wide
standards provide guidance across projects, programs,
and portfolios.

24-Aug-21 SWE2003 - Requirements Enginering and 15

Management
Contd…

 Maturity Level 4: Quantitatively Managed

Measured and controlled. Organization is data-driven with
quantitative performance improvement objectives that are
predictable and align to meet the needs of internal and
external stakeholders.
 Maturity Level 5: Optimizing
Stable and flexible. Organization is focused on continuous
improvement and is built to pivot and respond to
opportunity and change. The organization’s stability
provides a platform for agility and innovation.

24-Aug-21 SWE2003 - Requirements Enginering and 16

Management
 Application of RM Techniques -
Types of Software Applications
 IS/IT: Information systems and other applications
developed for use within a company, e.g., the payroll
system of a certain company
 ISV: Software developed and sold as commercial
products., e.g. MS Word, Excel
 Companies developing this type of software are
referred to as independent software vendors (ISVs).
 Embedded applications: Software that runs on
computers embedded in other devices, machines, or
complex systems, e.g. software in cell phones,
automobile
24-Aug-21 SWE2003 - Requirements Enginering and 17
Management
 The Road Map
 To develop quality software—on time and on budget—that meets
customers' real needs.
 Many questions will arise:
 Is this a need or a requirement?
 Is this a nice-to-have or a must-have?
 Is this a statement of the problem or a statement of the solution?
 Is this a goal of the system or a contractual requirement?
 Do we have to program in Java?
 Who doesn't like the new system, and where was that person
when we visited here before?

24-Aug-21 SWE2003 - Requirements Enginering and 18

Management
 The Road Map
 Problem domain is related to the
 Stakeholder needs
 (e.g.) the drivers and other users find it difficult to operate the
manual opening and close of windows in their car.
 Solution domain is related to the
 Features of the system (e.g.) Feature: Power Window
 Software requirements (e.g.) 1) The window must fully open
and fully close within 5 s. 2) If the up command is issued for
between 200 ms and 1 s, the window must fully open. If the
down command is issued for between 200 ms and 1 s, the
window must fully close.

24-Aug-21 SWE2003 - Requirements Enginering and 19

Management
 Separate the problem from the
solution
 A separate problem description is useful:
 Problem statement can be discussed with
stakeholders
 Problem statement can be used to evaluate
design choices
 Problem statement is a source of good test
cases
 Still need to check:
 Solution correctly solves the stated problem
 Problem statement corresponds to the needs of
the stakeholders

24-Aug-21 SWE2003 - Requirements Enginering and 20

Management
 Difference between verification
and validation
 Verification is the process of checking that a software achieves its
goal without any bugs. It is the process to ensure whether the
product that is developed is right or not. It verifies whether the
developed product fulfills the requirements that we have.
Verification is static testing.
Verification means Are we building the product right?
 Validation is the process of checking whether the software product
is up to the mark or in other words product has high level
requirements. It is the process of checking the validation of product
i.e. it checks what we are developing is the right product. it is
validation of actual and expected product. Validation is the dynamic
testing.
Validation means Are we building the right product?

24-Aug-21 SWE2003 - Requirements Enginering and 21

Management
Verification Validation
It consists of checking of documents/files and is It consists of execution of program and is
performed by human. performed by computer.

Verification is the static testing. Validation is the dynamic testing.

It does not include the execution of the code. It includes the execution of the code.

Methods used in verification are reviews, Methods used in validation are Black Box Testing,
walkthroughs, inspections and desk-checking. White Box Testing and non-functional testing.

It checks whether the software meets the

It checks whether the software conforms to
requirements and expectations of a customer or
specifications or not.
not.

It can find the bugs in the early stage of the It can only find the bugs that could not be found by
development. the verification process.

The goal of verification is application and software

The goal of validation is an actual product.
architecture and specification.

Validation is executed on software code with the

Quality assurance team does verification.
help of testing team.

It comes before validation. It comes after verification.

24-Aug-21 SWE2003 - Requirements Enginering and 22

Management
Example - Advertisement

 Problem situation

 Problem statement

 Implementation statement

 System

24-Aug-21 SWE2003 - Requirements Enginering and 23

Management
But design changes the world…

24-Aug-21 SWE2003 - Requirements Enginering and 24

Management
The Problem Domain
 Problem domain
 Consists of the real users and other stakeholders i.e. people
whose needs must be addressed.
 These users have business or technical problems. Hence they
need our help to solve.
 Therefore, the software developers should understand the problems of
the users and all stakeholders, in their culture and in their language.
 This helps in building software systems that meet their needs.

24-Aug-21 SWE2003 - Requirements Enginering and 25

Management
Stakeholders Needs

 It is also our responsibility to understand the

needs of users and other stakeholders.

24-Aug-21 SWE2003 - Requirements Enginering and 26

Management
Moving Toward the Solution domain
 The solution domain starts with a definition
of the software system (to be developed) in
terms of:
 the features of the system
 the software requirements that will drive its
design and implementation.

24-Aug-21 SWE2003 - Requirements Enginering and 27

Management
Features of the System
 A feature refers to the service provided by the software system.
 It fulfils one or more stakeholder needs.
 Features are expressed in simple statements, in the user's language.
 Based on a detailed user survey, a car manufacturer comes to know that the
drivers and other users find it difficult to operate the manual opening and
close of windows in their car. (This is problem domain)
 The future versions of the car should overcome this difficulty. Technically if
you decode this problem domain, what you understand is…the users prefer
to operate the windows by clicking a button. A sample feature that will inspire
a potential buyer will be as follows:
"The car will have power windows.“

24-Aug-21 SWE2003 - Requirements Enginering and 28

Management
Software Requirements

 After finalizing the the feature set the users must accept them.

 The next step is to define more specific requirements needed

in the solution.

 This will ensure that the system we develop will deliver the
features we promised.

24-Aug-21 SWE2003 - Requirements Enginering and 29

Management
 Overview of the Problem Domain and
the Solution Domain
Problem domain:

Feature:

Software Requirements (Quantitative)

24-Aug-21 SWE2003 - Requirements Enginering and 30

Management
Key points
 A requirement denotes the capability requirements of the
system.

 Requirements management consists of eliciting, organizing,

and documenting the requirements for a complex system.

 The key challenge is to understand the users' problems in their

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

 A feature is a service (aspect) that the system provides to fulfill

one or more stakeholder needs.

24-Aug-21 SWE2003 - Requirements Enginering and 31

Management
Key points
 The goal of software development
 develop quality software – on time and on budget

 Project success depends on effective requirements

management.

 Requirements errors are the most common type of systems

development error

 Requirements error are the most costly to fix (25% - 40% of the
total project budget).

 A few key skills can significantly reduce requirements errors

and thus improve software quality.

24-Aug-21 SWE2003 - Requirements Enginering and 32

Management