Requirement

Engineering

by

Dr. Rizwan
 Software Requirement

 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 more difficult to rectify later.
 Requirements form the basis for all software products
 Requirements engineering is the process, which
enables us to systematically determine the
requirements for a software product.
 Software Requirement

 Something required, something wanted or needed –

Webster’s Definition
 There is a huge difference between wanted and
needed and it should be kept in mind all the time.
 “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 Definition

3
 4

To achieve done right and managed

right, software development must start
with a clear set of software
requirements, which are later planned,
designed, implemented, and tested.
 Software Requirement

 Software Requirement stimulates what must be

 Accomplished,
 Transformed,

 Produced or Provided

 Software Requirement is a capability that must be met or

possessed by a software in order to satisfy a contract, standard,
or specification
 The source of these Requirements could come from
 Client/Customer
 Buyers,
 Users/End user, or system specifications

5
 Requirement
Can be
functionality
constraint

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

system...tosatisfy a contract, standard, specification, or other formally
imposed document.
IEEE Std729
 Requirement

How? the
System
system
Property or
should
Attributes
behave

Constraint on
What?
the
should be
development
implemented
process
Requirement
 Need and Want

 Something required, something wanted or needed

 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

8
 Requirements Engineering
 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 more difficult to rectify later.

 One of the two most common causes of runaway projects is

unstable requirements

9
 Requirement Engineering Vs
Architecture and Design

 Requirements specify what a system must do.

 Requirements engineering is the process of eliciting
stakeholder needs and desires and developing them into an
agreed-upon set of detailed requirements that can serve as a
basis for all subsequent development activities.
 Architecture describes how a system will be organized and
how it will behave in order to fulfill these requirements.
 Requirements describe the problem and architecture
describes the high-level solution.
 Types of Requirements

 Functional requirements
 Non-Functional requirements
 Domain requirements
 Business Requirements
 UI Requirements
 Inverse Requirements
 Design and Implementation Constraints

11
 Functional and Non-Functional Requirements

 Functional requirements
 Statements of services the system should provide, how
the system should react to particular inputs and how the
system should behave in particular situations.
 May state what the system should not do.
 Functional system requirements should describe the
system services in detail.
 Customers and developers usually focus all their
attention on functional requirements

12
 Functional Requirements

 Abnormal behavior is also documented as functional

requirements in the form of exception handling
 In practice, it is impossible to produce a complete and
consistent requirements document
 Incomplete and ambiguous requirements are open to multiple
interpretations and assumptions
 This can lead to the development of poor quality, or faulty,
software products

13
 Non-functional Requirements
 Constraints on the services or functions offered by the
system such as timing constraints, constraints on the
development process, standards, etc.
 Often apply to the system as a whole rather than individual
features or services.
 These define system properties and constraints e.g.
reliability, response time and storage requirements.
Constraints are I/O device capability, system
representations, etc.
 Process requirements may also be specified mandating a
particular IDE, programming language or development
method.

14
 Non-Functional Requirements

 Non-functional requirements may be more critical than

functional requirements. If these are not met, the system
may be useless.
 Most non-functional requirements relate to the system as a
whole
 They include constraints on timing, performance,
reliability, security, maintainability, accuracy, the
development process, standards, etc.

15
 Non-Functional Requirements
 They are often more critical than individual functional
requirements
 Capture the emergent behavior of the system, that is they relate to
system as a whole
 Failure to meet a non-functional system requirement may make
the whole system unusable
 If an aircraft system does not meet reliability requirements, it will
not be certified as ‘safe’
 If a real-time control system fails to meet its performance
requirements, the control functions will not operate correctly
 Non-functional requirements may arise through user needs,
because of Budget constraints, organizational policies, need of
interoperability with other software and hardware systems,
external factors such as safety regulations, privacy legislation,
etc.
16
 Non-Functional Requirements

 Non-functional requirements are sometimes written as

general goals, which are difficult to verify
 They should be expressed quantitatively using metrics
(measures) that can be objectively tested
 Example of a Goal (unverifiable)
 The system should be easy to use by experienced
controllers and should be organized in such a way
that user errors are minimized
 Example of an NFR (verifiable)
 Experienced controllers shall be able to use all the
system functions after a total of two hours’ training.
After this training, the average number of errors made
by experienced users shall not exceed two per day
17
 Metrics for Non-Functional Requirements
 Speed
Processed transactions/second
 Response time
 Screen refresh time
 Robustness
 Time to restart after failure
 Percentage of events causing failure
 Probability of data corruption on failure
 Number of function points
 Ease of use
 Training time
 Number of help frames
 Number of target systems

