Requirement engineering — stakeholder, elicitation আর feasibility

১ · ভুল জিনিস নিখুঁতভাবে বানানো — requirement কেন project ডোবায়

একটি পরিচিত দৃশ্য দিয়ে শুরু করি। পাড়ার একটি ফার্মেসির মালিক — ধরা যাক তাঁর দোকানের নাম “ওষুধবাড়ি” (পুরো পর্বের উদাহরণটি কাল্পনিক) — একটি ছোট software দলকে ডেকে বললেন, “আমার একটা অ্যাপ লাগবে। কাস্টমার মোবাইল থেকে ওষুধ অর্ডার করবে, ব্যস।” দল চার মাসে একটি সুন্দর অ্যাপ বানাল: ক্যাটালগ, কার্ট, অনলাইন payment. এক মাস পর দেখা গেল, অর্ডার আসে দিনে দুই-তিনটি। বেশিরভাগ ক্রেতা বয়স্ক, তাঁরা আগের মতোই ফোন করেন। অ্যাপের অনেক অর্ডারে এমন ওষুধ চাওয়া হলো, যা প্রেসক্রিপশন ছাড়া দেওয়া যায় না। আর ফার্মাসিস্ট বললেন, “অর্ডার তো আসে, কিন্তু স্টকে আছে কি না দেখার কোনো উপায় অ্যাপে নেই — আমি খাতা খুলে মেলাই।”

দলের কোড ভালো ছিল। ব্যর্থতা কোডে নয়, কী বানাতে হবে সেই বোঝাপড়ায়। Requirement মানে software-কে কী করতে হবে বা কেমন হতে হবে, তার স্পষ্ট বিবরণ। আর সেই requirement খুঁজে বের করা, বোঝা, লিখে রাখা, যাচাই করা আর বদলের সাথে সামলানোর শৃঙ্খলাবদ্ধ কাজের নাম requirement engineering (RE).

দোলনার কার্টুন — ভুল বোঝার একটি পুরোনো ছবি

Software জগতে একটি কার্টুন কয়েক দশক ধরে ঘুরছে, সাধারণত “tree swing” কার্টুন নামে পরিচিত। প্রতিটি ছবিতে একই দোলনা, ভিন্ন মানুষের চোখে। কার্টুনটির ঠিক উৎস নিশ্চিত নয়; ১৯৬০-৭০-এর দশক থেকে এটি নানা রূপে ছাপা হয়েছে, আর বিভিন্ন সংস্করণে ছবির সংখ্যা ও কথাও আলাদা। একটি প্রচলিত সংস্করণের ছবিগুলো মোটামুটি এমন (খুঁটিনাটি সংস্করণ-ভেদে আলাদা):

কার্টুনের তিনটি কারণ ওষুধবাড়িতেও আছে:

• ভুল বোঝা: মালিক বললেন “অ্যাপ”; আসল চাওয়া ছিল “ফোনের ভিড় কমুক, ভুল ওষুধ না যাক।”
• বাদ পড়া stakeholder: কথা হয়েছে শুধু মালিকের সাথে; ফার্মাসিস্ট, বয়স্ক ক্রেতা, রাইডার আর ওষুধ বিক্রির নিয়ম আলোচনার বাইরে।
• বদলে যাওয়া চাহিদা: অ্যাপ হাতে পেয়ে মালিক নতুন জিনিস চাইলেন — মানুষ জিনিস দেখে তবেই নিজের চাওয়া বোঝেন। সমস্যা হয় বদল সামলানোর ব্যবস্থা না থাকলে।

মডিউল ৪-এর মানচিত্র

এই পর্ব দিয়ে মডিউল ৪ শুরু। এখানে আমরা “কী বানাতে হবে” প্রশ্নের প্রথম অর্ধেক — মানুষ খোঁজা, কথা বলা আর বানানো উচিত কি না — দেখব। বাকি অংশগুলো পরের চার পর্বে:

২ · Requirement engineering-এর সাতটি কাজ — একটি চক্র

Roger Pressman-এর Software Engineering: A Practitioner's Approach বইয়ের সাম্প্রতিক সংস্করণগুলো RE-কে সাতটি কাজে ভাগ করে; Ian Sommerville-এর Software Engineering একই কাজ মোটা দাগে দেখায় elicitation ও analysis, specification, validation আর requirement management হিসেবে। নাম বই-ভেদে আলাদা, ভেতরের কাজ প্রায় এক। আমরা Pressman-এর সাতটি নাম নেব, কারণ পরীক্ষায় এগুলোই বেশি আসে:

