আগের lesson-এ আমরা project context বুঝেছি।

আমরা একটি Order Management Backend তৈরি করতে যাচ্ছি এবং এই course-এ পুরো development process-টিকে একটি real engineering team-এর workflow-এর মতো follow করব।

এখন আমাদের team product side থেকে প্রথম requirement পেয়েছে।

কিন্তু requirement হাতে পাওয়া মানেই coding শুরু করা নয়।

এই lesson-এর goal হলো requirement-কে একজন backend engineer-এর মতো পড়া, analyse করা এবং implementation-এর আগে কোন information missing তা identify করা।

---

The Initial Product Requirement

ধরে নিন Product Manager আমাদের team-কে নিচের requirement দিয়েছেন:

We need an Order Management Backend for our commerce platform.

Customers should be able to browse available products and place orders.

An order may contain multiple products.

Customers should only be able to order products that are currently available in inventory.

The system should calculate the total price of the order.

Customers should be able to view their previous orders and cancel eligible orders.

Administrators should be able to manage products and inventory.

Customers should be able to pay for their orders using our payment provider.

We want the first version to support the core ordering flow.

এটি একটি perfectly reasonable product requirement।

Business perspective থেকে এখানে system-এর direction বোঝা যাচ্ছে।

কিন্তু backend engineer হিসেবে implementation শুরু করার জন্য এটি এখনও যথেষ্ট precise নয়।

এখন আমাদের কাজ হলো requirement-টিকে technical specification বানিয়ে ফেলা নয়।

প্রথম কাজ হলো এটি আসলে কী বলছে এবং কী বলছে না তা বোঝা।

---

Read Requirements Literally First

Requirement analyse করার সময় একটি common mistake হলো খুব দ্রুত নিজের assumption দিয়ে missing detail পূরণ করে ফেলা।

ধরা যাক requirement বলেছে:

Customers should be able to cancel eligible orders.

এখানে যদি আমরা মনে মনে ধরে নিই:

An unpaid order can be cancelled.

তাহলে আমরা requirement-এর মধ্যে এমন একটি business rule যোগ করলাম যা Product Manager বলেননি।

Rule-টি reasonable হতে পারে।

কিন্তু reasonable এবং confirmed একই জিনিস নয়।

Professional engineering-এ এই distinction গুরুত্বপূর্ণ।

আমরা প্রথমে আলাদা করব:

Explicit Requirement

এবং:

Our Assumption

---

Extracting Explicit Requirements

চলুন requirement থেকে শুধুমাত্র explicitly stated behaviour বের করি।

আমরা এখন কোনো নতুন rule যোগ করছি না।

Customer Capabilities

Requirement অনুযায়ী customer:

• available products browse করতে পারবে
• order place করতে পারবে
• একটি order-এ multiple products রাখতে পারবে
• previous orders দেখতে পারবে
• eligible order cancel করতে পারবে
• order-এর payment করতে পারবে

Product and Inventory Rules

আমরা explicitly জানি:

• product-এর inventory থাকবে
• available inventory না থাকলে customer product order করতে পারবে না
• administrator product manage করতে পারবে
• administrator inventory manage করতে পারবে

Order Behaviour

আমরা explicitly জানি:

• order একাধিক product contain করতে পারে
• system order total calculate করবে
• order payment provider-এর মাধ্যমে pay করা যাবে
• কিছু order cancel করা যাবে

এখন পর্যন্ত আমরা requirement-এর বাইরে যাইনি।

---

What We Still Do Not Know

এখন আসল engineering work শুরু হয়।

Requirement-এর প্রতিটি sentence-এর পেছনে unanswered questions আছে।

উদাহরণ হিসেবে:

Customers should be able to browse available products.

"Available" বলতে কী বোঝানো হয়েছে?

Possibilities:

Product exists in the database

OR

Product is active

OR

Product has inventory greater than zero

OR

Product is active and has inventory

এই চারটি behaviour এক নয়।

যদি আমরা নিজেরা একটি বেছে নিই, তাহলে হয়তো technically correct code লিখব, কিন্তু business requirement ভুল implement করব।

---

