Software Requirement

Engineering
Requirements Essential, Requirements
development process framework

Lecture 3&4
Requirements
Requirements:
• Requirements are a specification of what should be implemented in a system.
• They describe how the system should behave or define a system property or
attribute.
• Requirements can also serve as constraints on the development process.
Types of Requirements:
• Requirements encompass different types of information, collectively referred to as
"the requirements."
• They address both the user’s perspective (external system behavior) and the
developer’s perspective (internal characteristics).
Behavioral and Property-Based Requirements:
• Requirements define how a system should behave under specific conditions.
• They also include non-functional aspects, such as usability, efficiency, and
enjoyment of use.
What is requirement?
Requirements are a specification of what should be
implemented. They are descriptions of how the system
should behave, or of a system property or attribute. They
may be a constraint on the development process of the
system.
◦ This definition acknowledges the diverse types of information that
collectively are referred to as “the requirements.”
◦ Requirements encompass both the user’s view of the external
system behavior and the developer’s view of some internal
characteristics.
◦ They include both the behavior of the system under specific
conditions and those properties that make the system suitable—and
maybe even enjoyable—for use by its intended operators.
Types of requirements
Business Requirement:
• Describes the high-level objectives of an organization or a customer.
• It focuses on the business goals rather than technical aspects.
• Example: "The system must allow users to purchase products online."
Business Rule:
• A policy, guideline, or regulation that governs how the business operates.
• It is not a software requirement itself but influences other requirements.
• Example: "A customer cannot place an order without providing a valid billing address."
Constraint:
• Imposes restrictions on the developer’s choices in designing and constructing the
software.
• Constraints can be technical, legal, or business-related.
• Example: "The software must comply with GDPR regulations."
Types of requirements
External Interface Requirement:
• Defines how the software interacts with users, other software systems, or hardware
devices.
• Ensures smooth communication between different components.
• Example: "The system must support integration with third-party payment gateways.“

Feature:
• A set of capabilities that provide value to the user.
• Features are usually defined by functional requirements.
• Example: "The application should provide real-time notifications for order status
updates."

Why is this Important?

• Understanding these types helps in structuring software development efforts.
• It ensures that all business, technical, and user needs are properly captured.
• It facilitates better communication between stakeholders (developers, business analysts,
and clients).
Functional Requirement:
• Describes what the system should do under specific conditions.
• Focuses on system behavior and expected outputs.
• Example: "The system must allow users to log in with a valid username and
password."
Nonfunctional Requirement:
• Defines system properties, characteristics, or constraints.
• Focuses on aspects like performance, security, usability, etc.
• Example: "The system must respond to user input within 2 seconds."
Quality Attribute:
• A type of nonfunctional requirement related to service quality and system
performance.
• Focuses on scalability, maintainability, reliability, and efficiency.
• Example: "The application should handle up to 10,000 concurrent users without
performance degradation."
System Requirement:
• A high-level requirement that describes the overall system, including
software and hardware components.
• Includes requirements for multiple subsystems.
• Example: "The banking system must support integration with ATMs and
mobile banking applications."

User Requirement:
• Represents user goals, tasks, or desired product attributes.
• Focuses on what users expect from the system.
• Example: "A customer should be able to track their order status in real-time
from the mobile application."
Types of requirements
Why Are These Categories Important?
• Helps developers and stakeholders differentiate between system
functionality and constraints.

• Ensures that both business objectives and user expectations are met.

• Improves software design, testing, and validation by clearly defining

functional and nonfunctional aspects.
Business Requirements
Purpose of Business Requirements:
• Business requirements describe why a system is being developed.
• They focus on the business benefits the organization hopes to achieve.
• They are high-level requirements that guide system development.
Focus on Business Objectives:
• The primary concern is the organization’s goals or the customer’s needs that drive
the system’s creation.
• These objectives determine the direction of the project.
Example:
• An airline wants to reduce airport counter staff costs by 25%.
• To achieve this, they may decide to build a self-service kiosk where passengers can
check in for their flights.
• This business need drives the development of new software and hardware
solutions.
 Business Requirements