পর্ব ৩-এর (Software quality) ভাষায়, validation মানে “ঠিক জিনিস বানাচ্ছি তো?”, আর verification মানে “ঠিকভাবে বানাচ্ছি তো?” Requirement validation প্রথম প্রশ্নের সবচেয়ে সস্তা মুহূর্ত — কোড লেখার আগে।

৩ · Stakeholder — কে কে, কতটা ক্ষমতা, কতটা আগ্রহ

Stakeholder হলেন সেই সব মানুষ বা প্রতিষ্ঠান, যাঁরা software-টি দ্বারা প্রভাবিত হন বা এর ওপর প্রভাব রাখেন। শব্দটি ব্যবস্থাপনা-শাস্ত্রে জনপ্রিয় হয় R. Edward Freeman-এর Strategic Management: A Stakeholder Approach (১৯৮৪) বইয়ের পর।

খোঁজার কৌশল — “আর কে?”

প্রতিটি পরিচিত stakeholder-কে জিজ্ঞেস করুন, “আর কার সাথে কথা বলা উচিত? কার কাজ বদলাবে? কে আপত্তি করতে পারেন?” — নতুন নাম আসা বন্ধ না হওয়া পর্যন্ত। কয়েকটি দল আলাদা করে ভাবুন:

• যিনি টাকা দেন (customer বা sponsor): ওষুধবাড়ির মালিক।
• যিনি সরাসরি ব্যবহার করেন (user): ক্রেতা, ফার্মাসিস্ট, ডেলিভারি রাইডার — প্রত্যেকে ভিন্নভাবে।
• যিনি ফল ভোগ করেন কিন্তু হাত দেন না: রোগী নিজে, যখন অর্ডার দেন তাঁর সন্তান।
• যিনি নিয়ম ঠিক করেন: ওষুধ বিক্রি আর তথ্য-সুরক্ষার নিয়ন্ত্রক সংস্থা, payment-এর প্রতিষ্ঠান।
• যিনি বিরোধিতা করতে পারেন: কর্মী, যিনি ভাবছেন অ্যাপ এলে তাঁর চাকরি যাবে।

User class, persona আর “ব্যবহারকারীর কণ্ঠ”

“User” একটি দল নয়, অনেক দল। Karl Wiegers তাঁর Software Requirements বইয়ে (Joy Beatty-র সাথে তৃতীয় সংস্করণ ২০১৩) user class-এর কথা বলেন: যাঁদের কাজ, দক্ষতা আর অধিকার আলাদা — ওষুধবাড়িতে বয়স্ক নিয়মিত ক্রেতা, তরুণ ক্রেতা, ফার্মাসিস্ট আর রাইডার। প্রতিটি class থেকে একজন প্রতিনিধি — Wiegers-এর ভাষায় product champion — রাখলে সেই class-এর কণ্ঠ আলোচনায় হারায় না।

Persona হলো একটি user class-এর কাল্পনিক কিন্তু তথ্যভিত্তিক প্রতিনিধি, নাম আর গল্পসহ। ধারণাটি জনপ্রিয় করেন Alan Cooper, তাঁর The Inmates Are Running the Asylum (১৯৯৯) বইয়ে। যেমন: “রহিমা খাতুন, ৬৮, ডায়াবেটিস আর প্রেশারের ওষুধ প্রতি মাসে নেন। ছোট পর্দার লেখা পড়তে কষ্ট হয়, ছেলে বিদেশে থাকেন, ফোনে কথা বলতেই স্বচ্ছন্দ।” তখন দল জিজ্ঞেস করতে পারে, “রহিমা খালা কি এই screen বুঝবেন?” শর্ত: persona বানাতে হবে আসল interview আর observation থেকে, কল্পনা থেকে নয়।

Power/interest grid — কার সাথে কতটা

সবার সাথে সমান সময় দেওয়া অসম্ভব। একটি প্রচলিত হাতিয়ার power/interest grid: প্রতিটি stakeholder-কে দুটি মাপে বসানো হয় — power (project-এর সিদ্ধান্ত বা ফলাফলে প্রভাব খাটানোর ক্ষমতা) আর interest (ফলাফলে তাঁর কতটা আগ্রহ বা কতটা প্রভাবিত হবেন)। ধারণাটি সাধারণত Aubrey Mendelow-এর ১৯৮১ সালের একটি কাজের সাথে যুক্ত করা হয়, পরে ব্যবস্থাপনার বইগুলোতে জনপ্রিয় হয়েছে।

