Requirement management — prioritization, validation, traceability আর scope creep

১ · Requirement management কী — চাহিদা লেখার পরের কাজ

এই মডিউলের আগের চারটি পর্বে requirement জোগাড় করা আর লেখার কাজ দেখেছেন: stakeholder খোঁজা আর elicitation (পর্ব ২০, requirement engineering), functional আর non-functional requirement আর SRS (পর্ব ২১, functional আর non-functional requirement), use case আর user story (পর্ব ২২, use case আর user story), আর diagram দিয়ে মডেল (পর্ব ২৩, requirement modeling). কিন্তু লেখা শেষ মানে কাজ শেষ নয়। এরপর চারটি প্রশ্ন আসে:

1. কোনটি আগে? সময় আর টাকা সীমিত, চাহিদা অসীম — prioritization.
2. যা লিখেছি, তা কি ঠিক? চাহিদাটি আসল প্রয়োজন ধরেছে কি না — requirement validation.
3. কোন requirement কোথায় গেল? কোন নকশা, কোড আর test সেটি পূরণ করে — traceability.
4. বদলালে কী করব? কে অনুমোদন দেবেন, খরচ কত, কোন version — change control.

এই চারটি মিলেই requirement management. পুরো কাজটি জীবনচক্র জুড়ে চলে — শুধু শুরুতে নয়।

পুরো পর্ব জুড়ে একটি উদাহরণ চলবে: পাড়ার একটি মুদি দোকানের অনলাইন অর্ডার app (কাল্পনিক). দোকানের মালিক চান গ্রাহক মোবাইল থেকে অর্ডার দিন, cash on delivery বা মোবাইল ওয়ালেটে টাকা দিন, আর ঈদের আগে delivery-র সময় বেছে নিতে পারুন। প্রথম release-এর জন্য দলের হাতে আছে মোট ৪০ developer-দিন।

২ · অগ্রাধিকার কেন, আর MoSCoW

