REQUIREMENTS ENGINEERING TYPES

Product & Process Requirements

In software requirement engineering, product requirements and process requirements refer
to two distinct types of requirements that help shape both the final product and the methods
used to create it. Here’s a breakdown of each:

1. Product Requirements

Product requirements specify what the software product must do to fulfill its purpose and
meet user expectations. They focus on the features and functionalities that the end product
should offer. These requirements describe the system's behavior, performance, usability, and
other characteristics that are directly visible to users and stakeholders.

Examples of Product Requirements:

● Functional Requirements: These define specific features, such as “The system must
allow users to log in with a username and password” or “The software should calculate
monthly sales reports.”
● Non-functional Requirements: These define qualities or constraints of the system,
such as “The system should load within 3 seconds” (performance) or “The system must
ensure data security with encryption” (security).
● Interface Requirements: These specify how the system will interact with other systems,
hardware, or users, such as “The software must support integration with third-party
payment gateways.”

Product requirements are usually documented in a Software Requirements Specification (SRS)

and serve as the blueprint for the development team to build the final software product.

2. Process Requirements

Process requirements specify how the software development process itself should be
conducted. They focus on the practices, tools, and methodologies that need to be used to
create the software, ensuring the project is managed effectively and that quality standards are
met. Process requirements help in defining the framework and rules for development, testing,
deployment, and maintenance.

Examples of Process Requirements:

● Methodologies: “The project must follow Agile methodology for development” or “A

code review process is required before merging any changes.”
 ● Documentation Standards: “All code must be documented following company coding
standards” or “The team should produce a test plan for each release.”
● Quality Assurance: “Automated tests must cover at least 80% of the code” or “A
security audit must be performed before deployment.”
● Project Management: “Weekly meetings should be held to review project progress” or
“Requirements must be approved by the product owner before development starts.”

Process requirements help ensure that the development process is organized, consistent, and
aligned with the organization's standards, ultimately supporting the successful delivery of the
product requirements.

Summary

● Product Requirements: Define what the software should do (features, functionalities,

and qualities).
● Process Requirements: Define how the development process should be conducted
(methods, standards, and practices).

Together, these requirements ensure that the right product is built and that it’s built in the right
way.

Functional & Non-Functional Requirements

In software requirement engineering, functional and non-functional requirements are
essential for defining what a software system should do and how it should perform. Here’s a
detailed explanation of each:

1. Functional Requirements

Functional requirements describe what the system should do. They focus on the specific
actions, tasks, or functions that the software needs to perform to meet user needs. Essentially,
these requirements define the features and behaviors of the system.

Functional requirements are usually defined in response to business needs and user goals, and
they are often detailed in a Software Requirements Specification (SRS) document. These
requirements are essential because they directly impact the end-user experience, and they
need to be clear, complete, and testable to ensure that the software fulfills its intended purpose.

Examples of Functional Requirements:

1. User Authentication: The system must allow users to log in using a username and
password.
2. Search Feature: The application should enable users to search for products by name or
category.
3. Order Processing: The system should allow users to place orders and process
payments.
4. Notifications: The software should notify users of changes in their account status via
email.
5. Data Validation: The system must ensure that entered data meets certain validation
rules (e.g., email format for email fields).

Key Characteristics of Functional Requirements:

● Describes what the system should do (e.g., “The system must generate a report of
daily sales”).
● Interacts with the user or other systems (e.g., integrations, user inputs).
● Often defined as “use cases” or “user stories” (e.g., “As a user, I want to be able to
add items to my cart”).
● Should be testable: There should be a way to verify if the requirement is met.

Functional requirements are critical as they outline the core capabilities of the software and
ensure that it performs the actions for which it was designed.

2. Non-Functional Requirements

Non-functional requirements describe how the system should perform rather than what it
should do. They define the quality attributes of the system and outline constraints on its
operation. These requirements are often known as "quality attributes" and help determine the
usability, reliability, performance, and scalability of the system.

Non-functional requirements are as important as functional requirements because they

influence user satisfaction, system efficiency, and future maintenance. They are typically more
challenging to quantify and test but are crucial for ensuring the system’s quality and robustness.

Examples of Non-Functional Requirements:

1. Performance: The system must handle 10,000 concurrent users without slowing down.
 2. Scalability: The application should support additional servers and databases as the