18
Metrics for Non-Functional Requirements

 Reliability
 Mean time to failure
 Probability of unavailability
 Rate of failure occurrence
 Availability
 Portability
 Percentage of target-dependent statements
Software Requirement Types
 User Requirement vs.
System Requirement
 User requirements
 Statements in natural language plus diagrams of the services the
system provides and its operational constraints. Written for
customers.

 System requirements
 A structured document setting out detailed descriptions of the
system’s functions, services and operational constraints. Defines
what should be implemented so may be part of a contract
between client and contractor.
 Stakeholders

 Any person or organization who is affected by the system

in some way and so who has a legitimate interest

 Stakeholder types
 End users

 System managers

 System owners

 External stakeholders
 Software Engineering: Goal

 GOAL: to develop quality software—on time and on

budget—that meets customers' real needs
 A software is good if it MEETS STAKEHOLDERS
EXPECTATIONS: (?)
 However, stakeholders are different!
 Then?
 it should be(at least) correct, reliable, maintainable, user-
friendly …
 the total cost it incurs over all phases of its life cycle
should be minimal and within the budget
 Role of Requirements: A Contract
 The set of requirements constitute a contract
between the client and the software developer
 Software requirement documents are the medium
used to communicate user requirements to
technical people responsible for developing the
software.
 Requirement documents should emphasize user
behavior and activities.
 Serves as a basis for project planning (schedule,
budget)
 Requirements document is used both to drive the
design stage, and as a basis for test planning.
 Reality

 31.1% of computer software projects get canceled

before they are completed,
 52.7% will overrun their initial cost estimates by
189%.
 94% of project start-ups are restarts of previously
failed projects.
The Root Causes of Project Failure/Success

 The Three Largest Problems in Software Industry:

 Lack of user input: 13 percent of all “challenged”
projects
 Incomplete requirements and specifications: 12 percent
of all “challenged” projects
 Changing requirements specifications: 12 percent of all
“challenged” projects
 The Three Primary Success Factors:
 User involvement: 16 percent of all successful projects
 Executive management support: 14 percent of all
successful projects
 Clear statement of requirements: 12 percent of all
successful projects
 High Cost of Requirements Errors

If a unit cost of one is

assigned to the effort
required to detect and repair
an error during the coding
stage ….
 Why Engineer Requirement

 Insufficient user involvement

 Creeping user requirements
 Ambiguous requirements
 Gold plating
 Minimal specification
 Overlooked user classes
Why Engineer Requirement

29
Why Engineer Requirement
30
 Why Engineer Requirement
 The requirements are how we communicate
 They are the only part that everyone understand

CUSTOMER

USER DEVELOPER

Requirements
Why Engineer Requirement
 Why Engineer Requirement
Causes of the failed projects

Incomplete requirements

Lack of user involvement

Lack of resources

Unrealistic expectations

Lack of executive support

Changing requirements

Lack of planning

System no more needed

10% 20%
 Inconsistent and incomplete requirements are the most frequent causes of the system
problems
 Why Engineer Requirement
 Wicked problems
 Most large software systems address wicked problems
 Problems which are so complex that they can never be
fully understood and where understanding evolves during
the system development
 Therefore, requirements are normally both incomplete and
inconsistent
 Why Engineer Requirement

 Requirement engineering is the basic building block of any

project
 If requirements are not engineered software can have:
 Errors due to incomplete requirements
 Errors due to lack of involvement of users
 Cost of rectifying errors
Why Engineer Requirement

36
 Why Engineer Requirement

 Stakeholders don’t know what they really want

 Requirements expressed in domain specific terms
 Different stakeholders may have conflicting
requirements
 Organizational and political factors may influence the
system requirements
 The requirements change during the analysis process
 New stakeholders may emerge
 The business environment may change
37
 Why Engineer Requirement

 To identify the right product, you have to understand the needs

of your clients and users, not just the wants.
 What is a problem they need to solve?
 What are the tasks they need to do?
 Who will use this software and how will the user interact with
it?
 When you can answer these questions, you will help your
development team build the right product.

38
Without Requirement Engineering
After Requirement Engineering
 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.
 Feasibility Study
 A feasibility study decides whether or not the proposed system is
worthwhile based on information collection, information
assessment and report writing
 The study checks if the system
 contributes to organizational objectives
 can be engineered using current technology and within budget
 can be integrated with other systems that are used
 Questions for people in the organization
 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? 43
Feasibility Study: Analysis Techniques

 IF-Then Analysis: If-Then Analysis is a decision-making

technique that involves evaluating different scenarios and their
potential outcomes based on certain conditions.
 Root Cause Analysis (RCA): It is a method used to
