Requirements Engineering

Introduction and Context

Requirements engineering is the systematic process of discovering, analyzing, documenting, validating, prioritizing, and managing the services and constraints that a software system must provide. It connects stakeholder needs with technical design and implementation. A software product may be well programmed and still fail if it solves the wrong problem, omits essential capabilities, performs inadequately, or violates legal and organizational constraints.

Requirements engineering is therefore not a single activity performed before coding. It is a continuing discipline that begins when a problem or opportunity is identified and continues throughout development, operation, maintenance, and replacement. Requirements may change because users learn more about their needs, business policies change, regulations are introduced, technology evolves, or previously hidden assumptions are discovered.

A requirement should communicate a needed capability, quality, condition, or constraint clearly enough that stakeholders and developers can reach a shared interpretation. This does not mean that every requirement must be expressed in technical language. In fact, requirements are often best expressed in the language of users and business stakeholders, supported by models, examples, prototypes, and measurable acceptance criteria.

Learning Objectives

After studying this chapter, you should be able to:

• distinguish functional requirements from non-functional requirements and constraints;
• identify stakeholders and select suitable elicitation techniques;
• analyze requirements for feasibility, conflict, ambiguity, and completeness;
• express requirements using user stories, use cases, scenarios, and acceptance criteria;
• prioritize requirements using transparent professional methods;
• validate requirements against quality criteria;
• use prototypes and models to clarify uncertain requirements;
• construct and use a requirements traceability matrix;
• manage changes through impact analysis, versioning, and change control; and
• recognize ethical, legal, security, accessibility, and privacy responsibilities in requirements work.

The Nature and Classification of Requirements

A requirement may be viewed from several perspectives. A business requirement states an organizational objective, such as reducing the time needed to process applications. A user requirement describes a capability needed by a particular user group, such as allowing an applicant to submit documents online. A system requirement provides a detailed, testable statement of what the system shall do or the conditions it shall satisfy.

Functional requirements

Functional requirements describe services, behaviors, inputs, outputs, and responses to events. Examples include:

• The system shall allow a registered customer to reset a forgotten password.
• The system shall calculate the invoice total from item prices, quantities, taxes, and discounts.
• When payment is approved, the system shall issue a receipt by email.

A functional requirement normally identifies an actor, an action or system response, relevant data, and conditions or business rules. It should also indicate exceptional situations where appropriate.

Non-functional requirements

Non-functional requirements specify qualities, constraints, or conditions rather than particular business functions. Common categories include:

Non-functional requirements are often system-wide. A weak statement such as “the system must be fast” is not testable. A stronger statement identifies a measurable condition, population, workload, and measurement method. Performance requirements should state the relevant transaction, percentile or threshold, workload, environment, and test method. Availability requirements should define the measurement period and exclusions.

Constraints and assumptions

A constraint restricts possible solutions. Examples include the mandated use of a particular database, compliance with a national standard, operation on existing hardware, or integration with a legacy system. An assumption is something treated as true for planning purposes, such as the availability of a reliable identity service. Assumptions should be recorded because invalid assumptions create project risk.

Product and process requirements

Product requirements describe characteristics of the delivered software. Process requirements prescribe how development must be conducted, for example using a particular coding standard, review procedure, or regulatory development framework. Both can be legitimate, but they should be justified rather than imposed merely by habit.

Stakeholders and Requirements Perspectives

A stakeholder is any person, group, organization, or system that can affect, be affected by, or express legitimate interest in the software. Stakeholders may include end users, customers, sponsors, managers, support staff, system administrators, security officers, regulators, suppliers, accessibility representatives, and owners of integrated systems.

Stakeholders frequently have different goals. A customer may want extensive functionality, an operations team may prioritize stability, a security specialist may impose restrictions, and a finance department may require cost control. Requirements engineering must expose these perspectives rather than allowing the loudest participant to define the product alone.

A stakeholder analysis can record each stakeholder’s interests, influence, knowledge, availability, and preferred communication method. Analysts should also look for absent or underrepresented groups. For example, a public service designed only with frequent users may disadvantage people with disabilities, limited connectivity, low literacy, or limited digital experience.

Requirements Elicitation

Elicitation is the systematic discovery of requirements from stakeholders, documents, existing systems, data, regulations, observation, and experiments. No single technique is sufficient because stakeholders may not know how to articulate tacit work practices, may use inconsistent terminology, or may describe desired solutions instead of underlying needs.

