Requirements and Product Definition

Introduction

Product management converts customer, business, and technical needs into a product that can be built, released, and improved. Requirements and product definition are the central instruments of that conversion. They clarify the problem to be solved, identify for whom it is solved, describe the intended outcome, and establish boundaries for delivery.

Weak requirements create predictable problems: teams build features that users do not need, stakeholders interpret commitments differently, defects are discovered late, and scope expands without deliberate approval. Strong requirements do not eliminate uncertainty, but they make uncertainty visible and manageable. They provide a shared basis for prioritisation, design, engineering, testing, commercial planning, and governance.

This chapter explains how product managers create product briefs, user stories, use cases, acceptance criteria, and product requirement documents (PRDs). It also examines assumptions, dependencies, constraints, non-functional requirements, scope control, traceability, and responsible use of AI-supported product practices.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain the purpose and characteristics of effective product requirements.
2. Prepare a concise product brief from a customer or business problem.
3. Write user stories, use cases, and testable acceptance criteria.
4. Structure a useful and proportionate PRD.
5. Distinguish scope, assumptions, dependencies, constraints, and risks.
6. Specify important non-functional requirements.
7. Apply traceability and change-control practices.
8. Evaluate requirements for ambiguity, feasibility, value, and ethical implications.

1. Product Definition as a Decision System

A product definition is more than a feature list. It is a coherent explanation of:

• the user or customer affected;
• the problem or opportunity;
• the value expected;
• the proposed product behaviour;
• the evidence supporting the proposal;
• the boundaries of the work; and
• the conditions by which success will be judged.

Product definition is therefore a decision system. It supports decisions about what to build, what not to build, how to sequence work, and how to determine whether the result is effective. It should be detailed enough to coordinate a cross-functional team, but not so prescriptive that it prevents appropriate design or technical decisions.

Requirements and solutions

A requirement describes a need, behaviour, condition, or quality that the product must satisfy. A solution describes one way of satisfying it. For example:

• Requirement: “A customer must be able to recover access without contacting support.”
• Possible solution: “Provide a password-reset flow using a verified email address.”

Confusing the requirement with the solution can reduce innovation. However, some requirements legitimately constrain the solution—for example, legal obligations, a mandated integration, or a hardware interface.

Good requirements

Useful requirements are generally:

No requirement is perfectly complete in isolation. Product work is iterative, and requirements should evolve when evidence changes. The objective is controlled learning rather than false certainty.

2. From Problem to Product Brief

A product brief is a short decision document used to align stakeholders before detailed requirements are developed. It is especially useful at discovery and initiation stages. A brief should answer the following questions:

1. What problem or opportunity exists?
2. Who experiences it, and in what context?
3. Why does it matter now?
4. What outcome is sought?
5. What evidence supports the problem statement?
6. What is in scope and out of scope?
7. What constraints, assumptions, and dependencies apply?
8. How will success be measured?

A practical product brief may contain these sections:

Context and problem statement

The problem statement should describe an undesirable situation rather than prematurely prescribing a feature. A useful structure is:

[User or segment] experiences [problem] when [context], resulting in [impact].

For example: “Small-business owners experience uncertainty when reviewing monthly cash flow because transactions are categorised inconsistently, resulting in delayed decisions about spending.”

The statement should be supported by evidence such as interviews, behavioural data, support records, market research, or operational observations. A stakeholder opinion may initiate investigation, but it is not equivalent to validated evidence.

Desired outcome

An outcome describes the change expected in user behaviour, customer value, business performance, or operational quality. “Build a dashboard” is an output. “Enable owners to identify unusual spending within five minutes” is an outcome.

Outcomes should be measurable where practical. A baseline, target, population, and time period are useful. For example: “Within three months of release, at least 60% of active small-business accounts should review a cash-flow summary monthly, compared with a current baseline of 35%.” The metric is not automatically a complete measure of value; it should be interpreted alongside qualitative evidence and possible adverse effects.

Users and stakeholders