identify the core problem behind an issue or failure. The goal is
to address the actual cause of a problem rather than its
symptoms.
 Cost-Benefit Analysis (CBA): This technique is used to
determine the potential benefits of a project or decision
compared to its costs. The results can be used to decide
whether to undertake an initiative.
 Feasibility Study: Analysis Techniques

 SWOT Analysis: This is a strategic planning tool used to

evaluate the Strengths, Weaknesses, Opportunities, and Threats
involved in a project or business venture.
 PESTEL Analysis: It is a framework used to analyze the
macro-environmental factors affecting an organization or
business. The factors are Political, Economic, Social,
Technological, Environmental, and Legal.
 Value Chain Analysis: This technique analyzes the activities
that go into delivering a product or service. The goal is to
understand where value is added in the process and how to
maximize it.
Feasibility Study: Analysis Techniques

 Gap Analysis: This is used to identify the difference

between the current state and the desired future state of a
process or system. It helps organizations decide on the
necessary steps to bridge that gap.
 Risk Analysis: A process used to understand the
uncertainties in achieving program objectives. It identifies
potential risks and assesses the potential impact of those risks.
Requirements Engineering Process
 Requirement Engineering

 The description of the services and constraints are

the requirements for the system and
 The process of
 Finding out,
 Analyzing,
 Documenting and
 Checking these services and Constraints are called
Requirements Engineering.”

Ian Sommerville
 Requirement Engineering (Cont.)

 The process of establishing the services that a customer

requires from a system and the constraints under which it
operates and is developed.

 The system requirements are the descriptions of the

system services and constraints that are generated during
the requirements engineering process.

49
Requirement Engineering Process

 RE involves:
 Identification of user requirements,
 Analysis of the requirements to drive additional requirements,
 Documentation of the requirements as a specification
 Validation of the documented requirements against user
needs, as well as processes that support these activities.
Requirement Engineering Process
Requirement Engineering Process

 Software Requirement Elicitation

 In reality these processes cannot be performed
sequentially.
 Instead all phases are intertwined and performed
repeatedly.
Software Requirement Elicitation

 The process through which the customers, buyers

or the users of software system discover, reveal,
articulate and understanding their requirements
 Software Requirements Elicitation is any activity
that has as its objectives to:
 Identifying
 Gathering
 Determining
 Formulating
 Extracting
 Exposing
 Difficulties in Requirement Elicitation

 The process of elicitation of requirements is a difficult process.

 No single person has the complete picture.
 Work effectively as a coherent group.
 The following are some common difficulties associated with this
process:
 Articulation Problems
 Expression/ Communication
 Articulation problems can occur because the users are usually
experts in their application domain but not in the process of
engineering software.
 Additionally, the engineers are experts in development and not
in the users application domain.
 This problem is magnified by the users and developers having
different vocabulary, terms, and concepts
 Difficulties in Requirement Elicitation

 Articulation of the users needs

 The users may not be aware of their needs
 Users who are unwilling to prioritize and make tradeoffs
 The users may be aware of needs but be afraid to articulating it
 Users and developers misunderstand concepts or relationships
 User cannot make up their minds
 No single person has complete picture
 Developers may not really be listening to the users
Difficulties in Requirement Elicitation

 Articulation of the users needs

 Developer may fail to understand, appreciate, or relate to the
users
 Developers who are not skilled in listening
 Developers who are dominating in their approach to
elicitation
 Developers who are solution not problem orientated
 Difficulties in Requirement Elicitation

 Communication Barriers
 Communication is not a single direction information flow
 Users and developers come from different worlds and have
different professional vocabularies
 The users have different concerns from those of developers
 Medium of communication-Natural language are inherently
ambiguous
 People involved are different-some are submissive, some
are assertive
 There are different value system among people
 Difficulties in Requirement Elicitation

 Problem Complexity
 The complexity of modern software system makes the
process of requirements elicitation extremely difficult.
 These systems have interconnections between subsystems
and environments that even expert in specialized disciplines
have difficulty understanding.
 Nature of Requirements
 Requirements change and migrate
 Users learn and grow
 Requirements are diverse and conflicting
 Multiple views can be difficult to integrate
 Requirements can be difficult to evaluate.
Difficulties in Requirement Elicitation

 Knowledge and Cognitive Limitations

 Tunnel vision
 User and Developers don’t have adequate domain
knowledge
 No person has perfect memory
 Interpretation of statistics
 Problem simplification and ignoring part of the problem
because of complexity
 Some people are uncomfortable or impatient with
exploration
Difficulties in Requirement Elicitation
 Human Behavioral Issues
 Elicitation is a social process
 Everyone (users) assumes that it is not his/her responsibility to
