BASE ACADEMY – SOFTWARE REQUIREMENT ENGINEERING NOTES

Table of Contents
1. Introduction to Requirements Engineering
1.1 Overview of Requirements Engineering
1.2 Importance of Software Requirements
2. Software Requirements
2.1 Classification of Requirements
2.2 Requirements Process
2.3 Levels/Layers of Requirements
2.4 Requirement Characteristics
2.5 Analyzing Quality Requirements
3. Software Requirements in the Context of Systems Engineering
3.1 Requirement Evolution
3.2 Requirement Traceability
3.3 Requirement Prioritization
3.4 Trade-Off Analysis
3.5 Risk Analysis and Impact Analysis
3.6 Requirement Management
3.7 Interaction Between Requirement and Architecture
4. Requirement Elicitation
4.1 Elicitation Sources
4.2 Elicitation Techniques
5. Requirement Specification and Documentation
5.1 Specification Sources
5.2 Specification Techniques
5.3 Requirements Validation and Techniques
6. Management of Requirements
6.1 Introduction to Requirements Management
6.2 Requirements Management Problems
6.3 Managing Requirements in Various Organizations
6.3.1 Acquisition-Oriented Organizations
6.3.2 Supplier-Oriented Organizations
6.3.3 Product-Oriented Organizations
6.4 Requirements Engineering for Agile Methods
 BASE ACADEMY – SOFTWARE REQUIREMENT ENGINEERING NOTES

1. Introduction to Requirements Engineering

1.1 Overview of Requirements Engineering

What is Requirements Engineering?

Requirements Engineering (RE) is a process used in software development to identify,
understand, document, and manage what a software project needs to accomplish. It ensures that
the software serves the needs of users and stakeholders effectively.

• Key Questions it Answers:

o What should the software do?
o Who will use it?
o How will it work?

Why is Requirements Engineering Important?

• Clear Goals: Ensures everyone involved understands what the software aims to achieve.
• Avoids Errors: Reduces misunderstandings that could lead to costly mistakes.
• Saves Money: Fixing mistakes in planning is much cheaper than fixing them after development.
• Improves User Satisfaction: Ensures the software aligns with user needs.

Benefits of Requirements Engineering:

1. Better Communication: Helps developers, clients, and users stay on the same page by defining
goals clearly.
2. Higher Quality Software: Ensures the final product meets user needs and expectations.
3. Reduced Project Risks: Minimizes chances of failure by addressing issues early in the process.
4. Cost Efficiency: Saves money by avoiding unnecessary changes later in development.
5. Easier Maintenance: A clear understanding of requirements makes updates and fixes easier.

Challenges in Requirements Engineering:

1. Unclear Goals: If stakeholders are unsure of their needs, defining requirements becomes
harder.
2. Changing Requirements: Stakeholders may change their minds during the project, leading to
delays and rework.
3. Conflicting Stakeholder Interests: Different stakeholders may have opposing expectations.
 BASE ACADEMY – SOFTWARE REQUIREMENT ENGINEERING NOTES

4. Limited Resources: Time and budget constraints can make it difficult to explore all
requirements.
5. Communication Gaps: Miscommunication between teams or stakeholders can lead to
misunderstandings.

2. Software Requirements

2.1 Classification of Requirements

Here’s a deeper look at the three types of requirements:

1. Functional Requirements
o Define what actions the system should perform.
o Example: "The app must allow users to reset their password."
o Focus: Tasks, behaviors, and functions of the software.
2. Non-Functional Requirements
o Define qualities or standards the system must meet.
o Examples:
▪ Performance: "The app should load in under 2 seconds."
▪ Security: "The system should encrypt all sensitive data."
o Focus: Speed, security, user experience, scalability, etc.
3. Domain Requirements
o Special rules or constraints specific to the industry.
o Example: In banking, "All transactions must be logged and stored for 5 years."

Difference Between Functional, Non-Functional, and Domain Requirements

Functional Non-Functional
Aspect Domain Requirements
Requirements Requirements

What it Actions the system Qualities of system

Field-specific constraints
Defines performs performance

Industry rules and legal

Focus Features and tasks Speed, security, reliability
standards

Login feature, file Loads within 2 seconds, Complying with healthcare or

Example
upload encrypts data financial laws

Supports functional
Dependency Independent Tied to domain expertise
requirements
 BASE ACADEMY – SOFTWARE REQUIREMENT ENGINEERING NOTES

2.2 Requirements Process

The process of handling requirements is done step-by-step to ensure clarity and accuracy. Here
are 7 key steps:

1. Gather Requirements
o Collect all the requirements from users, stakeholders, and other sources.
o Techniques include interviews, surveys, and observation.
2. Analyze Requirements
o Check if the requirements are complete, clear, consistent, and feasible.
o Look for conflicts and resolve them early.
3. Prioritize Requirements
o Rank requirements by importance (e.g., must-have, nice-to-have).
o Focus first on critical requirements.
4. Document Requirements
o Write all requirements in a clear and detailed format, such as a Software Requirements
Specification (SRS) document.
5. Validate Requirements
o Confirm with users and stakeholders that the requirements meet their needs.
o Use prototypes or models for validation.
6. Manage Changes to Requirements
o Track and handle any changes in requirements during the project.
7. Review and Approve Requirements
o Ensure all stakeholders agree on the requirements before moving forward.

2.3 Levels/Layers of Requirements

Requirements exist at different levels to address various aspects of the system:

1. Business Requirements
o High-level goals of the organization.
o Example: "Reduce customer complaints by 20% within one year."
2. User Requirements
o What users expect from the software.
o Example: "The app should allow users to search for products by name or category."
3. System Requirements
o Detailed and technical specifications developers use to build the system.
o Example: "The app must support 10,000 users simultaneously without performance
issues."

Detailed Layers in System Requirements:

• Interface Requirements: Define how the system interacts with users or other systems.
Example: "The app must provide a search bar at the top of every page."
 BASE ACADEMY – SOFTWARE REQUIREMENT ENGINEERING NOTES

• Data Requirements: Specify how data is stored, retrieved, and managed.

Example: "User data must be stored in a relational database with encryption."
• Hardware Requirements: Include physical devices needed for the software to work.
Example: "The server must have at least 16 GB RAM and SSD storage."
• Operational Requirements: Describe the environment where the system will run.
Example: "The app should work on Android and iOS devices."

2.4 Requirement Characteristics

Good requirements must have these 10 characteristics:

1. Clear
o Use simple, unambiguous language.
o Example: Instead of "Should be fast," write "Must respond in under 1 second."
2. Complete
o Cover every detail.
o Example: Include what happens during errors or failures.
3. Consistent
o No contradictions within requirements.
o Example: If one requirement says "Free user accounts," another shouldn’t say "All
accounts must be paid."
4. Feasible
o Must be achievable with available resources.
5. Testable
o Should be easy to check if it is met.
o Example: "The system must support 100 users at once" can be tested, but "The system
should be user-friendly" is vague.
6. Prioritized
o Clearly indicate importance.
o Example: Mark "Critical," "Important," or "Optional."
7. Traceable
o Must show a clear connection between the requirement and its source.
8. Adaptable/Changeable
o Should allow modifications if needed.
9. Manageable
o Easy to organize, monitor, and control.
o Example: Use tools like JIRA or Trello to track requirement progress.
10. Verifiable

• Can be proven to work with real tests.

• Example: Write acceptance criteria for each requirement.
 BASE ACADEMY – SOFTWARE REQUIREMENT ENGINEERING NOTES

2.5 Analyzing Quality Requirements

Quality requirements ensure the software performs well and meets users’ expectations. Let’s
analyze each point in detail:

1. Performance:
o How fast should the system respond?
o Example: "The system should process up to 1,000 transactions per second."
2. Usability:
o Is the system easy to use?
o Example: "The interface should guide users with tooltips and clear labels."
3. Reliability:
o How stable is the system?
o Example: "The system should be operational 99.9% of the time."
4. Scalability:
o Can the system grow as user demand increases?
o Example: "The system should support up to 1 million users without performance
issues."
5. Security:
o Is the system safe from threats?
o Example: "All user data should be encrypted using AES-256."
6. Maintainability:
o How easy is it to fix bugs or add new features?
o Example: "The system should allow updates without downtime."
7. Interoperability:
o Can it work well with other systems?
o Example: "The software should integrate with popular payment gateways like PayPal."

Additional Techniques for Requirements

1. Workshops:
o Group discussions to gather and refine requirements.
2. Prototyping:
o Creating a simple version of the system to gather feedback.
3. Observation:
o Watching users perform tasks to understand their needs.
4. Brainstorming:
o Generating ideas as a group to identify requirements.
5. Questionnaires/Surveys:
o Asking users and stakeholders questions to collect requirements.
6. Use Case Modeling:
o Writing scenarios that describe how users will interact with the system.
 BASE ACADEMY – SOFTWARE REQUIREMENT ENGINEERING NOTES

3. Software Requirements in the Context of Systems Engineering

In systems engineering, software requirements play a crucial role in guiding the design and
development of software. These requirements ensure that the software will integrate seamlessly
into the larger system and meet user needs. Here, we explore various aspects of software
requirements in the context of systems engineering.

3.1 Requirement Evolution

Requirements evolve over time, which means that they can change as the project progresses, due
to shifting business needs, new technology, or user feedback. Managing this evolution properly
ensures the final product remains aligned with current goals and needs.

Subtopics in Requirement Evolution:

1. Why Requirements Evolve:

o New Information: As the project advances, more details become clear, which may lead
to changes in the requirements.
o Shifting Business Needs: The priorities of the business or users may change, affecting
the direction of the project.
o Technological Advancements: New technologies may offer better solutions, requiring
changes in requirements to take advantage of them.
o User Feedback: As users interact with prototypes or early versions of the software, they
may request changes or improvements.
2. Managing Requirement Evolution:
o Change Control: Ensure changes are documented and agreed upon by all stakeholders.
o Traceability: Keep track of how requirements evolve over time to maintain clarity and
consistency.
o Communication: Regular meetings and updates ensure that everyone understands the
evolving requirements.

3.2 Requirement Traceability

Requirement traceability involves tracking each requirement throughout its life cycle—from its
origin to its implementation and verification. This process ensures that each requirement is
accounted for and properly linked to its source.
 BASE ACADEMY – SOFTWARE REQUIREMENT ENGINEERING NOTES

Subtopics in Requirement Traceability:

1. Why Traceability is Important:

o Clear Links to Stakeholder Needs: Ensures that the software delivers what users and
stakeholders need.
o Verifying Coverage: Helps verify that all requirements are addressed during
development and testing.
o Change Management: When changes occur, traceability helps understand their impact
on the system and ensures consistency.
2. Types of Traceability:
o Forward Traceability: Tracks how each requirement influences design, coding, testing,
and validation.
o Backward Traceability: Tracks where each requirement originated from, ensuring it is
linked to stakeholder goals or business needs.
o Bidirectional Traceability: Combines both forward and backward traceability, ensuring
that requirements are both implemented and linked to the initial goals.
3. Tools for Traceability:
o Requirement Management Tools: Software like JIRA, IBM Rational DOORS, or Trello
help track requirements and their connections to other project components.
o Documentation: Manual methods of traceability, such as spreadsheets or traceability
matrices, can also be used to track requirements.

3.3 Requirement Prioritization

Not all requirements are of equal importance. Prioritization ensures that critical requirements are
addressed first, helping to allocate time and resources efficiently.

Subtopics in Requirement Prioritization:

1. Methods of Prioritization:
o MoSCoW Method: Categorizes requirements into Must-have, Should-have, Could-have,
and Won’t-have. This helps in focusing on essential features first.
o Kano Model: Classifies requirements into Basic, Performance, and Excitement factors to
understand which features are essential and which will delight users.
o Cost-Benefit Analysis: Weighs the cost of implementing a requirement against the
benefits it will provide.
o Stakeholder Voting: Gets input from stakeholders on which features are most
important to them.
2. Benefits of Prioritization:
o Ensures Timely Delivery: Focuses on critical requirements to ensure the project stays on
schedule.
o Optimizes Resource Allocation: Helps ensure resources are used on the most valuable
features.
o Reduces Risks: Prioritizing requirements ensures the most crucial features are
addressed first, reducing the risk of missing out on important functionality.
 BASE ACADEMY – SOFTWARE REQUIREMENT ENGINEERING NOTES

3.4 Trade-Off Analysis

Trade-off analysis is the process of comparing different options to make informed decisions
when faced with conflicting requirements or limitations.

Subtopics in Trade-Off Analysis:

1. When to Use Trade-Off Analysis:

o When requirements are in conflict with one another (e.g., performance versus cost).
o When the resources (time, money, manpower) are limited.
o When stakeholders have differing opinions on how to approach a requirement.
2. Steps in Trade-Off Analysis:
o Identify the Trade-Offs: List the conflicting requirements or constraints.
o Analyze the Impact: Assess how each option affects the overall system and goals.
o Make a Decision: Choose the option that best aligns with the project’s priorities, taking
into account the available resources and stakeholders’ needs.
3. Example of a Trade-Off Analysis:
o Scenario: A feature requires high performance, but adding it could delay the project or
increase costs. The team might trade off some functionality to maintain the project’s
timeline and budget.

3.5 Risk Analysis and Impact Analysis

Risk analysis helps identify potential problems early in the project, while impact analysis helps
understand the effects of changes in requirements or the system.

Subtopics in Risk Analysis and Impact Analysis:

1. Risk Analysis:
o Identifying Risks: Recognize potential risks like unclear requirements, changing
technology, or resource constraints.
o Assessing Risk Impact: Evaluate how these risks might affect the project (e.g., cost,
time, user satisfaction).
o Mitigation Strategies: Plan actions to reduce or avoid risks, such as adding buffers in the
schedule or using alternative technologies.
2. Impact Analysis:
o Assessing Changes: When a requirement changes, impact analysis helps understand
how that change will affect other parts of the project (e.g., design, cost, schedule).
o Example: A change in a requirement for a mobile app may affect its design, user
interface, and user experience.
3. Risk and Impact Management:
o Contingency Planning: Create backup plans for risks that are identified.
 BASE ACADEMY – SOFTWARE REQUIREMENT ENGINEERING NOTES

o Constant Monitoring: Continuously monitor and reassess risks and impacts throughout
the project’s lifecycle.

3.6 Requirement Management

Requirement management is the ongoing process of ensuring that all requirements are tracked,
updated, and met throughout the software development life cycle.

Subtopics in Requirement Management:

1. Managing Requirements Over Time:

o Documentation: Properly document requirements so they can be referred to during all
project stages.
o Version Control: Keep track of changes and updates to requirements to maintain a clear
project history.
o Change Management: Handle modifications to requirements by assessing their impact
and keeping stakeholders informed.
2. Tools for Requirement Management:
o Software Tools: Tools like JIRA, Confluence, or Microsoft Excel can help track, update,
and manage requirements throughout the project.
o Manual Methods: In small projects, spreadsheets or simple documents may be used to
manage requirements effectively.
3. Challenges in Requirement Management:
o Changing Stakeholder Needs: Stakeholders may revise their requirements during the
project, making it difficult to keep up.
o Scope Creep: The project scope may increase unexpectedly, leading to difficulties in
managing and tracking new requirements.

3.7 Interaction Between Requirement and Architecture

The relationship between requirements and the software architecture is crucial for ensuring that
the system is both functional and feasible.

Subtopics in Interaction Between Requirement and Architecture:

1. Requirements Influence Architecture:

o Functional Requirements: These directly affect how the system is designed (e.g., adding
a login feature will impact security architecture).
o Non-Functional Requirements: These impact the overall system performance, such as
scalability, security, or availability (e.g., requiring the system to support 1,000 users at
once).
 BASE ACADEMY – SOFTWARE REQUIREMENT ENGINEERING NOTES

2. Architecture Affects Requirements:

o Technical Constraints: The architecture might place limitations on what can be done,
forcing adjustments in requirements (e.g., a mobile app’s architecture may limit the
number of features it can support).
o Design Choices: Certain design choices may require specific changes in requirements
(e.g., choosing a cloud-based solution may require the system to be available at all
times).
3. Best Practices:
o Early Involvement of Architects: Architects should be involved in defining requirements
to ensure that the system architecture is feasible and aligned with the requirements.
o Regular Reviews: Periodically review the architecture and requirements to ensure that
they are still aligned.

4. Requirement Elicitation

Requirement elicitation is the process of gathering the needs and expectations of stakeholders,
including users, clients, and other people involved in the project. This is one of the first and most
important steps in the software development process because it ensures the software meets the
right goals and fulfills the necessary functions. Eliciting good requirements helps avoid problems
later in the project.

In this section, we’ll explore the sources from which requirements can be gathered (Elicitation
Sources) and the techniques used to gather them (Elicitation Techniques).

4.1 Elicitation Sources

Elicitation sources refer to where the information for the software requirements comes from.
These sources help you understand what stakeholders need and expect from the system. They are
the people, documents, or processes that can provide important insights.

Subtopics in Elicitation Sources:

1. Stakeholders:
o Definition: Stakeholders are people or groups that have an interest in the project. This
includes users, customers, developers, business managers, and even external groups
like regulatory bodies.
o Examples:
▪ End Users: People who will actually use the software, and whose needs should
be the primary focus.
▪ Customers: People or companies that commission the project and pay for its
development.
 BASE ACADEMY – SOFTWARE REQUIREMENT ENGINEERING NOTES

▪ Regulatory Authorities: Government bodies that may set legal standards for the
software (e.g., data privacy laws).
o Why Important: Stakeholders provide first-hand knowledge about what the software
needs to do, what they expect, and what limitations exist.
2. Existing Documentation:
o Definition: Existing documentation includes any documents that have already been
written about the system, such as project charters, business plans, or any previous
versions of the software.
o Examples:
▪ Business Plans: They often contain strategic goals, objectives, and business
needs.
▪ Old Software Specifications: If you're updating or upgrading software, previous
requirements may provide a starting point.
▪ Regulatory Documents: Legal or industry standards that the software must
comply with.
o Why Important: This documentation often has useful information and can save time,
especially when modifying existing systems or ensuring compliance.
3. Observations:
o Definition: Observing how users perform their tasks can help gather important
requirements by seeing how the current system (if any) works in real life.
o Examples:
▪ Watching Users: Observing how end users work with the existing software or
manual processes can help you identify what works well and what needs
improvement.
▪ Shadowing Employees: Following employees in their daily work to understand
how a new system can make their tasks easier.
o Why Important: It provides real-world insights that stakeholders may not express
directly.
4. Surveys and Questionnaires:
o Definition: Asking users or stakeholders to fill out forms or answer questions can help
collect their opinions and preferences.
o Examples:
▪ Online Surveys: Asking users to rate their current experience and provide
suggestions for new features.
▪ Questionnaires: Structured questions that allow for detailed responses about
user needs.
o Why Important: They help gather input from a large number of people in a quick and
structured manner.
5. Workshops and Focus Groups:
o Definition: These are group discussions where stakeholders discuss and clarify their
needs and expectations for the software.
o Examples:
▪ Workshops: Facilitated sessions where users and stakeholders come together to
define requirements, brainstorm ideas, and discuss problems.
▪ Focus Groups: Small groups of users or stakeholders are gathered to talk about
their needs and reactions to the proposed system.
 BASE ACADEMY – SOFTWARE REQUIREMENT ENGINEERING NOTES

o Why Important: These collaborative sessions encourage brainstorming and help clarify
any unclear or conflicting requirements.
6. Competitor Systems and Market Research:
o Definition: Looking at similar systems in the market can provide ideas on what features
and functions your software should have.
o Examples:
▪ Competitor Analysis: Reviewing what similar software applications do and
seeing what works well or what can be improved.
▪ Market Research: Gathering information on trends, customer preferences, and
technology that might influence your project.
o Why Important: Provides insights into user expectations and industry standards.

4.2 Elicitation Techniques

Elicitation techniques are methods used to gather the requirements from the identified sources.
These techniques help ensure the collected requirements are complete, clear, and actionable.

Subtopics in Elicitation Techniques:

1. Interviews:
o Definition: One-on-one conversations with stakeholders to gather detailed information
about their needs.
o Types:
▪ Structured Interviews: Follow a fixed set of questions to ensure consistency
across different interviews.
▪ Unstructured Interviews: More flexible, where the interviewer explores topics
as they arise.
o Why Important: They allow for in-depth understanding and clarification of stakeholder
needs.
o How to Use: Prepare a list of questions but be ready to explore responses in more
detail.
2. Brainstorming:
o Definition: A group activity where participants come up with ideas and solutions to
problems without worrying about limitations or feasibility.
o Why Important: Encourages creativity and allows for a wide range of ideas to be
generated quickly.
o How to Use: Gather a team of stakeholders, set a topic, and let everyone share their
thoughts freely. Afterward, evaluate and prioritize the ideas.
3. Use Case Modeling:
o Definition: Creating scenarios or stories to describe how users will interact with the
system. It helps to define functional requirements.
o Why Important: Use cases are easy to understand and describe specific system actions
based on real user interactions.
o How to Use: Write down a series of steps that show how users will perform tasks using
the system, such as logging in or submitting a form.
 BASE ACADEMY – SOFTWARE REQUIREMENT ENGINEERING NOTES

