আগের lesson-এ আমরা initial product requirement analyse করেছি এবং দেখেছি একটি requirement document পড়েই coding শুরু করা ঠিক নয়।

আমরা আলাদা করেছি:

• explicitly stated behaviour
• assumptions
• open questions
• risks
• scope uncertainty

এখন next step হলো requirement-গুলোকে আরও structuredভাবে বোঝা।

Backend system design করার সময় requirements broadly দুই ধরনের হতে পারে:

Functional Requirements

এবং:

Non-Functional Requirements

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

কারণ একটি system কী কী feature support করবে সেটি জানলেই যথেষ্ট নয়।

আমাদের এটিও জানতে হবে system-টি:

• কতটা reliable হতে হবে
• কতটা secure হতে হবে
• expected load-এর মধ্যে কেমন perform করবে
• failure হলে কীভাবে behave করবে
• operate এবং observe করা কতটা সহজ হবে

এই lesson-এ আমরা এই দুই ধরনের requirement আলাদা করব এবং আমাদের Order Management Backend-এর context-এ এগুলো analyse করব।

---

Functional Requirement কী?

Functional requirement describe করে system কী করবে।

সহজভাবে:

কোন user বা system কোন action করতে পারবে এবং সেই action-এর expected behaviour কী?

For example:

Customer can view available products.

এটি functional requirement।

কারণ এটি একটি capability describe করছে।

আরেকটি example:

Customer can create an order containing multiple products.

এটিও functional।

আর:

Administrator can update product inventory.

এটিও functional requirement।

এগুলো system-এর behaviour define করে।

---

আমাদের Current Functional Requirements

Initial product requirement থেকে আমরা ইতোমধ্যে কয়েকটি functional capability পেয়েছি।

Product Browsing

Customers should be able to browse available products.

এই requirement থেকে আমরা জানি customer-এর জন্য product information retrieve করার capability প্রয়োজন।

কিন্তু available শব্দটির exact meaning এখনো clarify করা দরকার।

---

Order Creation

Customers should be able to place orders.

এটি broad functional requirement।

আমরা ইতোমধ্যে জানি:

An order may contain multiple products.

এবং:

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

তাই order creation-এর behaviour inventory-এর সঙ্গে connected।

---

Price Calculation

The system should calculate the total price of the order.

এটি functional requirement।

System শুধু client-provided total accept করবে না।

Backend নিজে order total determine করবে।

এটি important business behaviour।

---

Order History

Customers should be able to view their previous orders.

এখানেও একটি clear capability আছে।

কিন্তু পরে আমাদের clarify করতে হবে:

Can customers view only their own orders?

How are orders sorted?

Do we need pagination?

Which details are shown?

এই questions functional behaviour refine করবে।

---

Order Cancellation

Customers should be able to cancel eligible orders.

Functional capability clear।

কিন্তু eligibility এখনও undefined।

তাই requirement incomplete।

এখানে important lesson হলো:

Requirement functional হলেই automatically precise হয় না।

---

Product Management

Administrators should be able to manage products.

এটি functional requirement।

কিন্তু manage broad।

এর মধ্যে থাকতে পারে:

Create product

Update product

Deactivate product

View product

Delete product

কিন্তু initial brief-এর wording থেকে সব operation assume করা যাবে না।

এগুলো later clarification-এর বিষয়।

---

Inventory Management

Administrators should be able to manage inventory.

Again, functional capability আছে।

কিন্তু exact operations undefined।

For example:

Set inventory quantity?

Increase inventory?

Decrease inventory?

View current inventory?

Technical design-এর আগে এগুলো clarify করতে হবে।

---

Payment

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

এটিও functional requirement।

এখানে system অন্য একটি external system-এর সঙ্গে interact করবে।

Later implementation-এর সময় payment integration details আসবে।

---

Functional Requirement শুধু Endpoint নয়

Backend development শেখার সময় অনেক learner functional requirement দেখেই endpoint ভাবতে শুরু করে।

For example:

Customer can create an order.

সঙ্গে সঙ্গে চিন্তা:

POST /orders

এটি natural।

কিন্তু functional requirement endpoint-এর চেয়ে broader।