Interviews

Interviews may be structured, semi-structured, or exploratory. Effective questions ask about goals, current activities, exceptions, decisions, information sources, pain points, and success measures. The analyst should distinguish what a stakeholder needs from a proposed implementation. “We need a mobile application” may represent a need for access while away from a desk, which could also be met by a responsive web application.

Workshops

A facilitated workshop brings several stakeholders together to identify processes, rules, conflicts, and priorities. Workshops are efficient but require preparation, a clear agenda, skilled facilitation, and an explicit record of decisions. Participants should be encouraged to explain evidence and consequences rather than merely state preferences.

Observation and contextual inquiry

Observation reveals actual work, including informal practices and exceptions that interviews may miss. An analyst should observe the work context respectfully, distinguish observation from interpretation, and avoid disrupting safety-critical activity. Contextual inquiry combines observation with questions asked at appropriate points in the workflow.

Document and interface analysis

Policies, forms, contracts, reports, manuals, legislation, existing databases, logs, and application interfaces can reveal requirements and constraints. Documents may be outdated or contradictory, so their authority and currency must be assessed.

Surveys and questionnaires

Surveys are useful for collecting comparable responses from a large population. They are less effective for discovering complex workflows or unexpected needs. Questions should be neutral, comprehensible, and tested with a small sample.

Prototyping

A prototype is a representation used to explore requirements. A paper sketch can clarify navigation, while an executable prototype can test workflow or technical feasibility. Prototypes may be throwaway or evolutionary. Stakeholders must understand whether a prototype is intended for learning or is likely to become part of the product; otherwise they may assume that unfinished behavior is guaranteed.

Scenarios and business process models

Scenarios describe how actors and systems interact to achieve a goal. Process models show activities, decisions, roles, and information flows. These techniques help analysts examine normal and exceptional paths and identify missing responsibilities.

Requirements Analysis and Negotiation

Analysis transforms elicited information into coherent, feasible, sufficiently detailed requirements. It includes classification, decomposition, modeling, conflict detection, feasibility assessment, and negotiation.

Decomposition and abstraction

A broad goal such as “improve appointment management” should be decomposed into measurable outcomes and user capabilities. Analysts should preserve traceability to the original goal while avoiding premature technical design. Requirements can be organized hierarchically from business goals to user needs, system capabilities, and detailed specifications.

Ambiguity and inconsistency

Ambiguous words include “easy,” “quick,” “appropriate,” “user-friendly,” and “secure” unless operationally defined. Inconsistency occurs when two requirements impose incompatible rules, such as one stating that an order may be cancelled after dispatch and another prohibiting cancellation after payment.

A useful analysis technique is to identify:

1. the actor or source;
2. the required behavior or quality;
3. the object or data involved;
4. triggering conditions;
5. normal and exceptional outcomes;
6. measurable acceptance conditions; and
7. dependencies and constraints.

Feasibility

Feasibility is not limited to technical possibility. Analysts should consider operational, economic, legal, schedule, organizational, security, and ethical feasibility. A requirement may be technically achievable but unaffordable, unlawful, unsafe, or impossible to operate with available staff.

Negotiation and conflict resolution

Conflicts should be made explicit and resolved using agreed decision criteria. These may include legal obligations, safety, business value, risk reduction, cost, dependencies, and stakeholder impact. Decisions should be documented, including rejected alternatives and the rationale. Negotiation is not simply compromise: a legally mandatory security control should not be traded away merely because it is inconvenient.

Representing Requirements

User stories

A user story expresses a capability from a user perspective:

As a library member, I want to renew an eligible loan online so that I can avoid an unnecessary visit to the library.

The common format identifies a role, capability, and benefit. A story is not a complete specification; it is a starting point for conversation, elaboration, and testing. A useful story is independent where possible, valuable, negotiable, estimable, small enough for delivery, and testable.

Stories should avoid embedding unnecessary implementation decisions. “As a member, I want a blue button using framework X” describes a solution detail rather than a user outcome.

Acceptance criteria

Acceptance criteria define conditions that must be satisfied for a requirement to be accepted. For the renewal story, criteria might include:

• An authenticated member can view eligible loans.
• The system rejects renewal when another member has reserved the item.
• The system displays the new due date after a successful renewal.
• The system records the renewal and provides a confirmation message.