Identify primary users, secondary users, customers, administrators, support teams, compliance personnel, and other affected parties. The purchaser, user, beneficiary, and person bearing risk may be different people. Accessibility and inclusion analysis should consider users with disabilities, limited connectivity, different languages, and varying levels of digital confidence.

Scope boundaries

Scope is the set of work and behaviour included in a defined initiative. A brief should state both inclusions and exclusions. Explicit exclusions are valuable because they prevent assumptions that every related request is part of the commitment.

Success measures and non-goals

Success measures should combine product, customer, business, and quality indicators where appropriate. Non-goals are outcomes deliberately not pursued in the current initiative. They protect focus without claiming that excluded needs are unimportant.

3. User Stories

A user story is a lightweight expression of a user need, commonly written as:

As a [type of user], I want [capability], so that [benefit].

Example:

As a returning customer, I want to save my delivery address, so that I can complete future orders more quickly.

The format encourages attention to actor, capability, and value. It is not a complete specification. A story normally requires conversation, supporting notes, design artefacts, data definitions, and acceptance criteria.

INVEST as a quality heuristic

The INVEST mnemonic is often used to assess stories:

• Independent: Minimises unnecessary dependence on other stories.
• Negotiable: Describes intent rather than serving as an inflexible contract for implementation.
• Valuable: Produces identifiable value for a user or stakeholder.
• Estimable: Contains enough information for the team to assess relative effort.
• Small: Can be completed within a suitable delivery interval.
• Testable: Has observable conditions of satisfaction.

INVEST is a heuristic, not a law. For example, some valuable capabilities are naturally dependent on shared platform work. The dependency should be managed rather than hidden.

Common story errors

A story is weak when it:

• describes a technical task rather than user value;
• combines several unrelated capabilities;
• uses vague words such as “easy,” “fast,” or “appropriate” without criteria;
• represents a stakeholder role as the user without identifying the actual beneficiary; or
• contains acceptance criteria that are merely implementation steps.

“Create a database table for addresses” may be a necessary technical task, but it is not normally a user story. It may be linked to the story about saving an address.

4. Use Cases and Scenarios

A use case describes interactions between an actor and a system to achieve a goal. It is useful when behaviour involves multiple steps, alternative paths, exceptions, permissions, or external systems.

A use-case specification commonly includes:

• name and goal;
• primary actor;
• supporting actors or systems;
• trigger;
• preconditions;
• main success flow;
• alternative and exception flows;
• postconditions;
• business rules; and
• relevant quality requirements.

Example: submitting an expense claim

Goal: An employee submits a valid expense claim.

Primary actor: Employee.

Preconditions: The employee is authenticated and belongs to an active organisation.

Trigger: The employee selects “New claim.”

Main flow:

1. The system displays claim fields.
2. The employee enters amount, date, category, and description.
3. The employee attaches a receipt.
4. The system validates required fields and file type.
5. The employee submits the claim.
6. The system records the claim as “Submitted” and notifies the approver.

Alternative flows: If a receipt is missing for a category requiring one, the system identifies the missing item and prevents submission. If the amount exceeds a policy threshold, the system routes the claim to an additional approval step.

Postcondition: The claim is stored with an auditable status history.

Use cases are particularly valuable for workflows, regulated processes, customer support operations, and integrations. User stories are usually more compact and backlog-oriented; use cases provide richer behavioural context. They are complementary rather than competing formats.

5. Acceptance Criteria

Acceptance criteria define the conditions that must be met for a requirement or story to be accepted. They should describe observable outcomes, not simply the developer’s activities.

A common format is Given–When–Then:

• Given a starting context;
• When an event or action occurs;
• Then an observable result follows.

Example:

Given a registered customer has a verified email address,

When the customer requests a password reset,

Then the system sends a single-use reset link that expires after the configured validity period.

Additional criteria may address invalid input, permissions, duplicate actions, failure recovery, auditability, accessibility, and notifications.

Characteristics of effective criteria

Acceptance criteria should be:

• unambiguous;
• collectively sufficient for the intended scope;
• independently verifiable where practical;
• expressed in business or user language where possible;
• explicit about important boundary conditions; and
• consistent with applicable policies and non-functional requirements.