Requirement:

Customer can cancel an eligible order.

API হতে পারে:

POST /orders/{id}/cancel

বা:

PATCH /orders/{id}

Technical design later decide করবে কোন API shape best।

Requirement-এর মূল বিষয়:

Eligible customer can cause an eligible order
to transition into a cancelled state.

Endpoint হলো সেই behaviour expose করার একটি mechanism।

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

Requirement
    ↓
Technical Design
    ↓
API

API নিজে requirement নয়।

---

Behaviour Should Be Observable

একটি useful functional requirement এমন হওয়া উচিত যাতে আমরা পরে verify করতে পারি behaviour correct কি না।

Bad:

The ordering experience should be good.

এটি verify করা কঠিন।

Better:

A customer can create an order containing
one or more valid products.

আরও precise:

If sufficient inventory is available,
the system creates the order and returns its identifier.

আর invalid condition:

If requested inventory is unavailable,
the system rejects the order.

এখন behaviour test করা সম্ভব।

---

Positive and Negative Behaviour

Functional requirement লিখতে গিয়ে শুধু success path নিয়ে ভাবলে system incomplete থাকে।

For example:

Customer can create an order.

Success case:

Valid customer
Valid product
Valid quantity
Enough inventory

→ order created

কিন্তু failure behaviour?

Unknown product

Invalid quantity

Insufficient inventory

Empty order

প্রতিটি ক্ষেত্রে expected outcome define করা দরকার হতে পারে।

এই reason-এ functional requirements পরে acceptance criteria-এর সঙ্গে closely connected হবে।

---

Non-Functional Requirement কী?

Non-functional requirement describe করে system কীভাবে operate করবে।

Functional requirement বলে:

Customer can create an order.

Non-functional requirement বলতে পারে:

Order creation must remain reliable under expected traffic.

অথবা:

A customer must never access another customer's private order data.

অথবা:

The service must expose enough operational information
for engineers to diagnose failures.

এখানে নতুন business feature যোগ হয়নি।

বরং existing feature-এর quality, constraint বা operational expectation define হয়েছে।

---

Functional vs Non-Functional: Simple Comparison

ধরা যাক requirement:

Customer can view order history.

এটি functional।

এখন:

Order history must only expose orders belonging
to the authenticated customer.

Security requirement।

আর:

Order history should remain responsive
under expected production traffic.

Performance concern।

আর:

Failures while loading order history
should be visible through logs and metrics.

Observability concern।

Feature একই।

কিন্তু quality expectations আলাদা।

---

Common Non-Functional Requirement Categories

Backend system-এর জন্য কয়েকটি common category আছে।

আমরা course-এ সব category একই depth-এ cover করব না।

কিন্তু একজন backend engineer হিসেবে এগুলো চিনতে হবে।

---

Performance

Performance requirement বলে system কত দ্রুত বা কত efficiently কাজ করবে।

Examples:

API response latency

Database query latency

Number of requests handled per second

Batch processing duration

আমাদের initial brief কোনো concrete latency target দেয়নি।

তাই আমরা এখন invent করব না:

All endpoints must respond within 200 ms.

এটি arbitrary হবে।

বরং open question হিসেবে রাখব:

Are there explicit response-time expectations?

এবং:

What production traffic should the first version support?

---

Scalability

Scalability হলো load বাড়লে system কীভাবে handle করবে সেই concern।

For example:

10 orders per minute

এবং:

10,000 orders per second

এর architecture একই হওয়া প্রয়োজন নেই।

কিন্তু এখানেও important principle:

Expected scale না জেনে massive scale-এর জন্য architecture build করা উচিত নয়।

আমাদের current course project-এর goal distributed-scale commerce platform বানানো নয়।

আমরা first version-এর জন্য professional backend foundation তৈরি করছি।

তাই unnecessary complexity introduce করব না।

---

Reliability

Reliability concern করে system expected behaviour consistently maintain করতে পারছে কি না।

Order system-এর ক্ষেত্রে reliability particularly important।

For example:

Payment succeeded,
but order remained unpaid.

এটি reliability problem।

আর:

Inventory was reduced,
but order creation failed.