Sources of Business Requirements:
• They usually come from key stakeholders, including:
• Funding sponsors
• Acquiring customers
• Managers of end-users
• Marketing departments
• Product visionaries (people who define the system’s long-term direction)
Documentation of Business Requirements:
• They are recorded in a Vision and Scope Document to ensure clarity and
alignment across stakeholders.
Assumption About Market Need:
• It is assumed that a business need or market opportunity has already been
identified before defining business requirements.
User Requirements
User requirements describe goals or tasks the users must be able to
perform with the product that will provide value to someone.
Ways to represent user requirements include use cases (Kulak and
Guiney 2004), user stories (Cohn 2004), and event-response tables.
Ideally, actual user representatives will provide this information.
User requirements describe what the user will be able to do with
the system.
Example
An example of a use case is “Check in for a flight” using an airline’s
website or a kiosk at the airport.
Written as a user story, the same user requirement might read: “As a
passenger, I want to check in for a flight so I can board my airplane.” It’s
important to remember that most projects have multiple user classes, as
well as other stakeholders whose needs also must be elicited.
User Requirements
User Requirements:
• Describe the actions, tasks, or goals that users must perform using the
product.
• The main focus is on providing value to the user.
• User requirements define what the user will be able to do with the system.

Ways to Represent User Requirements:

• Use Cases (Kulak & Guiney, 2004): Describe step-by-step interactions
between users and the system.
• User Stories (Cohn, 2004): A simple, short format that describes user needs.
• Event-Response Tables: Outline system behavior based on specific user
actions.

Ideally, actual user representatives should provide input for defining

user requirements.
User Requirements
Example to Illustrate User Requirements:
• Use Case Example: "Check in for a flight" via an airline’s website or airport kiosk.
• User Story Format:
• "As a passenger, I want to check in for a flight so I can board my airplane."
• This approach highlights how requirements can be framed from the user's
perspective.
Consideration for Different User Classes:
• Multiple user roles (e.g., passengers, airline staff, administrators) may have
different requirements.
• Other stakeholders' needs must also be considered.
Why Are User Requirements Important?
• They ensure the system meets user needs and delivers real value.
• They serve as a bridge between business requirements and functional
specifications.
• They help in designing user-friendly systems that align with user expectations.
 Functional Requirements
Functional Requirements:
• They specify how the system should behave under certain conditions.
• These requirements outline what the developers must implement so that
users can complete their tasks (user requirements).
• Functional requirements ensure that business requirements are met
through system functionality.

Alignment with Other Requirement Levels:

• Functional requirements form a bridge between:
• Business requirements (organizational goals).
• User requirements (user needs).
• System design and implementation (developer’s perspective).

Ensuring alignment among these levels is critical for project success.

 Functional Requirements
Examples of Functional Requirements:
• Functional requirements are often written using “shall” statements,
which indicate system obligations.
• Example 1: “The Passenger shall be able to print boarding passes for all
flight segments for which he has checked in.”
• Example 2: “If the Passenger’s profile does not indicate a seating preference,
the reservation system shall assign a seat.”
• These statements clearly describe specific system behaviors and expected
outcomes.

Why Are Functional Requirements Important?

• They define system behavior in a precise, measurable way.
• They guide developers and testers in implementing and verifying features.
• They ensure the system meets user and business needs.
 System Requirements
System Requirements:
• System requirements define what is needed for a complete system, including
software, hardware, and human processes.
• They are based on ISO/IEC/IEEE 2011 standards for system engineering.
Scope of a System:
• A system can be:
• Pure software (e.g., an online banking system).
• A combination of software and hardware (e.g., an ATM or a self-checkout
system).
• It includes people and processes, meaning some system functions might be
performed by human users.
Some people use "system requirements" to mean detailed software
specifications, but in this context, it refers to the entire system (both software
and hardware components).
 System Requirements
Example: Supermarket Cashier’s Workstation
A cashier’s workstation is a good example of a system composed of multiple
subsystems:
• Hardware Components:
• Bar code scanner (integrated with a scale).
• Handheld barcode scanner for additional scanning.
• Keyboard and display for manual input and interaction.
• Cash drawer for handling money.
• Card reader and PIN pad for credit/debit/loyalty card transactions.
• Change dispenser for automated cash transactions.
• Printers for receipts, coupons, or credit card slips.
Software Components:
• Controls all hardware devices.
• Manages interactions between components.
• Ensures seamless operation of transactions.
System Requirements
System Requirements in Action:
• Each hardware device interacts under software control.
• The business analyst must derive specific requirements for each subsystem.
• The interfaces between these components must be well-defined.

Why Are System Requirements Important?

