আগের lesson-এ আমরা functional এবং non-functional requirements আলাদা করেছি।

এখন আমাদের কাছে broad understanding আছে যে system কী কী capability support করবে।

কিন্তু broad requirement directly implementation ticket হিসেবে ব্যবহার করা কঠিন।

For example:

Customers should be able to place orders.

এই requirement important, কিন্তু একজন engineer যদি শুধু এই sentence নিয়ে কাজ শুরু করে, অনেক behaviour undefined থেকে যায়।

তাই real-world software teams requirement-কে ছোট, understandable এবং testable unit-এ ভাঙে।

এই lesson-এ আমরা দুটি common concept ব্যবহার করব:

User Story

এবং:

Acceptance Criteria

এগুলোর purpose process-heavy documentation তৈরি করা নয়।

Purpose হলো সবাই যেন একই behaviour বুঝে এবং একটি change কখন complete বলা যাবে সেটি clear থাকে।

---

From Product Requirement to Engineering Work

আমাদের current flow:

Product Requirement
        ↓
Requirement Analysis
        ↓
Functional Requirements
        ↓
User Stories
        ↓
Acceptance Criteria
        ↓
Engineering Tickets
        ↓
Implementation

এই flow rigid rule নয়।

সব company একইভাবে কাজ করে না।

Small team হয়তো user story না লিখে সরাসরি ticket লিখতে পারে।

কিন্তু underlying problem একই:

Engineer implementation শুরু করার আগে expected behaviour sufficiently clear হতে হবে।

---

What Is a User Story?

User Story একটি short description যা কোনো user-এর perspective থেকে desired capability explain করে।

একটি common format:

As a <type of user>,
I want <some capability>,
so that <some outcome>.

For example:

As a customer,
I want to place an order,
so that I can purchase available products.

এখানে তিনটি জিনিস বোঝা যাচ্ছে:

Who?
Customer

What?
Place an order

Why?
Purchase available products

এটি implementation বলে না।

এটি behaviour-এর intent capture করে।

---

User Story Technical Specification নয়

এই distinction খুব গুরুত্বপূর্ণ।

User Story:

As a customer,
I want to view my previous orders,
so that I can review my purchase history.

এখানে বলা হয়নি:

GET /api/v1/orders

বা:

Use Spring Data JPA.

বা:

Query orders by customer_id.

কারণ এগুলো implementation decisions।

User Story primarily বলে:

Who needs what and why?

Technical design পরে বলে:

How will we provide it?

---

Why the "Why" Matters

ধরা যাক story:

As a customer,
I want to view my orders.

এটি understandable।

কিন্তু:

so that I can review my purchase history

যোগ করলে intent clearer হয়।

Why important?

কারণ later design decision-এর সময় engineer বুঝতে পারে user-এর actual need কী।

For example, যদি requirement শুধু recent order status check করা হতো, API এবং UI needs একরকম হতে পারত।

কিন্তু full purchase history দরকার হলে:

pagination
historical data
sorting

এর গুরুত্ব বেড়ে যেতে পারে।

User intent technical decision-এর context দেয়।

---

User Stories Are Not Mandatory Everywhere

Real engineering team-এ terminology vary করতে পারে।

কেউ ব্যবহার করে:

User Story

কেউ:

Feature

কেউ:

Product Requirement

কেউ সরাসরি:

Engineering Ticket

আমাদের course-এ User Story ব্যবহার করার কারণ হলো requirement decomposition শেখানো।

আমরা tool বা process worship করছি না।

Core idea:

Work-এর user-facing purpose clear থাকতে হবে।

---

Our First User Stories

আমাদের initial product requirement থেকে কয়েকটি user story তৈরি করা যায়।

Browse Products

As a customer,
I want to browse available products,
so that I can decide what to order.

Create Order

As a customer,
I want to place an order containing one or more products,
so that I can purchase available items.

View Order History

As a customer,
I want to view my previous orders,
so that I can review my purchase history.

Cancel Order

As a customer,
I want to cancel an eligible order,
so that I can stop an order I no longer want.

Pay for Order

As a customer,
I want to pay for an order,
so that the order can proceed after payment.

Manage Products

As an administrator,
I want to manage products,
so that customers can access the current product catalog.

Manage Inventory

As an administrator,
I want to manage inventory,
so that available stock remains accurate.

এই stories useful।