Avoid criteria such as “the page should be user-friendly.” Replace them with observable expectations, usability-test objectives, or measurable quality thresholds. A statement such as “95% of representative test users complete the task without assistance” is testable, but its sample, task definition, and test method must also be specified.

Acceptance criteria are not the same as a test script. Criteria express what must be true; test cases specify how evidence will be collected.

6. Product Requirement Documents

A PRD consolidates the product definition for a significant initiative, feature, or release. Its structure should be proportionate to risk and complexity. A possible PRD outline is:

1. Document control: owner, status, version, date, and reviewers.
2. Summary: the problem, proposed outcome, and decision required.
3. Context and evidence: research, data, market conditions, and relevant history.
4. Goals and non-goals: intended outcomes and deliberate exclusions.
5. Users and use cases: actors, needs, scenarios, and journey context.
6. Functional requirements: behaviours and business rules.
7. Non-functional requirements: quality attributes and operational conditions.
8. Scope and prioritisation: must, should, could, and excluded items.
9. Dependencies and assumptions: conditions outside or underlying the work.
10. Constraints and risks: limits and uncertainties.
11. Design and technical considerations: principles, interfaces, and open decisions.
12. Measurement plan: launch criteria, outcome metrics, and monitoring.
13. Acceptance and traceability: links to stories, tests, evidence, and decisions.
14. Release and rollout: migration, support, communication, and rollback considerations.

The PRD should not duplicate every design or engineering document. It should link to specialised artefacts while preserving the product-level decisions and rationale.

Prioritisation and scope control

One simple prioritisation method is MoSCoW:

• Must have: Required for the release to provide its intended minimum value or meet a critical obligation.
• Should have: Important but a temporary omission is acceptable.
• Could have: Desirable if capacity remains.
• Won’t have this time: Explicitly excluded from the current scope.

MoSCoW is a communication tool, not a substitute for evidence or economic analysis. A “must” classification should be justified; otherwise every request becomes a must.

Scope control involves a defined baseline, transparent change proposals, impact assessment, and an agreed decision authority. When a new request appears, assess its effect on value, time, cost, quality, risk, dependencies, and existing commitments. A change may be accepted, deferred, exchanged for another item, or rejected. Scope control is not resistance to change; it is deliberate change management.

7. Assumptions, Dependencies, Constraints, and Risks

These concepts are related but distinct.

A useful assumptions register records the assumption, rationale, owner, validation method, date, and consequence if false. Dependencies should have owners, required dates, interfaces, and fallback plans. Constraints should be distinguished from preferences; otherwise teams may treat negotiable decisions as fixed limitations.

A basic risk priority can be discussed qualitatively using likelihood and impact. If a numerical risk score is used, the organisation must define its scale consistently; multiplying arbitrary ratings does not create a scientifically precise probability. The purpose is comparative attention, not false accuracy.

8. Non-Functional Requirements

Functional requirements describe what the product does. Non-functional requirements (NFRs) describe qualities, conditions, or limits under which it must operate. Important categories include:

• Performance: response time, throughput, and resource use.
• Availability and resilience: uptime objectives, recovery, and fault tolerance.
• Security: authentication, authorisation, encryption, secrets management, and threat resistance.
• Privacy: collection minimisation, purpose limitation, retention, consent, and user rights.
• Accessibility: compatibility with assistive technologies, keyboard operation, contrast, captions, and understandable language.
• Scalability: behaviour as users, transactions, or data volume increase.
• Maintainability: diagnosability, modularity, documentation, and safe change.
• Compatibility: supported devices, browsers, operating systems, and integrations.
• Compliance and auditability: records, controls, and evidence required by law or policy.

NFRs should be measurable or at least assessable. “The service must be fast” is inadequate. “For the defined transaction and test environment, 95% of requests should complete within 500 milliseconds under the agreed load” is more useful, provided the transaction, environment, load, and measurement method are specified. NFRs often apply across many stories and should therefore be visible in the PRD, architecture discussions, test strategy, and release criteria.