4. Prototyping:
o Definition: Building a simple version (or prototype) of the system to gather feedback
from stakeholders.
o Why Important: Stakeholders can interact with the prototype and provide real-time
feedback, which helps refine requirements.
o How to Use: Develop a basic version of the system or feature, share it with
stakeholders, and gather their feedback on its design and functionality.
5. Observation (Job Shadowing):
o Definition: Observing how users perform their tasks can uncover hidden needs that
users might not directly express.
o Why Important: It reveals how users behave and interact with the current system,
providing insights that may not be captured in interviews.
o How to Use: Spend time with the user, watch them perform their tasks, and take notes
on how they interact with the existing system or process.
6. Document Analysis:
o Definition: Reviewing existing documentation (e.g., system manuals, business plans,
process descriptions) to identify requirements.
o Why Important: It’s a quick way to gather historical or background information on a
system, especially when updating existing software.
o How to Use: Go through the available documents to identify requirements or business
rules that are relevant to the new system.
7. Surveys and Questionnaires:
o Definition: These are structured forms that collect information from a large number of
people.
o Why Important: Helps gather input from many stakeholders quickly and in a structured
manner.
o How to Use: Distribute the survey/questionnaire and analyze the responses to identify
common requirements or preferences.
8. Workshops:
o Definition: Group discussions where stakeholders come together to clarify and define
requirements.
o Why Important: It fosters collaboration, reduces misunderstandings, and ensures
alignment among different stakeholders.
o How to Use: Plan and facilitate discussions to get input from users, business
representatives, and technical teams.
9. Focus Groups:
o Definition: A small group of users or stakeholders discuss their needs and expectations
in a controlled setting.
o Why Important: It provides a deeper understanding of user needs and their reactions to
ideas or concepts.
o How to Use: Select a group of representative stakeholders, ask open-ended questions,
and record feedback.
 BASE ACADEMY – SOFTWARE REQUIREMENT ENGINEERING NOTES

5. Requirement Specification and Documentation

Requirement specification and documentation is the process of clearly defining and recording the
requirements that the system should meet. Proper specification is essential because it provides a
clear and detailed description of what the software is expected to do. This ensures all
stakeholders understand the goals and features of the software and helps avoid mistakes,
miscommunications, or unmet expectations later in the project.

5.1 Specification Sources

Specification sources are where you get the details to create your requirements specification.
These sources are crucial because they provide the information needed to ensure the software
will meet its objectives.

Subtopics in Specification Sources:

1. Stakeholders:
o Definition: These are the people who have a stake in the project’s success, such as
users, clients, and developers. Their needs and expectations form the foundation of the
specifications.
o Examples:
▪ End Users: Who will directly use the system.
▪ Customers: Those who requested or funded the project.
▪ Regulatory Bodies: Organizations that set standards that the system must meet.
2. Business Documents:
o Definition: These include documents such as business plans, project charters, and
contracts that outline the project’s goals, objectives, and constraints.
o Examples:
▪ Business Objectives: High-level goals the project should achieve, such as
improving customer satisfaction.
▪ Contracts: Agreements between the client and developers that outline the
system’s deliverables.
3. System and Software Documentation:
o Definition: This includes any previous or related documents from current or past
systems that provide insight into how the system should behave.
o Examples:
▪ Existing System Manuals: Useful for software updates or when improving an
existing system.
▪ Technical Specifications: Detailed descriptions of technical requirements and
standards.
4. User Feedback:
o Definition: Direct input from users and stakeholders gathered through surveys,
interviews, or workshops. This helps ensure the system is user-friendly and meets their
needs.
o Examples:
 BASE ACADEMY – SOFTWARE REQUIREMENT ENGINEERING NOTES

▪ Surveys: Gather feedback from a broad group of users about their needs and
challenges.
▪ Interviews: Direct conversations to understand specific user needs.

5.2 Specification Techniques

Specification techniques are methods used to organize and document requirements in a clear and
understandable way. Good specification techniques ensure that requirements are accurate, easy
to follow, and testable.

Subtopics in Specification Techniques:

1. Use Case Descriptions:

o Definition: Use cases describe how the system will interact with users to achieve
specific goals.
o Why Important: They help stakeholders visualize the user experience and the system's
behavior.
o How to Use: Write scenarios or steps showing how a user interacts with the system.
Example: A use case might describe a user logging into the system, entering their
credentials, and accessing their account.
2. User Stories:
o Definition: A user story is a simple description of a feature from the user’s perspective.
o Why Important: User stories are easy to understand and allow for a clear focus on user
needs.
o How to Use: Write a short sentence: “As a [type of user], I want to [perform an action]
so that I can [achieve a goal].” Example: "As a shopper, I want to filter products by price
so that I can find affordable options."
3. Wireframes and Prototypes:
o Definition: Wireframes are simple drawings of the interface, while prototypes are early
versions of the system that can be tested by users.
o Why Important: These visual tools help clarify how the system will look and function,
making it easier for users and developers to understand requirements.
o How to Use: Sketch the layout of the interface (wireframe) or create a working model
(prototype) to test and refine requirements.
4. Requirements Traceability Matrix:
o Definition: A document that links requirements to specific parts of the system, helping
ensure that every requirement is met during development.
o Why Important: It ensures that all requirements are covered and allows you to track the
progress of each one.
o How to Use: Create a table that lists each requirement and maps it to the corresponding
part of the design or testing process.
5. Data Flow Diagrams (DFDs):
o Definition: DFDs visually represent how data moves within the system.
o Why Important: They help clarify how the system will process and use data, making it
easier to understand the system’s functionality.
 BASE ACADEMY – SOFTWARE REQUIREMENT ENGINEERING NOTES

