Requirements Engineering

Presented By

Md. Fazle Hasan Mihad

Lecturer, Department of CSE & CSIT
 Welcome Everyone

Course Code: CSE 3107

Course Title: Software Engineering

Lecture-05
Lecture Overview:

Requirement Engineering
Types of Requirements
Types of System Requirements
Functional Requirements
Non-functional Requirements
Domain Requirements
Requirement Engineering
(RE):
Requirement Engineering (RE) refers to the process of defining, documenting and
maintaining requirements in the engineering design process. Requirement Engineering
provides the appropriate mechanism to understand,
• what the customer desires.
• Analyzing the need.
• Assessing feasibility (Economically, Technically, Operational)
• Negotiating a reasonable solution.
• Specifying the solution clearly.
• Validating the specification.
• Managing the requirement.
Requirement Engineering
(RE):
What is a Requirement?
A requirement can be:
• A general idea of what the system should do.
• A detailed technical specification.
• Used for two purposes:
• For Bidding – Written broadly so different companies can propose solutions.
• For Development – Written in detail to ensure the final product meets expectations.

Requirements Abstraction (Davis’s Perspective)

• A company must define needs abstractly so multiple vendors can bid.
• After contract selection, the vendor provides a detailed system definition.
• Both documents are considered requirements documents at different stages.
Types of Requirements
Types of Requirements
1. User Requirements
User requirements are statements in a natural language plus diagrams, of what services the system is
expected to provide and the constraints under which it must operate.
1. What it is: Simple descriptions of system services and constraints.
2. Format: Written in natural language with diagrams.
3. Purpose: Helps customers understand what the system will do.
Types of Requirements
2. System Requirements
System requirements set out the system functions, Service, and operational constraints in detail. The
system requirement document (functional specification) should be precise. It should define exactly
what is to be implemented.
1. What it is: A detailed, structured document describing system functions, services, and
constraints.
2. Format: More technical, often includes specifications for developers.
3. Purpose: Defines what should be implemented and may be part of a contract between the
client and developer.

Key Difference:
• User requirements focus on what the user needs (simple, high-level).
• System requirements focus on how the system works (detailed, technical).
Types of Requirements
Example
Types of Requirements
Readers of different types of requirements specifications

User requirements focus on what the user wants.

System requirements focus on how the system will be built.
Types of System
Requirements
Types of System Requirements
1. Functional Requirements
2. Non-Functional Requirements
3. Domain Requirements
Functional Requirements
1. Functional Requirements
Functional requirements define what a system should do—its features and actions. They
describe how the system interacts with users and other systems.
• Define what the system should do.
• Describe services, system behavior, and responses to inputs.
• May include what the system should not do.

It describes the specific actions and behaviors the system must perform for users or other
systems. Examples include user login, data entry, search functionality, report generation, and
data processing. It focuses on the system's functionality and is usually expressed as "the
system shall..." statements.
Functional Requirements
Example:
Functional Requirements
Challenges of Functional Requirements (FRs):
• Unclear Requirements: Confusing words lead to misunderstandings.
Example: "Search" – Search where? Whole site or just one page?
• Missing Features: Important functions might be forgotten.
Example: A booking system but no way to cancel.
• Conflicting Needs: Some needs may not work well together.
Example: Data should be encrypted but also easy to access.
• Changing Requirements: Business needs often change, so FRs may become outdated.
• Technical Limits: Some features might not be possible due to hardware or software restrictions.
• Scalability Issues: System may not work well with more users in the future.
• Wrong User Assumptions: Users expect features that were never planned.
Example: Expecting an “Undo” button that doesn’t exist.
👉 Solution: Clear communication, regular updates, and testing help avoid these problems.
Non-functional Requirements
2. Non-functional Requirements (How)
These are constraints on the services are functions offered by the system. They include
timing constraints, constraints on the development process, and standards.
• Set constraints on system functions, such as:
• Performance (timing, speed)
• Development standards
• Security & reliability
• Apply to the whole system rather than specific features.

For example, the website should load any product page within 3 seconds.
Non-functional Requirements
Types of nonfunctional requirements:
Non-functional Requirements
Types of Non-Functional Requirements (NFRs)
Non-functional requirements define system quality, security, and compliance rather than
specific features. They are categorized as:
1. Product Requirements (System Performance & Quality): Requirements which specify
that the delivered product must behave in a particular way, e.g, execution speed, reliability,
etc.
• Efficiency – Fast response time, low resource usage.
• Includes: Usability, Performance, Storage.
• Dependability – Reliable, always available, fault-tolerant.
• Security – Protects data, prevents unauthorized access.
Non-functional Requirements
2. Organizational Requirements (Internal Policies & Operations): Requirements which
are a consequence of organizational policies and procedures e.g. process standards used,
implementation requirements, etc.
• Environmental – Works in specific conditions (hardware, climate).
• Operational – Must be available 24/7, support many users.
• Development – Uses specific tools, follows coding standards.

3. External Requirements (Legal & Ethical Compliance): Requirements which arise from
factors which are external to the system and its development process.
• Regulatory – Follows industry laws (e.g., GDPR, ISO).
• Ethical – Prevents bias, ensures fair use.
• Legislative – Meets financial and safety standards.
Non-functional Requirements
Type Category Examples
Efficiency Usability, Performance, Storage

Product Requirements Dependability Reliability, Availability, Fault Tolerance

Authentication, Encryption, Threat
Security
Protection
Hardware compatibility, Weather
Environmental
resilience
Organizational Requirements Operational 24/7 uptime, Multi-user support
Development Coding standards, Preferred tools
Regulatory GDPR, ISO Standards
External Requirements Ethical Bias prevention, Fair technology access
Legislative Tax compliance, System safety
Non-functional Requirements
Example:
Non-functional Requirements
Metrics for specifying nonfunctional requirements:
Non-functional Requirements

Implementation Challenges:
• Affect the whole system, not just one function.
• Can lead to new functional requirements (e.g., security rules may require login systems).
• It may conflict with other requirements (e.g., strong security vs. fast performance).
Domain Requirements
3. Domain Requirements
These are requirements that come from the application domain of the system and that
reflect the characteristics and constraints of that domain. These reflect the fundamental
characteristics, rules, processes, and terminology of that particular industry or area of
expertise.
For example, if you're building software for a hospital, you'll have requirements related to
medical records, patient care protocols, and healthcare regulations – these are domain
requirements specific to the healthcare domain.

• Specific constraints based on the system’s field of application.

• Ensure compatibility with industry standards, regulations, or business rules.
Domain Requirements
Challenges:
• Lack of domain knowledge.
• Conflicting regulations.
• Frequent industry changes.
Thank You