Trade-offs are unavoidable. Stronger security may add friction; longer retention may improve analysis but increase privacy exposure; higher availability may increase cost. Product managers must make these trade-offs explicit and involve relevant specialists.

9. Traceability and Validation

Traceability connects the chain from need to evidence:

Problem or opportunity → outcome → requirement → story/use case → acceptance criterion → test evidence → released behaviour → outcome measurement

A lightweight traceability matrix can reveal orphaned work and untested obligations.

Validation asks whether the team is building the right thing; verification asks whether it has built the thing correctly. Interviews, prototypes, usability tests, analytics, technical spikes, accessibility reviews, and compliance assessments support validation. Automated tests, inspections, and operational checks support verification. Both are necessary.

Requirements review should include the people who will use or be affected by the product, not only the product team. Review for ambiguity, missing actors, exceptional conditions, data handling, accessibility, operational support, and unintended consequences.

10. Ethical, Legal, and Governance Considerations

Requirements can encode social values and risks. A product manager should ask:

• Does the feature disadvantage a protected or vulnerable group?
• Is consent meaningful, specific, and revocable where required?
• Are data collection and retention proportionate to the purpose?
• Can users understand and challenge consequential decisions?
• Are accessibility needs treated as requirements rather than optional enhancements?
• Does the design create dark patterns, coercion, or unnecessary friction?
• Is responsibility clear when an automated decision is wrong?

Legal requirements vary by jurisdiction and sector, so product managers should obtain qualified advice rather than treating a generic checklist as legal compliance. Governance should define approval roles, evidence retention, change history, incident response, and escalation routes.

AI can assist with clustering feedback, identifying duplicate requirements, proposing edge cases, and checking documents for inconsistent terminology. It can also reproduce bias, invent unsupported requirements, expose confidential data, or create unjustified confidence. AI-generated content must be reviewed against authoritative evidence, privacy rules, security controls, and human accountability. It should support—not replace—user research, professional judgement, and approval responsibility.

11. Worked Application: Campus Equipment Booking

The following is an illustrative case.

Background and problem

A college lends cameras, microphones, and laptops to students. Bookings are currently made through email. Staff spend substantial time resolving double bookings, missing return information, and disputes about equipment condition.

Analysis

Interviews identify three user groups: students who need reliable access, equipment staff who manage inventory, and lecturers who sometimes reserve equipment for classes. Records show that most disputes arise when booking status and return condition are not visible to all relevant staff. The product opportunity is not simply “build a booking app”; it is to improve reliable, accountable access to equipment.

Product brief

Outcome: Students and staff can reserve available equipment with clear confirmation, while equipment staff can manage availability and return status.

In scope: catalogue, availability view, reservation request, approval rules, confirmation, cancellation, check-out and return records, and an audit history.

Out of scope for the first release: payment, external commercial rentals, predictive demand forecasting, and mobile-native applications.

Assumptions: inventory records are accurate; users have college accounts; staff can define approval rules.

Dependencies: identity service, inventory data, email service, and equipment-condition process.

Constraints: only authorised users may reserve equipment; personal data must be retained according to college policy; the service must be accessible through supported browsers.

User story and criteria

As a student, I want to see whether a camera is available for a specified period, so that I can plan my project with confidence.

Acceptance criteria:

1. Given an authenticated student selects equipment and a start and end time, when the search is submitted, then the system displays availability for that period.
2. Given an overlapping confirmed reservation exists, when the student searches the period, then the equipment is shown as unavailable and cannot be reserved for the overlapping interval.
3. Given the student submits a valid available request, when the reservation is confirmed, then the system displays the reservation identifier and sends a confirmation message.
4. Given the student lacks permission for restricted equipment, when the student views that equipment, then the system explains the restriction without exposing confidential administrative notes.

Non-functional requirements

The team defines the following initial NFRs:

• availability searches should return results within two seconds for 95% of requests under the agreed test load;
• all reservation changes must record actor, time, prior state, and new state;
• keyboard-only users must be able to search and submit a reservation;
• unauthorised users must not access another user’s personal booking details; and
• the system must prevent two confirmed reservations for the same equipment and overlapping time interval.

Approach and outcome