Question 1: What Is a Customer?

Requirement বারবার customer বলছে।

কিন্তু backend-এর জন্য জানতে হবে customer কীভাবে identify হবে।

Questions:

Does a customer need an account?

Must the customer be authenticated?

Can guests place orders?

Does every order belong to exactly one customer?

Can an administrator place an order on behalf of a customer?

এই course-এর initial version-এর জন্য আমরা পরে authentication implement করব।

কিন্তু requirement analyse করার সময় authentication-related assumptions এখনই identify করা দরকার।

---

Question 2: What Is a Product?

Requirement বলছে administrator product manage করবে এবং customer products browse করবে।

কিন্তু product-এর minimum information কী?

For example:

id
name
description
price
status

এগুলোর সবগুলো initial version-এর জন্য দরকার কি?

Product delete করা যাবে?

Product deactivate করা যাবে?

Already ordered product delete করলে historical order-এর কী হবে?

Product price update করলে existing order-এর price change হবে?

এগুলো implementation detail নয়।

এগুলোর অনেকগুলো business behaviour।

---

Question 3: What Does Inventory Mean?

Requirement-এর সবচেয়ে গুরুত্বপূর্ণ sentence-এর একটি হলো:

Customers should only be able to order products
that are currently available in inventory.

কিন্তু inventory নিয়ে অনেক ambiguity আছে।

ধরা যাক product-এর available quantity:

5

Customer request করল:

quantity = 6

Clearly reject করা উচিত।

কিন্তু customer যদি request করে:

quantity = 0

বা:

quantity = -2

তখন কী হবে?

এগুলো validation rule হিসেবে পরে define করব।

আরও গুরুত্বপূর্ণ প্রশ্ন:

When does inventory decrease?

Possible options:

When order is created

When payment starts

When payment succeeds

When order is shipped

প্রতিটি choice-এর consequence আছে।

যদি payment success পর্যন্ত inventory না কমাই, তাহলে একই শেষ item একাধিক customer order করতে পারে।

যদি order creation-এর সময় inventory কমাই, তাহলে unpaid orders inventory ধরে রাখতে পারে।

এই decision পরে আমাদের transaction এবং concurrency design-কে affect করবে।

তাই requirement stage-এই এটিকে identify করতে হবে।

---

Question 4: How Should Price Work?

Requirement বলছে:

The system should calculate the total price of the order.

Simple মনে হচ্ছে।

ধরা যাক:

Product A
Price: €10
Quantity: 2

Product B
Price: €5
Quantity: 3

তাহলে:

Order Total = (10 × 2) + (5 × 3)
            = 35

কিন্তু আরও গুরুত্বপূর্ণ প্রশ্ন আছে।

Order তৈরি হওয়ার পরে Product A-এর price €10 থেকে €15 হয়ে গেল।

আগের order-এর total কি এখন পরিবর্তিত হবে?

সাধারণত historical order-এর জন্য আমরা purchase-time price preserve করতে চাই।

অর্থাৎ OrderItem-এ শুধু productId এবং quantity থাকলেই যথেষ্ট নাও হতে পারে।

আমাদের হয়তো order creation-এর সময় unit price snapshot রাখতে হবে।

For example:

OrderItem

productId
quantity
unitPrice

Notice করুন—আমরা এখনও implementation করছি না।

Requirement থেকে একটি domain consequence বের করছি।

---

Question 5: What Does “Multiple Products” Mean?

Requirement বলছে:

An order may contain multiple products.

এখানেও প্রশ্ন আছে।

একই product কি order-এ দুইবার থাকতে পারবে?

For example:

Product A × 2
Product A × 3

নাকি system এটিকে normalize করবে:

Product A × 5

Customer কি অন্তত একটি item দিতে বাধ্য?

Empty order কি valid?

প্রতিটি item-এর quantity কি positive integer হতে হবে?

একটি order-এ maximum কত item থাকতে পারে?

সব প্রশ্ন first release-এর জন্য answer করা জরুরি নাও হতে পারে।

কিন্তু কোনগুলো এখন answer দরকার এবং কোনগুলো পরে defer করা যায়, সেটিও engineering judgement-এর অংশ।