কিন্তু এখনও implementation-ready নয়।

কারণ details missing।

এখানেই আসে Acceptance Criteria।

---

What Are Acceptance Criteria?

Acceptance Criteria describe করে কোন conditions satisfy হলে একটি story বা feature accepted হবে।

সহজভাবে:

আমরা কীভাবে জানব যে requested behaviour correctly implemented হয়েছে?

Example User Story:

As a customer,
I want to place an order,
so that I can purchase available products.

Possible Acceptance Criteria:

- An order must contain at least one item.
- Every item must reference an existing product.
- Every requested quantity must be valid.
- Requested inventory must be available.
- The backend calculates the order total.
- A valid request creates an order.

এখন behaviour অনেক বেশি concrete।

---

Acceptance Criteria Implementation বলে না

Acceptance Criteria:

Requested inventory must be available.

এটি correct।

কিন্তু:

Use SELECT ... FOR UPDATE on the inventory row.

এটি acceptance criterion নয়।

এটি technical design বা implementation detail।

একই requirement different implementation দিয়ে satisfy করা যেতে পারে।

Requirement:

Inventory must remain valid during concurrent ordering.

Possible solutions later হতে পারে:

pessimistic locking

বা:

optimistic concurrency control

Acceptance Criteria ideally implementation-independent হওয়া উচিত যতক্ষণ implementation constraint নিজেই requirement নয়।

---

Good Acceptance Criteria Are Testable

Bad:

Order creation should work correctly.

"Correctly" কী?

Better:

Given sufficient inventory,
when a customer submits a valid order,
then the system creates the order.

আর:

Given insufficient inventory,
when a customer requests more units than are available,
then the system rejects the order.

এখন behaviour test করা যায়।

---

Given / When / Then

Acceptance Criteria লেখার একটি common format:

Given <initial condition>
When <action>
Then <expected outcome>

এটি Behaviour-Driven Development বা BDD context-এও widely used।

Example:

Given a product with 10 units available
When a customer orders 2 units
Then the order is accepted

Negative scenario:

Given a product with 1 unit available
When a customer orders 2 units
Then the order is rejected

এই format useful কারণ behaviour sequence clear হয়।

কিন্তু সব criterion এই format-এ লিখতেই হবে এমন নয়।

Simple bullet অনেক সময় better।

---

Avoid Ceremonial Given / When / Then

Bad usage:

Given that the system exists
When the customer wants to browse products
Then products should be browsable

এখানে format আছে, clarity নেই।

Given/When/Then ব্যবহার করার উদ্দেশ্য ceremony নয়।

এটি useful যখন:

initial state
action
result

গুরুত্বপূর্ণ।

For simple validation:

Order quantity must be greater than zero.

এই sentence-ই যথেষ্ট।

---

Let's Refine the Order Story

এখন আমাদের সবচেয়ে important first-version capability:

Order Creation

User Story:

As a customer,
I want to place an order containing one or more products,
so that I can purchase available items.

এখন requirement analysis থেকে আমরা জানি কিছু behaviour এখনও unclear।

কিন্তু course project এগিয়ে নেওয়ার জন্য product clarification-এর মাধ্যমে concrete rules establish করতে হবে।

এই point থেকে আমরা first-release-এর agreed product behaviour হিসেবে নিচের rules ব্যবহার করব।

---

Agreed Order Creation Behaviour

An Order Must Have at Least One Item

Empty order-এর business value নেই।

তাই:

An order must contain at least one item.

Invalid:

{
  "items": []
}

---

Quantity Must Be Positive

Each order item-এর quantity:

quantity >= 1

Valid:

1
2
5

Invalid:

0
-1
-5

Fractional quantity এই system-এর current scope-এ নেই।

আমাদের products discrete units হিসেবে treat করা হবে।

---

Referenced Product Must Exist

Customer যদি এমন product reference করে যেটি system-এ নেই:

productId = unknown

order create হবে না।

Criterion:

Every order item must reference an existing product.

---

Product Must Be Available

Initial version-এর জন্য আমরা available product বলতে এমন product বুঝব যা active এবং ordering-এর জন্য available।

Product lifecycle later domain modeling-এর সময় আরও clearly define করা হবে।

কিন্তু inactive product order করা যাবে না।

---

Inventory Must Be Sufficient

ধরা যাক:

Available inventory = 5
Requested quantity = 3

Order proceed করতে পারে।

কিন্তু:

Available inventory = 5
Requested quantity = 6

Order reject হবে।

Important invariant:

Successful order creation must not make
available inventory negative.

Concurrent ordering-এর technical solution এখন define করছি না।

সেটি later transaction module-এ আসবে।

---

The Backend Determines Price

Client order request-এ product price trusted source হবে না।

For example, client যদি পাঠায়:

{
  "productId": 10,
  "quantity": 2,
  "unitPrice": 1
}

কিন্তু actual product price যদি €50 হয়, backend client-supplied €1 ব্যবহার করবে না।

Backend current product pricing data থেকে price determine করবে।

Criterion:

The backend calculates item prices and the order total.

---

Purchase-Time Price Must Be Preserved

এটি important business clarification।

ধরা যাক order create হওয়ার সময়:

Product price = €20

পরের সপ্তাহে product price:

€25

Historical order:

€20

থাকবে।

Past order current catalog price change-এর কারণে rewrite হবে না।

তাই requirement:

The price used when an order is created
must remain part of that historical order.

Implementation later decide করবে কীভাবে এটি persist করা হবে।

---

Duplicate Product Entries

একই product যদি একই request-এ multiple times আসে:

Product A × 2
Product A × 3

Initial version-এর জন্য আমরা request-এ একই product multiple order lines হিসেবে allow করব না।

Client should combine it:

Product A × 5

Criterion:

A product may appear at most once in a single order request.

এতে first version-এর behaviour simpler এবং unambiguous থাকে।

---

What Happens If One Item Is Invalid?

ধরা যাক order:

Product A × 2
Product B × 3
Product C × 1

Product C-এর inventory unavailable।

আমরা partial order create করব না।

Whole request fail করবে।

Criterion:

Order creation is all-or-nothing.

Either:

entire order succeeds

or:

no order is created

এটি later transaction design-এর জন্য গুরুত্বপূর্ণ হবে।

---

Order Creation Acceptance Criteria

এখন complete first-pass acceptance criteria:

AC-1
An order must contain at least one item.

AC-2
Each order item must reference an existing product.

AC-3
Each product may appear at most once in the request.

AC-4
Each quantity must be a positive whole number.

AC-5
Only products available for ordering may be included.

AC-6
Requested quantity must not exceed available inventory.

AC-7
The backend determines the price of each order item.

AC-8
The backend calculates the order total.

AC-9
The price used when the order is created
must remain part of the historical order.

AC-10
If any item is invalid, the complete order request fails.

AC-11
A successful order belongs to the requesting customer.

এখন story অনেক বেশি actionable।

---

Notice What We Still Have Not Decided

আমরা এখনও define করিনি:

database tables

JPA entities

controller classes

repository interfaces

HTTP status codes

locking mechanism

transaction implementation

এগুলো later technical design-এর অংশ।

Acceptance Criteria যথেষ্ট precise behaviour define করেছে, কিন্তু technical solution dictate করেনি।

এটাই desirable।

---

Product Browsing Story

User Story:

As a customer,
I want to browse available products,
so that I can decide what to order.

Initial Acceptance Criteria:

AC-1
Only products available for ordering are returned.

AC-2
Each result includes the product information
required to make an ordering decision.

AC-3
Product price is included.

AC-4
The result can support multiple products
without requiring all products to be returned at once.

শেষ criterion ইঙ্গিত করছে pagination প্রয়োজন হতে পারে।

কিন্তু actual API pagination design later হবে।

---

Why Pagination Appears Early

ধরা যাক database-এ:

20 products

তখন সব return করা সহজ।

কিন্তু later:

100,000 products

সব record এক response-এ return করা poor design।

এই reason-এ list behaviour-এর requirement stage-এই bounded result-এর প্রয়োজন দেখা যেতে পারে।

আমরা এখন exact page size invent করব না।

Technical/API design-এর সময় সেটি decide করা হবে।

---

Order History Story

User Story:

As a customer,
I want to view my previous orders,
so that I can review my purchase history.

Acceptance Criteria:

AC-1
A customer can access only their own orders.

AC-2
Previous orders include enough information
to understand what was ordered.

AC-3
Historical item prices remain unchanged
when current product prices change.

AC-4
Order history supports multiple orders
without requiring the entire history
to be returned in one response.