The team first prototypes the booking flow and tests it with students and equipment staff. A technical spike investigates how the identity and inventory systems expose data. The initial release prioritises trustworthy availability and auditability over advanced recommendations. After release, the team monitors booking errors, support contacts, completion rates, and accessibility feedback. If the evidence shows that students still cannot obtain equipment reliably, adding more features would not address the core problem; the team would investigate the underlying operational process.

Learning points

The case demonstrates that a coherent definition links problem, outcome, scope, workflow, quality, governance, and measurement. It also shows why edge cases—overlapping reservations, permissions, cancellation, and audit history—must be addressed before implementation rather than discovered only after launch.

Best Practices for Professional Requirements Work

1. Start with a problem and evidence, not a preferred feature.
2. Separate outcomes, requirements, solutions, tasks, and tests.
3. Use the lightest artefact that provides sufficient shared understanding.
4. Write acceptance criteria before development is considered complete.
5. Make exclusions and unresolved decisions visible.
6. Treat NFRs, accessibility, privacy, and security as part of the product definition.
7. Assign owners to assumptions, dependencies, risks, and decisions.
8. Review requirements with users, delivery specialists, and affected operational teams.
9. Maintain version history and explain important changes.
10. Measure outcomes after release and update the product definition when evidence changes.

Challenges and Limitations

Requirements cannot resolve strategic disagreement by themselves. A perfectly written document may still describe a low-value product. Customer research can be incomplete, stakeholders may have conflicting incentives, and technical feasibility may change. Detailed documents can become obsolete, while overly brief documents can leave important assumptions hidden. Agile delivery reduces the value of large upfront specifications but does not remove the need for shared intent, quality criteria, or scope decisions. The appropriate level of documentation depends on risk, uncertainty, regulatory exposure, team distribution, and product complexity.

Chapter Summary

Requirements and product definition translate problems and opportunities into a shared, testable basis for product decisions. A product brief establishes context, users, outcomes, evidence, scope, and success measures. User stories express a user-centred need, while use cases describe richer interactions, alternative paths, and exceptions. Acceptance criteria define observable conditions of satisfaction, often using Given–When–Then.

A PRD consolidates product context, goals, users, functional and non-functional requirements, scope, dependencies, assumptions, constraints, risks, measures, and rollout considerations. Scope control requires explicit boundaries and transparent assessment of change. Assumptions, dependencies, constraints, risks, and issues should not be treated as interchangeable. Non-functional requirements address qualities such as performance, security, privacy, accessibility, resilience, and compliance.

Traceability links problems to outcomes, requirements, acceptance evidence, tests, and post-release measures. Ethical and governance analysis ensures that requirements do not create avoidable exclusion, privacy harm, coercion, or unaccountable automation. Effective product managers balance clarity with adaptability: they document enough to coordinate responsible action while continuing to learn from evidence.

Key Terms

Product definition: A structured description of the problem, users, outcomes, scope, behaviours, and conditions of a product initiative.

Requirement: A need, behaviour, condition, or quality the product must satisfy.

Product brief: A concise document aligning stakeholders around a problem, outcome, scope, and evidence.

Outcome: The change in user, customer, business, or operational condition sought by an initiative.

Scope: The work and behaviour included in a defined initiative.

User story: A concise statement of a user need, capability, and benefit.

Use case: A description of interactions between an actor and a system to achieve a goal.

Acceptance criteria: Observable conditions that determine whether a requirement is acceptable.

PRD: Product requirement document consolidating product-level decisions and requirements.

Functional requirement: A requirement describing what the product does.

Non-functional requirement: A quality, condition, or limit governing how the product operates.

Assumption: A proposition treated as true for planning but requiring validation.

Dependency: An external or internal element on which delivery relies.

Constraint: A limitation within which the product must operate.

Risk: An uncertain event or condition that may affect objectives.

Traceability: The ability to link needs, requirements, implementation, tests, and outcomes.

MoSCoW: A prioritisation approach using Must, Should, Could, and Won’t categories.

Scope creep: Uncontrolled expansion of agreed work without deliberate assessment and approval.