প্রায় প্রতিটি project-এ চাহিদার তালিকা হাতের সময়ের চেয়ে বড় হয়। অগ্রাধিকার না দিলে দুটি জিনিস ঘটে: দল সহজ বা মজার কাজ আগে করে, অথবা যিনি সবচেয়ে জোরে কথা বলেন তাঁর কাজ আগে হয়। দ্বিতীয়টির একটি রসিক নাম আছে — HiPPO (Highest Paid Person's Opinion, সবচেয়ে বেশি বেতনের মানুষের মত)। অগ্রাধিকারের পদ্ধতিগুলোর কাজ হলো সিদ্ধান্তকে প্রকাশ্য আর যুক্তিনির্ভর করা।

MoSCoW-এর চারটি ঘর

MoSCoW নামের বড় হাতের অক্ষরগুলো চারটি ঘর; মাঝের ছোট “o” শুধু উচ্চারণের সুবিধার জন্য। পদ্ধতিটি সাধারণত Oracle UK-তে কাজ করা Dai Clegg-এর নামে উদ্ধৃত হয় (১৯৯৪ সালের দিকে), আর পরে এটি DSDM (Dynamic Systems Development Method) পদ্ধতির কেন্দ্রীয় অংশ হয় — পর্ব ০৪-এ (process model) দেখেছেন, RAD-এর কিছু চিন্তা DSDM হয়ে Agile-এ মিশেছে।

MoSCoW-এর আসল শক্তি একটি নিয়মে: DSDM-এর নির্দেশনায় (AgilePM-এর মতো পরের রূপেও) সাধারণত বলা হয়, Must-এর কাজ মোট পরিকল্পিত কাজের প্রায় ৬০%-এর বেশি না হওয়াই ভালো, আর বাকিটা Should ও Could — যাতে অনুমান ভুল হলে Could বাদ দিয়ে Must রক্ষা করা যায়। সংখ্যাটি নির্দেশনা, প্রাকৃতিক নিয়ম নয়; কিন্তু “সবকিছুই Must”-এর রোগ সারাতে এটি খুব কাজের। নিচের stepper-এ মুদি দোকানের app-এর প্রথম release-এর workshop দেখুন।

৩ · Kano model — কোন feature খুশি করে, কোনটির অভাব শুধু কষ্ট দেয়

MoSCoW মানুষের মতামত সাজায়। কিন্তু গ্রাহক নিজে কোন feature-কে কীভাবে অনুভব করেন? ১৯৮৪ সালে জাপানি গুণমান-বিশেষজ্ঞ Noriaki Kano ও সহকর্মীরা জাপানের গুণমান সমিতির পত্রিকায় “Attractive quality and must-be quality” নামে একটি লেখা প্রকাশ করেন। মূল পর্যবেক্ষণ: সব feature সন্তুষ্টিকে একভাবে বাড়ায় না। এটিই Kano model.

প্রশ্নপত্র — একটি feature, দুটি প্রশ্ন

Kano-র কৌশলের মূল চালাকি হলো প্রতিটি feature নিয়ে দুটি প্রশ্ন: functional (“feature-টি থাকলে আপনার কেমন লাগবে?”) আর dysfunctional (“feature-টি না থাকলে কেমন লাগবে?”)। প্রতিটির উত্তর পাঁচটির একটি: ১ ভালো লাগবে, ২ এটাই তো স্বাভাবিক (প্রত্যাশিত), ৩ কিছু যায় আসে না, ৪ মেনে নেব, ৫ খারাপ লাগবে। দুই উত্তরের জোড়া নিচের মূল্যায়ন-টেবিলে বসিয়ে শ্রেণি পাওয়া যায়। টেবিলের এই রূপটি সাধারণত Berger ও সহলেখকদের ১৯৯৩ সালের একটি লেখা থেকে প্রচলিত; উত্তরের শব্দ আর টেবিলের খুঁটিনাটি উৎসভেদে একটু আলাদা।

M = must-be, O = one-dimensional, A = attractive, I = indifferent, R = reverse, Q = questionable (পরস্পরবিরোধী উত্তর — যেমন “থাকলেও ভালো, না থাকলেও ভালো”, যা সাধারণত প্রশ্ন বুঝতে ভুলের লক্ষণ)। উদাহরণ: একজন গ্রাহক cash on delivery নিয়ে বললেন “থাকলে — এটাই তো স্বাভাবিক (২)”, “না থাকলে — খারাপ লাগবে (৫)” → সারি ২, কলাম ৫ = M. নিচের প্রোগ্রাম আটজন গ্রাহকের উত্তর থেকে প্রতিটি feature-এর সবচেয়ে বেশিবার আসা শ্রেণি (mode) বের করে। প্রতিটি উত্তর দুই অঙ্কের লেখা: প্রথম অঙ্ক functional, দ্বিতীয় dysfunctional.

// Kano classifier: each answer pair (functional, dysfunctional) -> category.
// Answers: 1 like, 2 expect, 3 neutral, 4 live-with, 5 dislike
// Categories: M must-be, O one-dimensional (performance), A attractive,
//             I indifferent, R reverse, Q questionable (contradictory answer)
const TABLE = [            // rows: functional 1..5, columns: dysfunctional 1..5
  ["Q", "A", "A", "A", "O"],
  ["R", "I", "I", "I", "M"],
  ["R", "I", "I", "I", "M"],
  ["R", "I", "I", "I", "M"],
  ["R", "R", "R", "R", "Q"]
];
// answers[feature] = list of "fd" pairs, one per respondent (8 respondents)
const answers = {
  "cash on delivery":   ["25", "25", "15", "25", "35", "25", "15", "25"],
  "order tracking":     ["15", "15", "15", "25", "14", "15", "13", "15"],
  "recipe suggestions": ["13", "14", "13", "33", "13", "14", "15", "34"],
  "product reviews":    ["33", "34", "13", "33", "43", "33", "14", "33"],
  "auto-play video ad": ["51", "52", "53", "41", "33", "51", "52", "53"]
};
for (const [feature, list] of Object.entries(answers)) {
  const count = {};
  for (const pair of list) {
    const cat = TABLE[pair[0] - 1][pair[1] - 1];
    count[cat] = (count[cat] || 0) + 1;
  }
  const sorted = Object.entries(count).sort((a, b) => b[1] - a[1]);
  const tie = sorted.length > 1 && sorted[0][1] === sorted[1][1];
  console.log(feature.padEnd(19) + JSON.stringify(count).padEnd(26) + "-> " +
    sorted[0][0] + (tie ? " (tie with " + sorted[1][0] + ")" : ""));
}

cash on delivery   {"M":6,"O":2}             -> M
order tracking     {"O":5,"M":1,"A":2}       -> O
recipe suggestions {"A":5,"I":2,"O":1}       -> A
product reviews    {"I":6,"A":2}             -> I
auto-play video ad {"R":7,"I":1}             -> R

৪ · সংখ্যা দিয়ে অগ্রাধিকার — relative weighting, RICE, WSJF, ১০০ টাকা আর AHP

MoSCoW আর Kano শ্রেণিতে ভাগ করে; একই শ্রেণির ভেতরে ক্রম ঠিক করতে প্রায়ই সংখ্যা লাগে। তবে মনে রাখুন: প্রতিটি সূত্রের ভেতরের সংখ্যাগুলো অনুমান। সূত্র অনুমানকে স্পষ্ট করে — সত্য বানায় না।

Value বনাম cost — Wiegers-এর relative weighting

Requirement বিশেষজ্ঞ Karl Wiegers ১৯৯৯ সালের দিকে “First Things First” লেখায় আর পরে তাঁর Software Requirements বইয়ে একটি weighted scoring পদ্ধতি দেন। প্রতিটি feature-কে ১–৯ মাপে চারটি নম্বর: benefit (থাকলে লাভ), penalty (না থাকলে ক্ষতি), cost আর risk. Value = benefit × ওজন + penalty × ওজন; তারপর প্রতিটির শতকরা ভাগ নিয়ে:

উদাহরণে প্রায়ই ওজন দেওয়া হয় benefit ২, penalty ১, cost ১, risk ০.৫ — তবে দল নিজের ওজন বেছে নিতে পারে। তিনটি feature-এ হিসাব (নম্বরগুলো দলের অনুমান):

যেমন cash on delivery: value = ২ × ৮ + ৯ = ২৫; মোট value ২৫ + ১৮ + ৯ = ৫২, তাই value% = ৪৮.১; priority = ৪৮.১ ÷ (১৬.৭ × ১ + ১০.০ × ০.৫) = ৪৮.১ ÷ ২১.৭ ≈ ২.২২. বেশি priority মানে প্রতি একক খরচ-ও-ঝুঁকিতে বেশি মূল্য।

RICE আর WSJF

RICE জনপ্রিয় হয় product-messaging কোম্পানি Intercom-এর একটি blog লেখা থেকে (Sean McBride, ২০১৬ সালের দিকে বলে উল্লেখ পাওয়া যায়)। চারটি অংশ:

• Reach: নির্দিষ্ট সময়ে (যেমন এক quarter-এ) কতজন ব্যবহারকারী feature-টির ছোঁয়া পাবেন।
• Impact: প্রত্যেকের ওপর প্রভাব, একটি নির্দিষ্ট মাপে — Intercom-এর লেখায় ৩ = বিশাল, ২ = বেশি, ১ = মাঝারি, ০.৫ = কম, ০.২৫ = খুব কম।
• Confidence: অনুমানগুলোয় কতটা ভরসা — ১০০%, ৮০% বা ৫০%; অনুমাননির্ভর উচ্ছ্বাসে লাগাম।
• Effort: কত person-month কাজ।

WSJF (Weighted Shortest Job First) আসে অন্য দিক থেকে: দেরির দাম. Donald Reinertsen তাঁর The Principles of Product Development Flow (২০০৯) বইয়ে বলেন, প্রতিটি কাজ দেরি হলে প্রতি সপ্তাহে কিছু মূল্য হারায় — এটি cost of delay. যে কাজের cost of delay বেশি আর সময় কম, সেটি আগে; তাঁর ভাষায় cost of delay ÷ duration. SAFe (Scaled Agile Framework) এটিকে আপেক্ষিক নম্বরে সহজ করে:

এখানে job size কাজের সময়ের প্রতিনিধি হিসেবে আপেক্ষিক আকার (সাধারণত ১, ২, ৩, ৫, ৮, ১৩, ২০ ধরনের সংখ্যা)। Time criticality হলো RICE-এ যা নেই: ঈদের আগে delivery slot না এলে ঈদের পরে এর মূল্য প্রায় শূন্য। নিচের প্রোগ্রাম একই আটটি feature দুই পদ্ধতিতে সাজায়।

// Same 8 features, two scoring models: RICE (Intercom) and WSJF (Reinertsen/SAFe).
// [id, name, reach/quarter, impact, confidence, effort(person-months),
//  business value, time criticality, risk reduction/opportunity, job size]
const F = [
  ["F1", "wallet payment",     1800, 2,    0.8, 3,  13, 8,  8, 8],
  ["F2", "cash on delivery",   2500, 1,    1.0, 1,  8,  5,  2, 2],
  ["F3", "product search",     3000, 1,    0.8, 2,  8,  3,  3, 5],
  ["F4", "order tracking",     1500, 1,    0.8, 2,  5,  2,  1, 3],
  ["F5", "Eid delivery slot",   900, 2,    0.8, 2,  8, 20,  3, 3],
  ["F6", "loyalty points",      600, 0.5,  0.5, 3,  3,  1,  2, 5],
  ["F7", "product reviews",    1200, 0.5,  0.8, 1,  2,  1,  1, 2],
  ["F8", "stock alert SMS",     700, 1,    0.5, 1,  3,  2,  8, 2]
].map(([id, name, r, i, c, e, bv, tc, rr, js]) =>
  ({ id, name, rice: r * i * c / e, wsjf: (bv + tc + rr) / js }));
const rank = key => [...F].sort((a, b) => b[key] - a[key]).map(f => f.id);
const rice = rank("rice"), wsjf = rank("wsjf");
console.log("pos  RICE (score)        WSJF (score)");
for (let p = 0; p < F.length; p++) {
  const a = F.find(f => f.id === rice[p]), b = F.find(f => f.id === wsjf[p]);
  console.log(String(p + 1).padStart(2) + "   " + (a.id + " " + a.rice.toFixed(0)).padEnd(19) +
              b.id + " " + b.wsjf.toFixed(2));
}
console.log("disagreements (position gap >= 3):");
for (const f of F) {
  const gap = rice.indexOf(f.id) - wsjf.indexOf(f.id);
  if (Math.abs(gap) >= 3) console.log("  " + f.id + " " + f.name + ": RICE #" +
    (rice.indexOf(f.id) + 1) + ", WSJF #" + (wsjf.indexOf(f.id) + 1));
}

pos  RICE (score)        WSJF (score)
 1   F2 2500            F5 10.33
 2   F3 1200            F2 7.50
 3   F1 960             F8 6.50
 4   F5 720             F1 3.63
 5   F4 600             F3 2.80
 6   F7 480             F4 2.67
 7   F8 350             F7 2.00
 8   F6 50              F6 1.20
disagreements (position gap >= 3):
  F3 product search: RICE #2, WSJF #5
  F5 Eid delivery slot: RICE #4, WSJF #1
  F8 stock alert SMS: RICE #7, WSJF #3

১০০ টাকার ভোট আর জোড়ায় জোড়ায় তুলনা

১০০ ডলারের পরীক্ষা (cumulative voting) — Dean Leffingwell ও Don Widrig-এর Managing Software Requirements বইসহ অনেক requirement-বইয়ে বর্ণিত একটি কৌশল — খুব সহজ: প্রত্যেক stakeholder-কে কাল্পনিক ১০০ টাকা দিন, যেভাবে খুশি feature-গুলোতে ভাগ করতে বলুন। আমাদের app-এ চারজন (মালিক, delivery-কর্মী, দুজন গ্রাহক) চারটি feature-এ টাকা দিলেন:

ফল: search, তারপর ঈদের slot. সুবিধা — টাকা সীমিত বলে প্রত্যেককে আপস করতে হয়। দুর্বলতা — বারবার চালালে মানুষ কৌশল করেন (“প্রিয়টি এমনিতেই উঠবে, সব টাকা অন্যটিতে দিই”)। Delivery-কর্মীর ৭০ টাকা সত্যিকারের জরুরিতা কি না, আলোচনায় জিজ্ঞেস করুন।

জোড়ায় জোড়ায় তুলনা আর AHP: Thomas Saaty-র Analytic Hierarchy Process (১৯৭০-এর দশকের শেষে প্রস্তাবিত, তাঁর ১৯৮০ সালের বইয়ে বিস্তারিত) প্রতিটি জোড়া নিয়ে জিজ্ঞেস করে — “A আর B-এর মধ্যে কোনটি কত গুণ বেশি গুরুত্বপূর্ণ?” (১–৯ মাপে)। এরপর গণিত দিয়ে সব জোড়ার উত্তর থেকে ওজন বের হয়, আর একটি consistency ratio দেখায় উত্তরগুলো পরস্পরবিরোধী কি না (A > B, B > C অথচ C > A হলে অসংগত)। অসুবিধা: n-টি feature-এ তুলনা লাগে n(n − ১) ÷ ২টি — ৮টি feature-এ ২৮টি, ২০টিতে ১৯০টি। তাই AHP সাধারণত অল্প কয়েকটি বড় সিদ্ধান্তে (যেমন তিনটি architecture-এর মধ্যে বাছাই) ব্যবহার হয়।

৫ · Requirement validation — ঠিক জিনিস লিখেছি তো?

দর্জির কাছে পাঞ্জাবির মাপ দেওয়ার পরে ভালো দর্জি মাপের খাতাটি একবার পড়ে শোনান: “বুক ৪০, লম্বা ৪২, হাতা ২৪ — ঠিক আছে?” তখনই আপনি বলতে পারেন “না, লম্বা ৪৪ হবে।” কাপড় কাটার পরে বললে কাপড়ই নষ্ট। Requirement-এর ভুল কোড লেখার আগে ধরা সবচেয়ে সস্তা — পর্ব ০৪-এ দেখেছেন, দেরিতে আসা পরিবর্তন কত rework আনে।

ISO/IEC/IEEE 29148 (প্রথম সংস্করণ ২০১১, হালনাগাদ ২০১৮; পুরোনো IEEE 830-এর উত্তরসূরি) একটি ভালো requirement-এর গুণের তালিকা দেয় — ২০১৮ সংস্করণে necessary, appropriate, unambiguous, complete, singular, feasible, verifiable, correct আর conforming. এই তালিকাই একটি review checklist-এর ভিত্তি। পর্ব ২১-এ মাপা যায় এমন requirement লেখার কৌশল দেখেছেন; এখানে দেখি সেগুলো যাচাইয়ের পাঁচটি কৌশল।

Test case বানানোর কৌশল সবচেয়ে সস্তা আর শক্তিশালী। “Checkout দ্রুত হবে” থেকে test লিখতে গেলেই প্রশ্ন ওঠে — কত দ্রুত? কোন নেটওয়ার্কে? কতজন একসাথে? উত্তর লিখলে requirement নিজেই মাপা যায় এমন হয়: “৩G নেটওয়ার্কে ৯৫% checkout ৩ সেকেন্ডের মধ্যে শেষ হবে।” পর্ব ২২-এর Given-When-Then আকারের acceptance criteria এই কাজটিকেই নিয়মিত অভ্যাসে পরিণত করে।

৬ · Traceability — requirement থেকে test পর্যন্ত সুতো

মুদি দোকানের হিসাবের খাতায় প্রতিটি খরচের পাশে রশিদ নম্বর লেখা থাকলে মাসের শেষে যেকোনো খরচ ধরে রশিদ পর্যন্ত যাওয়া যায়, আবার যেকোনো রশিদ ধরে খাতার লাইন পর্যন্ত। Software-এ এই সংযোগই traceability. Orlena Gotel আর Anthony Finkelstein-এর ১৯৯৪ সালের বহুল উদ্ধৃত লেখার সংজ্ঞাটি মোটামুটি এমন: একটি requirement-এর জীবনকে সামনের ও পেছনের — দুই দিকেই বর্ণনা করতে আর অনুসরণ করতে পারার ক্ষমতা।

• Forward traceability: requirement → design → code → test. প্রশ্ন: “প্রতিটি requirement কি বানানো আর test হয়েছে?”
• Backward traceability: test বা code → requirement → stakeholder-এর চাহিদা। প্রশ্ন: “এই কোড বা test কেন আছে? কার চাহিদায়?” যে কোডের কোনো requirement নেই, সেটি হয় অপ্রয়োজনীয়, নয়তো একটি না-লেখা requirement.
• Bidirectional: দুই দিকই রাখা। বাস্তবে একই link দুই দিকে পড়া যায় — R2 → T3 লিখলে T3 → R2-ও জানা।

Requirements traceability matrix (RTM)

Requirements traceability matrix (RTM) একটি টেবিল: প্রতিটি সারিতে একটি requirement, কলামে তার design, code আর test. Spreadsheet-এ, requirement টুলে, অথবা issue tracker আর Git-এর ID দিয়ে রাখা যায়। নিচের stepper-এ release ১-এর শুরুর matrix সারি ধরে ধরে তৈরি হচ্ছে।

একই matrix প্রোগ্রামে রাখলে দুটি কাজ স্বয়ংক্রিয় হয়: ফাঁক খোঁজা, আর impact analysis — একটি requirement বদলালে কোন নকশা, কোন file, অন্য কোন requirement আর কোন কোন test-এর ওপর প্রভাব পড়বে। ধরুন মালিক বললেন R2-এর সীমা ৫০০০ থেকে ৩০০০ টাকা হবে।

// Requirements traceability: requirement -> design -> code -> tests, both directions.
const reqs = {
  R1: { text: "customer pays by mobile wallet", design: ["D-pay"] },
  R2: { text: "cash on delivery up to 5000 tk", design: ["D-pay", "D-order"] },
  R3: { text: "search products in Bangla",     design: ["D-search"] },
  R4: { text: "track order status",            design: ["D-order"] },
  R5: { text: "SMS when order is shipped",     design: ["D-notify"] }
};
const code = { "D-pay": ["payment.js"], "D-order": ["order.js", "cart.js"],
               "D-search": ["search.js"], "D-notify": ["sms.js"] };
const tests = {                       // test id -> requirement ids it verifies
  T1: ["R1"], T2: ["R1"], T3: ["R2"], T4: ["R3"], T5: ["R4"], T6: ["R9"], T7: []
};
// forward: requirement -> tests; backward: test -> requirement
for (const [id, r] of Object.entries(reqs)) {
  const ts = Object.keys(tests).filter(t => tests[t].includes(id));
  const files = r.design.flatMap(d => code[d]);
  console.log(id + " " + r.design.join("+").padEnd(15) + files.join(",").padEnd(28) +
              (ts.length ? ts.join(",") : "NO TEST"));
}
const orphans = Object.keys(tests).filter(t => !tests[t].some(r => r in reqs));
console.log("orphan tests (no valid requirement): " + orphans.join(", "));
// impact analysis: requirement R2 changes (COD limit 5000 -> 3000 tk)
function impact(id) {
  const designs = reqs[id].design;
  const files = [...new Set(designs.flatMap(d => code[d]))];
  const shared = Object.keys(reqs).filter(o => o !== id &&
                   reqs[o].design.some(d => designs.includes(d)));
  const retest = Object.keys(tests).filter(t =>
                   tests[t].some(r => r === id || shared.includes(r)));
  console.log("change " + id + " -> design " + designs.join(",") + " | files " +
              files.join(",") + "\n  also touches " + shared.join(",") +
              " | re-run tests " + retest.join(","));
}
impact("R2");

R1 D-pay          payment.js                  T1,T2
R2 D-pay+D-order  payment.js,order.js,cart.js T3
R3 D-search       search.js                   T4
R4 D-order        order.js,cart.js            T5
R5 D-notify       sms.js                      NO TEST
orphan tests (no valid requirement): T6, T7
change R2 -> design D-pay,D-order | files payment.js,order.js,cart.js
  also touches R1,R4 | re-run tests T1,T2,T3,T5

৭ · Baseline আর change control

পরিবর্তন খারাপ নয় — বাজার বদলায়, আইন বদলায়, ব্যবহারকারী নতুন কিছু শেখেন। সমস্যা হলো নিয়ন্ত্রণহীন পরিবর্তন: কেউ করিডোরে developer-কে বললেন, developer বদলে দিলেন, test দল জানল না, দাম আর সময়ের হিসাব কেউ করল না। এর ওষুধ তিনটি ধারণা।

• Baseline: review করে সবাই মিলে অনুমোদন দেওয়া requirement-এর একটি নির্দিষ্ট version, যা পরের কাজের ভিত্তি; এরপর এটি শুধু আনুষ্ঠানিক পথে বদলায়। পরীক্ষার খাতার খসড়া আর ফেয়ার কপির মতো — ফেয়ার কপিতে কাটাকাটি করতে হলে নিয়ম মেনে।
• Change request (CR): baseline বদলানোর লিখিত অনুরোধ — কে চাইলেন, কী, কেন, কতটা জরুরি।
• Change control board (CCB): যাঁরা CR-এর ওপর সিদ্ধান্ত দেন — ছোট দলে হয়তো product owner আর tech lead মাত্র দুজন, বড় চুক্তিতে গ্রাহক, ব্যবস্থাপক আর প্রধান প্রকৌশলীদের একটি কমিটি। Configuration management-এর মান IEEE 828 এই ধরনের নিয়ন্ত্রণের কাঠামো দেয়।

মুদি দোকানের app-এ release ১-এর দ্বিতীয় সপ্তাহে মালিক একটি নতুন অনুরোধ আনলেন। নিচের stepper অনুরোধটিকে জমা থেকে সিদ্ধান্ত পর্যন্ত নিয়ে যায়। পরিকল্পনা তখন §২-এর workshop-এর পঞ্চম ধাপের মতো — ৪০ ÷ ৪০, SMS-সহ; cart-এর বাড়তি খরচ তখনো দেখা দেয়নি।

Requirement-কে Git-এ রাখা

Requirement দলিল Word file-এ থাকলে “কোন version-এ কী বদলেছিল” বের করা কঠিন। সাধারণ লেখার ফরম্যাট Markdown-এ রাখলে মডিউল ২–৩-এর সব হাতিয়ার কাজে লাগে: git diff দিয়ে পার্থক্য (পর্ব ০৯, history আর পার্থক্য দেখা), pull request-এ review মানেই requirement review (পর্ব ১৬, pull request আর fork), আর annotated tag দিয়ে baseline (পর্ব ১৮, ভালো commit, tag আর release). নিচের উদাহরণ একটি নতুন repository-তে তৈরি, Git ২.৫৩-এ।

$ git add docs/requirements.md
$ git commit -q -m "docs(req): baseline requirements for release 1"
$ git tag -a req-v1.0 -m "Requirements baseline v1.0"
# CR-07 অনুমোদনের পরে docs/requirements.md বদলানো হলো
$ git commit -q -am "docs(req): apply CR-07, add delivery slot, move wallet to release 2" -m "Approved by CCB on 2026-01-15. Refs: CR-07"
$ git tag -a req-v1.1 -m "Requirements baseline v1.1"
$ git log --oneline --decorate
f1a9e14 (HEAD -> main, tag: req-v1.1) docs(req): apply CR-07, add delivery slot, move wallet to release 2
236f0b8 (tag: req-v1.0) docs(req): baseline requirements for release 1
$ git diff req-v1.0 req-v1.1
diff --git a/docs/requirements.md b/docs/requirements.md
index 28270db..4d4e43d 100644
--- a/docs/requirements.md
+++ b/docs/requirements.md
@@ -2,7 +2,8 @@

 | ID | Requirement | MoSCoW | Tests |
 |----|-------------|--------|-------|
-| R1 | Pay by mobile wallet | Should | T1, T2 |
+| R1 | Pay by mobile wallet | Won't (release 2) | T1, T2 |
 | R2 | Cash on delivery up to 5000 tk | Must | T3 |
 | R3 | Search products in Bangla | Must | T4 |
 | R4 | Track order status | Should | T5 |
+| R6 | Choose a delivery slot before Eid (CR-07) | Must | T8 |
$ git diff --word-diff req-v1.0 req-v1.1
…
| R1 | Pay by mobile wallet | [-Should-]{+Won't (release 2)+} | T1, T2 |
| R2 | Cash on delivery up to 5000 tk | Must | T3 |
| R3 | Search products in Bangla | Must | T4 |
| R4 | Track order status | Should | T5 |
{+| R6 | Choose a delivery slot before Eid (CR-07) | Must | T8 |+}
$ git log --oneline --grep=CR-07
f1a9e14 docs(req): apply CR-07, add delivery slot, move wallet to release 2

৮ · Scope creep, gold-plating আর volatility

Scope creep মানে project-এর পরিধি ধীরে ধীরে, নিয়ন্ত্রণ ছাড়া বেড়ে যাওয়া — প্রতিটি ছোট “এটাও একটু করে দিন” আলাদাভাবে নিরীহ, কিন্তু সময়, বাজেট বা অগ্রাধিকার না বদলে সব একসাথে project ডোবায়। লক্ষ্য করুন, CR-07 scope creep নয়: এটি লিখিত হয়েছে, প্রভাব মাপা হয়েছে, বিনিময়ে wallet সরেছে। পার্থক্য পরিবর্তনের আকারে নয়, পথে.

Gold-plating শুনতে নিরীহ — “বাড়তি কাজই তো করেছি” — কিন্তু এর দাম আছে: সময় যায় চাওয়া কাজ থেকে, নতুন কোডে নতুন bug, আর কেউ test-এর পরিকল্পনা করেননি (traceability matrix-এ এর কোনো requirement নেই — backward traceability এটি ধরে)। ভালো ধারণা থাকলে সেটি CR হিসেবে জমা দিন, নিজে নিজে বানাবেন না।

Requirement volatility — পরিবর্তন মাপা

কতটা পরিবর্তন “বেশি”? একটি প্রচলিত metric হলো requirement volatility:

সংজ্ঞা উৎসভেদে একটু আলাদা — কেউ ভাগ করেন baseline-এর মোট দিয়ে, কেউ সময়ের শেষের মোট দিয়ে, কেউ বদলের আকার অনুযায়ী ওজন দেন। যেটিই নিন, পুরো project-এ একই সংজ্ঞা রাখুন; তবেই প্রবণতা তুলনা করা যায়। নিচের প্রোগ্রামে ৪০টি requirement-এর baseline নিয়ে ছয়টি sprint-এর পরিবর্তন seeded PRNG দিয়ে তৈরি; চতুর্থ sprint-এ মালিকের নতুন একটি ধারণা আসে, তাই সেখানে বেশি যোগ-বদলের সুযোগ রাখা হয়েছে। ২০%-এর সতর্ক-রেখা দলের নিজের ঠিক করা, কোনো মান নয়।

// Requirements volatility per sprint = (added + deleted + modified) / total at sprint start.
let seed = 24; function rand() {   // mulberry32: small seeded PRNG
  seed = (seed + 0x6D2B79F5) | 0; let t = Math.imul(seed ^ (seed >>> 15), 1 | seed);
  t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t; return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
}
const pick = max => Math.floor(rand() * (max + 1));      // whole number 0..max
let total = 40;                                          // baseline: 40 requirements
const ALERT = 0.20;                                      // team's own warning line
console.log("sprint start  +add -del ~mod  volatility");
const vols = [];
for (let s = 1; s <= 6; s++) {
  const big = s === 4;                                   // sprint 4: owner's new idea
  const added = pick(big ? 8 : 3), deleted = pick(2), modified = pick(big ? 6 : 4);
  const v = (added + deleted + modified) / total;
  vols.push(v);
  console.log(String(s).padStart(4) + String(total).padStart(7) +
    String(added).padStart(6) + String(deleted).padStart(5) + String(modified).padStart(5) +
    (" " + (v * 100).toFixed(1) + "%").padStart(10) + (v > ALERT ? "  <- above 20%" : ""));
  total += added - deleted;
}
const avg = vols.reduce((a, b) => a + b, 0) / vols.length;
console.log("final total " + total + ", average volatility " + (avg * 100).toFixed(1) + "%");

sprint start  +add -del ~mod  volatility
   1     40     1    2    1     10.0%
   2     39     0    1    0      2.6%
   3     38     1    1    4     15.8%
   4     38     7    1    2     26.3%  <- above 20%
   5     44     0    1    3      9.1%
   6     43     1    2    4     16.3%
final total 42, average volatility 13.3%

৯ · Agile-এ requirement management

Agile দলে “requirement management” শব্দটি কম শোনা যায়, কিন্তু কাজগুলো আছে — শুধু রূপ আলাদা। Agile Manifesto-র একটি নীতিই বলে, development-এর দেরির ধাপেও বদলাতে থাকা চাহিদাকে স্বাগত জানান। তাই প্রশ্নটি “পরিবর্তন ঠেকাব কীভাবে” নয়, “পরিবর্তন সস্তা রাখব কীভাবে”।

Acceptance test-ই specification: পর্ব ২২-এর Given-When-Then আকারের acceptance criteria যদি স্বয়ংক্রিয় test হয়ে চলে, তবে সেগুলো একই সাথে requirement, test আর traceability-র link — একটি test ফেল করলে ঠিক কোন চাহিদা ভাঙল, তা নাম থেকেই বোঝা যায়। Gojko Adzic এই চর্চাকে বলেছেন specification by example. TDD আর BDD-তে এর কৌশল আসবে পর্ব ৪৮-এ।

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

AI এখন একটি meeting-এর নোট থেকে user story, acceptance criteria, এমনকি traceability matrix পর্যন্ত বানিয়ে দিতে পারে। এতে সময় বাঁচে, কিন্তু এই কাজে AI-এর ভুলগুলো খুব বিশ্বাসযোগ্য দেখায়।

AI-এর খসড়া হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি requirement নোটের কোনো বাক্যে ফিরে যায় (backward traceability); উৎসহীনগুলো আলাদা করে stakeholder-কে জিজ্ঞেস করেছি
• অগ্রাধিকারের প্রতিটি নম্বর দলের দেওয়া; সূত্রের হিসাব নিজে আবার করেছি
• AI-এর লেখা acceptance test ইচ্ছা করে ভাঙা কোডে চালিয়ে দেখেছি যে সেগুলো সত্যিই ফেল করে
• মান, বই আর বছরের প্রতিটি দাবি মূল উৎসে মিলিয়েছি
• Requirement file-এর পরিবর্তন pull request-এ diff দেখে review করেছি — AI-কে সরাসরি baseline বদলাতে দিইনি
• Prompt-এ গ্রাহকের ব্যক্তিগত তথ্য, দাম-চুক্তি বা গোপন ব্যবসায়িক তথ্য দিইনি