এটিও serious consistency issue।

আর:

Same payment was processed twice.

এটিও reliability concern।

এই ধরনের failure later modules-এ transactions, idempotency এবং integration design-এর সঙ্গে connected হবে।

---

Availability

Availability হলো system users-এর request serve করার জন্য available কি না।

একটি service যদি feature-perfect হয় কিন্তু প্রায়ই down থাকে, production perspective থেকে সেটি useful নয়।

Questions হতে পারে:

Is this service business-critical?

Is occasional downtime acceptable?

Do we have an availability target?

Initial requirement কোনো SLA বা availability target দেয়নি।

তাই আমরা number invent করব না।

---

Security

Security backend requirements-এর central অংশ।

Functional requirement:

Customer can view previous orders.

Security expectation:

Customer must not be able to view
another customer's orders.

Administrative operation:

Administrator can update inventory.

Security expectation:

Regular customers must not have access
to administrative inventory operations.

এই requirements পরে authentication এবং authorization design determine করবে।

---

Data Integrity

Order Management Backend-এর জন্য data integrity critical।

Examples:

Inventory should never become negative
because of successful order placement.

Order totals must remain internally consistent
with recorded order items.

Historical orders should not accidentally change
because current product data changes.

এই ধরনের requirement অনেক সময় functional এবং non-functional-এর boundary-তে পড়ে।

Real-world categorization সবসময় perfect নয়।

এখানে label-এর চেয়ে behaviour এবং invariant clear করা বেশি গুরুত্বপূর্ণ।

---

Maintainability

Production software শুধু আজ কাজ করলেই যথেষ্ট নয়।

পরের মাসে engineer-দের change করতে হবে।

Maintainability concerns:

Can engineers understand the code?

Are responsibilities separated clearly?

Can important behaviour be tested?

Can configuration change safely?

Can a new feature be added without rewriting everything?

সব maintainability expectation formal requirement document-এ লেখা থাকে না।

কিন্তু engineering design-এর জন্য এটি important।

---

Observability

Production system fail করলে আমাদের জানতে হবে কী ঘটছে।

Observability-এর মধ্যে থাকতে পারে:

Logs
Metrics
Health checks
Request correlation
Operational dashboards
Tracing

এই course-এর current scope অনুযায়ী আমরা later:

structured logging
metrics
health checks
request IDs

নিয়ে কাজ করব।

Advanced distributed tracing architecture এই course-এর scope নয়।

---

Recoverability

System failure হলে recovery কীভাবে হবে সেটিও গুরুত্বপূর্ণ।

For example:

Deployment failed.

Can we rollback?

Database migration failed.

Can the previous application version still run?

External payment provider timed out.

Can the operation safely retry?

এই questions later deployment এবং external integration modules-এ গুরুত্বপূর্ণ হবে।

---

Compliance Is Context-Dependent

কিছু system-এর জন্য legal বা regulatory requirements থাকতে পারে।

For example:

financial regulations

personal data requirements

audit requirements

আমাদের current fictional product requirement এমন specific compliance constraint দেয়নি।

তাই course project-এর জন্য arbitrary regulation invent করা হবে না।

কিন্তু real project-এ engineer হিসেবে আপনাকে জানতে হবে:

Are there compliance requirements that affect this feature?

---

Non-Functional Requirement Measurable হওয়া ভালো

Bad:

The system should be fast.

fast measurable নয়।

Better:

The system should meet the agreed latency target
for normal production traffic.

আর যদি actual target known হয়:

95% of requests should complete within X milliseconds.

কিন্তু X অবশ্যই business বা engineering context থেকে আসতে হবে।

নিজে বানানো যাবে না।

Bad:

The system must be highly available.

Better:

The service must meet the agreed availability target.

আর concrete target agreed হলে সেটি record করা হবে।

---

Avoid Fake Precision

Engineers কখনও কখনও specification professional দেখানোর জন্য arbitrary number লিখে দেয়।

For example:

99.999% availability

50 ms response time

100,000 requests per second

এগুলো impressive শোনাতে পারে।

কিন্তু context ছাড়া meaningless।

প্রতিটি target-এর cost আছে।

For example:

Higher availability
        ↓
More redundancy
        ↓
More operational complexity
        ↓
More cost

তাই requirement target বাস্তব need থেকে আসা উচিত।

---

Product Requirement থেকে NFR বের করা

আমাদের initial brief explicit NFR দেয়নি।

তবুও কিছু important concern identify করা যায়।

Notice করুন—আমরা এখনও exact target invent করছি না।

Security Concern

কারণ system customers এবং administrators distinguish করবে।

Open questions:

How will customers authenticate?

How will administrators authenticate?

How will authorization be enforced?

---

Reliability Concern

Order creation inventory modify করতে পারে।

Payment external provider-এর সঙ্গে communicate করবে।

তাই risks:

Partial order creation

Incorrect inventory update

Duplicate payment

Payment timeout

---

Data Integrity Concern

System order total calculate করবে।

Inventory availability enforce করবে।

তাই important invariants likely include:

Order total must be calculated by the backend.

Successful orders must respect available inventory.

Exact inventory reservation model later clarify হবে।

---

Performance Concern

Customers products browse করবে এবং previous orders দেখবে।

Potential questions:

How many products might exist?

How many historical orders can a customer have?

Do list APIs need pagination?

What traffic should we expect?

---

Observability Concern

কারণ production system operate করতে হবে।

Questions:

How will failures be diagnosed?

What health information should the service expose?

Which business failures should appear in metrics?

আমরা later production-readiness module-এ এগুলো implement করব।

---

Requirement Priority

সব requirement একই priority-এর নয়।

একটি team commonly concepts ব্যবহার করতে পারে যেমন:

Must Have

Should Have

Could Have

Won't Have for Now

বা অন্য prioritization method।

আমাদের জন্য সবচেয়ে গুরুত্বপূর্ণ হলো v1 scope clear করা।

For example:

Must support core order creation.

কিন্তু:

Discount campaigns

initial requirement-এ নেই।

তাই system future-এ discount support করতে পারে বলে এখন থেকেই complicated pricing engine build করা ঠিক নয়।

---

Functional Requirement Decomposition

Broad requirement:

Customer can place an order.

এটিকে smaller behaviours-এ decompose করা যায়।

For example:

Customer provides one or more requested items.

System validates requested products.

System validates quantities.

System checks required inventory.

System determines item prices.

System calculates the total.

System persists the resulting order.

কিন্তু caution:

এই decomposition-এর কিছু অংশ implementation-oriented হতে পারে।

তাই decomposition করার সময় requirement এবং design-এর boundary aware থাকতে হবে।

---

Functional Requirement এবং Business Rule

Functional capability:

Customer can cancel an order.

Business rule:

Only eligible orders can be cancelled.

Functional requirement বলে capability আছে।

Business rule বলে capability কোন condition-এ valid।

আর invariant বলতে পারে:

A cancelled order cannot return to an active state.

সবগুলো system behaviour-এর অংশ।

Backend design-এর জন্য তিনটিই important।

---

Example Requirement Set

ধরা যাক clarification-এর পরে একটি feature-এর requirement এমন হতে পারে:

Feature:
Create an order.

Functional Behaviour:

- Customer submits one or more order items.
- Each item references an existing product.
- Each quantity must be valid.
- Requested inventory must be available.
- Backend determines the order price.
- A valid request creates an order.

তার পাশে non-functional concerns:

Security:

Only an authenticated customer can create
an order for themselves.

Reliability:

Order creation must not leave partial state
if the operation fails.

Data Integrity:

Inventory-related rules must remain valid
even when concurrent requests occur.

Observability:

Unexpected order creation failures
must be diagnosable.

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

---

Some Requirements Cross Categories

Real-world requirements সবসময় textbook category-তে neatly fit করে না।

For example:

Inventory must never become negative.

এটি কি functional?

না non-functional?

কেউ এটিকে business invariant বলবে।

কেউ data integrity requirement বলবে।

কেউ functional correctness-এর অংশ বলবে।

এখানে classification নিয়ে debate করে বেশি সময় নষ্ট করার প্রয়োজন নেই।

Important হলো:

The rule is explicit.

Everyone understands it.