প্রতিটি ভাগের একটি প্রচলিত engagement কৌশল আছে। নিচের প্রোগ্রাম stakeholder তালিকা থেকে ভাগ আর কৌশল বের করে:

// Power/interest grid for the (fictional) pharmacy-ordering app.
// Scores 1-10 come from the team's judgement, not from a formula.
const people = [
  { name: "Pharmacy owner",   power: 9, interest: 9 },
  { name: "Pharmacist",       power: 4, interest: 9 },
  { name: "Elderly customer", power: 3, interest: 8 },
  { name: "Delivery rider",   power: 2, interest: 6 },
  { name: "Drug regulator",   power: 9, interest: 3 },
  { name: "Payment gateway",  power: 6, interest: 3 },
  { name: "Local doctor",     power: 5, interest: 5 },
  { name: "Shop next door",   power: 1, interest: 2 },
];
const CUT = 5; // a score >= 5 counts as "high"
const PLAN = {
  "Manage closely": "workshops + review every release",
  "Keep satisfied": "short briefings, ask before big changes",
  "Keep informed":  "interviews, prototype tests, newsletters",
  "Monitor":        "occasional check, low effort",
};
function quadrant(p) {
  const hp = p.power >= CUT, hi = p.interest >= CUT;
  if (hp && hi) return "Manage closely";
  if (hp) return "Keep satisfied";
  if (hi) return "Keep informed";
  return "Monitor";
}
const count = {};
for (const p of people) {
  const q = quadrant(p);
  count[q] = (count[q] || 0) + 1;
  console.log(p.name.padEnd(17) + ("P" + p.power + " I" + p.interest).padEnd(7) + q.padEnd(15) + PLAN[q]);
}
console.log("---");
for (const q of Object.keys(PLAN)) console.log(q.padEnd(15) + (count[q] || 0));

Pharmacy owner   P9 I9  Manage closely workshops + review every release
Pharmacist       P4 I9  Keep informed  interviews, prototype tests, newsletters
Elderly customer P3 I8  Keep informed  interviews, prototype tests, newsletters
Delivery rider   P2 I6  Keep informed  interviews, prototype tests, newsletters
Drug regulator   P9 I3  Keep satisfied short briefings, ask before big changes
Payment gateway  P6 I3  Keep satisfied short briefings, ask before big changes
Local doctor     P5 I5  Manage closely workshops + review every release
Shop next door   P1 I2  Monitor        occasional check, low effort
---
Manage closely 2
Keep satisfied 2
Keep informed  3
Monitor        1

এবার দেখুন, একটি দল বাস্তবে কীভাবে grid ভরে — আর কীভাবে প্রায় একজন গুরুত্বপূর্ণ stakeholder বাদ পড়ে যাচ্ছিলেন:

৪ · Elicitation-এর কৌশল — কোনটি কখন

“Elicit” মানে বের করে আনা: requirement মাটিতে পড়ে থাকে না যে কুড়িয়ে নেবেন; মানুষের মাথা, অভ্যাস আর কাগজপত্র থেকে বের করে আনতে হয়। কোনো একটি কৌশল সব জানায় না, তাই কয়েকটি মেলাতে হয়।

Interview — তিন ধরন আর দুই ধরনের প্রশ্ন

Interview সবচেয়ে প্রচলিত কৌশল, আবার সবচেয়ে বেশি ভুলভাবে করা হয়। গঠন অনুযায়ী তিন ধরন:

• Structured: আগে থেকে লেখা প্রশ্ন, একই ক্রমে সবাইকে। তুলনা সহজ, কিন্তু অপ্রত্যাশিত বিষয় ধরা পড়ে না।
• Semi-structured: একটি প্রশ্নের তালিকা থাকে, কিন্তু উত্তর অনুযায়ী পিছু নেওয়া (follow-up) যায়। বাস্তবে সবচেয়ে বেশি ব্যবহৃত।
• Unstructured: খোলা আলাপ, একটি বিষয় ধরে। একেবারে শুরুতে, যখন কী জিজ্ঞেস করবেন তাও জানা নেই।