o How to Use: Draw diagrams that show where data comes from, how it moves, and
where it goes within the system.

5.3 Requirements Validation and Techniques

Requirements validation ensures that the documented requirements accurately reflect the needs
of the stakeholders and that they are feasible and clear. Validating requirements helps avoid
costly mistakes later in the project.

Subtopics in Requirements Validation:

1. Reviewing Requirements with Stakeholders:

o Definition: Regularly reviewing the documented requirements with stakeholders to
confirm that they accurately capture what is needed.
o Why Important: It ensures that any misunderstandings or missing requirements are
identified early.
o How to Use: Schedule meetings with stakeholders to go through the requirements and
get their feedback.
2. Prototyping:
o Definition: Creating a working model of the system to help validate requirements by
showing stakeholders what the system will look like and how it will work.
o Why Important: It allows stakeholders to see the system in action and confirm that the
requirements are correct.
o How to Use: Develop a simple version of the system or key features and present it to
stakeholders for feedback.
3. Modeling and Simulation:
o Definition: Creating models or simulations of the system to visualize how it will function
and verify that it meets the requirements.
o Why Important: It allows stakeholders to test out features and identify any issues
before development begins.
o How to Use: Create detailed models, such as flowcharts or simulations, and ask
stakeholders to interact with them to identify any discrepancies.
4. Test Case Development:
o Definition: Writing test cases based on the requirements to ensure the system meets
the documented needs.
o Why Important: It helps ensure that the system will be tested properly and that it
meets all the requirements.
o How to Use: Develop test cases that match each requirement, and use them to check
the system during development.
5. Walkthroughs and Inspections:
o Definition: A formal review process where team members go through the requirements
in detail to identify errors, ambiguities, or missing information.
o Why Important: It provides a systematic approach to catch problems early.
o How to Use: Organize a session where team members read through each requirement
and discuss potential issues.
 BASE ACADEMY – SOFTWARE REQUIREMENT ENGINEERING NOTES

6. Consistency Checks:
o Definition: Verifying that the requirements do not contradict each other and that they
are consistent with the overall system goals.
o Why Important: Conflicting requirements can lead to confusion and wasted effort.
o How to Use: Go through the requirements carefully to check for contradictions and
resolve any issues.

6. Management of Requirements

Requirements management is the process of managing and controlling requirements throughout

the lifecycle of a software project. It involves activities such as tracking changes, ensuring
alignment with business goals, prioritizing requirements, and maintaining clear communication
with stakeholders. Proper management helps in avoiding confusion and delays, and ensures that
the software delivers what it was intended to.

6.1 Introduction to Requirements Management

Requirements management is the practice of organizing, tracking, and controlling requirements

throughout the project. It ensures that all requirements are accurately captured, clearly
documented, and updated whenever changes occur. This process is crucial because requirements
can evolve over time as new information becomes available or as the project progresses.

Key Activities in Requirements Management:

1. Tracking Requirements: Ensure that each requirement is tracked from its inception through to
its implementation, testing, and final delivery.
2. Managing Changes: Handle any changes in requirements, ensuring they are carefully reviewed,
communicated, and documented.
3. Prioritizing Requirements: Determine which requirements are the most critical and should be
addressed first.
4. Validation and Verification: Regularly check that requirements are still relevant and feasible,
and validate them against the stakeholders’ needs.

Tools for Requirements Management:

• Requirements Management Software: Tools like JIRA, Trello, or specialized software such as
IBM Engineering Requirements Management can help manage and track requirements.
• Traceability Matrix: This is a document that links requirements to specific parts of the system,
ensuring that all requirements are addressed.
 BASE ACADEMY – SOFTWARE REQUIREMENT ENGINEERING NOTES

6.2 Requirements Management Problems

While managing requirements, several common problems can arise. Addressing these issues
early on can prevent project delays and cost overruns.

Common Problems in Requirements Management:

1. Ambiguity in Requirements:
o Description: Requirements that are unclear or vague can lead to confusion and errors.
o Solution: Use clear, simple language and involve stakeholders in the clarification
process.
2. Changing Requirements:
o Description: Requirements often change during the project, which can cause scope
creep (uncontrolled changes or continuous growth).
o Solution: Implement a change control process to track and approve changes.
3. Incomplete Requirements:
o Description: Missing or incomplete requirements can cause delays or lead to system
flaws.
o Solution: Ensure that all aspects of the system are covered in the requirements, and
regularly validate them with stakeholders.
4. Conflicting Requirements:
o Description: Requirements that contradict each other can lead to confusion about how
the system should behave.
o Solution: Regularly review requirements for conflicts and resolve them before
development begins.
5. Lack of Communication:
o Description: Poor communication between stakeholders, developers, and users can lead
to misunderstandings.
o Solution: Regular meetings, reviews, and feedback loops should be set up to keep
everyone informed.

6.3 Managing Requirements in Various Organizations

Different types of organizations have different approaches to managing requirements based on

their goals, structure, and the role they play in the supply chain. Understanding these different
approaches can help in tailoring the requirements management process to fit the specific needs of
an organization.

6.3.1 Acquisition-Oriented Organizations

