Interview Requirements: scope ও assumption স্পষ্ট করা
Requirement Clarification and Scope
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- অস্পষ্ট prompt থেকে user journey বের করা
- Functional scope ও quality target আলাদা করা
- Assumption এবং excluded feature স্পষ্ট বলা
সমস্যা দিয়ে শুরু
Interviewer বললেন notification system design করুন। Candidate সঙ্গে সঙ্গে Kafka, Kubernetes ও microservices আঁকলেন। পরে জানা গেল requirement ছিল ছোট দোকানের transactional email; ordered global stream দরকারই ছিল না। Design interview product uncertainty কমানো দিয়ে শুরু হয়। প্রশ্ন করার উদ্দেশ্য সময় নষ্ট করা নয়, কোন problem solve করছেন তা স্থির করা। এখানে দেওয়া response pattern শিক্ষামূলক অনুশীলন, কোনো employer-এর official scoring policy নয়।
সহজ করে বুঝি
প্রথমে actor, primary action এবং success condition জিজ্ঞেস করুন। Functional requirements কী করবে বলে; non-functional requirements কত দ্রুত, কত reliable, কত data এবং কী security boundary চাই বলে। Explicit scope থেকে API ও storage choice আসে। উত্তর না পেলে reasonable assumption বলে confirm করুন। সব feature সমান গুরুত্ব পায় না; must-have দুই বা তিনটি journey-তে focus রাখুন।
পরিচিত একটি উপমা
বাড়ির drawing শুরু করার আগে কতজন থাকবেন, কত budget এবং কোন জমি জানা দরকার। শুধু সুন্দর staircase আঁকলে wheelchair access বা flood level-এর requirement পরে হারিয়ে যায়। Architecture choice requirements-এর পরে আসা উচিত।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart LR P[Ambiguous prompt] --> U[Actors and core journeys] U --> F[Functional scope] F --> Q[Quality and constraints] Q --> A[Stated assumptions] A --> S[Agreed design boundary] S --> D[Architecture exploration]
Prompt থেকে actors ও jobs বের করুন। Must-have list এবং out-of-scope list লিখে quality প্রশ্ন করুন। Scale number-এর unit এবং peak shape জিজ্ঞেস করুন। Assumption আলাদা চিহ্নিত করে boundary summarize করুন। Interviewer অন্য direction দিলে tree বদলান; নিজের memorized diagram ধরে না থেকে requirement-এর সঙ্গে পরিবর্তন যুক্ত করুন।
PHP ও Laravel-এ প্রয়োগ
অনুশীলন: Laravel notification API-এর Form Request rules-method fragment। এটি scope-এর input contract প্রকাশ করে; authorization policy, category consent এবং rate limit আলাদা। Channel list deliberately email ও database-এ সীমিত। Laravel/PHP code এখানে interview-এ পুরো লিখতেই হবে এমন নয়, requirement কীভাবে concrete validation হয় তা দেখায়।
public function rules(): array
{
return [
'recipient_id' => ['required', 'integer', 'exists:users,id'],
'category' => ['required', 'in:transactional,marketing'],
'channel' => ['required', 'in:mail,database'],
'event_key' => ['required', 'string', 'max:100'],
];
}সুবিধা, সীমাবদ্ধতা ও trade-off
বেশি clarification correctness বাড়ায়, কিন্তু প্রতিটি minor UI detail-এ আটকে গেলে design-এর সময় থাকে না। High-impact unknown আগে: loss tolerance, ordering, privacy, traffic এবং external side effects। পরে পরিবর্তনযোগ্য label বা button color কম priority। Scope সীমিত করা weakness নয়; তার বাইরে extension path explain করলে decision quality বোঝা যায়।
সাধারণ ভুল
- প্রথম প্রশ্নের আগেই technology list ঘোষণা করা।
- DAU-কে সরাসরি QPS ধরে নেওয়া।
- সব feature must-have বলা এবং কোনো priority না রাখা।
আরও একটু গভীরে
একটি assumption log রাখুন: statement, design consequence, এবং ভুল হলে কী বদলাবে। উদাহরণ, notification five minutes delay tolerate করলে async queue যথেষ্ট হতে পারে; OTP ten seconds requirement আলাদা priority চায়। Security প্রশ্নে tenant boundary ও recipient consent অন্তর্ভুক্ত করুন। Requirements summarize করে interviewer-এর correction নেওয়া পরের estimate এবং API discussion-এর foundation তৈরি করে।
মনে রাখুন
ভালো clarification actors, core journey, quality ও constraints স্থির করে; technology decision সেই boundary থেকে আসে।
নিজে চেষ্টা করুন
File storage prompt নিয়ে আটটি প্রশ্ন লিখুন। তার মধ্যে তিনটি high-impact question আগে করুন। উত্তর না পাওয়া পাঁচটি assumption এবং প্রতিটির architecture consequence নোট করুন। দুই মিনিটে নিজের scope aloud summarize করে record শুনুন।
নিজের বোঝা যাচাই করুন
1. প্রথমে কী জিজ্ঞেস করব?
Actor ও core successful action। Data path না বুঝে scale বা technology বেছে নিলে ভুল problem solve হতে পারে।
2. উত্তর না পেলে?
Reasonable assumption স্পষ্ট বলুন এবং তার consequence জানান। লুকানো অনুমানকে fact হিসেবে চালাবেন না।
3. সব প্রশ্ন করা দরকার?
না। High-impact unknown prioritize করুন। Time budget অনুযায়ী low-impact detail পরে নেওয়া যায়।
4. Scope বাদ দিলে দুর্বল?
যৌক্তিক exclusion focus বাড়ায়। কেন বাদ এবং requirement বদলালে extension কী হবে explain করুন।
5. Validation কি requirement-এর সব?
না। Shape validation-এর বাইরে authorization, business invariant, latency এবং recovery requirements থাকে।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।