এখানে security requirement user-facing behaviour-এর অংশ হয়ে গেছে:

A customer can access only their own orders.

এটি extremely important।

---

Order Cancellation Story

User Story:

As a customer,
I want to cancel an eligible order,
so that I can stop an order I no longer want.

eligible previously ambiguous ছিল।

Initial release-এর জন্য agreed behaviour:

Only unpaid orders may be cancelled.

Paid-order cancellation এবং refunds v1-এর scope-এর বাইরে থাকবে।

Acceptance Criteria:

AC-1
A customer may cancel their own unpaid order.

AC-2
A customer may not cancel another customer's order.

AC-3
A paid order cannot be cancelled in v1.

AC-4
An already-cancelled order cannot be cancelled again.

AC-5
Cancelling an order restores inventory
reserved by that order.

AC-6
A successfully cancelled order remains cancelled.

এখানে important consequence:

cancel order
    ↓
restore inventory

এটি later transactional behaviour হবে।

---

Payment Story

User Story:

As a customer,
I want to pay for my order,
so that the order can proceed after payment.

Initial acceptance criteria:

AC-1
A customer may pay only for their own order.

AC-2
Only an unpaid active order is eligible for payment.

AC-3
Payment is processed using the configured payment provider.

AC-4
A successful payment marks the order as paid.

AC-5
A failed payment must not mark the order as paid.

AC-6
The same successful payment must not be applied twice.

এখানে external integration complexity later আসবে।

বিশেষ করে:

timeout
retry
idempotency
partial failure

কিন্তু acceptance criteria business expectation establish করছে।

---

Product Management Story

User Story:

As an administrator,
I want to manage products,
so that customers can access the current product catalog.

manage word broad।

Initial release-এর জন্য আমরা behaviour narrow করি।

Administrator can:

create product
view product
update product
deactivate product

Initial version-এ physical deletion required নয়।

কারণ product historical order-এ reference হতে পারে।

Acceptance Criteria:

AC-1
An administrator can create a product.

AC-2
An administrator can update supported product information.

AC-3
An administrator can deactivate a product.

AC-4
A deactivated product cannot be ordered.

AC-5
Deactivating a product must not remove
historical order information.

AC-6
Regular customers cannot perform
administrative product operations.

এখানে আমরা delete intentionally scope-এর বাইরে রাখছি।

---

Inventory Management Story

User Story:

As an administrator,
I want to manage inventory,
so that available stock remains accurate.

Initial behaviour:

Administrator can view and adjust current inventory.

Acceptance Criteria:

AC-1
An administrator can view current inventory.

AC-2
An administrator can adjust inventory quantity.

AC-3
Inventory quantity cannot be set below zero.

AC-4
Regular customers cannot modify inventory.

AC-5
Inventory changes affect future order availability.

Later আমরা audit trail বা warehouse management যোগ করছি না।

কারণ initial requirement-এ এগুলো নেই।

---

Acceptance Criteria Should Cover Permissions

Backend feature-এর ক্ষেত্রে permission ignore করা dangerous।

Story:

Customer can view order.

Incomplete acceptance criteria:

Order details are returned.

Better:

The requesting customer owns the order.

এবং:

Another customer cannot access it.

Security behaviour feature-এর part।

এটি পরে "security team-এর problem" হিসেবে defer করা উচিত নয়।

---

Happy Path Alone Is Not Enough

Suppose:

Create Order

Happy path:

valid items
+
sufficient inventory
+
valid customer
=
order created

যদি শুধু এটুকু acceptance criteria থাকে, implementation অনেক important behaviour miss করতে পারে।

Negative cases:

empty items

unknown product

inactive product

quantity zero

negative quantity

insufficient inventory

duplicate product entry

Strong acceptance criteria happy path এবং meaningful failure paths দুটোই cover করে।

---

But Do Not Write Every Possible Test Case as Acceptance Criteria

এখানে balance দরকার।

Acceptance Criteria:

Quantity must be a positive whole number.

এটি enough।

এর জন্য আলাদা acceptance criteria:

quantity = 0 fails
quantity = -1 fails
quantity = -10 fails
quantity = -999 fails

লেখার প্রয়োজন নেই।

এগুলো tests হতে পারে।

Requirement-এর job general rule define করা।

Test suite সেই rule-এর representative cases verify করবে।

---

