1

SOFTWARE REQUIREMENT
ENGINEERING

Chapter - 1
 What are requirements?
2

 Requirements are defined during the early stages of a system development as a

specification of what should be implemented or as a constraint of some kind on
the system. Something required, something wanted or
needed
 They may be: • Need- something you have to have
• Want -something you would like to have
 a user-level facility description,

 a detailed specification of expected system behaviour,

 a general system property,

 a specific constraint on the system,

 information on how to carry out some computation,

 a constraint on the development of the system.

 Product and Process Requirements
3

 Product parameters are requirements on software to be developed

 for example, “The software shall verify that a student meets all
prerequisites before he or she registers for a course.”.
 A process parameter is essentially a constraint on the development
of the software.
 for example, “The software shall be written in Ada.”.
 What is requirements engineering?
4

 Requirements engineering covers all of the activities involved in

discovering, documenting, and maintaining a set of requirements
for a computer-based system.

 The use of the term ‘engineering’ implies that systematic and

repeatable techniques should be used to ensure that system
requirements are complete, consistent, relevant, etc.
 Sub-disciplines of Software Requirements Engineering
5

 These sub-disciplines encompass all the activities involved with exploring,

evaluating, documenting, and confirming the requirements for a product
 What happens if the requirements are wrong?
6

 The system may be delivered late and cost more than originally
expected.
 The customer and end-users are not satisfied with the system. They
may not use its facilities or may even decide to scrap it altogether.
 The system may be unreliable in use with regular system errors and
crashes disrupting normal operation.
 If the system continues in use, the costs of maintaining and evolving
the system are very high.
 Why is requirements engineering difficult?
7

 Businesses operate in a rapidly changing environment so their

requirements for system support are constantly changing.
 Multiple stakeholders with different goals and priorities are involved
in the requirements engineering process.
 System stakeholders do not have clear ideas about the system
support that they need.
 Requirements are often influenced by political and organisational
factors that stakeholders will not admit to publicly.
 RE process inputs and outputs
8

Existing
systems
information

Stakeholder Agreed
needs requirements

Requirements System
Organisational engineering process
standards specification

System
Regulations models

Domain
information
 Requirements engineering processes
9

 The goal of RE Process is to create & maintain a system

requirements documents.
 Includes 4 High level RE Sub-processes:
 Feasibility study : usefulness to the business ;
 Elicitation and analysis : discovering and analyzing requirements;
 Specification: conversion of requirement into some standard form;
 Validation : check the requirements which defines the system that
the customer wants;
 The requirements engineering process
10
 Feasibility studies
11

 A feasibility study decides whether or not the proposed system is

worthwhile.
 A short focused study that checks:
 If the system contributes to organizational objectives;
 If the system can be implemented using current technology, within
given cost and schedule constraints;
 If the system can be integrated with other systems that are already
in place.
 Feasibility study implementation
12

 Feasibility study involves information assessment (what is required),

information collection and report writing.
 Questions for people in the organization for information assessment and
collection:
 What if the system wasn’t implemented?
 What are current process problems?
 How will the proposed system help?
 What will be the integration problems?
 Is new technology needed? What skills?
 What facilities must be supported by the proposed system?
 Feasibility study report should make a recommendation about the
development to continue or not.
 Requirements elicitation and analysis
13
Requirement Elicitation
 Elicitation encompasses all of the activities involved with discovering requirements.
 The key actions are:
 Identifying the product’s expected user classes and other stakeholders.
 Understanding user tasks and goals and the business objectives with which those
tasks align.
 Learning about the environment in which the new product will be used.
 Working with individuals who represent each user class to understand their
functionality needs and their quality expectations.
 Requirements elicitation typically takes either a usage-centric (understanding and
exploring user goals ) or a product-centric approach (focuses on defining features)
 Requirements elicitation and analysis..
14

 Eliciting & understanding stakeholder requirement is difficult due to the

following reasons:
 Stakeholders don’t know what they really want except in most general.
 Stakeholders express requirements in their own terms.
 Different stakeholders may have deferent requirements.
 Organizational & political factors may influence the system requirements.
 The requirements change during the analysis process.
 New stakeholders may emerge and the business environment change.
 Requirements elicitation and analysis..
15

Requirement Analysis
 understanding of each requirement & representing sets of requirements in multiple
ways.
 Following are the principal activities:
 Analysing the information received from users to distinguish their task goals
from functional requirements, quality expectations, business rules, suggested
solutions, and other information
 Decomposing high-level requirements into an appropriate level of detail

 Deriving functional requirements from other requirements information

 Understanding the relative importance of quality attributes

 Allocating requirements to software components defined in the system

architecture
 Negotiating implementation priorities

 Identifying gaps in requirements or unnecessary requirements as they relate to

the defined scope
 E&A Process activities…