The implementation protects it.

Tests verify it.

---

Requirement Traceability

Large engineering project-এ useful practice হলো understand করা:

Why does this code exist?

Ideally flow:

Product Requirement
        ↓
Engineering Requirement
        ↓
Ticket
        ↓
Implementation
        ↓
Test

For example:

Requirement:
Customers cannot order unavailable inventory.

Later ticket:

BACKEND-xxx
Validate inventory during order creation.

Implementation সেই behaviour enforce করবে।

Integration test verify করবে insufficient inventory request reject হয়।

এভাবে code business requirement-এর সঙ্গে trace করা সহজ হয়।

---

Testing Starts at Requirement Time

Testing implementation শেষে শুরু হয়—এমনভাবে ভাবা ঠিক নয়।

Requirement পড়ার সময়ই test scenarios মাথায় আসা উচিত।

Requirement:

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

Possible scenarios:

Inventory = 10
Requested = 2
→ success

Inventory = 2
Requested = 2
→ expected behaviour?

Inventory = 1
Requested = 2
→ reject

Inventory = 0
Requested = 1
→ reject

এই questions requirement refine করতেও সাহায্য করে।

---

Failure Cases Are Requirements Too

External payment example:

Functional requirement:

Customer can pay for an order.

কিন্তু payment provider fail করলে?

Possible outcomes:

Payment declined

Provider timeout

Provider unavailable

Our database fails after provider success

আমরা সব failure এখন solve করব না।

কিন্তু requirement analysis-এ failure modes recognize করা গুরুত্বপূর্ণ।

Production backend-এর quality মূলত happy path-এর বাইরে বোঝা যায়।

---

Our Requirement Document Is Still Evolving

এই মুহূর্তে আমাদের কাছে high-level requirements আছে।

আমাদের উচিত নয় এগুলোকে prematurely final specification মনে করা।

Current state roughly:

Product Brief
    ↓
Requirement Analysis
    ↓
Functional / Non-Functional Classification
    ↓
Clarification
    ↓
Acceptance Criteria
    ↓
Technical Design

আমরা এখন middle stage-এ আছি।

---

Working Functional Requirement List

বর্তমান product brief-এর ভিত্তিতে আমাদের initial functional list:

FR-1
Customers can browse available products.

FR-2
Customers can place orders.

FR-3
An order can contain multiple products.

FR-4
Ordering is constrained by available inventory.

FR-5
The backend calculates order totals.

FR-6
Customers can view previous orders.

FR-7
Customers can cancel eligible orders.

FR-8
Customers can pay for orders through the payment provider.

FR-9
Administrators can manage products.

FR-10
Administrators can manage inventory.

এগুলো এখনও final নয়।

Clarification-এর পরে wording change হতে পারে।

---

Working Non-Functional Concern List

এগুলো concrete targets নয়।

এগুলো areas যেখানে requirement বা engineering decision দরকার।

NFR Area: Security

Customer and administrator capabilities
must be protected appropriately.

NFR Area: Data Integrity

Order, price, and inventory state
must remain internally consistent.

NFR Area: Reliability

Failures should not leave the system
in unintended partial states.

NFR Area: Performance

Expected traffic and list sizes
must be understood before finalizing performance targets.

NFR Area: Observability

Production failures must be diagnosable.

NFR Area: Maintainability

The application should remain understandable
and safely changeable as requirements evolve.

Notice করুন আমরা exact SLA বা performance number দিইনি।

কারণ সেগুলোর evidence এখনো নেই।

---

What Goes Into the Product Requirement?

সব technical concern Product Manager-এর requirement document-এ যেতে হবে না।

For example:

Database indexes

connection pool size

Spring configuration

এগুলো engineering implementation details।

অন্যদিকে:

Customer cannot see another customer's orders.

এটি product behaviour এবং security expectation দুই দিক থেকেই important।

Good collaboration মানে product এবং engineering concerns-এর boundary বোঝা।

---

A Useful Review Method

Requirement analyse করার সময় প্রতিটি feature-এর জন্য চারটি question করতে পারেন:

1. What should happen?

2. When should it be allowed?

3. What should happen when it cannot succeed?