---

Question 6: What Is an Eligible Cancellation?

Requirement বলছে:

Customers should be able to cancel eligible orders.

এখানে সবচেয়ে বড় ambiguity হলো eligible।

আমাদের জানতে হবে order lifecycle কী।

একটি সম্ভাব্য lifecycle হতে পারে:

PENDING
   ↓
PAID
   ↓
COMPLETED

এবং cancellation:

PENDING
   ↓
CANCELLED

কিন্তু এটি এখনও আমাদের assumption।

Product requirement যদি বলে:

Only unpaid orders can be cancelled.

তাহলে rule clear।

যদি paid order-ও cancel করা যায়, payment refund-এর question আসে।

Initial requirement refund mention করেনি।

তাহলে backend engineer হিসেবে আমাদের জিজ্ঞেস করতে হবে:

Are paid orders cancellable in the first version?

এই একটি answer system scope উল্লেখযোগ্যভাবে পরিবর্তন করতে পারে।

---

Question 7: What Does Payment Mean?

Requirement বলছে:

Customers should be able to pay for their orders
using our payment provider.

এখানে external dependency আছে।

আমাদের জানতে হবে:

Is payment synchronous?

What does a successful response look like?

Can payment fail?

Can it time out?

Can the same order be paid twice?

Does the provider support idempotency?

Do we receive webhooks?

What payment reference should we store?

সব answer initial product requirement-এ থাকা realistic নয়।

Technical discovery-এর সময় কিছু information payment provider documentation থেকে আসতে পারে।

কিছু Product Manager-এর কাছ থেকে আসবে।

কিছু engineering decision হবে।

এখানে গুরুত্বপূর্ণ distinction:

সব unanswered question Product Manager-কে করার প্রশ্ন নয়।

একজন backend engineer-কে বুঝতে হবে কোনটি business decision এবং কোনটি technical investigation।

---

Business Questions vs Technical Questions

উদাহরণ:

Can a paid order be cancelled?

এটি business question।

Product বা business stakeholder answer করবে।

অন্যদিকে:

Should we use Spring WebClient or RestClient
for the payment provider integration?

এটি technical question।

Product Manager-এর কাছে এটি জিজ্ঞেস করার প্রয়োজন নেই।

আর:

Does the payment provider support idempotency keys?

এটি external system capability question।

এর answer provider documentation থেকে আসতে পারে।

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

---

Categories of Questions

Requirement analysis-এর সময় questions কয়েকটি category-তে ভাগ করা useful।

Business Behaviour

Who can perform an action?

When is an action allowed?

What happens after the action?

Which state transitions are valid?

Data

What information must be stored?

What must remain historically accurate?

What relationships exist between entities?

Validation

Which inputs are valid?

What limits exist?

What should happen for invalid requests?

Failure Behaviour

What happens when a dependency fails?

Can an operation be retried?

Can partial success occur?

Security

Who can access which resource?

Can one customer see another customer's order?

Which operations require administrator permissions?

Scope

What belongs in version one?

What is explicitly out of scope?

এই categories requirement review-কে systematic করে।

---

Do Not Solve Everything at Once

এখানে আরেকটি common mistake হলো requirement হাতে পেয়েই every possible edge case solve করার চেষ্টা করা।

ধরা যাক আমরা brainstorm করতে করতে ভাবলাম:

discounts
coupons
tax calculation
shipping
multiple currencies
refunds
warehouse allocation
backorders
subscriptions
gift cards
fraud detection

Commerce system-এ এগুলো realistic features।

কিন্তু initial requirement-এ এগুলো নেই।

এগুলো এখন design করলে আমরা unnecessary complexity introduce করব।

Strong engineering-এর একটি অংশ হলো কী build করতে হবে জানা।

আরেকটি অংশ হলো কী এখন build করা উচিত নয় সেটি জানা।

---

Scope Control

আমাদের initial requirement-এর শেষ sentence:

We want the first version to support the core ordering flow.

এটি গুরুত্বপূর্ণ।

Product explicitly first version-এর কথা বলছে।