Acquisition-oriented organizations are typically the ones purchasing software or systems from
suppliers. These organizations focus on acquiring products that meet specific requirements and
standards.
 BASE ACADEMY – SOFTWARE REQUIREMENT ENGINEERING NOTES

Key Characteristics of Acquisition-Oriented Organizations:

• Primary Focus: Selecting a solution that fits the organizational needs.

• Requirements Management Approach: The organization typically focuses on defining very
clear, specific requirements for the product to ensure it meets their needs.
• Example: A government agency looking to acquire a new software system may have strict,
detailed requirements to ensure compliance with regulations and standards.

Key Activities for Managing Requirements:

1. Defining Clear, Detailed Requirements: Specifying what the system should do and what
standards it must meet.
2. Selecting Vendors: Managing the process of evaluating and choosing suppliers who can meet
these requirements.
3. Contract Management: Ensuring that the final product matches the agreed-upon requirements.

6.3.2 Supplier-Oriented Organizations

Supplier-oriented organizations are the ones developing or supplying systems to customers. They
focus on creating and delivering products that meet the requirements set by their clients.

Key Characteristics of Supplier-Oriented Organizations:

• Primary Focus: Delivering a product that meets the requirements of the client.
• Requirements Management Approach: These organizations manage both customer
requirements and internal constraints (technical limitations, resources, etc.).
• Example: A software development company creating a mobile app for a client.

Key Activities for Managing Requirements:

1. Client Requirements Analysis: Understanding the client’s needs and translating them into clear,
actionable requirements.
2. Internal Team Coordination: Managing communication within the development team to ensure
they understand and meet the requirements.
3. Delivering and Testing: Ensuring the product matches the requirements during testing phases.

6.3.3 Product-Oriented Organizations

Product-oriented organizations focus on creating and selling products to a broad market, often
with generic features that cater to multiple customers.
 BASE ACADEMY – SOFTWARE REQUIREMENT ENGINEERING NOTES

Key Characteristics of Product-Oriented Organizations:

• Primary Focus: Building a product with broad market appeal, potentially with customization
options for clients.
• Requirements Management Approach: Balancing the needs of different customers while
maintaining a standard product offering.
• Example: A company that develops and sells a customer relationship management (CRM)
software to multiple clients.

Key Activities for Managing Requirements:

1. Market Research: Identifying the most common needs across customers.

2. Feature Prioritization: Determining which features to prioritize based on market demand.
3. Managing Product Lifecycle: Tracking how product requirements evolve over time and ensuring
updates meet customer expectations.

6.4 Requirements Engineering for Agile Methods

Agile methods are increasingly used for software development, and requirements engineering
must adapt to the flexible, iterative nature of Agile projects. In Agile, requirements are more
fluid and evolve over time through collaboration between developers, users, and stakeholders.

Key Concepts in Agile Requirements Engineering:

1. User Stories: Agile often uses "user stories" to describe the system’s functionality from
the perspective of the end-user. These are short, simple descriptions of what the user
wants to achieve.
o Example: "As a user, I want to be able to log in with my social media account to simplify
the login process."
2. Continuous Collaboration: Agile projects rely on continuous feedback from users and
stakeholders to refine and adjust requirements throughout the project.
3. Prioritization: In Agile, requirements are prioritized based on business value and the
customer’s needs, ensuring that the most important features are delivered first.
4. Iterative Development: Requirements are revisited and refined in each iteration of the
development cycle, allowing for flexibility and improvement.
5. Sprint Planning: In Agile, requirements are broken down into manageable pieces that
can be developed and tested during sprints (short development cycles, usually lasting 1-4
weeks).
6. Backlog Management: The product backlog is a prioritized list of all the user stories and
requirements that need to be developed and delivered in the project.

Challenges in Agile Requirements Engineering:

1. Scope Creep: Due to the evolving nature of requirements, there is a risk of the project’s scope
expanding without proper control.
 BASE ACADEMY – SOFTWARE REQUIREMENT ENGINEERING NOTES

2. Unclear Requirements: Since Agile emphasizes flexibility, some requirements may be vague or
not fully defined at the start.
3. Stakeholder Involvement: Continuous collaboration requires frequent involvement from
stakeholders, which can be challenging to coordinate.

Best Practices in Agile Requirements Engineering:

1. Frequent Communication: Regular meetings and reviews with stakeholders to ensure everyone
is aligned.
2. Clear Prioritization: Ensure that the most important requirements are addressed first.
3. Flexibility: Be prepared to adjust and refine requirements as the project evolves and new
insights emerge.

SUMMARY

• Overview of Requirements Engineering: The process of defining, documenting, and

managing software requirements.
• Importance of Software Requirements: Ensures software meets user needs, quality
standards, and project goals.
• Classification of Requirements:
o Functional Requirements (Describe the behavior and functions of the system).
o Non-Functional Requirements (Specify system attributes like performance,
security, and usability).
o Domain-Specific Requirements (Requirements specific to the domain or
industry).
• Requirements Process: The steps from gathering to validation of requirements.
• Levels/Layers of Requirements:
o High-Level Requirements (Broad business or stakeholder needs).
o System-Level Requirements (Specifications for the system as a whole).
o Detailed (Software) Requirements (Precise technical specifications for
development).
• Requirement Characteristics: Requirements should be clear, consistent, feasible, and
verifiable.
• Analyzing Quality Requirements: Focus on performance, security, usability, etc.
• Requirement Evolution: Requirements may change over time due to new needs or
technology changes.
• Requirement Traceability: Tracking requirements from origin through to
implementation.
• Requirement Prioritization: Determining which requirements are most important or
urgent.
• Trade-Off Analysis: Balancing competing requirements (e.g., cost vs. functionality).
• Risk Analysis and Impact Analysis: Identifying potential risks and the impact of
changes.
 BASE ACADEMY – SOFTWARE REQUIREMENT ENGINEERING NOTES