Acceptance Criteria vs Test Cases

Acceptance Criterion:

Requested quantity must not exceed
available inventory.

Potential test cases:

available = 10
requested = 1
→ success

available = 10
requested = 10
→ success

available = 10
requested = 11
→ failure

Acceptance criterion rule describe করে।

Test cases examples দিয়ে verify করে।

দুটো related কিন্তু same নয়।

---

Boundary Cases Matter

Backend logic-এ bugs অনেক সময় boundary-তে হয়।

Requirement:

Requested quantity must not exceed available inventory.

ধরা যাক:

available = 5

Important cases:

requested = 4

requested = 5

requested = 6

বিশেষ করে:

requested == available

valid কি না clear হতে হবে।

আমাদের rule:

requested <= available

তাই exact remaining stock order করা valid।

---

Acceptance Criteria Can Reveal Missing Requirements

Suppose আমরা cancellation story লিখছি:

A customer can cancel an eligible order.

Criterion লিখতে গিয়ে:

Cancelling an order restores reserved inventory.

সঙ্গে সঙ্গে question আসে:

When was inventory reserved?

এটি দেখায় inventory lifecycle define করা দরকার।

Acceptance Criteria শুধু requirement record করে না।

এটি unclear requirement expose করতেও সাহায্য করে।

---

User Stories Should Be Small Enough

Bad story:

As a customer,
I want to use the commerce platform,
so that I can shop online.

এটি প্রায় পুরো product।

এর মধ্যে:

browse products
create order
pay
cancel
view history

সব আছে।

এমন story implementation planning-এ useful নয়।

Better stories independently understandable হওয়া উচিত।

---

But Do Not Split Stories Artificially

অন্য extreme:

As a customer,
I want the product ID field to exist.

এটি meaningful user capability নয়।

বা:

As a customer,
I want an OrderRepository.

User repository নিয়ে care করে না।

এগুলো engineering tasks হতে পারে।

User Story এবং technical task এক জিনিস নয়।

---

User Story vs Engineering Task

Story:

As a customer,
I want to place an order,
so that I can purchase available products.

Later engineering tasks হতে পারে:

Create order domain model

Add order persistence

Implement order creation service

Expose order creation API

Add integration tests

Story user value capture করে।

Tasks implementation work break down করে।

---

One Story Can Require Multiple Tickets

ধরা যাক story:

Customer can place an order.

একটি mature codebase-এ এটি multiple tickets হতে পারে:

BACKEND-121
Create order domain model

BACKEND-122
Add order persistence

BACKEND-123
Implement inventory validation

BACKEND-124
Implement order creation workflow

BACKEND-125
Expose create-order endpoint

BACKEND-126
Add integration tests

আমরা Module 1-এর শেষ দিকে backlog তৈরি করার সময় এই breakdown করব।

---

Definition of Done Is Different

Acceptance Criteria বলে:

এই feature-এর expected behaviour কী?

Definition of Done বলে:

Team-এর perspective থেকে একটি কাজ complete হওয়ার minimum quality bar কী?

For example:

Acceptance Criteria:

Customer cannot create an order
with insufficient inventory.

Definition of Done later include করতে পারে:

implementation complete
tests added
code reviewed
documentation updated where needed
CI passes

এই distinction আমরা dedicated lesson-এ বিস্তারিত দেখব।

---

Avoid Mixing Company Process Into Product Behaviour

Acceptance Criteria-তে:

PR must have two reviewers.

লেখা উচিত নয়।

এটি team process।

আর:

Order creation must reject unavailable inventory.

এটি product behaviour।

Documentation clear রাখতে এগুলো আলাদা রাখা ভালো।

---

A Practical Story Template

আমরা course project-এ lightweight format ব্যবহার করতে পারি:

# Story

## User Story

As a ...
I want ...
so that ...

## Context

Why is this capability needed?

## Acceptance Criteria

- ...
- ...
- ...

## Out of Scope

- ...

## Open Questions

- ...

সব story-তে সব section প্রয়োজন হবে না।

কিন্তু complex story-তে context এবং out-of-scope useful।

---

Example: Create Order Story Document

# Create Order

## User Story

As a customer,
I want to place an order containing one or more products,
so that I can purchase available items.

## Acceptance Criteria