user base grows.
3. Reliability: The system should be available 99.9% of the time (uptime requirement).
4. Usability: The system interface should be easy to navigate and accessible to users with
disabilities.
5. Security: Sensitive data, such as passwords, must be encrypted and stored securely.

Key Characteristics of Non-Functional Requirements:

● Describes how the system performs or operates under certain conditions (e.g., “The
system should load within 2 seconds”).
● Focuses on quality attributes such as speed, security, reliability, and usability.
● Constraints on the system rather than features or functionalities (e.g., “The system
should not allow more than three failed login attempts”).
● Defines performance metrics and standards that help ensure a high-quality
experience.

Non-functional requirements are typically documented separately from functional requirements

but are equally important for project success. They often influence architectural and design
decisions to ensure that the system is scalable, secure, and maintainable.

Comparison of Functional and Non-Functional Requirements

Aspect Functional Requirements Non-Functional Requirements

Focus What the system does How the system performs

Type of Features, behaviors, and Quality attributes and operational

Requirements interactions constraints

Examples Login, search, report Speed, security, scalability, usability

generation

Measurement Easily measurable through Measured through performance

testing metrics, standards

Impact Defines system functionality Defines system quality and user

experience

Testing Validation testing Performance, load, and security

testing
Why Both are Necessary

Both functional and non-functional requirements are essential for a successful software project.
Functional requirements are necessary to ensure that the system does what it’s supposed to
do, fulfilling user needs and business goals. Without them, the software lacks purpose and fails
to serve its users.

Non-functional requirements, on the other hand, ensure that the software operates efficiently,
reliably, and securely. They influence user satisfaction, operational stability, and maintainability,
which are vital for long-term success. A system with excellent functionality but poor
non-functional attributes (e.g., slow performance, frequent downtime) is likely to frustrate users
and be unsustainable.

Together, functional and non-functional requirements provide a comprehensive understanding of

both what the system should do and how well it should do it.

Emergent Properties
In software requirement engineering, emergent properties are characteristics of a software
system that arise from the interaction and combination of individual system components. They
are properties that cannot be attributed to any single part of the system on its own but are the
result of how the system's components work together as a whole.

Characteristics of Emergent Properties

1. System-Wide: Emergent properties apply to the system as a whole and depend on the
way components interact. They are not properties of any single module or component.
2. Complexity-Driven: They often appear in complex systems where multiple components
work together, making them challenging to predict from the properties of individual
components.
3. Holistic: Emergent properties emphasize the idea that "the whole is greater than the
sum of its parts." They are only evident when all the parts function together.

Examples of Emergent Properties

Some common emergent properties in software systems include:

1. Performance: This refers to how fast or efficiently the system responds to user actions,
processes data, or completes tasks. Performance depends on how components work
together; for example, how quickly data flows between the database, business logic, and
UI layers affects overall response time.
2. Reliability: Reliability is the ability of the system to consistently perform its intended
functions without failure. Even if individual components are reliable, the overall reliability
 of the system depends on component interactions, error handling, fault tolerance, and
recovery mechanisms.
3. Scalability: Scalability is the ability of the system to handle increased loads by adding
resources, like more users or larger datasets. It depends on interactions between
components such as databases, servers, and network infrastructure.
4. Usability: Usability refers to how easy and intuitive it is for users to interact with the
system. It’s not just about the interface design but also about how components like the
database and backend logic support smooth interactions.
5. Security: Security is an emergent property as it depends on how the system manages
data access, handles user authentication, secures communication channels, and
implements permissions and encryption. Secure behavior depends on various system
elements working in harmony to prevent vulnerabilities.
6. Maintainability: Maintainability is the ease with which developers can update, fix, or
improve the system. It depends on factors like code organization, modularity,
documentation, and how well the system’s components interact without introducing
unnecessary complexity.
7. Interoperability: This is the ability of the system to work well with other systems.
Interoperability emerges from consistent standards, protocols, and APIs that allow
seamless data exchange and interaction with external systems.

Why Emergent Properties are Important in Software Engineering

Emergent properties are essential in software engineering because they affect the overall
system behavior and quality in ways that are often difficult to predict. Here are some reasons
why emergent properties matter:

1. Impact on User Satisfaction: Properties like usability, performance, and reliability