The Given–When–Then form is useful for behavioral examples:

• Given a member has an eligible loan and no active reservation exists,
• When the member selects Renew,
• Then the system extends the due date and records the renewal.

Acceptance criteria should cover normal behavior, invalid input, boundary conditions, authorization, error handling, and important non-functional expectations. They should be observable and testable, not merely restate the story.

Use cases

A use case describes interactions between an actor and a system to achieve a goal. It normally includes the goal, actors, preconditions, trigger, main success scenario, alternative flows, exception flows, and postconditions.

Use case: Submit assignment

• Primary actor: Student
• Preconditions: The student is authenticated and the submission window is open.
• Trigger: The student selects a course assignment.
• Main flow: The system displays requirements; the student selects a file; the system validates type and size; the student confirms; the system stores the file and records the submission time; the system displays confirmation.
• Alternative flow: If the file exceeds the limit, the system explains the limit and requests another file.
• Postcondition: A valid submission is associated with the student and assignment.

Use cases are particularly valuable when interactions, business rules, and exceptions are important. User stories are often concise and delivery-oriented; use cases provide more structured behavioral detail. They are complementary rather than competing methods.

Models and glossaries

Context diagrams establish system boundaries and external interfaces. Activity or process models clarify workflow. Domain models identify important entities and relationships. State models show how an entity changes in response to events. A requirements glossary defines terms such as “active customer,” “approved payment,” or “archived record.” Consistent terminology reduces misunderstanding.

Prioritization

Prioritization determines what should be delivered first and what may be deferred. A transparent method prevents priority from being determined solely by status or personal preference.

The MoSCoW method classifies requirements as Must have, Should have, Could have, or Won’t have this time. “Must” should be used sparingly; if everything is a must, the classification provides no guidance. A weighted scoring method may score value, risk reduction, urgency, and dependency on defined scales, but the scales and weights must be agreed and documented. Relative ranking can be useful when stakeholders can compare requirements directly.

Priority is not the same as implementation effort. A high-value requirement may be difficult, while a low-value requirement may be easy. Teams should consider value, cost, risk, dependency, compliance, and learning benefit together. Priorities should be revisited as evidence changes.

Validation and Quality Criteria

Validation asks whether the documented requirements describe the right product and whether they are expressed well enough to guide construction and testing. A requirement set should be:

• correct: represents a genuine stakeholder or organizational need;
• unambiguous: has one reasonable interpretation;
• complete: includes necessary functions, constraints, data, and significant exceptions;
• consistent: does not conflict with other requirements;
• feasible: can be implemented and operated within constraints;
• verifiable: can be checked through test, inspection, analysis, or demonstration;
• traceable: has an identifiable source and links to downstream work;
• prioritized: has an agreed level of importance; and
• understandable: is accessible to its intended readers.

Validation techniques include peer reviews, stakeholder walkthroughs, prototypes, scenario simulations, test-case derivation, inspections, and automated checks for duplicate or incomplete records. Testers should be involved early because a requirement that cannot produce a meaningful test may be inadequately specified.

Verification and validation are related but distinct. Verification asks whether the requirement is written according to agreed quality standards; validation asks whether it represents the correct need. A grammatically perfect requirement can still describe the wrong product.

Requirements Traceability

Traceability records relationships among requirements and other artifacts. A forward trace may connect a business goal to user stories, design elements, code, and tests. A backward trace connects a feature or test to its originating need. Bidirectional traceability supports impact analysis and demonstrates coverage.

A simple requirements traceability matrix may contain:

Traceability is not merely administrative overhead. It supports change impact analysis, compliance evidence, test completeness, and communication. It should be maintained at a useful level of detail; excessive links that no one can keep current become unreliable.

Requirements Management and Change Control

Requirements management controls versions, status, ownership, priorities, dependencies, changes, and decisions throughout the product life cycle. A baseline is a formally agreed version against which changes are assessed. Baselines do not mean that change is forbidden; they make change visible and governed.

A typical change-control process is:

1. record the change request and its rationale;
2. clarify the requested outcome and affected requirements;
3. analyze impact on scope, architecture, interfaces, data, security, tests, cost, schedule, operations, and compliance;
4. estimate alternatives and risks;
5. obtain a decision from the authorized product or change authority;
6. update requirements, models, plans, tests, and traceability; and
7. communicate the decision and monitor implementation.