tell the developers
 Developer may assume that user will give the information
 User may assume that developer will ask appropriate questions
 Expectation and /or fears from proposed system
 Technical Issues
 Obsolete requirement by the time the elicitation process is
completed
 Software and hardware technologies (corporate management,
government regulations, sales and marketing department)
 Unprecedented system
Requirement Elicitation Techniques

 Joint Application Development (JAD)

 Quality Function Deployment (QFD)
 Adaptive Loops Framework
 Prototyping
 Contextual Inquiry
 Critical Success Factors Analysis
 Brainstorming
 Interviewing
 PIECES framework
 Performance information and data, Economy
Control, Efficiency, and services
Requirement Engineering Process
 Software Requirement Analysis
 The process of reasoning about the requirements that
have been elicited .
 Involves examining requirements for conflicts or
inconsistencies, combining related requirements, and
identifying missing requirements
 Software Requirements Analysis is any activity that has
as its objective to
 Organize,

 Interpret,

 Understand,

 Classify, or assess feasibility,

 Completeness, or consistency of software requirements.

 Analysis

Analysis Phase
Involves great detail
what the information system needs to accomplish
In order to provide the organization
with the desired benefits.
 Analysis
 Analysis means looking into the problem,
investigating.
 Its purpose is to understand the business
requirements “WHAT” through problem domain
understanding so as to suggest solution in
accordance to user requirements.
 This is only possible when analysis is brought under
consideration.
 Be sure you really understand problem!
 Refine, simplify, clarify, think. Repeat.
 Decompose it into sub-problems
 First ideas are NEVER the best ones.
 Analysis

Analysis Phase involves:

 gather information,
 define system requirements,
 prioritize requirements,
 prototype for feasibility and discovery,
 generate and evaluate alternatives, and
 review recommendations with management.
Output of Requirements Analysis

 Software Requirements Specification (SRS) is the

direct result of a requirement analysis
 A SRS is a document that enlists all necessary
requirements for project development.
 To derive the requirements we need to have clear
and thorough understanding of the domain and the
product to be developed.

66
 Why Analyze Software

 Stakeholders don’t know what they really want

 Requirements expressed in domain specific terms
 Different stakeholders may have conflicting
requirements
 Organizational and political factors may influence the
system requirements
 The requirements change during the analysis
process
 New stakeholders may emerge
 The business environment may change

67
 Why Analyze Software

 Complexity
 Due to larger size of software

 Problem domains (areas) tend to have poorly defined

BOUNDARIES.
 Problem domain solutions usually require
INTERDISCIPLINARY knowledge and skills.
 Why Analyze Software

 The STARS radar display terminals for the US air

traffic control system.
 Old system has knobs to adjust the display, and
ABC keyboard.
 New system has color display, pull down menus, and
a QWERTY keyboard. Controllers found it very
difficult (and dangerous) to use the new terminals.
 Ear rings,Ring or POLO
 Requirement Engineering Process

 Software Requirement Specification

 The process of recording the requirements in one or
more forms, including natural language and formal,
symbolic, or graphical representations
 Software Requirements Specification is any activity
that has as its objective to capture a description of the
software requirements
 Usually the final form of this description is a software
requirements specification (SRS).
Requirement Engineering Process

 Software Requirement Specification Document

 SRS (Software Requirement specification)
 The official statement of what is required by the system
developers
 The goal of the SRS is to describe all externally observed
behaviors and characteristics expected of the software
system
 Includes user requirements and system requirements
 Standards for SRS
 RUP

 IEEE

 Ian Summerville
Requirement Engineering Process

 Characteristics of SRS
 Correct
 All requirements stated in the SRS are one that the

software shall meet.

 Unambiguous
 Every requirement stated in the SRS only has one

logical interpretation.
 Characteristics of SRS

With requirement engineering

Without requirement engineering

The system must The user-interface shall

be user friendly. be menu driven .It shall
provide dialogue boxes,
How should we help screens, radio
measure user- buttons, dropdown
menus.
friendliness?

Unambiguous Requirements
Requirement Engineering Process

 Complete
 The SRS includes all significant requirements
 The SRS includes all realizable classes of input
data
 The SRS includes full labels and references to
all figures, tables and diagrams.
 With requirement engineering
All screens must When the user
accesses any screen,
Without requirement engineering

appear on the
it must appear on the
monitor quickly. monitor within 2
How long is seconds.
quickly?

Incomplete Requirements
 With requirement engineering
On power loss,
Without requirement engineering

battery backup
must support On power loss ,
normal operations. battery backup must
support normal
For how long? operations for 20
minutes.