তাই আমরা current scope narrow রাখব।

Initial version-এর জন্য possible scope:

Products

Inventory

Customers

Orders

Payments

Basic order cancellation

Out of scope হতে পারে:

Discounts

Coupons

Shipping

Refunds

Multiple warehouses

Multiple currencies

Product recommendations

Event-driven architecture

কিন্তু একটি জিনিস মনে রাখুন:

আমরা course author হিসেবে arbitrary business rule invent করব না।

পরবর্তী lessons-এ product clarification-এর মাধ্যমে scope formally establish করব।

---

Functional Requirements

এখন requirement-কে functional behaviour হিসেবে দেখা যাক।

Functional requirement বলে system কী করতে পারবে।

For example:

Customer can view products.

Customer can create an order.

Customer can view their orders.

Customer can cancel an eligible order.

Customer can pay for an order.

Administrator can manage products.

Administrator can manage inventory.

এগুলো system behaviour describe করছে।

কিন্তু functional requirements alone production system define করার জন্য যথেষ্ট নয়।

---

Non-Functional Requirements

ধরা যাক system technically order create করতে পারে।

কিন্তু একটি request complete হতে 45 seconds লাগে।

Technically feature আছে।

Operationally system unusable হতে পারে।

Non-functional requirements system-এর quality বা operational expectation describe করে।

For example:

performance
availability
security
reliability
observability
scalability
maintainability

আমাদের initial product brief explicit non-functional target দেয়নি।

এটি অস্বাভাবিক নয়।

এই stage-এ আমাদের প্রশ্ন হতে পারে:

Do we have expected traffic?

Are there response-time expectations?

Is this business-critical?

Are there regulatory requirements?

Do we need an audit trail?

পরবর্তী lesson-এ functional এবং non-functional requirements আলাদাভাবে আরও পরিষ্কার করব।

---

Identify Invariants Early

Backend system design-এর জন্য একটি powerful concept হলো invariant।

Invariant হলো এমন একটি rule যা system-এর valid state বজায় রাখতে সবসময় true থাকতে হবে।

আমাদের current requirement থেকে একটি likely invariant দেখা যাচ্ছে:

Inventory must not become negative.

Requirement exact wording-এ এটি বলা হয়নি।

কিন্তু:

Customers should only be able to order products
that are currently available in inventory.

এর natural consequence হলো unavailable quantity sell করা যাবে না।

Later clarification-এর মাধ্যমে আমরা এটিকে formally define করব।

আরেকটি potential invariant:

An order must belong to a customer.

আর:

An order total must match its order items.

Business invariants identify করা গুরুত্বপূর্ণ কারণ এগুলো পরে domain model, transaction boundary এবং tests determine করবে।

---

Requirement Analysis Should Produce Questions

একটি good requirement review-এর output code নয়।

Output হতে পারে:

Known facts
Unknowns
Assumptions
Questions
Risks
Scope boundaries

চলুন আমাদের requirement নিয়ে একটি first-pass analysis লিখি।

---

First-Pass Requirement Analysis

Known

Customers can browse products.

Customers can create orders.

Orders can contain multiple products.

Inventory availability affects ordering.

The system calculates order totals.

Customers can view previous orders.

Some orders can be cancelled.

Administrators manage products and inventory.

Orders can be paid through an external payment provider.

Unknown

How customers authenticate.

Whether guest checkout exists.

Exact product fields.

When inventory is reduced.

Exact order statuses.

Cancellation eligibility.

Whether paid orders can be cancelled.

Whether refunds are required.

Payment provider behaviour.

What historical pricing data must be preserved.

Initial traffic expectations.

Likely Risks

Overselling inventory.

Incorrect order totals.

Duplicate payment attempts.

Unauthorized access to another customer's order.

External payment provider failures.

এই risks এখনই solve করার প্রয়োজন নেই।

কিন্তু early visibility valuable।

---

Avoid Hidden Assumptions

ধরা যাক developer requirement পড়ল এবং code লিখল:

if (order.getStatus() == OrderStatus.PENDING) {
    order.cancel();
}

এখানে developer silently decide করেছে:

Only PENDING orders can be cancelled.

Code compile করবে।

Tests pass করতে পারে।

কিন্তু business যদি চেয়েছিল PAID order-ও cancellation support করবে, implementation wrong।

Hidden assumption-এর dangerous অংশ হলো এটি documentation-এ দেখা যায় না।

এটি code-এর ভিতরে business decision হয়ে বসে থাকে।

Better approach:

Requirement says "eligible orders".

Eligibility is undefined.

Clarify cancellation rules before implementation.

---

Clarification Does Not Mean Endless Meetings

Requirement clarification-এর কথা শুনে মনে হতে পারে প্রতিটি ছোট detail-এর জন্য meeting করতে হবে।

না।

Good engineering communication concise হতে পারে।

For example:

Question:

For v1, which order states should customers be able to cancel?

Proposed behaviour:

Only unpaid orders can be cancelled.
Paid orders and refunds will remain out of scope.

এখানে engineer শুধু question করেনি।

সে একটি concrete proposal-ও দিয়েছে।

Stakeholder সহজে বলতে পারে:

Yes, use that behaviour.

অথবা:

No, paid orders also need cancellation.

এই style communication efficient।

---

Ask Questions With Context

Bad question:

How should cancellation work?

এটি খুব broad।

Better:

For the first release, can we limit cancellation
to unpaid orders?

If an unpaid order is cancelled, we will restore
its reserved inventory.

Refunds for paid orders would remain out of scope.

এখন stakeholder বুঝতে পারছে decision-এর consequence কী।

Senior engineers সাধারণত শুধু questions collect করে না।

তারা ambiguity narrow করে actionable decision তৈরি করে।

---

Separate Requirement From Proposed Solution

আরেকটি গুরুত্বপূর্ণ habit:

Requirement এবং solution mix করবেন না।

Requirement:

A customer must not be able to purchase
more inventory than is available.

Potential solution:

Use a database transaction with row-level locking.

এগুলো এক জিনিস নয়।

Business requirement stable থাকতে পারে, কিন্তু technical solution change হতে পারে।

For example, later solution হতে পারে:

optimistic concurrency

বা অন্য কোনো approach।

তাই documentation-এ ideally:

What must happen

এবং:

How we plan to implement it

আলাদা রাখা ভালো।

---

Product Language and Engineering Language

Product requirement বলতে পারে:

Customers should be able to quickly see their previous orders.

"Quickly" human-friendly শব্দ।

কিন্তু engineering-এর জন্য measurable নয়।

Technical requirement হতে পারে:

Typical order-history requests should complete
within an agreed latency target.

কিন্তু target কত?

200 ms?
500 ms?
2 seconds?

এটি context-এর উপর নির্ভর করে।

Requirement analysis-এর কাজ হলো vague wording notice করা।

নিজে arbitrary number invent করা নয়।

---

Example: Analysing One Requirement

চলুন একটি sentence পুরো process দিয়ে analyse করি।

Requirement:

Customers should be able to place orders.

Step 1 — Explicit Behaviour

Customer order create করতে পারবে।

Step 2 — Missing Information

Must the customer be authenticated?

Can an order be empty?

Can the same product appear twice?

What quantity values are valid?

What happens when a product does not exist?

What happens when inventory is insufficient?

When is inventory reserved or reduced?

How is price calculated?

Step 3 — Risks

Overselling

Incorrect pricing

Invalid order state

Duplicate requests

Step 4 — Decisions Needed Before Implementation

At minimum:

Order item validation

Inventory behaviour

Pricing behaviour

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

---

Requirement Review Is an Engineering Skill

Junior engineers অনেক সময় requirement-কে instruction হিসেবে দেখে:

Someone told me what to build.
I will implement it.

Experienced engineers requirement-কে conversation-এর starting point হিসেবে দেখে।

তাদের চিন্তা হয়:

Do we understand the behaviour?

Are there contradictions?

What assumptions are we making?

What failure cases matter?

What is outside the scope?

Can this be implemented safely?

এর অর্থ Product Manager-এর requirement reject করা নয়।

