SOFTWARE

REQUIREMENTS
ENGINEERING
ASIM ALI
DEPARTMENT OF COMPUTER
SCIENCE
 Outlin
•e1 Requirement Engineering
• 1.1 Introduction
• 1.2 Requirements Engineering
Process
• 1.3 Understanding Requirements
 ROLE OF REQUIREMENT
ENGINEERING
• Helps software engineer to better understand the
problem.
• Participants involved:
• Software Engineers
• Managers
• Customers
• Users
• 1 Requirement Engineering
• 1.1 Introduction
• 1.2 Requirements Engineering
Process
• 1.3 Understanding Requirements
• 1.4 Ground Work Establishment
• 1.4.1 Multiple Viewpoints
Recognition
• 1.4.2 Collaboration
• 1.4.3 Building Use Cases
 1.1
INTRODUCTION
• Engineering discipline of establishing
user requirements and specifying software
systems
• Comprehensively RE is:
• Requirements Engineering is the process of establishing
the services that the customer requires from the system
and the constraints under which it is to be developed and
operated.
• 1 Requirement Engineering
• 1.1 Introduction
• 1.2 Requirements Engineering
Process
• 1.3 Understanding Requirements
• 1.4 Ground Work Establishment
• 1.4.1 Multiple Viewpoints Recognition
• 1.4.2 Collaboration
• 1.4.3 Building Use Cases
 1.2 REQUIREMENT
ENGINEERING PROCESS

• Feasibility Study
• Find out the current user needs.
• Budget
• Requirement Analysis
• What the stakeholders require from the system.
• Requirements Definition
• Define the requirements in a form understandable to the
customer.

• Requirements Specification
• Define the requirements in detail.
 1.2 REQUIREMENT
ENGINEERING PROCESS
• Requirements Document:
• Official Statement
• Include both a definition and specification
• Specify external system behavior
• Specify implementation constraints.
• Easy to change

• Problems of Requirements Analysis

• Stakeholders don’t know what they really want
• Stakeholders express requirements in their
own terms
• Requirement change during the analysis process.
REQUIREMENT ENGINEERING
PROCESS
• 1 Requirement Engineering
• 1.1 Introduction
• 1.2 Requirements Engineering
• 1.3 Understanding
Requirements
• 1.4 Ground Work Establishment
• 1.4.1 Multiple Viewpoints
Recognition
• 1.4.2 Collaboration
• 1.4.3 Building Use Cases
1.3 UNDERSTANDING
REQUIREMENTS
• Collecting needs from the
customer.
• Managing the Process.
• Tasks involved:
 Requirement Elicitation
 Requirement analysis
 Requirement Specification
 Requirement Validation
 Requirements Management
 Requirements Traceability
 Requirement Elicitation:
(Extraction)
• The process of discovering the requirements for a system by
communication with customers, system users and others who have a stake
in the system development.
• How to elicit:
• Identify relevant requirements sources.
• Ask them appropriate questions to understand their needs.
• Look for implications, inconsistencies, and unresolved issues in gathered information.
• Confirm your understanding of requirements with the users.
 Requirement Elicitation:
(Extraction)
Eliciting requirements is difficult because of
• Problems of scope  identify the boundaries of the system.
• Problems of understanding  domain , computing
environment.
• Problems of Volatility  requirements may change over time.
Elicitation Techniques:
• Questionnaire
• Interviewing
• Requirements Workshops
• Brain storming
• Use cases
• Role Playing
• Prototyping
• Story boards
 REQUIREMENT
ANALYSIS
• The process of breaking down user requirements into their components
and
studying these to develop a set of system requirements.
• The three major goals of this process are:
• Achieve agreement among developers and customers.
• Provide a basis for design.
• Provide a basis for Verification and Validation (V&V)
 PROCESS
MODELS

• Work Flow
Diagramming
• Use Case
Diagramming
• Activity Diagrams
• Decision Trees
• Etc
 REQUIREMENT
SPECIFICATION

• “Complete description of the behavior of the system to be