Incomplete Requirements
Requirement Engineering Process: An
Example of Incompleteness
 Incomplete Requirements

D grade at 47
No grading criteria is defined e.g. Relative marking,
Absolute marking etc.
Requirement Engineering Process

 Characteristics of SRS
 Verifiable
 For every requirement stated in the SRS, there exists
some finite cost-effective process with which a person or
machine can check that the software meets the
requirements.
 Modifiable
 The entire SRS has a style and structure such that any
changes to the requirements can be made
 Easily,
 Completely, and
 Consistently and retaining the structure and style.
Requirement Engineering Process

 Consistent
 No subset of individual requirements stated in the
SRS conflict with other individual requirements.
Requirement Engineering

 The user presses the Assign Course’ button.

Characteristics of SRS

 Traceable
 For every requirement stated in the SRS, it is
clear of the requirements origin and it is possible
to reference each requirement in future
developments.
Traceability in Requirement Engineering
 Requirement Engineering

 Software Requirement Validation

 The process of confirming with the customer or user of the
software that the specified requirements are
 valid,
 correct, and
 complete
 Software Requirements Validation is any activity that has
as its objective to obtain buyer approval of the
specification of the software requirements.
Requirement Engineering
Requirement Engineering
Validation with
the Customer

Verification of
the SRS
Document
Requirement Engineering Process

 Advantages of SRS
 The SRS can establish the basis for contractual
agreement between the customer and developers.
 The SRS can establish the basis for performing cost,
schedule, and resource estimates for the
developmental effort.
 The SRS can provide a baseline for verification and
validation of the software.
 Requirements Reviews

 A group of people read and analyze the

requirements, look for problems, meet and discuss
the problems and agree on actions to address these
problems.

88
 Requirements Review Process

Plan review Distribute

documents

Prepare for Hold review

review meeting

Follow‐up Revise
actions documents

89
 Review Activities

 Plan review
 The review team is selected and a time and place
for the review meeting is chosen.
 Distribute documents
 The requirements document is distributed to the
review team members.
 Prepare for review
 Individual reviewers read the requirements to find
conflicts, omissions, inconsistencies, deviations
from standards and other problems.
90
 Review Activities Cont.
 Hold review meeting
 Individual comments and problems are
discussed and a set of actions to address the
problems is agreed.
 Follow-up actions
 The chair of the review checks that the agreed
actions have been carried out.
 Revise document
 The requirements document is revised to
reflect the agreed actions. At this stage, it may
be accepted or it may be re-reviewed.
91
 Types of SRS
 Production of System Specification
 Written document
 Graphical model
 Formal mathematical model
 Usage scenarios
 Prototype
 Any combination of above
Outcomes of Requirement Engineering

Tangible
Intangible
 Outcome of a Good Requirement
Engineering Process

 Users Perspective
 The users will have a better understanding of their needs and
constraints.
 The users will be in a position to evaluate alternatives and
understand the implications of their decisions.
 This level of understanding is extremely important since it is
usually the users who drives the requirements, which in turn
drives the design and implementation of the entire software
system.
 Thus, the quality of the requirements document is related to
the users understanding of the issues and tradeoffs involved.
Outcome of a Good Requirement
Engineering Process

 Users Perspective
 The users and the developers form a common vision of
the problem and the conceptualized software solution.
 To strive for this common understanding of all
individuals involved in the software engineering
process
 A sense of ownership
 Feel informed and educated
 Committed to the success of the project
Outcome of a Good Requirement
Engineering Process
 Developers Perspective
 This is the fundamental process that will be used
to construct a clear high level specification of the
problem that is to be solved.
 Other outcomes of a good elicitation process are
developers who:
 Are developing a solution to the right problem
 Are solving a problem that is feasible from all
perspectives
 Have a high level specification of the solution
 Have cooperative users
Outcome of a Good Requirement
Engineering Process

 Developers Perspective
 Have all the necessary information, explanations, and
justifications
 Can make proper design justifications
 Need minimal ongoing interactions with the users
 They have trust and confidence of the customer
 Knowledge of the domain of the system
 Agile Methods and Requirements

 Many agile methods argue that producing detailed system

requirements is a waste of time as requirements change so quickly.

 The requirements document is therefore always out of date.

 Agile methods usually use incremental requirements engineering and

may express requirements as “user stories”.

 This is practical for business systems but problematic for systems

that require pre-delivery analysis (e.g., critical systems) or systems

developed by several teams.
98
99
https://boosthigh.com/software-requirements-specification/

100
Mastering the Requirements Process – Third Edition,
Page # 24

101
102
103
104
105
106
107
108
109