- An order must contain at least one item.
- Every item must reference an existing product.
- Each product may appear at most once.
- Quantity must be a positive whole number.
- Only products available for ordering may be included.
- Requested quantity must not exceed available inventory.
- The backend determines item prices.
- The backend calculates the order total.
- Purchase-time prices remain part of the historical order.
- If any item is invalid, the complete request fails.
- The created order belongs to the requesting customer.

## Out of Scope

- Discounts
- Coupons
- Shipping
- Multiple currencies

এই document implementation-এর জন্য অনেক useful context দেয়।

---

Avoid Over-Specifying Error Messages

Acceptance Criteria:

Invalid quantity must be rejected.

এটি fine।

কিন্তু early product story-তে:

Return HTTP 400 with code INVALID_ORDER_ITEM_QUANTITY
and exact message:
"Quantity must be greater than zero."

লেখা premature হতে পারে।

API error contract later technical design-এ standardize করা হবে।

Exception হলো যদি exact error behaviour public API contract-এর requirement হয়।

আমাদের current stage-এ নয়।

---

Avoid Designing Database Through Acceptance Criteria

Bad:

OrderItem must have product_id,
quantity and unit_price columns.

এটি database design।

Better business behaviour:

Historical order-item pricing must remain unchanged
when the current product price changes.

Later engineer decide করতে পারে:

store unit_price

যা likely solution।

কিন্তু requirement behaviour-first থাকবে।

---

Out of Scope Is Part of Clarity

Create Order story-এর scope:

basic product ordering
inventory validation
price calculation

Out of scope:

discounts
tax calculation
shipping
coupon codes
gift cards

Out-of-scope section extremely useful কারণ এটি future assumptions prevent করে।

Engineer যেন না ভাবে:

"Commerce order, তাহলে tax engine-ও বানিয়ে ফেলি।"

No.

Current problem যতটুকু require করে, ততটুকুই।

---

Do User Stories Need Estimates?

অনেক team story point বা time estimate ব্যবহার করে।

For example:

3 points
5 points
8 points

এই course-এ আমরা estimation methodology নিয়ে deep যাব না।

কারণ আমাদের current focus:

requirements
design
implementation
engineering workflow

Planning-এর সময় work size discuss করব, কিন্তু artificial estimation framework course-এর goal নয়।

---

Story Priority

সব story একই সময়ে build করতে হবে না।

আমাদের dependency roughly:

Products
   ↓
Inventory
   ↓
Orders
   ↓
Payments

Order history order creation-এর পরে meaningful।

Cancellation-ও order lifecycle-এর উপর depend করে।

তাই backlog ordering later dependencies consider করবে।

---

Vertical Slice vs Technical Layer

একটি interesting planning question:

আমরা কি firstে:

all entities
then all repositories
then all services
then all controllers

করব?

নাকি একটি small working capability end-to-end করব?

Real teams often vertical slice prefer করে।

For example:

Create Product

API
 ↓
Service
 ↓
Persistence
 ↓
Database
 ↓
Tests

তারপর next capability।

এতে system incrementally usable হয়।

আমাদের course implementation-এ এই approach extensively ব্যবহার করা হবে।

---

But Some Foundation Work Comes First

Vertical slice মানে কোনো shared foundation থাকবে না এমন নয়।

For example:

Spring Boot bootstrap
database migration setup
error-handling foundation

কিছু foundational work একবার করতে হবে।

তারপর feature-by-feature vertical development useful।

---

Acceptance Criteria and Code Review

Good Acceptance Criteria reviewer-এর জন্যও useful।

Reviewer শুধু code দেখে জিজ্ঞেস করবে না:

Does this code look clean?

বরং:

Does this change satisfy the intended behaviour?

For example:

Criterion:

A customer may not cancel another customer's order.

Reviewer code-এ ownership validation খুঁজবে।

Tests-এও expected scenario দেখতে চাইবে।

Requirement review এবং code review connected।

---

Acceptance Criteria and Testing

Later test strategy:

Acceptance Criteria
        ↓
Test Scenarios
        ↓
Automated Tests

Example:

Criterion:

Each quantity must be a positive whole number.

Potential unit/integration tests:

quantity = 1 → valid
quantity = 0 → rejected
quantity = -1 → rejected

Criterion:

A customer may not access another customer's order.

Integration test:

Customer A creates order
Customer B requests that order
→ access denied / resource unavailable according to API contract

Exact HTTP behaviour later define হবে।