developed.
• Requirements document is a reference document.
• Contract between stakeholders
• Must be maintained over the life of the project
REQUIREMENT
SPECIFICATION
“Complete description of the behavior of the system to be
developed by the requirements engineer Software
Requirement Specification Document
 SRS Document.
 Known as ‘Black-box specification’
 Concentrates on
 ‘What’ needs to be done
 Carefully avoids the ‘how to do’ aspects
 Serves as a contract
 Formalizes the functional and behavioral requirements of the
proposed software in both the graphical and textual format.
 Requirement
Validation
• Ensuring that the set of requirements is correct,
complete & consistent.
• Ensuring that a model can be created that satisfies
the
requirements.
• Ensuring that a real-world solution can be built and
tested to prove that it satisfies the requirements.
REQUIREMENT V & V:
OBJECTIVES
• Certify that the requirements document is an acceptable description of
the
system to be implemented
• Check requirements document for:
• Correctness, completeness and consistency
• according to standards
• Requirement conflicts
• Technical errors
• Ambiguous requirements
 REQUIREMENTS: ANALYSIS &
VALIDATION

• Analysis works with raw requirements as elicited from the system

stakeholders.
• “Have we got the right requirements?” is the key question to be answered at this stage.
• Validation works with final draft of the requirements document i.e.
with negotiated and agreed requirements.
• “Have we got the requirements right?” is the key question to be answered at this
stage.
REQUIREMENT V & V: INPUTS AND
OUTPUTS
Requirements
Management
REQUIREMENT MANAGEMENT KEY
ACTIVITIES
• Understand relationships among key stakeholders and involve
them
• Identify change in requirements
• Managing & controlling requirements changes
• Identify and track requirements attributes
• Trace requirements
REQUIREMENT
TRACEABILITY
• ‘The ability to describe and follow the life of a requirement, in both forwards and
backwards direction (i.e. from its origins, through its development and specification,
to its subsequent deployment and use, and through all periods of on-going
refinement and iteration in any of these phases’
• To ensure the object of the requirements conforms to the requirements by associating
each requirement with the object via the traceability matrix.
• Concerned with documenting the life of a requirement.
• To find the origin of each requirement and track every change which was made to
this requirement
WHAT IS SOFTWARE
REQUIREMENT?
• Requirements are descriptions of the services that a software system
must provide and the constraints/limitation under which it must operate.
• Types of Requirement
• User requirements
• Statements in natural language plus diagrams of the services that the systems provides and
its operational constraints.
• System requirements
• A structured document setting out detailed descriptions of the system services.
• Software specification
• A detailed software description which can serve as a basis for a design or implementation
CLASSIFICATION OF
REQUIREMENTS
• Main types of software requirement can be of 3
types:
• Functional requirements
• Non-functional requirements
• Domain Requirements
FUNCTIONAL AND NON-FUNCTIONAL
REQ.
• Functional requirements
• Statements of services that the system should provide, how the system should react to
particular inputs and how the system should behave in particular situations

• Non-functional requirements
• Non-functional requirements in software engineering refer to the characteristics of a
software system that are not related to specific functionality or behavior. They describe
how the system should perform, rather than what it should do. Examples of non-
functional requirements include: Performance, Security etc.
• Domain requirements
• Domain Req. are expectations related to a particular type of software or Purpose.
Domain requirements can be functional or nonfunctional. The common factor for domain
requirements is that they meet established standards or widely accepted feature sets
for that category of software project.
FUNCTIONAL
REQ.
• Describe functionality or system services
• Depend on the type of software, expected users and the type of system
where the software is used
• Functional user requirements may be high-level statements of what the system
should do; functional system requirements should describe the system services
in detail
• Example
• The system shall provide appropriate viewers for the user to read documents in
the document store
• When creating functional requirements, it is important to keep in mind that
they should be specific, measurable, achievable, relevant, and time-bound
(SMART). In other words, your functional requirements should:
• Be specific about what the system should do
• Be measurable so that you can tell if the system is doing it
• Be achievable within the timeframe you have set
• Be relevant to your business goals
• Be time-bound so that you can track progress

• By following these guidelines, you can be sure that your functional

requirements are clear and will help your development team build the
right product.
NON-FUNCTIONAL
REQ.
Performance: This includes requirements related to the speed, responsiveness
of the system. For example, a requirement that the system should be able to
handle a certain number of concurrent users or process of certain amount of
data within a specific time frame.
Security: This includes requirements related to the protection of the system and
its data from unauthorized access, as well as the ability to detect and recover
from security breaches.
Usability: This includes requirements related to the ease of use and
understandability of the system for the end-users.
Reliability: This includes requirements related to the system’s ability to
function
correctly and consistently under normal and abnormal conditions.
Maintainability: This includes requirements related to the ease of maintaining
the system, including testing, and modifying the system.
Portability: This includes requirements related to the ability of the system to
be
easily transferred to different hardware or software environments.
LEVELS/LAYERS OF
REQUIREMENTS
• There are many different types of requirements ranging from high level
business requirements down to detailed technical requirements that specify
a complex part of a computer algorithm or hardware device.
User requirements: These requirements describe what the end-user wants
from the software system. User requirements are usually expressed in natural
language and are typically gathered through interviews, surveys, or user
feedback.
System requirements: These requirements specify the technical characteristics
of the software system, such as its architecture, hardware requirements,
software components, and interfaces. System requirements are typically
expressed in technical terms and are often used as a basis for system design.
Business requirements: These requirements describe the business goals and
objectives that the software system is expected to achieve. Business
requirements are usually expressed in terms of revenue, market share,
customer satisfaction, or other business metrics.
Regulatory requirements: These requirements specify the legal or
regulatory standards that the software system must meet. Regulatory
requirements may include data privacy, security, accessibility, or other legal
compliance requirements.
Interface requirements: These requirements specify the interactions between
the software system and external systems or components, such as databases,
web services, or other software applications.
• Design requirements: These requirements describe the technical
design of the software system. They include information about
the software architecture, data structures, algorithms, and other
technical aspects of the software.
CHARACTERISTICS OF EFFECTIVE
REQUIREMENTS
• A requirement needs to meet • Unambiguous
• Testable (verifiable)
several criteria to be considered a • Clear (concise, terse, simple,
“good requirement” precise)
• Correct
• Good requirements should have • Understandable
the following characteristics: • Feasible (realistic, possible)
• Independent
• Atomic
• Necessary
• Implementation-free (abstract)
UNAMBIGUOU
S
• There should be only one way to interpret the requirement. Sometimes
ambiguity is introduced by undefined acronyms:
• REQ1 The system shall not accept passwords longer than 15 characters.
• It is not clear what the system is supposed to do:
• The system shall not let the user enter more than 15 characters.
• The system shall truncate the entered string to 15 characters.
• The system shall display an error message if the user enters more than 15 characters.

• The corrected requirement reflects the clarification:

• REQ1 The system shall not accept passwords longer than 15 characters. If the user enters more
than 15 characters while choosing the password, an error message shall ask the user to
correct it.
TESTABLE
(VERIFIABLE)
• Testers should be able to verify whether the requirement is implemented
correctly. The test should either pass or fail. To be testable,
requirements should be clear, precise, and unambiguous. Some words
can make a requirement untestable.
• Some adjectives: robust, safe, accurate, effective, efficient, expandable,
flexible, maintainable, reliable, user-friendly, adequate
• Some adverbs and adverbial phrases: quickly, safely, in a timely manner
• Nonspecific words: etc., and/or, TBD
CLEAR (CONCISE, TERSE, SIMPLE,
PRECISE)
• Requirements should not contain unnecessary information. They should
stated clearly and
be

simply:
REQ1 Sometimes the user will enter Airport Code, which the system
understand, but sometimes the closest city may replace it, so the user does
will
need to know what the airport code is, and it will still be understood by
not
system.
the
• This sentence may be replaced by a simpler

one:
REQ1 The system shall identify the airport based on either an Airport
or a City
Code
Name.
CORREC
T
• If a requirement contains facts, these facts should be

true:
REQ1 Car rental prices shall show all applicable taxes (including 6%
tax).
state
• The tax depends on the state, so the provided 6% figure is
incorrect.