directly impact user experience. If a system has poor emergent properties, users may
find it frustrating or unreliable, leading to poor adoption or even failure of the software.
2. System Robustness: Emergent properties such as security and reliability make the
system robust and resilient to failures, attacks, or unexpected inputs. Neglecting these
can leave the system vulnerable to threats or performance issues.
3. Scalability and Future-Proofing: With scalability as an emergent property, the system
can grow to meet future demands, like handling more users or data. A system that lacks
scalability might be successful initially but will struggle to keep up as usage grows.
4. Maintenance and Operational Costs: A system with good maintainability is easier to
update and fix, reducing long-term operational costs. Emergent properties like
maintainability are crucial for the sustainability of the system throughout its lifecycle.

Challenges in Managing Emergent Properties

Emergent properties are often complex to manage due to the following reasons:
 1. Interdependency of Components: Since these properties emerge from interactions
between components, even minor changes in one part of the system can affect the
overall system behavior. Predicting the impact of such changes is challenging.
2. Difficulty in Testing: Testing emergent properties can be complicated. For example,
while a module can be tested for individual functionality, testing system performance or
reliability under various loads often requires simulation of real-world conditions, which
can be costly and time-consuming.
3. Unpredictability: Some emergent properties only reveal themselves during system
operation under real-world conditions. Issues with reliability or performance may not be
apparent until the system is in production and handling real users.
4. Balance and Trade-offs: Improving one emergent property may negatively affect
another. For example, adding complex security measures can sometimes slow down
performance or make usability harder. Software engineers need to find a balance that
aligns with user needs and project goals.

Examples of Emergent Properties in Practice

1. Web Application with High Traffic: A social media platform may perform well with a
small number of users but encounter performance issues as user activity scales up.
Here, performance and scalability are emergent properties affected by how the
database, cache, server, and network interact under heavy load.
2. E-commerce Platform Security: An e-commerce system handling sensitive customer
information needs to be secure. Security is an emergent property based on encryption,
access control, network security, and secure data storage working together to prevent
unauthorized access.
3. Healthcare Software Reliability: In healthcare software, reliability is crucial because
downtime or errors could risk patient safety. Reliable behavior emerges from
redundancy, error handling, and robust communication between software components.
4. Automobile Embedded Systems: In a car’s embedded system, the safety of the
vehicle is an emergent property. Safety depends on the interaction between various
systems (e.g., braking, steering, and stability control) to ensure the car behaves correctly
in different scenarios.

Strategies for Managing Emergent Properties

1. Modular Design: Breaking the system into independent, well-defined modules can
make it easier to understand and manage interactions between components, helping to
control emergent behavior.
2. Robust Testing: Conducting performance, scalability, and security tests under
real-world conditions can help identify potential issues in emergent properties before
deployment.
3. Clear Standards and Protocols: Establishing consistent coding standards, design
patterns, and protocols can ensure that components interact in predictable ways,
minimizing unexpected emergent behaviors.
 4. Continuous Monitoring: Monitoring the system in production allows engineers to detect
and respond to issues with emergent properties, like performance degradation or
security vulnerabilities, as they arise.
5. Documentation of Dependencies: Documenting component dependencies and
interactions can help engineers understand how changes in one part of the system might
affect emergent properties across the system.

Summary

Emergent properties are a vital aspect of software systems, representing qualities that arise
only when all components interact as a whole. They include attributes like performance,
security, reliability, and scalability, which are crucial for a successful, sustainable software
system. By understanding and managing emergent properties, software engineers can ensure
that the system not only meets its functional requirements but also performs optimally and
provides a quality experience for users.

Quantifiable Requirements
In software requirements engineering, quantifiable requirements refer to requirements that
can be measured, tested, and verified objectively. They are specifications written in a way that
allows stakeholders to verify if the requirements have been met. Making requirements
quantifiable helps ensure that both developers and clients have a clear understanding of what is
expected, and it provides a basis for measuring project success.

Characteristics of Quantifiable Requirements

1. Measurable: The requirement should be expressed in specific, measurable terms (e.g.,

time, speed, capacity, response rate).
2. Testable: There should be a clear method or criteria for testing whether the requirement
has been fulfilled.
3. Objective: Quantifiable requirements avoid subjective language and vague descriptions.
They provide a concrete standard for assessment.