---

Product Manager and Engineer Collaboration

Suppose Product says:

Customers should be able to cancel orders.

Engineer might respond:

For v1, I propose allowing cancellation only
before payment.

Cancellation will restore reserved inventory.

Paid-order cancellation and refunds
will remain out of scope.

Does that match the intended behaviour?

Product confirms।

এখন acceptance criteria লিখে রাখা যায়।

এখানে engineer requirement invent করছে না।

সে ambiguity identify করে proposal দিয়েছে এবং business confirmation পেয়েছে।

এটাই healthy collaboration।

---

Not Every Criterion Comes From Product

কিছু criterion engineering correctness থেকে আসতে পারে।

For example:

Order creation should be atomic.

Product Manager হয়তো atomic transaction শব্দ ব্যবহার করবে না।

কিন্তু product expectation হতে পারে:

We should never create half an order.

Engineering এটিকে translate করতে পারে:

Order creation must not leave partial state.

Technical solution later transaction হবে।

Engineering role হলো business intent থেকে correctness requirement derive করা।

---

Don't Hide Technical Risk Behind a Story

Story simple হতে পারে:

Customer pays for order.

কিন্তু engineer যদি জানে payment provider timeout করতে পারে, তখন risk ignore করা যাবে না।

Acceptance Criteria business expectation capture করবে:

A failed payment must not mark the order as paid.

আর technical design address করবে:

timeout
retry
idempotency
provider success / local failure

Story simplicity risk eliminate করে না।

---

Our Initial Story Set

এই project-এর v1-এর জন্য current story set:

STORY-1
Browse Available Products

STORY-2
Create an Order

STORY-3
View Order History

STORY-4
Cancel an Eligible Order

STORY-5
Pay for an Order

STORY-6
Manage Products

STORY-7
Manage Inventory

Authentication capability later security implementation-এর prerequisite হবে, কিন্তু product-facing stories-এর permissions already reflect authenticated customer/admin concepts।

---

Are These Engineering Tickets Yet?

না।

এখন এগুলো product-level stories।

Next phases:

Story
  ↓
Technical Design
  ↓
Engineering Breakdown
  ↓
Tickets

For example:

STORY-2
Create an Order

later multiple implementation tickets-এ split হবে।

এই separation intentional।

---

A Simple Quality Check for User Stories

একটি story পড়ার পরে ideally আমরা answer করতে পারি:

Who benefits?

What capability do they need?

Why do they need it?

What behaviour makes it acceptable?

যদি এগুলো unclear হয়, story refine করা দরকার।

---

A Simple Quality Check for Acceptance Criteria

প্রতিটি criterion-এর জন্য জিজ্ঞেস করুন:

Is it clear?

Can we verify it?

Is it actually required?

Is it behaviour rather than implementation?

Does it conflict with another criterion?

Does it expose an unresolved question?

এই checks অনেক ambiguity early catch করে।

---

Engineering Principle

এই lesson-এর core principle:

A requirement becomes useful engineering input when expected behaviour is clear enough that different people can independently recognize whether it has been satisfied.

User Story আমাদের বলে:

who
what
why

Acceptance Criteria বলে:

what must be true
for the work to be accepted

এগুলোর purpose paperwork নয়।

Purpose shared understanding।

---

Where We Are Now

আমাদের project progression:

Initial Product Requirement
          ↓
Requirement Analysis
          ↓
Functional / Non-Functional Requirements
          ↓
User Stories
          ↓
Acceptance Criteria

এখন আমরা major customer এবং administrator capabilities-এর expected behaviour significantly clearer করেছি।

কিন্তু এখনও একটি গুরুত্বপূর্ণ প্রশ্ন আছে:

First release-এ exactly কী build করব, এবং কোন জিনিস deliberateভাবে build করব না?

সব technically possible feature current goal-এর অংশ নয়।

পরের lesson-এ আমরা Understanding the Existing Engineering Context নিয়ে কাজ করব।

সেখানে আমরা project-টিকে isolated greenfield coding exercise হিসেবে দেখব না।

বরং একজন engineer নতুন team-এ join করলে যেসব existing technical constraint, organizational context, system boundary এবং dependency বুঝতে হয়—সেগুলো analyse করব।

এরপরই আমরা Definition of Done এবং initial engineering backlog-এর দিকে যেতে পারব।