• They help break down complex systems into manageable components.
• They ensure smooth integration between software, hardware, and human
processes.
• They provide a clear structure for engineers, designers, and business
analysts to develop the system efficiently.
 Business Rules
• Business rules include:
• Corporate policies (e.g., internal company guidelines).
• Government regulations (e.g., tax laws, compliance laws).
• Industry standards (e.g., ISO, GDPR, HIPAA).
• Computational algorithms that dictate business logic.

Examples of Business Rules:

• “A new client must pay 30 percent of the estimated consulting fee and travel
expenses in advance.”
• “Time-off approvals must comply with the company’s HR vacation policy.”
• These rules govern how processes are managed in a business.
Business Rules
Business Rules vs. Software Requirements:
• Business rules are not software requirements themselves.
• However, they often dictate the need for certain system functionalities.
• Example: If a company has a vacation policy, the HR software must include time-off
approval workflows that follow the policy.
Business Rules Influence System Design:
• Security policies may lead to specific quality attributes (e.g., encryption for data
protection).
• Functional requirements can often be traced back to a business rule.
• Example: If GDPR compliance is required, the system must implement user data
protection and consent features.
Why Are Business Rules Important?
• Ensure legal and regulatory compliance.
• Define how a business operates and what constraints exist.
• Influence the functional and quality requirements of a system.
Non-Functional Requirements
Quality attributes are also known as quality factors, quality of
service requirements, constraints, and the “–ilities.”
They describe the product’s characteristics in various dimensions
that are important either to users or to developers and maintainers,
such as performance, safety, availability, and portability.
Other classes of nonfunctional requirements describe external
interfaces between the system and the outside world.
These include connections to other software systems, hardware
components, and users, as well as communication interfaces.
Design and implementation constraints impose restrictions on
the options available to the developer during construction of
the product.
 Non-Functional Requirements
Quality Attributes:
• Non-functional requirements are often called quality attributes, quality
factors, or quality of service requirements.
• They describe how well the system performs rather than what it does.

• Common quality attributes include:

• Performance (e.g., response time should be under 2 seconds).
• Safety (e.g., system must prevent unauthorized access to sensitive data).
• Availability (e.g., system should have 99.9% uptime).
• Portability (e.g., software should run on Windows, macOS, and Linux).
 Non-Functional Requirements