Validation: Determining whether the right product or requirement is being pursued.

Verification: Determining whether the product has been built according to its requirements.

Review Questions

Short Answer Questions

1. What is the difference between a requirement and a solution?
2. State the standard structure of a user story.
3. What purpose do acceptance criteria serve?
4. Distinguish an assumption from a dependency.
5. Name four categories of non-functional requirements.

Long Answer Questions

1. Explain how a product brief supports alignment before detailed requirements are written.
2. Compare user stories and use cases, including situations in which each is most useful.
3. Describe the main sections of a proportionate PRD.
4. Explain how scope control can support agility rather than prevent change.
5. Discuss why privacy, accessibility, security, and auditability should be included in product definition.

Analytical / Application Questions

1. A stakeholder requests “an AI dashboard to improve customer retention.” Analyse how you would convert this request into a problem statement, evidence plan, outcome, scope boundary, and initial requirement.
2. A booking system occasionally creates overlapping reservations. Identify possible functional requirements, non-functional requirements, dependencies, assumptions, and acceptance criteria that should be investigated.
3. A team discovers that a legally required data-retention rule conflicts with a proposed analytics feature. Explain how the product manager should analyse, document, escalate, and resolve the conflict.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a requirement from a solution?

A. A requirement describes a need or condition, while a solution is one way to satisfy it.

B. A requirement is always technical, while a solution is always commercial.

C. A requirement is written after implementation, while a solution is written before research.

D. A requirement is optional, while a solution is mandatory.

Correct Answer: A. A requirement describes a need or condition, while a solution is one way to satisfy it.

Question 2

Which item is an outcome rather than an output?

A. Build a dashboard.

B. Create three database tables.

C. Enable owners to identify unusual spending within five minutes.

D. Release version 2.0 of the application.

Correct Answer: C. Enable owners to identify unusual spending within five minutes.

Question 3

In a Given–When–Then acceptance criterion, “When” identifies the:

A. starting context

B. event or action

C. expected result

D. business owner

Correct Answer: B. event or action

Question 4

Which artefact is most suited to describing alternative and exception flows in detail?

A. Use case

B. Product vision statement

C. Release note

D. Burndown chart

Correct Answer: A. Use case

Question 5

Which of the following is a constraint?

A. The team assumes users have verified email addresses.

B. The payment provider must expose refund status.

C. The service must retain data within a specified jurisdiction.

D. The provider may change its API before launch.

Correct Answer: C. The service must retain data within a specified jurisdiction.

Question 6

Which is a non-functional requirement?

A. A customer can cancel an order.

B. An administrator can export a report.

C. The service returns 95% of defined requests within 500 milliseconds under the agreed load.

D. A user can add an item to a basket.

Correct Answer: C. The service returns 95% of defined requests within 500 milliseconds under the agreed load.

Question 7

What is the primary purpose of explicit out-of-scope statements?

A. To prevent all future product changes.

B. To clarify boundaries and reduce conflicting assumptions.

C. To replace user research.

D. To guarantee that the project will finish early.

Correct Answer: B. To clarify boundaries and reduce conflicting assumptions.

Question 8

Which sequence best represents product traceability?

A. Test evidence → problem → outcome → requirement

B. Problem → outcome → requirement → acceptance evidence

C. Design task → meeting → budget → problem

D. Release date → feature request → legal review → user need

Correct Answer: B. Problem → outcome → requirement → acceptance evidence

Question 9

What is the main weakness of the statement “The page must be user-friendly”?

A. It contains too many measurable conditions.

B. It is a technical implementation detail.

C. It is vague and lacks observable evaluation criteria.

D. It defines an exception flow too precisely.

Correct Answer: C. It is vague and lacks observable evaluation criteria.

Question 10

Which use of AI in requirements work is most responsible?

A. Allowing AI to approve legal compliance without review.

B. Using AI to suggest duplicate detection, followed by human validation against evidence.

C. Uploading confidential customer data to an unapproved tool.

D. Replacing user research with AI-generated personas.

Correct Answer: B. Using AI to suggest duplicate detection, followed by human validation against evidence.