প্রশ্নের ধরনও দুই রকম। Open question উত্তরদাতাকে নিজের ভাষায় বলতে দেয়: “এখন একটি ফোন-অর্ডার কীভাবে নেন, একদম শুরু থেকে বলবেন?” Closed question-এর উত্তর হ্যাঁ/না বা একটি ছোট তথ্য: “দিনে কতগুলো ফোন আসে?” দুটোই দরকার — শুরুতে open প্রশ্নে ছবিটা পাওয়া, পরে closed প্রশ্নে সংখ্যা আর সীমা নিশ্চিত করা। বিপদ হলো leading question, যা উত্তর আগেই বলে দেয়: “Home delivery তো নিশ্চয়ই চান, তাই না?” ভদ্রতার খাতিরে বেশিরভাগ মানুষ “হ্যাঁ” বলবেন।

Active listening মানে শুধু চুপ করে শোনা নয়: মাঝে মাঝে নিজের ভাষায় ফিরিয়ে বলা (“তাহলে বুঝলাম, অস্পষ্ট প্রেসক্রিপশনে আপনি ডাক্তারকে ফোন করেন — ঠিক?”), নীরবতাকে সময় দেওয়া, আর উত্তরের “কেন”-র পিছু নেওয়া। শেষ প্রশ্নটি সবসময় রাখুন: “আমার জিজ্ঞেস করা উচিত ছিল, এমন কিছু বাদ গেল?”

নিচের প্রোগ্রামটি একটি খেলনা question checker: কয়েকটি শব্দ-নিয়ম দিয়ে interview-এর প্রশ্নে closed, leading বা “দুই প্রশ্ন এক বাক্যে” ধরনের সমস্যা চিহ্নিত করে। এটি ভাষা বোঝে না — শুধু দেখায় কোন ধরনের ভুল খুঁজতে হয়।