এর অর্থ engineering responsibility নেওয়া।

---

Our Current Clarification List

আমাদের Order Management Backend-এর জন্য first clarification list এখন এমন হতে পারে:

1. Are customers required to authenticate?

2. Can guests place orders?

3. What makes a product "available"?

4. When should inventory be reduced or reserved?

5. Must an order contain at least one item?

6. Can the same product appear multiple times in one order?

7. Should the purchase-time product price be stored with the order?

8. Which order states are cancellable?

9. Are refunds required in v1?

10. What are the initial order states?

11. What happens after successful payment?

12. What payment-provider capabilities are available?

13. Which product and inventory operations can administrators perform?

14. Are there important performance or availability expectations?

15. What is explicitly out of scope for the first release?

সব প্রশ্ন একই priority-এর নয়।

পরের lessons-এ আমরা এগুলো refine করব।

---

A Practical Requirement Review Template

Real project-এ আপনি lightweight template ব্যবহার করতে পারেন:

# Requirement Review

## Problem

What business problem are we solving?

## Users

Who uses this capability?

## Explicit Requirements

What behaviour has been requested?

## Open Questions

What is still ambiguous?

## Assumptions

What are we currently assuming?

## Risks

What could make the implementation incorrect or unsafe?

## Out of Scope

What are we deliberately not building?

এটি RFC নয়।

এটি requirement বুঝতে সাহায্য করার একটি lightweight working document।

সব team-এ এমন document প্রয়োজন হবে না।

কিন্তু thinking model হিসেবে এটি useful।

---

What We Should Not Do Yet

আমাদের কাছে এখনও enough information নেই:

to design the database schema

to create JPA entities

to define all API endpoints

to create OrderStatus enum

to choose transaction strategy

to implement payment integration

আমরা এগুলোর কিছু নিয়ে educated idea করতে পারি।

কিন্তু এখনই finalise করলে solution requirement-এর আগে চলে যাবে।

এই course-এ আমরা intentionally সেই shortcut নেব না।

---

Engineering Principle

এই lesson-এর সবচেয়ে গুরুত্বপূর্ণ principle:

Never turn an assumption into a business rule without noticing that you did it.

সব ambiguity eliminate করা সম্ভব নয়।

Real-world software-এ সবসময় কিছু uncertainty থাকবে।

কিন্তু strong engineer জানে:

What do I know?

What am I assuming?

What must I clarify?

What can safely wait?

এই awareness অনেক production bug prevent করতে পারে।

---

Before We Move Forward

আমাদের initial product requirement এখন আর শুধু কয়েকটি paragraph নয়।

আমরা এর মধ্যে থেকে বের করেছি:

explicit behaviour
open questions
possible invariants
risks
scope uncertainty

এটাই requirement analysis-এর purpose।

আমাদের next step হলো requirement-গুলোকে আরও structuredভাবে classify করা।

বিশেষ করে আমরা আলাদা করব:

Functional Requirements

vs

Non-Functional Requirements

কারণ একটি backend শুধু feature implement করলেই production-ready হয় না।

System কী করবে তার পাশাপাশি system কেমনভাবে behave করবে সেটিও গুরুত্বপূর্ণ।

---

Summary

এই lesson-এ আমরা শিখেছি:

• Product requirement implementation instruction নয়; এটি engineering discussion-এর starting point।
• Explicit requirement এবং assumption আলাদা রাখতে হয়।
• Ambiguous business behaviour implementation-এর আগে identify করা উচিত।
• সব unanswered question Product Manager-এর জন্য নয়।
• Business, technical এবং external-system questions আলাদা করতে হয়।
• Requirement analysis-এর সময় scope এবং non-goals equally important।
• Early risk এবং invariant identification later design decisions improve করে।
• Strong engineers code লেখার আগে system behaviour বুঝতে চেষ্টা করে।

আমাদের Order Management Backend-এর requirement এখনো final নয়।

এবং সেটিই expected।

পরের lesson-এ আমরা Functional vs Non-Functional Requirements নিয়ে কাজ করব এবং আমাদের project-এর requirements-কে আরও precise engineering language-এ structure করব।