16

 Requirements discovery
 Interacting with stakeholders to discover their requirements. Domain
requirements are also discovered at this stage.
 Requirements classification and organization
 Group related requirements and organizes them into coherent clusters.
 Prioritization and negotiation
 Prioritizing requirements & finding and resolving requirements conflicts.
 Requirements documentation
 Requirements are documented and input into the next round of the spiral.
 Requirements elicitation & analysis Process…
17
 Requirements elicitation & analysis Process…
18

Requirements discovery
 The process of gathering information about the proposed and existing
systems and distilling the user and system requirements from this
information.
 Sources of information include documentation, system stakeholders and the
specifications of similar systems.
 Approaches & Techniques of requirements discovery are:
 Questioner
 Interviewing
 Document analysis
 Use-cases
 Requirements Specification
19

 Requirements specification involves representing and storing the collected

requirements knowledge in a persistent and well-organized fashion.
 The principal activity is:
 Translating the collected user needs into written requirements and
diagrams suitable for comprehension, review, and use by their
intended audiences.
 A complete Software Requirement Specifications should be:
 Clear, Correct, Consistent, Coherent, Comprehensible, Modifiable
Verifiable, Prioritized, Unambiguous, Traceable…
 Requirements validation…
20

 Confirms that you have the correct set of requirements information

that will enable developers to build a solution that satisfies the
business objectives
 Concerned with demonstrating that the requirements define the
system that the customer really wants.
 Requirements error costs are high so validation is very important
 Fixing a requirements error after delivery may cost up to 100
times the cost of fixing an implementation error.
 Requirements validation…
21

Requirements checking
 Validity: Does the system provide the functions which best support
the customer’s needs?
 Consistency: Are there any requirements conflicts?
 Completeness: Are all functions required by the customer included?
 Realism: Can the requirements be implemented given available
budget and technology
 Verifiability: Can the requirements be checked?
 Requirements validation…
22

Requirements validation techniques (central activities):

 Requirements reviews
 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.
 If test is difficult or impossible to design for the requirement
means it is difficult to implement that requirement
 Requirements validation…
23

Requirements reviews
 Regular reviews should be held while the requirements definition is
being formulated.
 Both client and contractor staff should be involved in reviews.
 Reviews may be formal (with completed documents) or informal.
 Good communications between developers, customers and users
can resolve problems at an early stage.
 Requirements validation…
24

Review checks
 Verifiability: Is the requirement realistically testable?
 Comprehensibility: Is the requirement properly understood?
 Traceability: Is the origin of the requirement clearly stated?
 Adaptability: Can the requirement be changed without a large
impact on other requirements?
 Requirements management
25

 Requirements management is the process of managing, changing

requirements during the requirements engineering process and
system development.
 Requirements are inevitably incomplete and inconsistent
 New requirements emerge during the process as business needs
change and a better understanding of the system is developed;
 Different viewpoints have different requirements and these are
often contradictory.
 Requirements management…
26

Requirements change
 The priority of requirements from different viewpoints changes
during the development process.
 System customers may specify requirements from a business
perspective that conflict with end-user requirements.
 The business and technical environment of the system changes
during its development.
 Emergent properties
27

 Emergent properties are properties of the system as a whole rather than

properties that can be derived from the properties of components of a
system.
 Emergent properties are a consequence of the relationships between
system components.
Some examples of emergent properties:
 Volume/the total space occupied
 Reliability
 Security
 Reparability
 Usability
 Types of Software Requirements
28

Functional requirement
 A functional requirement defines a function of a software system or its
component.
 A function is described as a set of inputs, the behaviour, and outputs.
 Functional requirements may be calculations, technical details, data
manipulation & processing and other specific functionality that define
what a system is supposed to accomplish.
 Functional requirements should be complete and consistent
 Customers and developers usually focus all their attention on functional
requirements
 Types of Software Requirements…
29

Non-Functional requirement
 A requirement that specifies criteria that can be used to judge the operation of a
system, rather than specific behaviours.
 Non-functional requirements are often called qualities of a system
Types:
 Product requirements: Efficiency (performance & space) , Reliability,
Portability requirements
 Organizational requirements (organizational policies and procedures):
Delivery , Implementation , Standards requirements
 External requirements (factors which are external to the system):
Interoperability , legislative (Privacy & safety), Ethical requirements ..
 Software and System Requirements
30

 A software requirements specification (SRS) includes in-depth

descriptions of the software that will be developed.
 A system requirements specification (SyRS) collects information on the
requirements for a system.
 System requirements relate to the system as a whole. They may
relate to hardware, software, processes, documentation and so on.
 “Software” and “system” are sometimes used interchangeably as SRS.
 But, a software requirement specification provides greater detail than a
system requirements specification.
31

Thank You!!
?