Requirements: কাজ ও মানের চাহিদা নির্ধারণ
Functional and Non-Functional Requirements
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- Functional ও non-functional requirement আলাদা করা
- অস্পষ্ট লক্ষ্যকে যাচাইযোগ্য করা
- Scope ও assumption লিখতে শেখা
সমস্যা দিয়ে শুরু
একজন বলেন, “Daraz-এর মতো দ্রুত একটি shop চাই।” কথাটি দিয়ে database schema বা server count নির্ধারণ করা যায় না। দোকানে কী কী কাজ হবে, কোন কাজ আগে দরকার এবং “দ্রুত” বলতে কী বোঝানো হচ্ছে—এগুলো না জানলে architecture অকারণে বড় হবে বা গুরুত্বপূর্ণ জায়গায় দুর্বল থাকবে।
সহজ করে বুঝি
Functional requirement বলে system কী করবে: product search, cart, order, refund। Non-functional requirement বলে সেই কাজের গুণগত শর্ত: response time, availability, security, data durability ও cost।
“দ্রুত হবে” যাচাই করা কঠিন। বরং লিখুন, “সম্মত load profile-এ product detail endpoint-এর ৯৫ শতাংশ response ৩০০ ms-এর মধ্যে থাকবে।” এটি একটি উদাহরণস্বরূপ লক্ষ্য, benchmark নয়। Load profile, measurement boundary এবং কোন request বাদ যাবে—এসব না লিখলে সংখ্যাটিও অসম্পূর্ণ।
পরিচিত একটি উপমা
বাড়ি তৈরির functional requirement হতে পারে তিনটি bedroom। Non-functional requirement হতে পারে ভূমিকম্পের সহনশীলতা, পর্যাপ্ত আলো এবং সর্বোচ্চ budget। বেশি bedroom দিয়ে দুর্বল foundation-এর ক্ষতি পূরণ হয় না; একইভাবে বেশি feature দিয়ে incorrect payment-এর সমস্যা ঢেকে রাখা যায় না।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart TD A[Business problem] --> B[User actions] A --> C[Quality constraints] B --> D[API and data model] C --> E[Latency security reliability] D --> F[Architecture choices] E --> F
প্রথমে actor ও action লিখুন। তারপর প্রতিটি action-এর correctness rule লিখুন। সবশেষে ওই flow-এর latency, durability, security ও expected traffic নির্ধারণ করুন। যেমন checkout-এর জন্য “মজুতের বেশি confirmed order নয়” একটি ব্যবসায়িক invariant; এটি transaction ও concurrency design-এ সরাসরি প্রভাব ফেলে।
PHP ও Laravel-এ প্রয়োগ
Laravel Form Request ব্যবহার করে user input-এর কিছু শর্ত যাচাই করা যায়। নিচের class fragment একটি StoreOrderRequest-এর rules method। তবে validation-এ stock দেখা এবং পরে order লেখা atomic নয়। Concurrent checkout সামলাতে transaction-এর মধ্যে stock আবার যাচাই করতে হবে।
public function rules(): array
{
return [
'product_id' => ['required', 'integer', 'exists:products,id'],
'quantity' => ['required', 'integer', 'min:1', 'max:10'],
];
}
public function authorize(): bool
{
return $this->user() !== null;
}সুবিধা, সীমাবদ্ধতা ও trade-off
বিস্তারিত requirements design সহজ করে, কিন্তু সব ভবিষ্যৎ scenario আগেই জানা সম্ভব নয়। প্রথম release-এর must-have এবং পরে করা যাবে এমন বিষয় আলাদা রাখুন। বেশি availability-এর লক্ষ্য multi-zone deployment দাবি করতে পারে; তার খরচ business value দিয়ে বিচার করতে হবে।
সাধারণ ভুল
- “দ্রুত”, “নিরাপদ”, “অনেক user”—পরিমাপহীন শব্দে থেমে যাওয়া।
- Assumption-কে যাচাইকৃত traffic হিসেবে দেখানো।
- Form validation-কে concurrency correctness ধরে নেওয়া।
- একই deadline-এ সব feature must-have ঘোষণা করা।
আরও একটু গভীরে
একই product-এর ভিন্ন endpoint-এর লক্ষ্য আলাদা হতে পারে। Search result কিছুক্ষণ পুরোনো হলেও চলতে পারে; order confirmation-এ ভুল user-এর তথ্য দেখানো একেবারেই চলবে না। তাই সব request-এর জন্য একটি universal consistency বা latency policy চাপিয়ে দেবেন না।
মনে রাখুন
- কী করবে এবং কেমন করে করবে—দুই ধরনের requirement লিখুন।
- প্রতিটি quality goal-এর measurement boundary দিন।
- Business invariant design-এর মূল শর্ত।
নিজে চেষ্টা করুন
একটি ticket booking service-এর তিনটি functional requirement, তিনটি measurable quality goal এবং দুটি invariant লিখুন। “এক আসন দুজন পাবে না” কীভাবে যাচাই করবেন সেটিও লিখুন।
নিজের বোঝা যাচাই করুন
1. Search কি functional requirement?
হ্যাঁ, এটি ব্যবহারকারীর একটি কাজ। Search-এর p95 latency target হলো non-functional requirement।
2. Security কি শুধু non-functional?
Security একটি quality concern; তবে password reset বা permission management-এর মতো নির্দিষ্ট security feature functional requirement-ও হতে পারে।
3. p95 ৩০০ ms কি সব app-এর standard?
না। এটি এই পাঠের উদাহরণ। বাস্তব লক্ষ্য user expectation, network, workload ও খরচ অনুযায়ী ঠিক হয়।
4. exists validation stock নিশ্চিত করে?
না। Request যাচাইয়ের পর অন্য transaction stock বদলাতে পারে। Write-এর সময় concurrency control লাগে।
5. Scope কমানোর লাভ কী?
আগে core flow সঠিক করা যায়, কম assumption নিয়ে ছোট design তৈরি হয় এবং ফল দ্রুত যাচাই করা যায়।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।