// A TOY interview-question checker: simple word rules, no real language understanding.
const questions = [
  "Do you want a mobile app?",
  "How do you take an order today when a customer phones?",
  "You would obviously like home delivery, wouldn't you?",
  "Tell me about the last time a medicine was out of stock.",
  "Is the current paper register slow and hard to search?",
  "What happens if a prescription photo is unclear?",
];
const CLOSED = /^(do|does|did|is|are|was|can|could|will|would|should|have|has)\b/i;
const OPEN = /^(what|how|why|when|where|who|which|tell me|describe|walk me)\b/i;
const LEADING = /\b(obviously|surely|clearly|agree that|isn't it|wouldn't you|don't you|right\?)/i;
function check(q) {
  const flags = [];
  if (LEADING.test(q)) flags.push("LEADING");
  if (CLOSED.test(q)) flags.push("CLOSED");
  if (CLOSED.test(q) && /\band\b|\bor\b/i.test(q)) flags.push("DOUBLE?");
  if (!flags.length && OPEN.test(q)) flags.push("ok-open");
  return flags.length ? flags : ["unknown"];
}
let ok = 0;
questions.forEach((q, i) => {
  const f = check(q);
  if (f[0] === "ok-open") ok++;
  console.log((i + 1) + ". [" + f.join(",") + "] " + q);
});
console.log(ok + " of " + questions.length + " look open and neutral");

1. [CLOSED] Do you want a mobile app?
2. [ok-open] How do you take an order today when a customer phones?
3. [LEADING] You would obviously like home delivery, wouldn't you?
4. [ok-open] Tell me about the last time a medicine was out of stock.
5. [CLOSED,DOUBLE?] Is the current paper register slow and hard to search?
6. [ok-open] What happens if a prescription photo is unclear?
3 of 6 look open and neutral

Workshop আর JAD: JAD (Joint Application Design) ১৯৭০-এর দশকের শেষে IBM-এ গড়ে ওঠে বলে সাধারণভাবে বলা হয়। আলাদা আলাদা interview-এর বদলে মূল stakeholder আর developer-রা এক বা কয়েক দিন এক ঘরে বসেন, একজন নিরপেক্ষ সঞ্চালক (facilitator) আর একজন লেখকসহ; বিরোধ সেখানেই সামনে আসে। ঝুঁকি: সবচেয়ে ক্ষমতাবান মানুষ কথা বললে বাকিরা চুপ হয়ে যান — সঞ্চালকের কাজ সবার কথা বের করে আনা।

৫ · একটি interview — অস্পষ্ট কথা থেকে candidate requirement

Interview-এর ফল একটি “requirement-এর তালিকা” নয়, বরং candidate requirement, যা পরে যাচাই আর মীমাংসার মধ্য দিয়ে যাবে। নিচে মালিকের সাথে একটি semi-structured interview-এর অংশ — দেখুন অস্পষ্ট বাক্য থেকে কীভাবে পরীক্ষাযোগ্য কথা বেরোয়।

৬ · বলা বনাম করা — survey, observation আর tacit knowledge

দার্শনিক Michael Polanyi তাঁর The Tacit Dimension (১৯৬৬) বইয়ে একটি বিখ্যাত কথা লেখেন, মোটামুটি এমন: “আমরা যতটা বলতে পারি, তার চেয়ে বেশি জানি।” এই মুখে-না-আসা জ্ঞানের নাম tacit knowledge. অভিজ্ঞ ফার্মাসিস্ট এক নজরে বোঝেন অস্পষ্ট হাতের লেখা কোন ওষুধ, কখন ডাক্তারকে ফোন করতে হয় — কিন্তু interview-এ বলবেন, “এ তো সাধারণ ব্যাপার।”

এই “say vs do” ফাঁক requirement-এর মৌলিক সমস্যা: মানুষ বলেন আদর্শ রূপ, করেন বাস্তব রূপ — শর্টকাট আর ব্যতিক্রমসহ। কয়েকটি কৌশল ফাঁকটি কমায়:

• Observation ও ethnography: কাজের জায়গায় বসে দীর্ঘ সময় দেখা। ১৯৯০-এর দশকের শুরুতে ব্রিটেনের এয়ার ট্রাফিক কন্ট্রোল নিয়ে Lancaster University-র সমাজবিজ্ঞানী ও software গবেষকদের কাজ RE-তে এর ব্যবহার জনপ্রিয় করে বলে উল্লেখ করা হয়; তাঁরা দেখান কাগজের “flight strip” নিয়ন্ত্রকদের নীরব যোগাযোগেরও মাধ্যম ছিল, যা interview-এ ওঠেনি।
• Job shadowing: একজনের পেছনে একটি পুরো দিন ছায়ার মতো থাকা। কাউন্টারে একদিন বসলেই দেখা যাবে, ফার্মাসিস্ট ফোন ধরে রেখেই অন্য ক্রেতাকে ওষুধ দেন — অর্ডারের screen এক হাতে চালানো যাওয়া চাই।
• Contextual inquiry আর apprenticing: কাজ চলাকালীন দেখা আর প্রশ্ন করা, “কেন এটা করলেন?” (Beyer ও Holtzblatt-এর Contextual Design, ১৯৯৮); অথবা Robertson দম্পতির Mastering the Requirements Process-এর মতো analyst নিজে শিক্ষানবিশ হয়ে কাজটি শেখেন।
• Prototype: কাগজে আঁকা একটি screen দেখালে মানুষ যা বলেন, তা কথার চেয়ে অনেক বাস্তব — পর্ব ৪-এর throwaway prototype.

Survey — অনেক মানুষ, কিন্তু কারা?

Questionnaire বা survey অনেক মানুষের কাছে পৌঁছায়, আর জানা প্রশ্নে “কতজন” মাপতে কাজের। মতামতের প্রশ্নে প্রায়ই Likert scale ব্যবহার হয় — ১ (একদম একমত নই) থেকে ৫ (পুরো একমত); নামটি মনোবিজ্ঞানী Rensis Likert-এর ১৯৩২ সালের কাজ থেকে। কিন্তু survey-র সবচেয়ে বড় ফাঁদ sampling bias: যাঁরা উত্তর দিলেন, তাঁরা কি আসল ব্যবহারকারীদের মতো?

ধরুন ওষুধবাড়ি ফেসবুক পেজে একটি অনলাইন ফর্ম দিল। নিচের প্রোগ্রাম নির্দিষ্ট seed থেকে ১২০টি কাল্পনিক উত্তর বানায় (তরুণেরা বেশি উত্তর দেন), গণনা করে, আর শেষে দোকানের ক্রেতা-খাতার বয়সের হিসাবের সাথে মেলায়:

// Survey analysis with seeded (fake) responses -- same output on every run.
function mulberry32(a) { return () => { a = (a + 0x6D2B79F5) | 0; let t = Math.imul(a ^ (a >>> 15), 1 | a);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296; }; }
const rnd = mulberry32(20);
const pick = (items, w) => { let x = rnd() * w.reduce((a, b) => a + b, 0);
  for (let i = 0; i < items.length; i++) { x -= w[i]; if (x < 0) return items[i]; } return items.at(-1); };
// An ONLINE form: young people answer far more often than older customers.
const N = 120, rows = [];
for (let i = 0; i < N; i++) {
  const age = pick(["18-29", "30-44", "45-59", "60+"], [45, 35, 15, 5]);
  const old = age === "60+" || age === "45-59";
  const channel = pick(["App", "Phone call", "Visit shop"], old ? [2, 5, 4] : [6, 2, 2]);
  const likert = pick([1, 2, 3, 4, 5], old ? [3, 3, 2, 1, 1] : [1, 1, 2, 4, 3]); // "I would upload a prescription photo"
  rows.push({ age, channel, likert });
}
const freq = (key) => rows.reduce((m, r) => (m[r[key]] = (m[r[key]] || 0) + 1, m), {});
const pct = (n) => (100 * n / N).toFixed(1) + "%";
console.log("Preferred channel:"); for (const [k, v] of Object.entries(freq("channel"))) console.log("  " + k.padEnd(11) + String(v).padStart(3) + "  " + pct(v));
const lk = freq("likert"), s = rows.map(r => r.likert).sort((a, b) => a - b);
console.log("Likert 1..5 counts: " + [1, 2, 3, 4, 5].map(k => lk[k] || 0).join(" "));
const agree = (lk[4] || 0) + (lk[5] || 0);
console.log("median " + s[N / 2 - 1] + "/" + s[N / 2] + ", agree (4-5) " + pct(agree) + ", mean " + (s.reduce((a, b) => a + b) / N).toFixed(2));
// Bias check: compare the sample with the shop's own customer register.
const register = { "18-29": 20, "30-44": 30, "45-59": 25, "60+": 25 }; // % of real customers
const ages = freq("age");
console.log("Age   sample  register");
for (const a of Object.keys(register)) console.log(a.padEnd(6) + pct(ages[a] || 0).padStart(6) + String(register[a] + "%").padStart(9));

Preferred channel:
  App         63  52.5%
  Visit shop  29  24.2%
  Phone call  28  23.3%
Likert 1..5 counts: 22 12 21 41 24
median 4/4, agree (4-5) 54.2%, mean 3.27
Age   sample  register
18-29  38.3%      20%
30-44  35.8%      30%
45-59  20.0%      25%
60+     5.8%      25%

Domain বোঝা আর শব্দের তালিকা

Elicitation-এর একটি নীরব কাজ হলো domain — কাজের ক্ষেত্রটি — শেখা। ওষুধের দোকানে “generic name” আর “brand name”, “strip” আর “box”, “মেয়াদ” আর “ব্যাচ” — এই শব্দগুলোর সঠিক অর্থ না জানলে developer আর ফার্মাসিস্ট একই শব্দে ভিন্ন জিনিস বুঝবেন। তাই প্রথম দিন থেকেই একটি domain glossary রাখা ভালো:

এই তালিকাই পরে domain model-এর ভিত্তি হয় (পর্ব ২৩, Requirement modeling).

৭ · Feasibility study — বানানো কি উচিত?

সব কথা শোনার পর একটি কঠিন প্রশ্ন: এটা কি আদৌ বানানো উচিত, আর কোন পথে? Feasibility study এই প্রশ্নের উত্তর খোঁজে, সাধারণত RE-র শুরুর দিকে — বড় টাকা খরচের আগে। পাঠ্যবইগুলোতে পাঁচটি দিক প্রচলিত, অনেকে ইংরেজি আদ্যক্ষর মিলিয়ে TELOS বলেন:

টাকার হিসাব — payback period আর NPV

Economic feasibility-র দুটি সহজ মাপ। Payback period: শুরুর বিনিয়োগ কত বছরে নিট লাভ থেকে উঠে আসে। সহজ, কিন্তু টাকার সময়-মূল্য আর payback-এর পরের লাভ ধরে না।

টাকার সময়-মূল্য মানে: আজকের ১০০ টাকা এক বছর পরের ১০০ টাকার চেয়ে বেশি দামি, কারণ আজকের টাকা খাটানো যায়। তাই ভবিষ্যতের টাকাকে একটি discount rate (r) দিয়ে আজকের মূল্যে আনা হয়। t বছর পরের টাকা C-এর আজকের মূল্য (present value):

NPV (net present value) হলো সব বছরের নিট টাকার প্রবাহের আজকের মূল্যের যোগফল, শুরুর বিনিয়োগ (t = 0, ঋণাত্মক) সহ। NPV > 0 হলে সেই rate-এ project লাভজনক; অন্য সব সমান হলে বেশি NPV ভালো। আর যে payback ভবিষ্যতের টাকাকে discount করে হিসাব হয়, তার নাম discounted payback. ওষুধবাড়ির দুটি কাল্পনিক বিকল্প, অঙ্ক লাখ টাকায়, ১০% discount rate-এ:

• A — নিজস্ব অ্যাপ বানানো: শুরুতে ১২ লাখ; পাঁচ বছরে নিট লাভ ২.৫, ৪, ৪.৫, ৪.৫, ৪.৫ লাখ।
• B — একটি তৈরি অর্ডার-platform ভাড়া নেওয়া: শুরুতে ২ লাখ (সেটআপ, প্রশিক্ষণ); ভাড়া বাদে নিট লাভ ১.৮, তারপর প্রতি বছর ২.২ লাখ।

// Economic feasibility: two fictional options, amounts in lakh taka.
// Year 0 = investment (negative); years 1-5 = net benefit after running costs.
const RATE = 0.10; // stated discount rate: 10% per year
const options = {
  "A: build own app":  [-12, 2.5, 4.0, 4.5, 4.5, 4.5],
  "B: rent a platform": [-2, 1.8, 2.2, 2.2, 2.2, 2.2],
};
function npv(flows, r) {
  return flows.reduce((sum, cf, t) => sum + cf / Math.pow(1 + r, t), 0);
}
function payback(flows, r) { // r = 0 gives the simple (undiscounted) payback
  let cum = 0;
  for (let t = 0; t < flows.length; t++) {
    const pv = flows[t] / Math.pow(1 + r, t);
    if (t > 0 && cum + pv >= 0) return t - 1 + (-cum / pv); // part of year t
    cum += pv;
  }
  return null; // never pays back inside the horizon
}
for (const [name, f] of Object.entries(options)) {
  const total = f.slice(1).reduce((a, b) => a + b, 0);
  const pb = payback(f, 0), dpb = payback(f, RATE);
  console.log(name);
  console.log("  benefit sum   " + total.toFixed(2) + "  (cost " + (-f[0]) + ")");
  console.log("  NPV @10%      " + npv(f, RATE).toFixed(2));
  console.log("  payback       " + (pb === null ? "none" : pb.toFixed(2) + " yr"));
  console.log("  disc. payback " + (dpb === null ? "none" : dpb.toFixed(2) + " yr"));
}
console.log("NPV of A if rate were 20%: " + npv(options["A: build own app"], 0.20).toFixed(2));

A: build own app
  benefit sum   20.00  (cost 12)
  NPV @10%      2.83
  payback       3.22 yr
  disc. payback 3.99 yr
B: rent a platform
  benefit sum   10.60  (cost 2)
  NPV @10%      5.98
  payback       1.09 yr
  disc. payback 1.20 yr
NPV of A if rate were 20%: -0.56

টাকা শুধু একটি দিক। নিচের stepper-এ দেখুন পাঁচটি দিক মিলিয়ে একটি সিদ্ধান্ত কীভাবে দাঁড়ায়:

৮ · বিরোধ, মীমাংসা আর “কী” বনাম “কীভাবে”

Stakeholder বাড়লে বিরোধও বাড়ে — এটি স্বাভাবিক। ওষুধবাড়িতে:

• মালিক চান অর্ডার তখনই নিশ্চিত হোক (ক্রেতা চলে না যান); ফার্মাসিস্ট চান আগে যাচাই (ভুল ওষুধ না যায়)।
• রাইডার চান এক যাত্রায় অনেক অর্ডার; ক্রেতা চান দুই ঘণ্টার মধ্যে।

Barry Boehm ১৯৮৯ সালে Rony Ross-এর সাথে “Theory W” প্রস্তাব করেন — “সবাইকে জয়ী করুন” (make everyone a winner) — আর পরে সহকর্মীদের সাথে WinWin নামে requirement negotiation-এর একটি পদ্ধতি ও tool গড়ে তোলেন। মূল চিন্তা: প্রতিটি পক্ষের “win condition” স্পষ্ট লেখা, তারপর যেখানে দুটি win condition সংঘাত করে, সেখানে এমন বিকল্প খোঁজা যাতে দুপক্ষই যথেষ্ট পায়। ওষুধবাড়ির প্রথম বিরোধে:

দুপক্ষের প্রথম কথা (“তখনই নিশ্চিত”, “আগে যাচাই”) ছিল অবস্থান (position); নিচে ছিল স্বার্থ (interest) — ক্রেতা ধরে রাখা আর নিরাপত্তা। অবস্থান নিয়ে দর-কষাকষিতে একজন হারেন; স্বার্থ নিয়ে কথা বললে প্রায়ই তৃতীয় বিকল্প বেরোয়। মীমাংসা না হলে কে সিদ্ধান্ত নেবেন, তা আগে থেকে ঠিক থাকা দরকার; অগ্রাধিকারের নিয়মমাফিক পদ্ধতি পর্ব ২৪-এ।

Requirement বনাম design — “কী” আর “কীভাবে”

একটি পুরোনো নিয়ম: requirement বলবে software কী করবে, design ঠিক করবে কীভাবে। “প্রতিটি অর্ডার ডেলিভারির আগে একজন ফার্মাসিস্ট অনুমোদন করবেন” — requirement. “অর্ডার টেবিলে approved_by কলাম থাকবে, আর ফার্মাসিস্ট একটি সবুজ button চাপবেন” — design (software design). Requirement-এ design ঢুকে গেলে দুটি ক্ষতি: ভালো বিকল্পের পথ বন্ধ হয়, আর stakeholder এমন বিষয়ে সিদ্ধান্ত নেন যেখানে তাঁর দক্ষতা নেই।

শেষ দুটি সারি দেখায় সীমারেখা সবসময় পরিষ্কার নয়: একটি স্তরের “কীভাবে” তার নিচের স্তরের “কী” হয়ে যায়। Constraint আর trade-off-এর বিস্তারিত System design কোর্সে (Requirement আর trade-off).

৯ · আমাদের প্রেক্ষাপটে elicitation — ভাষা, সম্মান আর সংযোগ

Elicitation-এর বই সাধারণত অন্য দেশের কর্মক্ষেত্র মাথায় রেখে লেখা। আমাদের দেশে কাজ করতে গেলে কিছু চেনা চ্যালেঞ্জ প্রায়ই দেখা যায় — এগুলো সাধারণ পর্যবেক্ষণ, প্রতিটি প্রতিষ্ঠান আর মানুষ আলাদা:

উৎসব আর মৌসুমের প্রভাবও জিজ্ঞেস করুন — ঈদের আগের ভিড়, বর্ষায় ডেলিভারির সমস্যা। আর সবচেয়ে বড় নিয়ম: অনুমান না করে জিজ্ঞেস করা আর দেখা; “আমাদের দেশে মানুষ এমনই” ধরনের সাধারণীকরণও এক ধরনের ভুল requirement.

১০ · AI-এর যুগে requirement engineering

AI এখন interview-এর প্রশ্ন বানায়, meeting-এর সারাংশ লেখে, চাইলে কয়েক সেকেন্ডে দুই পাতা requirement দেয়। শুরুর খসড়া বা ভুলে যাওয়া প্রশ্ন মনে করাতে এটি কাজের। কিন্তু AI আপনার stakeholder-দের সাথে কথা বলেনি; সে দেয় “সাধারণত এমন অ্যাপে যা থাকে” — আপনার ফার্মাসিস্টের ভয় বা রহিমা খালার সমস্যা নয়। পরিচিত ভুলগুলো:

AI-এর সাহায্যে requirement-এর কাজ — চেকলিস্ট

• প্রতিটি requirement-এর উৎস (কোন stakeholder, কোন interview বা observation) লেখা আছে; AI-এর প্রস্তাব আলাদা চিহ্নে “যাচাই বাকি”
• AI-এর বানানো তালিকা আসল stakeholder-দের সাথে review করেছি — ফার্মাসিস্টের মতো প্রতিদিনের ব্যবহারকারীসহ
• আইন, মান বা নিয়মের প্রতিটি উল্লেখ মূল উৎস বা বিশেষজ্ঞের কাছে যাচাই করেছি
• Feasibility-র হিসাব (payback, NPV) একটি ছোট উদাহরণে নিজে মিলিয়েছি, discount rate-এর উৎস লিখেছি
• Interview-এর রেকর্ড বা নোট AI-কে দেওয়ার আগে অনুমতি নিয়েছি আর ব্যক্তিগত ও স্বাস্থ্য-তথ্য মুছেছি