Why Quantifiable Requirements Are Important

Quantifiable requirements help minimize ambiguity and miscommunication. Without quantifiable

requirements, stakeholders may interpret requirements differently, leading to misunderstandings
and potential project failures. They provide:
 ● Clarity and Precision: Avoids vague descriptions, ensuring that all parties have the
same understanding.
● Accountability: Allows developers and stakeholders to verify if a feature or function
meets the agreed-upon specifications.
● Ease of Testing and Validation: Quantifiable requirements make it easier to conduct
tests and verify if the project meets specified criteria.
● Objective Measurement of Success: Enables a straightforward, unbiased evaluation of
whether the requirement has been met.

Examples of Quantifiable Requirements

1. Performance Requirements: "The system should process 1,000 transactions per

second." This can be tested by measuring the transaction processing speed.
2. Response Time: "The webpage should load within 2 seconds under normal conditions."
The load time can be measured and verified.
3. Storage Requirements: "The database should support up to 10 terabytes of data
without performance degradation." This can be verified through testing and monitoring
data storage capacity.
4. Uptime and Reliability: "The system should have 99.9% uptime, allowing a maximum
of 8.76 hours of downtime per year." This can be tracked and measured over time.
5. Security Requirements: "All user data should be encrypted with AES-256 encryption."
This can be checked by reviewing the encryption method used in the system.
6. User Interface Requirements: "The dashboard should allow users to complete a
search query in under 3 clicks." The user interface can be tested to verify the number of
actions needed.

Writing Quantifiable Requirements: Best Practices

1. Use Specific Metrics: Where possible, include specific metrics (e.g., "2 seconds,"
"99.9% uptime," "1,000 transactions per second") rather than vague terms like "fast" or
"responsive."
2. Avoid Subjective Language: Avoid words like "user-friendly," "efficient," or "intuitive,"
unless these terms are further defined with measurable criteria.
3. Define Testing Methods: Specify how the requirement will be tested to ensure all
stakeholders agree on how the system’s compliance with the requirement will be
measured.
4. Set Realistic Targets: Ensure that the targets set in quantifiable requirements are
realistic and achievable based on the project's scope, budget, and timeline.

Challenges in Defining Quantifiable Requirements

1. Difficult to Quantify Certain Qualities: Qualities like user satisfaction, usability, or

aesthetic appeal are harder to quantify, even though they may be essential.
 2. Changing Requirements: Quantifiable targets may need to be adjusted as the project
progresses, which can complicate planning and testing.
3. Overly Rigid Specifications: Setting excessively strict or narrow quantifiable
requirements can lead to design constraints that hinder the flexibility and creativity of the
development team.

Summary

In software requirement engineering, quantifiable requirements are essential for creating

measurable, testable, and objective criteria for a software project. They improve clarity, reduce
ambiguity, and provide a basis for verifying the success of the final product. By specifying
requirements in quantifiable terms, development teams and stakeholders can ensure that
expectations are clear and that the final product can be objectively assessed.

System and Software Requirements

In software requirements engineering, system requirements and software requirements are
two types of specifications that describe what a system or software product should achieve.
Both are crucial for defining and developing a project, but they differ in scope and detail.

Here’s a breakdown of these terms in detail:

1. System Requirements

System requirements define the overall functionality, constraints, and capabilities of the entire
system, encompassing both hardware and software components. They cover the system as a
whole and focus on how different parts of the system work together to meet the needs of
stakeholders.

System requirements are typically broader and address aspects like performance, security,
hardware compatibility, and interoperability with other systems.

Types of System Requirements

1. Functional System Requirements:

 ○ Describe what the entire system should do.
○ Outline the major functions and capabilities expected from the system.
○ For example: "The system should allow users to securely access and update
their profiles."
2. Non-functional System Requirements:
○ Define constraints or standards for how the system operates rather than what it
does.
○ Include requirements for performance, security, reliability, scalability, and
usability.
○ For example: "The system should support up to 5,000 concurrent users."
3. Interface Requirements:
○ Define how the system interacts with other systems or hardware.
○ Describe the protocols, data formats, or APIs that the system must support to
communicate with external components.
○ For example: "The system must support data exchange with external databases
via REST API."
4. Performance Requirements:
○ Specify the expected speed, capacity, or responsiveness of the system.
○ Often includes latency, throughput, and response time specifications.
○ For example: "The system should process at least 100 transactions per second."
5. Security Requirements:
○ Define how the system should protect against unauthorized access or data
breaches.
○ For example: "The system should require two-factor authentication for all user
logins."

