SOFTWARE REQUIREMENTS

ENGINEERING
ASIM ALI
DEPARTMENT OF COMPUTER SCIENCE
Outline
• 1 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 several • Unambiguous

• Testable (verifiable)
criteria to be considered a “good
• Clear (concise, terse, simple, precise)
requirement” • Correct

• Good requirements should have the • Understandable

• Feasible (realistic, possible)
following characteristics: • Independent
• Atomic
• Necessary
• Implementation-free (abstract)
UNAMBIGUOUS

• 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 be

stated clearly and simply:
 REQ1 Sometimes the user will enter Airport Code, which the system will
understand, but sometimes the closest city may replace it, so the user does not
need to know what the airport code is, and it will still be understood by the
system.
• This sentence may be replaced by a simpler one:
 REQ1 The system shall identify the airport based on either an Airport Code
or a City Name.
CORRECT

• If a requirement contains facts, these facts should be true:

 REQ1 Car rental prices shall show all applicable taxes (including 6%
state tax).
• The tax depends on the state, so the provided 6% figure is incorrect.