External Interfaces:
• Some NFRs focus on external system interactions.
• These describe how the system connects with:
• Other software systems (e.g., API integrations).
• Hardware components (e.g., IoT devices, printers).
• Users (e.g., graphical user interfaces, voice interfaces).
• Communication interfaces (e.g., Bluetooth, HTTP, WebSockets).
Design and Implementation Constraints:
• These impose restrictions on how developers can implement the system.
Examples of constraints:
• Legal Requirements (e.g., "The system must protect user data like banking details").
• Technology Limits (e.g., "The app must use MySQL because the company already has
MySQL servers").
• Hardware Restrictions (e.g., "The software must work only on Android phones")
 Why Are Non-Functional
Requirements Important?
• Ensure system usability, reliability, and security.
• Help optimize performance and maintainability.
• Define architectural constraints that developers must follow.
 Software Requirements Specification
(SRS)
• The Software Requirements Specification (SRS) is a document that
defines the expected behavior of a software system.
• It is created by a Business Analyst (BA) to capture functional
requirements.
SRS Purpose:
• Provides a detailed description of what the software should do.
• Serves as a reference guide for developers, testers, and stakeholders.
• Ensures that software development follows clear expectations.
 Software Requirements Specification
(SRS)
Why is an SRS Important?
• Acts as an official agreement between stakeholders and the
development team.
• Helps avoid misunderstandings by defining the scope, features, and
constraints of the software.
• Ensures that software is developed correctly according to requirements.
Example of an SRS Requirement
• Requirement: “The system shall allow users to reset their password via
email verification.”
• Explanation: This requirement specifies a functional behavior that must be
implemented in the software.
 Software Requirements Specification
(SRS)
Who Uses SRS?
• Developers – To build software based on requirements.
• Testers – To validate that software meets expectations.
• Project Managers – To track progress and ensure requirements are met.
• Stakeholders – To confirm that the software aligns with business goals.
Business Analyst
Business Analyst (BA):
• A BA is a key role in a project responsible for leading requirement-related activities.
• They work in project management and related functions to ensure the successful
execution of a project.

Responsibilities of a Business Analyst:

• Understanding and documenting requirements:
• The BA gathers, analyzes, and documents project requirements to ensure clarity and
completeness.
• Acting as a bridge between stakeholders:
• They facilitate communication between business users (who define what they need) and
the technical team (who build the solution).
• This ensures everyone has a clear understanding of project goals.
• Translating business needs into technical requirements:
• The BA converts high-level business needs into detailed technical specifications that
developers and testers can implement.
Business Analyst
Why is a Business Analyst Important?
• Prevents misunderstandings between business and technical teams.
• Ensures project alignment with business goals.
• Improves efficiency by clearly defining requirements before development
begins.
• Reduces risks and costly rework by identifying issues early.
 Functional Requirements
▪ These describe the specific behaviors, functions, or features that the
software must perform to meet the business needs.
Example:
▪ If the software is an e-commerce platform, a functional requirement
might be the ability for users to add items to their cart.
Feature
A feature consists of one or more logically related system
capabilities that provide value to a user and are described by a set of
functional requirements.
Web browser bookmarks, spelling checkers, the ability to define a
custom workout program for a piece of exercise equipment, and
automatic virus signature updating in an anti-malware product are
examples of features.
A feature can encompass multiple user requirements, each of which
implies that certain functional requirements must be implemented to
allow the user to perform the task described by each user
requirement.
Figure 1-2 illustrates a feature tree, an analysis model that shows
how a feature can be hierarchically decomposed into a set of smaller
features, which relate to specific user requirements and lead to
specifying sets of functional requirements (Beatty and Chen 2012).
 Feature
• A feature is a system capability that provides value to the user.
• It is described by a set of functional requirements that define how the feature
behaves. OR
• A feature consists of one or more logically related system capabilities
that provide value to a user and are described by a set of functional
requirements.
Examples of Features:
• Web browser bookmarks – Allow users to save web pages.
• Spell checkers – Help users detect and correct spelling errors.
• Custom workout programs – Let users create personalized exercise routines on
fitness equipment.
• Automatic virus signature updates – Ensure antivirus software stays up to date
against new threats.
 Feature
Features and Functional Requirements:
• A single feature can involve multiple user requirements.
• Each user requirement is supported by specific functional requirements that
enable the feature to work.
• Example:
• Feature: "User profile customization" in a mobile app.
• User Requirements: Users should be able to change their profile picture and
update their bio.
• Functional Requirements: The system must allow image uploads and text
editing.
Feature Tree Analysis Model :
• Figure 1-2 illustrates a feature tree an analysis model (Beatty and Chen 2012).
• Feature trees help break down a feature into smaller sub-features.
• Each sub-feature relates to specific user requirements.
• This leads to a clear structure for specifying functional requirements.
 Feature
Why Are Features Important?
• They define key functionalities that deliver value to users.
• They help organize system requirements into logical and manageable
units.
• They ensure functional requirements are aligned with user needs.
Relationships among features, user
requirements, and functional requirements
Aspect Feature User Requirement Functional Requirement

Definition A high-level system capability that Describes what the user wants to Specifies how the system should
provides value to users. achieve with the system. behave to fulfill user requirements.

Scope Broad, represents a collection of Focused on user goals and interactions Detailed and technical, defining
related capabilities. with the system. system operations.

Purpose Defines major functionalities of the Expresses what the user needs from Describes how the system will fulfill
system. the system. user needs.

Example “Bookmark Management” in a web “Users should be able to save and “The system shall allow users to add,
browser. organize bookmarks.” delete, and rename bookmarks.”

Relation to Other A feature contains multiple user A user requirement maps to one or Functional requirements implement
Requirements requirements. more functional requirements. user requirements.
Relationships among features, user
requirements, and functional
requirements
 Relationships among features, user
requirements, and functional requirements
In Diagram:
• The Web Browser is the main system.
• It contains several features such as:
• Bookmarks
• Cookies
• Tabs
• Add-Ins

• The diagram focuses on Bookmarks and how it connects to user and

functional requirements.
 Relationships among features, user
requirements, and functional requirements
Breakdown of a Feature (Bookmarks):
• The Bookmarks feature includes several user requirements:
• Add a Bookmark
• Export Bookmarks
• Go to a Bookmarked Location
• Edit Bookmarks

• These user requirements lead to specific functional requirements.

Relationships among features, user
requirements, and functional requirements
Examples of Functional Requirements (For Editing Bookmarks):
• The system shall display bookmarks as a collapsible and expandable
hierarchical tree.
• The user shall be able to resequence bookmarks.
• The system shall display bookmark properties.
• The user shall be able to modify a bookmark’s name, URL, and description.

Understanding the Key(feature, User :

• Features are the high-level capabilities of the system.
• User requirements define what actions users can perform with those
features.
• Functional requirements specify how the system should support those
actions.
 Relationships among features, user
requirements, and functional requirements
Why Is This Important?
• Ensures a structured breakdown of requirements from high-level
features to technical details.
• Helps developers understand what needs to be built at different levels.
• Improves traceability between features and functional implementation.
Putting into a case(fill the blacks as
which req it belongs?)
To illustrate some of these various kinds of requirements, consider a
project to develop the next version of a text editor program. A
………… requirement might be “Increase sales by 25 percent
within 6 months.” Marketing realizes that the competitive products
only have English-language spelling checkers, so they decide that the
new version will include a multi language spelling checker feature.
Corresponding ……. requirements might include tasks such as
“Select language for spelling checker,” “Find spelling errors,” and
“Add a word to a dictionary.” The spelling checker has many
individual …………. requirements, which deal with operations such
as highlighting misspelled words, autocorrect, displaying suggested
replacements, and globally replacing misspelled words with
corrected words. ……….. requirements specify how the software is
to be localized for use with specific languages and character sets.
Putting into a case
Business Requirement → “Increase sales by 25 percent within 6
months.”
• Explanation:
• This is a high-level goal related to the business objective.
• It defines the purpose of the project from a business perspective.

User Requirements → Tasks such as “Select language for spelling

checker,” “Find spelling errors,” and “Add a word to a dictionary.”
• Explanation:
• These describe what users should be able to do in the system.
• They are actions the user can perform with the multi-language spelling
checker.
 Putting into a case
Functional Requirements → Operations such as highlighting misspelled
words, autocorrect, displaying suggested replacements, and globally
replacing misspelled words with corrected words.
• Explanation:
• These define specific behaviors of the system.
• They ensure the spelling checker works as intended.
Non-Functional Requirements → Specify how the software is to be
localized for use with specific languages and character sets.
• Explanation:
• These focus on system quality attributes such as localization, usability,
and compatibility.
• They ensure the software supports multiple languages and character
sets.
 Putting into a case
Why is This Case Important?
• Shows how different requirement types relate to real-world projects.
• Helps understand how business goals drive user needs, which define
functional and non-functional requirements.
• Demonstrates how requirements guide software development for
better user experience.
 Levels of requirements
Software requirements include three distinct levels:
• Business requirements,
• User requirements,
• and functional requirements.
• In addition, every system has a variety of nonfunctional requirements.
Requirements Information
Relationship

Diagram shows the relationships among several types of requirements information. Solid
arrows mean “are stored in”; dotted arrows mean “are the origin of” or “influence.”
 Requirements Information
Relationship
❑ Business Requirements:
• These are high-level goals of the organization, driving the project.
• They are stored in the Vision and Scope Document.
• Business requirements influence Business Rules, User Requirements,
and Quality Attributes.
❑ Vision and Scope Document:
• This document stores business requirements and serves as a high-level
overview of the project goals and scope.
• It influences the User Requirements.
 Requirements Information
Relationship
❑ User Requirements:
▪ These describe what users need from the system and are derived from
business requirements.
• They are stored in the User Requirements Document and influence the
Functional Requirements a nd System Requirements.

❑ User Requirements Document:

• This document stores user requirements and serves as a reference for
detailed requirements gathering.

❑ System Requirements:
• These are technical specifications for how the system should operate, which
are derived from user requirements.
 Requirements Information
Relationship
❑ Functional Requirements:
• These detail what the system should do, influenced by user and system
requirements.
• They are stored in the Software Requirements Specification and influence
elements like External Interfaces.

❑ Software Requirements Specification:

• This is where the detailed functional requirements, constraints, and system

specifications are stored.

❑ Business Rules:
• These are rules that govern the business processes and influence functional
requirements and quality attributes.
 Requirements Information
Relationship
❑ Quality Attributes:
• These are non-functional requirements related to performance, security,
etc., influenced by business rules and user requirements.

❑ External Interfaces:
• These describe how the system interacts with external systems and are
derived from functional requirements.

❑ Constraints:
• These are limitations within which the system must operate and are
stored within the SRS.
Working with the three levels
• Figure 1-3 illustrates how various
stakeholders might participate in
eliciting the three levels of
requirements.

• Different organizations use a variety of

names for the roles involved in these
activities

• The role names often differ depending

on whether the developing
organization is an internal corporate
entity or a company building software
for commercial use.
 Continued…..
▪ Based on an identified business need, a market need, or an
exciting new product concept, managers or marketing
define the business requirements for software that will
help their company operate more efficiently (for
information systems) or compete successfully in the
marketplace (for commercial products).
▪ In the corporate environment, a business analyst then
typically works with user representatives to identify user
requirements.
▪ Companies developing commercial products often identify
a product manager to determine what features to include
in the new product.
 Continued…..
▪ Each user requirement and feature must align with
accomplishing the business requirements.
▪ From the user requirements, the BA or product manager
derives the functionality that will let users achieve their
goals.
▪ Developers use the functional and nonfunctional
requirements to design solutions that implement the
necessary functionality, within the limits that the
constraints impose.
▪ Testers determine how to verify whether the requirements
were correctly implemented.
 Product vs. Project requirements
▪ So far we have been discussing requirements that describe
properties of a software system to be built.
◦ Let’s call those product requirements.

▪ Projects certainly do have other expectations and

deliverables that are not a part of the software the team
implements, but that are necessary to the successful
completion of the project as a whole.
◦ These are project requirements but not product requirements.

▪ An SRS houses the product requirements, but it should not

include design or implementation details (other than known
constraints), project plans, test plans, or similar information.
 Project Requirements
▪ Physical resources the development team needs, such as
workstations, special hardware devices, testing labs, testing
tools and equipment, team rooms, and videoconferencing
equipment.
▪ Staff training needs.
▪ User documentation, including training materials, tutorials,
reference manuals, and release notes.
▪ Support documentation, such as help desk resources and field
maintenance and service information for hardware devices.
▪ Infrastructure changes needed in the operating environment.
▪ Requirements and procedures for releasing the product,
installing it in the operating environment, configuring it, and
testing the installation.
 Continued….
▪ Requirements and procedures for transitioning from an old system to a new
one, such as data migration and conversion requirements, security setup,
production cutover, and training to close skills gaps; these are sometimes
called transition requirements (IIBA 2009).
▪ Product certification and compliance requirements.
▪ Revised policies, processes, organizational structures, and similar documents.
▪ Sourcing, acquisition, and licensing of third-party software and hardware
components.
▪ Beta testing, manufacturing, packaging, marketing, and distribution
requirements.
▪ Customer service-level agreements.
▪ Requirements for obtaining legal protection (patents, trademarks, or
copyrights) for intellectual property related to the software.
When bad requirements happen to
good people
Insufficient user involvement
◦ Customers often don’t understand why it is so essential to work hard
on eliciting requirements and assuring their quality.
◦ Developers might not emphasize user involvement, perhaps because
they think they already understand what the users need.
◦ In some cases it’s difficult to gain access to people who will actually
use the product, and user substitutes don’t always understand what
users really need.
◦ Insufficient user involvement leads to late-breaking requirements
that generate rework and delay completion.
◦ Another risk of insufficient user involvement, particularly when
reviewing and validating the requirements, is that the business
analyst might not understand and properly record the true business
or customer needs.
 Overlooked stakeholders
▪ Most products have several groups of users who might use
different subsets of features, have different frequencies of use,
or have varying levels of experience.
▪ If you don’t identify the important user classes for your product
early on, some user needs won’t be met.
▪ After identifying all user classes, make sure that each has a
voice.
▪ Besides obvious users, think about maintenance and field
support staff who have their own requirements, both
functional and nonfunctional.
▪ You might have stakeholders who don’t even know the project
exists, such as government agencies that mandate standards
that affect your system, yet you need to know about them and
their influence on the project.
 Benefits from a high-quality
requirements process
▪ Some people mistakenly believe that time spent discussing requirements
simply delays delivery by the same duration.
▪ This assumes that there’s no return on investment from requirements
activities. In actuality, investing in good requirements will virtually always
return more than it costs.
▪ The potential payoff includes:
◦ Fewer defects in requirements and in the delivered product.
◦ Reduced development rework.
◦ Faster development and delivery.
◦ Fewer unnecessary and unused features.
◦ Lower enhancement costs.
◦ Fewer miscommunications.
◦ Reduced scope creep.
◦ Reduced project confusion.
◦ Higher customer and team member satisfaction.
◦ Products that do what they’re supposed to do.
 Requirements Development and
Management
• Figure shows, we subdivide
requirements development into
elicitation, analysis, specification,
and validation (Abran et al.
2004).
• These sub disciplines encompass
all the activities involved with
exploring, evaluating,
documenting, and confirming the
requirements for a product.

• Regardless of what development life cycle your project is following—be it pure waterfall,
phased, iterative, incremental, agile, or some hybrid—these are the things you need to
do regarding requirements.

• Depending on the life cycle, you will perform these activities at different times in the
project and to varying degrees of depth or detail.
 Requirements Development and
Management
❑ Requirements Engineering:
• This is the overall process that encompasses all activities related to
understanding, specifying, and managing the needs for a system.
❑ Requirements Management:
• This involves tracking and maintaining requirements throughout the
project lifecycle. It ensures that requirements are kept up-to-date and
any changes are managed efficiently to maintain alignment with project
goals.
 Requirements Development and
Management
❑ Requirements Development:
• This involves the processes of discovering and defining the requirements
for a project. It consists of four key activities:

• Elicitation: Gathering requirements from stakeholders through various

techniques like interviews, surveys, or workshops.
• Analysis: Understanding and refining the gathered requirements to ensure
they are complete, feasible, and aligned with the project's goals.
• Specification: Documenting the requirements in a clear and structured
format, typically in a requirements document or SRS
• Validation: Ensuring that the documented requirements accurately reflect
stakeholder needs and are feasible for implementation.
 Requirements Development and
Management
❑ Applicability in Different Development Models:
• These activities are performed regardless of the software development
lifecycle used:
• Waterfall – Conduct all activities upfront in a sequential process.
• Agile/Iterative – Perform these activities in smaller increments
throughout development.
• Hybrid Approaches – A mix of structured and iterative methods
❑ Timing and Depth of Activities:
• The depth and timing of requirements activities depend on the project
lifecycle.
• Some phases may require more detailed documentation while others
focus on continuous adaptation.
 Elicitation
❑ Elicitation encompasses all of the activities involved with discovering
requirements from stakeholders, such as interviews, workshops,
document analysis, prototyping, and others.
❑ 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.
 Analysis
❑ Reaching a richer and more precise understanding of each
requirement:
• Analyzing the requirements to ensure clarity, completeness, and accuracy.
• It involves identifying ambiguities or conflicts and refining requirements to
make them actionable and well-understood by all stakeholders.
• The goal is to ensure that each requirement fully aligns with the business
goals and stakeholder needs.
❑ Representing sets of requirements in multiple ways:
• This refers to expressing the requirements through various formats such
as text descriptions, diagrams, use cases, models, or flowcharts.
• Using multiple representations helps different stakeholders, from business
users to technical teams, to understand the requirements more effectively.
• Different formats help in visualizing relationships between requirements,
making the analysis process more thorough.
 Principal Activities
◦ Analyzing 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
 Specification
❑ 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.
 Validation
❑ Requirements validation confirms that you have the correct set of
requirements information that will enable developers to build a
solution that satisfies the business objectives.
❑ The central activities are:
• Reviewing the documented requirements to correct any problems before
the development group accepts them.
• Developing acceptance tests and criteria to confirm that a product based on
the requirements would meet customer needs and achieve the business
objectives.
❑ Iteration is a key to requirements development success.
❑ Plan for multiple cycles of exploring requirements, progressively
refining high-level requirements into more precision and detail, and
confirming correctness with users.
 Requirements Management
❑ Requirements management activities include the following:
◦ Defining the requirements baseline, a snapshot in time that
represents an agreed-upon, reviewed, and approved set of
functional and nonfunctional requirements, often for a specific
product release or development iteration
◦ Evaluating the impact of proposed requirements changes and
incorporating approved changes into the project in a controlled way
◦ Negotiating new commitments based on the estimated impact of
requirements changes
◦ Defining the relationships and dependencies that exist between
requirements
◦ Tracing individual requirements to their corresponding designs,
source code, and tests.
◦ Tracking requirements status and change activity throughout the
project
 Applicability in Different Development Models:
• These activities are performed regardless of the software development
lifecycle used:
• Waterfall – Conduct all activities upfront in a sequential process.
• Agile/Iterative – Perform these activities in smaller increments
throughout development.
• Hybrid Approaches – A mix of structured and iterative methods
Thank you