Change requests should not be rejected automatically. In an agile environment, the product backlog is continuously refined and reprioritized. Governance remains necessary: agile development changes the timing and form of control, not the need for clear decisions, evidence, and accountability.

Version control should identify who changed a requirement, when, why, and under whose authority. Status values such as proposed, under review, approved, implemented, verified, rejected, and superseded make progress visible.

Worked Example: From Need to Testable Requirement

Suppose a college wants to reduce queues for laboratory equipment. A stakeholder initially states: “Students need a simple online booking system.”

The analyst investigates and discovers that students need to see available equipment, reserve it for permitted time periods, cancel before the booking begins, and receive confirmation. Laboratory staff need to prevent double booking, restrict reservations to trained students, and obtain a daily schedule.

A refined user story is:

As a trained student, I want to reserve available laboratory equipment for an approved time period so that I can complete practical work without waiting.

Acceptance criteria include:

• only authenticated students with current training may reserve equipment;
• the system shall display only available time slots;
• a reservation shall not overlap an existing reservation for the same equipment;
• the system shall show the equipment, date, start time, end time, and responsible student before confirmation;
• a successful reservation shall produce a unique confirmation and email notification; and
• a student shall be able to cancel before the permitted cancellation deadline.

A non-functional requirement might be:

For a workload of 200 concurrent users, 95% of availability searches shall return results within 2 seconds, measured at the application interface during an agreed performance test.

This version is stronger because it identifies the population, workload, measurement, percentile, and operation. The analyst should still confirm whether 2 seconds and 200 users reflect real operational needs.

Applied Case: Campus Health Appointment Service

The following is an illustrative case.

Background

A college plans an online service for booking health appointments. The existing telephone process creates long queues, and staff manually reconcile cancellations and clinician schedules.

Problem

The initial proposal, “build an appointment app,” is too vague. It does not identify user groups, privacy requirements, emergency handling, clinician availability, cancellation rules, accessibility, or integration with the student identity system.

Analysis

Stakeholders include students, receptionists, clinicians, counselors, administrators, information-security staff, accessibility representatives, and the identity-system owner. Interviews reveal that students want convenient booking, receptionists need controlled schedule management, and clinicians must see only information necessary for care. A workshop identifies a critical rule: an online booking service must not be presented as an emergency service.

The analysis also identifies non-functional requirements. The service must protect sensitive health information, provide accessible interaction, remain available during enrollment periods, record audit events, and recover safely from failures. The team decides that cancellation and rescheduling require explicit confirmation and that notifications must not reveal sensitive medical details in message previews.

Approach and solution

The team creates a context model, appointment use cases, a glossary, user stories, and a prioritized backlog. A prototype tests the booking workflow with students and accessibility representatives. Acceptance tests cover available slots, double-booking prevention, unauthorized access, cancellation deadlines, notification content, and audit records.

The traceability matrix links the privacy requirement to the access-control design, security review, and authorization tests. A change-control rule requires approval from the service owner and privacy officer for changes affecting health data. Performance testing uses an agreed peak workload rather than an arbitrary speed claim.

Outcome

The prototype reveals that students interpret “appointment type” as a diagnosis category, which would unnecessarily expose sensitive information. The interface is redesigned to use neutral service labels. Testing also discovers that a cancelled appointment could be booked twice because two requests were processed concurrently; the design is corrected to enforce an atomic availability decision.

Learning points

The case demonstrates that requirements engineering exposes risks before implementation. Stakeholder diversity, privacy, accessibility, exception handling, prototype evaluation, testable criteria, and traceability are all necessary. A short request for an app can conceal substantial organizational and ethical complexity.

Challenges, Ethics, and Governance

Requirements work involves power and responsibility. Analysts decide whose needs are visible and which risks receive attention. They should avoid discriminatory assumptions, protect confidential information, obtain informed participation in research activities, and document uncertainty honestly.

Privacy should be considered during elicitation and design, not added after implementation. Requirements should address data minimization, purpose limitation, access control, retention, auditability, correction, and lawful processing where applicable. Security requirements should include authentication, authorization, confidentiality, integrity, availability, logging, recovery, and abuse resistance according to the system’s risk.

Accessibility is a quality and inclusion obligation. Requirements should consider keyboard operation, screen readers, color contrast, captions, readable language, input assistance, and alternative channels. Accessibility representatives and users with diverse abilities should participate in validation.