4. What qualities or constraints matter?

Example:

Feature:
Order cancellation

Question 1:

What should happen?

The order becomes cancelled.

Question 2:

When is it allowed?

Still unclear.

Question 3:

What happens if cancellation is not allowed?

Still needs definition.

Question 4:

What constraints matter?

Authorization, inventory consistency,
and possibly payment state.

এখন আমরা clearly দেখতে পাচ্ছি কী clarify করতে হবে।

---

Avoid Architecture Requirements Without Reason

একটি dangerous requirement হতে পারে:

The system must use microservices.

যদি business problem microservices require না করে, এটি requirement-এর পরিবর্তে premature technical constraint হয়ে যায়।

আর:

The system must use Kafka.

এটিও functional requirement নয়।

Technology choice-এর reason থাকা উচিত।

আমাদের current project-এ আমরা intentionally simple application দিয়ে শুরু করছি।

কারণ current business requirement-এর জন্য unnecessary distributed architecture justify করা হয়নি।

---

Requirement Quality Checklist

একটি requirement review করার সময় আপনি দেখতে পারেন এটি:

Clear?

Different people কি একই meaning বুঝবে?

Testable?

Behaviour correct কি না verify করা যাবে?

Necessary?

এটি actual problem solve করছে?

Scoped?

এটি current release-এর অংশ?

Consistent?

অন্য requirement-এর সঙ্গে conflict করছে না?

Feasible?

Known constraints-এর মধ্যে implement করা সম্ভব?

সব requirement perfect হবে না।

কিন্তু এগুলো useful review questions।

---

Engineering Does Not Mean Making Requirements Bigger

Strong engineer হওয়া মানে requirement-এর সঙ্গে আরও technology যোগ করা নয়।

Weak interpretation:

Order system?

Let's add:
Kafka
Redis
Elasticsearch
Kubernetes
CQRS
Event Sourcing

Strong interpretation:

What behaviour is required?

What risks exist?

What is the simplest design
that safely satisfies those requirements?

এই mindset আমরা পুরো course জুড়ে follow করব।

---

Where We Are Now

আমাদের project এখন পর্যন্ত:

Initial Product Brief
        ↓
Requirement Analysis
        ↓
Functional Requirements
        ↓
Non-Functional Concerns

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

আমাদের next problem হলো:

How do we define exactly what success looks like?

For example:

Customer can create an order.

এটি এখনও broad।

কোন conditions fulfil হলে ticket complete বলা যাবে?

এই জায়গায় আসে:

User Stories

এবং:

Acceptance Criteria

---

Engineering Principle

এই lesson-এর core principle:

A feature is not fully understood until both its behaviour and the qualities that matter around that behaviour are considered.

Functional requirement বলে system কী করবে।

Non-functional requirement বলে সেই capability কতটা secure, reliable, performant, observable বা maintainable হওয়া প্রয়োজন।

দুটোর balance ছাড়া production software incomplete।

---

Summary

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

• Functional requirement system-এর capability এবং behaviour describe করে।
• Non-functional requirement system-এর quality, constraint এবং operational expectation describe করে।
• API endpoint নিজে business requirement নয়।
• Success path-এর পাশাপাশি invalid এবং failure behaviour consider করা দরকার।
• Security, reliability, data integrity, performance এবং observability backend development-এর গুরুত্বপূর্ণ concerns।
• Non-functional target evidence ছাড়া invent করা উচিত নয়।
• Arbitrary latency, throughput বা availability number professional specification তৈরি করে না।
• কিছু rule functional/non-functional category-এর boundary-তে থাকতে পারে; clear behaviour classification-এর চেয়ে বেশি important।
• Requirement থেকেই testing scenarios ভাবা শুরু করা যায়।
• Architecture technology দিয়ে requirement define করা উচিত নয়।
• Simpler solution preferable যতক্ষণ সেটি actual requirements safely satisfy করে।

পরের lesson-এ আমরা User Stories and Acceptance Criteria নিয়ে কাজ করব।

সেখানে আমাদের broad requirements-কে ছোট, testable এবং engineering-ticket-ready behaviour-এ convert করা শুরু হবে।