Importance of System Requirements

● Alignment with Business Goals: System requirements ensure that the end product
aligns with the overall business objectives and satisfies stakeholder needs.
● Foundation for Design and Development: These requirements guide both software
and hardware design choices.
● Helps with Integration: System requirements clarify how different components (both
internal and external) interact, ensuring compatibility and interoperability.

2. Software Requirements

Software requirements are more detailed and specific than system requirements. They describe
the behavior, functions, and features of the software itself, typically focusing on what the
software should accomplish to fulfill system requirements.
Software requirements are derived from the system requirements and are usually defined after
the high-level system requirements are outlined. They specify the exact tasks that the software
component of the system should perform.

Types of Software Requirements

1. Functional Software Requirements:

○ Describe the individual functions or operations that the software should perform.
○ Typically represented as specific features or tasks.
○ For example: "The software should allow users to reset their passwords through
email."
2. Non-functional Software Requirements:
○ Address how the software operates rather than what it does.
○ Include criteria such as performance, security, usability, and reliability within the
software itself.
○ For example: "The software should respond to user input within 2 seconds."
3. User Interface (UI) Requirements:
○ Define how users will interact with the software and what the user interface
should look like.
○ Include layout specifications, color schemes, and accessibility standards.
○ For example: "The login screen should have a user-friendly design and comply
with WCAG 2.1 accessibility guidelines."
4. Data Requirements:
○ Specify how the software should handle, store, and manage data.
○ Include database requirements, data validation, data storage, and retrieval
mechanisms.
○ For example: "The software should store user profiles in a relational database
with encrypted passwords."
5. Error Handling Requirements:
○ Define how the software should handle errors or exceptions.
○ Describe the types of error messages, recovery actions, and logging.
○ For example: "The software should display a clear error message when a user
enters invalid input."
6. Security Requirements:
○ Specify how the software should secure data and user interactions.
○ Include encryption, access control, and secure authentication requirements.
○ For example: "The software should encrypt sensitive data using AES-256
encryption."

Importance of Software Requirements

● Guides Development and Testing: Software requirements are the foundation for
writing code and testing software functionality.
● Improves Clarity and Reduces Rework: Clearly defined software requirements reduce
misunderstandings, which can minimize costly changes later.
 ● Ensures Consistency with System Requirements: Software requirements ensure that
the software component fulfills the broader system requirements.

Key Differences between System and Software Requirements

Aspect System Requirements Software Requirements

Scope Entire system, including both Only the software component of the
hardware and software system

Detail Level High-level overview of system Detailed specifications on software

functions and constraints behavior and features

Focus Overall system performance, security, Functionality, UI, performance, and

and compatibility internal security of the software

Purpose Ensures all components of the Ensures that the software fulfills its
system work together to meet goals role in the system

Examples Performance, interoperability, and Specific software functions, user

reliability of the entire system interface, and data handling

Example Scenario: Online Banking System

Suppose we’re building an online banking system. Here’s how system and software
requirements might be defined:

● System Requirements:
○ Performance: The system should support 1,000 concurrent users.
○ Security: The system should ensure secure data transfer through SSL
encryption.
○ Interface: The system must be compatible with mobile and web platforms.
● Software Requirements (for the banking application):
○ Functional: Users should be able to view their account balance, transfer funds,
and view transaction history.
○ Non-functional: The app should respond within 3 seconds to user actions.
○ Security: The software should require two-factor authentication for logging in.
○ UI: The software should display account details in a clear, readable format.
Conclusion

System and software requirements are both essential in the software development lifecycle, but
they serve different purposes. System requirements focus on the overall structure and operation
of the entire system, ensuring that the hardware, software, and external systems all work
together effectively. Software requirements, on the other hand, are specific to the software
component, providing the detailed specifications that developers need to build the application.

Both types of requirements are crucial for guiding the development process, ensuring alignment
with business goals, and enabling effective testing and validation of the final product. Properly
defined system and software requirements set clear expectations, reduce development risks,
and contribute to a successful project outcome.