AI systems create additional requirements concerns. A system using automated recommendations or classification may require explainability appropriate to its context, human oversight, performance evaluation across relevant groups, data-provenance controls, monitoring for drift, appeal mechanisms, and clear responsibility for decisions. AI-generated requirements or prototypes must be reviewed by accountable humans; plausible wording is not evidence of correctness.

Regulatory obligations vary by jurisdiction and domain. Teams must identify applicable laws, contracts, standards, records obligations, safety rules, and professional codes. Requirements should cite authoritative sources where possible and should not claim compliance without evidence.

Common Failure Modes and Best Practices

Common failures include beginning with a preferred technology, relying on one stakeholder, writing vague quality requirements, ignoring exceptions, treating prototypes as final commitments, failing to record decisions, allowing uncontrolled scope growth, and postponing validation until after coding.

Effective practice includes:

• start with goals, users, context, and measurable outcomes;
• combine elicitation techniques and compare evidence;
• maintain a shared glossary;
• separate needs from proposed solutions;
• write small, testable requirements;
• include error, boundary, security, privacy, and accessibility conditions;
• involve developers, testers, operations staff, and affected users early;
• prioritize transparently and revisit priorities;
• preserve traceability without creating unnecessary bureaucracy;
• use prototypes to answer specific questions;
• baseline and version requirements; and
• treat change as a managed source of learning rather than as either chaos or failure.

Contemporary Practice

Modern software development increasingly uses continuous discovery, product analytics, collaborative backlog refinement, and automated testing. These practices shorten the feedback cycle but do not eliminate requirements engineering. Instead, requirements may be expressed as evolving hypotheses, measurable outcomes, stories, examples, and operational quality objectives.

Telemetry can reveal how a system is actually used, but analytics must respect privacy and must not be treated as a complete representation of user need. A feature used often is not necessarily valuable, and a feature used rarely may be essential in an emergency. Continuous delivery also increases the importance of operational requirements, monitoring, rollback, resilience, and responsible experimentation.

Requirements engineering remains a professional discipline because software decisions affect people, organizations, resources, safety, and rights. Its central purpose is to create shared, testable understanding while retaining enough flexibility to learn.

Chapter Summary

Requirements engineering discovers and manages what a software system must provide and the constraints under which it must operate. Functional requirements describe behavior; non-functional requirements describe qualities and constraints; business, user, and system requirements provide different levels of abstraction. Effective elicitation combines interviews, workshops, observation, document analysis, surveys, scenarios, models, and prototypes.

Analysis identifies ambiguity, inconsistency, feasibility issues, dependencies, and conflicts. User stories provide concise, user-centered statements, while use cases and models add structured behavioral detail. Acceptance criteria convert intentions into observable conditions. Prioritization should consider value, risk, cost, dependency, urgency, and compliance. Validation checks correctness, completeness, consistency, feasibility, verifiability, understandability, and traceability.

Traceability connects goals, requirements, design, implementation, and tests. Requirements management controls versions, decisions, priorities, and changes through impact analysis and authorized change control. Ethical and professional practice requires attention to privacy, security, accessibility, safety, fairness, legal obligations, and human accountability, including when AI is used. Good requirements engineering reduces rework and helps teams build software that is useful, dependable, and responsible.

Key Terms

Requirement: A needed capability, quality, condition, or constraint of a system.

Requirements engineering: The disciplined elicitation, analysis, specification, validation, prioritization, and management of requirements.

Functional requirement: A statement of behavior or service the system must provide.

Non-functional requirement: A quality attribute, constraint, or condition on the system or its development.

Stakeholder: A person, group, organization, or system affected by or interested in the product.

Elicitation: The discovery and exploration of requirements from relevant sources.

User story: A concise statement of a desired capability from a user perspective.

Acceptance criteria: Conditions that must be satisfied for a requirement to be accepted.

Use case: A structured description of interactions that achieve an actor’s goal.

Prototype: A representation used to explore, communicate, or validate requirements.

Constraint: A restriction on possible solutions or development methods.

Assumption: A proposition treated as true for planning or analysis.

Prioritization: The process of ranking requirements according to agreed criteria.

Validation: Checking that requirements describe the right product and are suitable for use.

Traceability: The ability to follow relationships among requirements and related artifacts.