• Requirement Management: Keeping track of changes, dependencies, and versions.

• Interaction Between Requirement and Architecture: How requirements influence
system architecture and vice versa.
• Elicitation Sources: Stakeholders, documents, existing systems, and market analysis.
• Elicitation Techniques: Interviews, surveys, workshops, observation, brainstorming.
• Specification Sources: User stories, use cases, prototypes, and documentation from
stakeholders.
• Specification Techniques: Natural language, formal specification, and models (e.g.,
UML).
• Requirements Validation and Techniques: Ensuring that requirements are correct and
complete, techniques include reviews, inspections, and testing.
• Introduction to Requirements Management: The process of organizing and controlling
requirements throughout the project.
• Requirements Management Problems: Issues include scope creep, unclear
requirements, and stakeholder disagreement.
• Managing Requirements in Various Organizations:
o Acquisition-Oriented Organizations (Focus on acquiring systems from
vendors).
o Supplier-Oriented Organizations (Focus on developing systems for external
customers).
o Product-Oriented Organizations (Focus on developing products for a market).
• Requirements Engineering for Agile Methods: Incorporates flexibility and iterative
development, focusing on user stories and evolving requirements.

IMPORTANT QUESTIONS

1. What is Requirements Engineering?

2. Why are software requirements important?
3. What are the different classifications of requirements?
4. What is the requirements process?
5. What are the levels/layers of requirements?
6. What are the characteristics of good requirements?
7. How do you analyze quality requirements?
8. What is requirement evolution?
9. What is requirement traceability?
10.How do you prioritize requirements?
11.What is trade-off analysis in requirements engineering?
12.What is risk analysis and impact analysis in requirements engineering?
13.How is requirement management carried out?
14.How do requirements interact with system architecture?
15.What are the different sources of requirement elicitation?
 BASE ACADEMY – SOFTWARE REQUIREMENT ENGINEERING NOTES

16.What are the various techniques for requirement elicitation?

17.How are requirements validated?
18.How are requirements managed in acquisition-oriented organizations?
19.How are requirements managed in supplier-oriented organizations?
20.How are requirements managed in product-oriented organizations?
21.How does requirements engineering apply to Agile methods?
22.What are the steps involved in the requirements process?
23.How do you handle conflicting requirements from different stakeholders?
24.What is the importance of clear and consistent requirements?
25.How do you ensure the completeness and correctness of requirements?

SCENARIO BASED QUESTIONS

1. Traceability Matrix Construction

Scenario: You have the following software requirements and associated test cases for a
new application:
o Requirements:
R1: User login
R2: Password reset
R3: View user profile
R4: Search functionality
R5: Edit user details
o Test Cases:
TC1: Test valid login
TC2: Test invalid login
TC3: Test password reset
TC4: Test user profile view
TC5: Test profile update
TC6: Test search functionality
TC7: Test edit user profile

Task: Create a traceability matrix that links each requirement to the corresponding test
cases.

2. Requirement Prioritization
Scenario: You are working on a software project with the following requirements and
their respective business value (on a scale of 1 to 10):
o R1: User login (Business Value: 9)
o R2: Password reset (Business Value: 6)
o R3: Search functionality (Business Value: 8)
 BASE ACADEMY – SOFTWARE REQUIREMENT ENGINEERING NOTES

o R4: View user profile (Business Value: 7)

o R5: Edit user details (Business Value: 5)

Task: Rank these requirements based on their business value and justify the prioritization
order. Assume that the higher the value, the higher the priority.

3. Risk Analysis and Impact Assessment

Scenario: A project has the following requirements and associated risks:
o R1: User login (Risk Probability: 0.3, Impact: 8)
o R2: Password reset (Risk Probability: 0.5, Impact: 6)
o R3: Search functionality (Risk Probability: 0.2, Impact: 7)
o R4: View user profile (Risk Probability: 0.4, Impact: 5)
o R5: Edit user details (Risk Probability: 0.6, Impact: 9)

Task: Calculate the risk score for each requirement (Risk Score = Probability * Impact)
and identify the most risky requirement based on the highest risk score.

4. Requirements Elicitation with Techniques

Scenario: A team gathered 50 requirements using three different elicitation techniques:
o Interviews: 15 requirements
o Surveys: 20 requirements
o Workshops: 15 requirements

Task: Calculate the percentage of requirements gathered by each technique and

determine which technique was the most effective in gathering requirements.

5. Requirement Traceability Matrix Calculation

Scenario: You are managing a project with the following requirements and corresponding
design components:
o Requirements:
R1: User login
R2: Password reset
R3: Search functionality
R4: View user profile
R5: Edit user details
o Design Components:
D1: Authentication module
D2: Profile management module
D3: Search module

Task: Create a requirement traceability matrix that links each requirement to the design
components that fulfill them. Also, indicate if any design component serves multiple
requirements.

These scenarios should provide a more practical application for creating traceability matrices,
performing risk analysis, and prioritizing requirements.
BASE ACADEMY – SOFTWARE REQUIREMENT ENGINEERING NOTES