Baseline: An agreed version of requirements controlled as a reference point.

Change control: The formal evaluation, authorization, recording, and implementation of changes.

Acceptance test: A test that determines whether specified acceptance conditions are met.

Requirements glossary: A controlled list of domain terms and their meanings.

Review Questions

Short Answer Questions

1. What is the difference between a functional and a non-functional requirement?
2. Why should assumptions be recorded during requirements analysis?
3. What three elements are commonly included in a user story?
4. State four quality characteristics of a good requirement.
5. What is the purpose of a requirements traceability matrix?

Long Answer Questions

1. Explain the requirements elicitation process and compare interviews, workshops, observation, and prototyping.
2. Describe how use cases and user stories complement one another in software development.
3. Explain a disciplined requirements change-control process, including impact analysis.
4. Discuss how privacy, security, accessibility, and legal obligations influence requirements.
5. Explain why non-functional requirements should include measurable conditions, workloads, and measurement methods.

Analytical / Application Questions

1. A customer says, “The application must be user-friendly and very fast.” Rewrite these statements as two or more testable requirements and identify assumptions that require investigation.
2. A booking system permits two users to reserve the same appointment when they submit requests simultaneously. Identify the missing or inadequate requirements and propose acceptance tests.
3. For an online student assessment service, identify at least five stakeholders, three functional requirements, three non-functional requirements, and one traceability relationship for each category.

Multiple Choice Questions with Answers

Question 1

Which statement is a non-functional requirement?

A. The system shall allow students to submit assignments.

B. The system shall email a receipt after payment.

C. The system shall require multi-factor authentication for administrators.

D. The system shall calculate the invoice total.

Correct Answer: C. The system shall require multi-factor authentication for administrators.

Question 2

What is the primary purpose of acceptance criteria?

A. To select the programming language

B. To define conditions for deciding whether a requirement is satisfied

C. To identify the project sponsor

D. To replace all system documentation

Correct Answer: B. To define conditions for deciding whether a requirement is satisfied

Question 3

Which elicitation technique is most likely to reveal informal work practices?

A. Observation

B. Source-code compilation

C. Database indexing

D. Load testing

Correct Answer: A. Observation

Question 4

What does bidirectional traceability support?

A. Faster typing of requirements

B. Linking requirements both to their sources and to downstream artifacts

C. Removing the need for testing

D. Guaranteeing that requirements never change

Correct Answer: B. Linking requirements both to their sources and to downstream artifacts

Question 5

In the MoSCoW method, what does “Must have” mean?

A. A feature that is merely interesting

B. A feature excluded from the current release

C. A requirement considered essential for the agreed outcome

D. A requirement with the lowest priority

Correct Answer: C. A requirement considered essential for the agreed outcome

Question 6

Which statement best distinguishes validation from verification?

A. Validation asks whether the right need is described; verification asks whether it is expressed properly.

B. Validation is performed only by programmers; verification only by customers.

C. Validation concerns costs; verification concerns schedules.

D. They are exactly the same activity.

Correct Answer: A. Validation asks whether the right need is described; verification asks whether it is expressed properly.

Question 7

A requirement says, “The system shall respond quickly.” What is its main weakness?

A. It contains too many measurable conditions.

B. It is ambiguous and difficult to verify.

C. It identifies a specific workload.

D. It defines an acceptance test completely.

Correct Answer: B. It is ambiguous and difficult to verify.

Question 8

Which item should normally be included in change impact analysis?

A. Only the font used in the requirements document

B. Architecture, interfaces, tests, cost, schedule, and compliance effects

C. Only the developer’s personal preference

D. Only requirements already rejected

Correct Answer: B. Architecture, interfaces, tests, cost, schedule, and compliance effects

Question 9

What is a use case primarily intended to describe?

A. The physical layout of a server room

B. Interactions between an actor and a system to achieve a goal

C. The salary structure of a development team

D. The color palette of an interface

Correct Answer: B. Interactions between an actor and a system to achieve a goal

Question 10

Why should a prototype’s purpose be explained to stakeholders?

A. To ensure stakeholders mistake it for the finished product

B. To prevent stakeholders from making any comments

C. To clarify whether it is for learning or intended to become part of the product

D. To eliminate the need for requirements validation

Correct Answer: C. To clarify whether it is for learning or intended to become part of the product