Functional আর non-functional requirement — SRS আর মাপা যায় এমন requirement

১ · দর্জির মাপ — “কী বানাবেন” আর “কেমন হবে”

ঈদের আগে দর্জির দোকানে গেছেন একটি পাঞ্জাবি বানাতে। দর্জি খাতায় লিখলেন: লম্বা ৪২ ইঞ্চি, বুক ৪০, হাতা ২৪, বুকের বাঁ দিকে একটি পকেট, গলায় তিনটি বোতাম। এগুলো হলো কী বানাতে হবে। তারপর আপনি বললেন: “কাপড়টা যেন গরমে আরাম দেয়, ধোয়ার পর রং না ওঠে, আর চাঁদরাতের আগের দিনের মধ্যে চাই।” এগুলো কেমন হবে আর কোন সীমার মধ্যে। শেষে যোগ করলেন: “শুধু সুতি কাপড়, আর বাজেট দুই হাজার টাকা।” এটি পছন্দের পথ বেঁধে দেওয়া শর্ত।

Software-এর requirement-ও ঠিক এই তিন ভাগে পড়ে। পর্ব ২০-এ (Requirement engineering — stakeholder, elicitation আর feasibility) দেখেছেন, stakeholder-দের কাছ থেকে চাওয়াগুলো কীভাবে বের করে আনা হয়। এই পর্বের কাজ তার পরের ধাপ: বের করে আনা চাওয়াগুলোকে ভাগ করা, পরিষ্কার বাক্যে লেখা আর যাচাই করা যায় এমন রূপ দেওয়া।

পুরো পর্বে আমরা একটি কাল্পনিক হাসপাতালের অ্যাপয়েন্টমেন্ট অ্যাপ ধরে কাজ করব। রোগী অ্যাপে ডাক্তার খুঁজবেন, খালি সময় (slot) বেছে বুক করবেন, ফি দেবেন, SMS-এ মনে করিয়ে দেওয়ার বার্তা পাবেন; রিসেপশনিস্ট বুকিং সামলাবেন, ডাক্তার নিজের দিনের তালিকা দেখবেন।

পর্ব ০৩-এ (Software quality — ISO/IEC 25010) quality-র আটটি characteristic আর quality scenario দেখেছেন। সেই শব্দভান্ডার এখানে আবার শেখানো হবে না; এখানে প্রশ্ন হলো, ওই গুণগুলোকে requirement-এর বাক্যে কীভাবে লিখবেন, SRS-এ কোথায় রাখবেন, আর পাস-ফেল কীভাবে ঠিক করবেন।

২ · Requirement-এর প্রকারভেদ — একটি গাছ

পাঠ্যবইভেদে শ্রেণিবিন্যাস একটু আলাদা, তবে মূল কাঠামো প্রায় একই। নিচের গাছে তিনটি প্রধান শাখা, প্রতিটির নিচে কয়েকটি পরিচিত উপশাখা।

Functional requirement-এর ভেতরে কী থাকে

একটি functional requirement সাধারণত তিনটি জিনিস বলে: কোন ঘটনা বা ইনপুটে (রোগী slot বেছে “নিশ্চিত” চাপলেন), system কী করবে (slot সংরক্ষণ করবে, booking ID বানাবে), আর কী আউটপুট দেবে (পর্দায় নিশ্চিতকরণ, SMS). এর ভেতরে প্রায়ই একটি business rule বসে থাকে — প্রতিষ্ঠানের নীতি, যা software-কে মানতে হয়: “একজন ডাক্তারের দিনে সর্বোচ্চ ৪০টি অ্যাপয়েন্টমেন্ট”, “অ্যাপয়েন্টমেন্টের ২ ঘণ্টা আগে পর্যন্ত বাতিল করলে পুরো ফি ফেরত।” Business rule আলাদা তালিকায় রাখা ভালো, কারণ নীতি বদলায় — আর বদলালে কোন কোন requirement ছুঁয়ে যায়, সেটি খুঁজে পাওয়া সহজ হয়।

Non-functional requirement — Sommerville-এর তিন ভাগ

Ian Sommerville-এর বহুল পঠিত পাঠ্যবই Software Engineering NFR-কে উৎস অনুযায়ী তিন ভাগে দেখায়: product requirement (software-এর নিজের আচরণ — গতি, জায়গা, নির্ভরযোগ্যতা, নিরাপত্তা, ব্যবহার-সহজতা), organisational requirement (প্রতিষ্ঠানের নীতি থেকে — কোন programming ভাষা, কোন development প্রক্রিয়া, কোন পরিবেশে চলবে) আর external requirement (বাইরের উৎস থেকে — আইন, নিয়ন্ত্রক সংস্থা, নৈতিকতা)। খেয়াল করুন, তাঁর “organisational” আর “external” ভাগের অনেকটাই অন্য লেখকেরা constraint বলেন। নাম নিয়ে বিভ্রান্ত হবেন না; প্রশ্নটি একই — এই শর্ত কোথা থেকে এলো, আর কে বদলাতে পারেন?

Domain requirement

Domain requirement আসে application-এর ক্ষেত্র থেকে — ব্যবহারকারী হয়তো মুখে বলবেনই না, কারণ তাঁর কাছে এটি “সবাই জানে”। চিকিৎসার ক্ষেত্রে: “একই রোগীর একই সময়ে দুই ডাক্তারের সাথে অ্যাপয়েন্টমেন্ট থাকতে পারবে না”, “শিশু রোগীর বুকিং অভিভাবকের মোবাইল নম্বরে হবে”, “ওষুধের নাম জেনেরিক নামসহ দেখাতে হবে।” ব্যাংকিংয়ে সুদের হিসাবের নিয়ম, রেলে আসন বণ্টনের নিয়ম — এগুলো domain requirement. সমস্যা হলো, ক্ষেত্রের বিশেষজ্ঞ এগুলো এত স্বাভাবিক ধরে নেন যে বলতে ভুলে যান, আর software engineer ক্ষেত্রটি না জানায় জিজ্ঞেস করতেও জানেন না। তাই domain বিশেষজ্ঞের সাথে বসা আর ক্ষেত্রের নথি পড়া elicitation-এর অংশ (পর্ব ২০)।

এবার অনুশীলন। নিচের stepper-এ হাসপাতাল অ্যাপের ছয়টি requirement একে একে শ্রেণিতে ফেলা হচ্ছে। প্রতিটি ধাপের আগে নিজে অনুমান করুন।

৩ · User requirement বনাম system requirement

একই চাওয়া দুই রকম পাঠকের জন্য দুই মাত্রায় লেখা হয়। হাসপাতালের পরিচালক বা রোগী-প্রতিনিধি চান এক পাতায় বুঝতে, অ্যাপটি কী সেবা দেবে। আর ডেভেলপার ও tester-এর দরকার এমন বিবরণ, যা থেকে কোড আর test লেখা যায়। Sommerville এই দুই স্তরকে বলেন user requirement আর system requirement.

খেয়াল করুন, একটি user requirement থেকে তিনটি system requirement এলো, আর এর দুটির কথা রোগী কখনো বলেননি — gateway ব্যর্থ হলে কী হবে, রাতে বার্তা পাঠানো যাবে কি না। এই “ভাঙার” সময়েই বেশিরভাগ লুকোনো প্রশ্ন বেরিয়ে আসে। প্রতিটি SR-এর সাথে কোন UR থেকে এলো (SR-3.1 → UR-3) লিখে রাখলে পরে traceability তৈরি হয় — পর্ব ২৪-এ (Requirement management) বিস্তারিত।

অনেক দলে এখন user requirement লেখা হয় user story আকারে (“রোগী হিসেবে আমি অ্যাপয়েন্টমেন্টের আগে মনে করিয়ে দেওয়ার বার্তা চাই, যাতে ভুলে না যাই”), আর system requirement-এর জায়গা নেয় acceptance criteria. সেই ধরন পর্ব ২২-এ (Use case আর user story) পুরোটা দেখবেন। আর চাওয়াগুলোকে ছবিতে মডেল করা — domain model, activity, state diagram — পর্ব ২৩-এ (Requirement modeling).

৪ · ভালো requirement-এর গুণ আর অস্পষ্টতার ফাঁদ

ভালো requirement-এর গুণ নিয়ে সবচেয়ে প্রচলিত আন্তর্জাতিক সূত্র এখন ISO/IEC/IEEE 29148 (প্রথম প্রকাশ ২০১১, সংশোধিত ২০১৮)। আমাদের জানামতে ২০১৮ সংস্করণ প্রতিটি requirement-এর জন্য নয়টি গুণ বলে, আর পুরো সেটের জন্য আলাদা কয়েকটি। মানদণ্ডের পূর্ণ লেখা কিনে পড়তে হয়, তাই শব্দ ও সংজ্ঞা পরীক্ষা বা চুক্তির কাজে মূল সূত্রে মিলিয়ে নিন; ২০১১ সংস্করণের তালিকা একটু আলাদা ছিল (যেমন সেখানে implementation free আর traceable আলাদা গুণ হিসেবে ছিল)।

পুরো সেটের গুণ: complete (কোনো চাওয়া বাদ পড়েনি, কোনো TBD ঝুলে নেই), consistent (দুটি requirement একে অপরের বিরোধী নয় — একটি বলে “বাতিলে পুরো ফেরত”, আরেকটি বলে “১০% কাটা যাবে” — এমন নয়), feasible (সব মিলিয়ে সময় ও বাজেটে সম্ভব), comprehensible (পাঠক বুঝতে পারেন system কী করবে) আর able to be validated (সব পূরণ হলে stakeholder-এর আসল প্রয়োজন মিটবে, তা দেখানো যায়)। পুরোনো IEEE 830-1998 প্রায় একই ধাঁচে একটি ভালো SRS-এর আটটি গুণ বলত: correct, unambiguous, complete, consistent, ranked for importance and/or stability, verifiable, modifiable আর traceable.

“shall”, “should”, “may” — কোন শব্দের কী ওজন

ইংরেজিতে লেখা SRS-এ ক্রিয়াপদই বলে দেয় কোনটি চুক্তির বাধ্যবাধকতা। 29148-এর প্রচলিত রীতি (আমাদের জানামতে): shall = বাধ্যতামূলক requirement; should = কাম্য লক্ষ্য বা পছন্দ, বাধ্যতামূলক নয়; may = অনুমতি বা ঐচ্ছিক; will = ঘটনার বিবরণ বা উদ্দেশ্য, requirement নয়। অনেক নির্দেশিকা “must” এড়াতে বলে, যাতে shall-এর সাথে গুলিয়ে না যায়। অন্য দিকে internet-এর প্রোটোকল-নথিতে (IETF) RFC 2119 (১৯৯৭) MUST, SHOULD, MAY-কে বড় হাতের অক্ষরে নির্দিষ্ট অর্থ দেয় — অর্থাৎ রীতিটা নথির শুরুতে ঘোষণা করে দেওয়াই আসল কথা।

অস্পষ্টতার পাঁচ ফাঁদ

• Weak word: fast, quick, user-friendly, easy, flexible, efficient, robust, adequate, “যত দ্রুত সম্ভব”, “ইত্যাদি”। এগুলোর মাপ নেই, তাই পাস-ফেল বলা যায় না।
• যাচাই করা যায় না এমন সর্বোচ্চ-সর্বনিম্ন: always, never, best, maximize, minimize, 100%. “কখনো crash করবে না” কোনো test দিয়ে প্রমাণ হয় না।
• TBD: “search-এর সময় TBD সেকেন্ড।” খোলা প্রশ্ন থাকা স্বাভাবিক, কিন্তু সাথে কে ঠিক করবেন আর কবে, তা না থাকলে সেটি স্থায়ী গর্ত হয়ে যায়।
• and/or আর যৌগিক বাক্য: “রোগী এবং/অথবা রিসেপশনিস্ট বাতিল করবেন” — দুজনই পারবেন, নাকি যেকোনো একজন, নাকি দুজন মিলে? যৌগিক বাক্য singular গুণও ভাঙে।
• কর্তাহীন passive আর অস্পষ্ট সর্বনাম: “অ্যাপয়েন্টমেন্ট বাতিল করা হবে” — কে করবে, system নিজে, নাকি রোগী? “ডাক্তার অনুপস্থিত হলে it shall notify them” — it কে, them কারা?

এই লক্ষণগুলোকে বলা হয় requirement smell — কোডের code smell-এর মতো (পর্ব ৪২): লক্ষণ মানেই ভুল নয়, কিন্তু দেখে নেওয়া দরকার। ১৯৯০-এর দশকের শেষে NASA-র Software Assurance Technology Center-এর ARM (Automated Requirement Measurement) টুলের মতো প্রচেষ্টা এমন শব্দ গুনে SRS-এর মান আঁচ করত, আর এখন অনেক requirement-টুল একই কাজ করে। নিচের program একটি খুব ছোট নিয়মভিত্তিক linter — ছয়টি কাল্পনিক requirement-এ লক্ষণ খোঁজে আর প্রতি লক্ষণে ২৫ নম্বর কেটে একটি score দেয়।

// Requirement smell checker: a tiny rule-based linter (fictional hospital app).
const WEAK = ["fast", "quick", "user-friendly", "easy", "simple", "efficient",
  "flexible", "robust", "adequate", "etc", "normally", "seamless"];
const UNVERIFIABLE = ["always", "never", "best", "maximize", "minimize",
  "as soon as possible", "100%"];
const has = (t, w) => new RegExp("(^|[^a-z])" + w + "([^a-z]|$)").test(t);
function smells(text) {
  const t = text.toLowerCase(), out = [];
  for (const w of WEAK) if (has(t, w)) out.push("weak '" + w + "'");
  for (const w of UNVERIFIABLE) if (has(t, w)) out.push("unverifiable '" + w + "'");
  if (/shall be \w+ed by/.test(t)) out.push("passive 'shall be ...ed by'");
  if (t.includes("and/or")) out.push("compound 'and/or'");
  if (has(t, "tbd")) out.push("placeholder TBD");
  if (/(^|\s)(it|they|them|this)(\s|\.|,)/.test(t)) out.push("vague pronoun");
  if (!has(t, "shall")) out.push("no 'shall'");
  return out;
}
const reqs = {
  "FR-01": "The system shall send an SMS reminder 24 hours before each appointment.",
  "FR-02": "The booking screen should be fast and user-friendly.",
  "FR-03": "An appointment shall be cancelled by the patient and/or the receptionist.",
  "NFR-04": "The doctor search shall return results in TBD seconds.",
  "FR-05": "When a doctor is marked absent, it shall notify them as soon as possible.",
  "NFR-06": "The system shall serve 200 req/s with p95 latency below 800 ms.",
};
let total = 0;
for (const [id, text] of Object.entries(reqs)) {
  const s = smells(text);
  const score = Math.max(0, 100 - 25 * s.length);
  total += score;
  console.log(id.padEnd(7), String(score).padStart(3), s.length ? s.join(", ") : "clean");
}
console.log("set quality score:", (total / Object.keys(reqs).length).toFixed(1), "/ 100");

FR-01   100 clean
FR-02    25 weak 'fast', weak 'user-friendly', no 'shall'
FR-03    50 passive 'shall be ...ed by', compound 'and/or'
NFR-04   75 placeholder TBD
FR-05    50 unverifiable 'as soon as possible', vague pronoun
NFR-06  100 clean
set quality score: 66.7 / 100

৫ · EARS — requirement লেখার পাঁচটি ছাঁচ

মুক্ত গদ্যে requirement লিখলে প্রত্যেকে নিজের মতো বাক্য গড়েন, আর অস্পষ্টতা ঢোকে। আবার পুরোপুরি গাণিতিক (formal) ভাষায় লিখলে stakeholder পড়তে পারেন না। মাঝামাঝি পথ হিসেবে Rolls-Royce-এর বিমান-ইঞ্জিন নিয়ন্ত্রণ software-এর requirement নিয়ে কাজ করতে গিয়ে Alistair Mavin ও সহকর্মীরা ২০০৯ সালের IEEE International Requirements Engineering Conference (RE'09)-এ একটি প্রবন্ধে EARS (Easy Approach to Requirements Syntax) প্রস্তাব করেন। মূল ধারণা: প্রায় সব requirement কয়েকটি বাক্য-ছাঁচের কোনো একটিতে আঁটে, আর প্রতিটি ছাঁচের শুরুর শব্দই বলে দেয় requirement কখন খাটে।

EARS-এর একটি বড় উপকার হলো “If … then” ছাঁচটি নিজেই প্রশ্ন জাগায়: প্রতিটি event-driven requirement লেখার পর জিজ্ঞেস করুন, “এই ঘটনাটি ব্যর্থ হলে কী হবে?” — payment না এলে, SMS না গেলে, নেটওয়ার্ক কেটে গেলে। Requirement-এর বেশিরভাগ ফাঁক থাকে ঠিক এই অনাকাঙ্ক্ষিত পথে। নিচের program শুরুর শব্দ দেখে বাক্যের ছাঁচ চেনে।

// EARS pattern classifier (Mavin et al., 2009) for single requirement sentences.
function earsPattern(s) {
  const t = s.trim().toLowerCase();
  if (!/\bshall\b/.test(t)) return "NOT EARS (no 'shall')";
  const kw = [];
  if (/^where\b|, where\b/.test(t)) kw.push("optional");
  if (/^while\b|, while\b/.test(t)) kw.push("state");
  if (/^when\b|, when\b/.test(t)) kw.push("event");
  if (/^if\b.*\bthen\b/.test(t)) kw.push("unwanted");
  if (kw.length > 1) return "complex (" + kw.join(" + ") + ")";
  const names = { optional: "optional feature", state: "state-driven",
                  event: "event-driven", unwanted: "unwanted behaviour" };
  if (kw.length === 1) return names[kw[0]];
  if (/^the [\w -]+ shall\b/.test(t)) return "ubiquitous";
  return "NOT EARS (unknown opening)";
}
const sentences = [
  "The appointment system shall store each booking with a unique booking ID.",
  "When a patient confirms a booking, the appointment system shall send an SMS with the booking ID.",
  "While the doctor's daily quota is full, the appointment system shall hide that doctor's remaining slots.",
  "If the payment gateway does not respond within 10 s, then the appointment system shall cancel the hold on the slot.",
  "Where the hospital enables video consultation, the appointment system shall show a video-call link 10 minutes before the slot.",
  "While the system is in maintenance mode, when a patient opens the app, the appointment system shall show the planned end time.",
  "Patients can book appointments easily.",
];
sentences.forEach((s, i) => console.log("R" + (i + 1) + ": " + earsPattern(s)));

R1: ubiquitous
R2: event-driven
R3: state-driven
R4: unwanted behaviour
R5: optional feature
R6: complex (state + event)
R7: NOT EARS (no 'shall')

এবার পুরো কৌশলটি একসাথে। নিচের stepper একটি অস্পষ্ট বাক্যকে ধাপে ধাপে পরীক্ষাযোগ্য EARS requirement-এ রূপ দেয়।

৬ · NFR-কে সংখ্যায় বাঁধা — fit criterion আর Planguage

Functional requirement-এ পাস-ফেল সাধারণত সহজ: SMS গেল কি না। NFR-এ কঠিন, কারণ “কতটা” প্রশ্নের উত্তর একটি সংখ্যা, আর সংখ্যার সাথে লাগে একক, মাপার পদ্ধতি আর পরিস্থিতি। Suzanne ও James Robertson-এর Mastering the Requirements Process (প্রথম সংস্করণ ১৯৯৯) আর তাঁদের Volere requirement template প্রতিটি requirement-এর সাথে একটি fit criterion লেখার কথা বলে — একটি মাপা যায় এমন শর্ত, যা পূরণ হলে requirement পূরণ হয়েছে ধরা হবে। পর্ব ০৩-এর quality scenario (source, stimulus, artifact, environment, response, response measure) একই লক্ষ্যে আরেকটি কাঠামো।

Planguage — Gilb-এর keyword

Tom Gilb বহু বছর ধরে বলে আসছেন, quality requirement-কে সংখ্যায় বাঁধা যায়, আর এজন্য তিনি Planguage নামে একটি keyword-ভিত্তিক কাঠামো প্রস্তাব করেন (বিস্তারিত তাঁর Competitive Engineering, ২০০৫)। পূর্ণ Planguage-এ অনেক keyword আছে; প্রচলিত মূল কয়েকটি (সংস্করণভেদে নাম ও ব্যবহার একটু আলাদা হতে পারে):

Must আর Plan আলাদা রাখার বুদ্ধিটা খেয়াল করুন: একটি সংখ্যা বলে কোথায় ব্যর্থ, আরেকটি বলে কোথায় সফল। মাঝের এলাকায় দল trade-off করতে পারে — হয়তো ৫০০ ms-এ রেখে অন্য feature-এ সময় দেওয়া। একটি মাত্র সংখ্যা দিলে সেটি লক্ষ্য না সীমা, তা নিয়েই বিতর্ক বাধে।

নিচের program “p95 latency < X ms at Y req/s” ধরনের fit criterion পড়ে নেয়, তারপর একটি কাল্পনিক load test-এর ২০০টি মাপের ওপর nearest-rank পদ্ধতিতে percentile বের করে পাস-ফেল বলে। মাপগুলো seed দেওয়া PRNG (mulberry32) থেকে বানানো, তাই প্রতিবার একই ফল আসবে।

// Is an NFR measurable? Parse a fit criterion and test it on a seeded sample.
function mulberry32(a) { return function () {
  a |= 0; 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(21);
// Fictional load test: 200 search requests at 200 req/s; 300 ms base + random tail
const sample = Array.from({ length: 200 }, () => Math.round(300 - 150 * Math.log(1 - rnd())));
const measuredLoad = 200;
const mean = Math.round(sample.reduce((a, b) => a + b) / sample.length);
console.log("mean =", mean, "ms, max =", Math.max(...sample), "ms");
function nearestRank(values, p) {                 // nearest-rank percentile
  const s = [...values].sort((x, y) => x - y);
  const rank = Math.ceil((p / 100) * s.length);   // 1-based rank
  return { rank, value: s[rank - 1] };
}
const RE = /^p(\d+) latency (<=|<) (\d+) ms at (\d+) req\/s$/;
const criteria = [
  "p95 latency < 800 ms at 200 req/s",
  "p99 latency <= 800 ms at 200 req/s",
  "p95 latency < 800 ms at 500 req/s",
  "search shall be fast",
];
for (const c of criteria) {
  const m = c.match(RE);
  if (!m) { console.log(`"${c}" -> NOT MEASURABLE (no scale, no meter)`); continue; }
  const [, p, op, limit, load] = m;
  if (Number(load) !== measuredLoad) { console.log(`"${c}" -> NO DATA at ${load} req/s`); continue; }
  const { rank, value } = nearestRank(sample, Number(p));
  const ok = op === "<" ? value < Number(limit) : value <= Number(limit);
  console.log(`"${c}" -> p${p} = ${value} ms (rank ${rank}/200) ${ok ? "PASS" : "FAIL"}`);
}

mean = 440 ms, max = 873 ms
"p95 latency < 800 ms at 200 req/s" -> p95 = 662 ms (rank 190/200) PASS
"p99 latency <= 800 ms at 200 req/s" -> p99 = 830 ms (rank 198/200) FAIL
"p95 latency < 800 ms at 500 req/s" -> NO DATA at 500 req/s
"search shall be fast" -> NOT MEASURABLE (no scale, no meter)

অন্য NFR-ও একই কৌশলে বাঁধা যায়। Usability: “প্রথমবারের ২০ জন রোগীর অন্তত ১৮ জন সাহায্য ছাড়া ৩ মিনিটে একটি অ্যাপয়েন্টমেন্ট বুক করতে পারবেন।” Maintainability: “নতুন একটি ফি-নিয়ম যোগ করতে একটির বেশি module বদলাতে হবে না।” Security: “লগইন ছাড়া কোনো রোগীর রিপোর্টের URL খুললে HTTP 401 বা 403 আসবে; প্রতি release-এ স্বয়ংক্রিয় scan-এ critical ফল শূন্য।” Portability: “Android 10 বা নতুন সংস্করণে মূল তিনটি কাজ সফল।” প্রতিটিতে আছে কী মাপা হবে, কীভাবে, আর কোন সীমায় পাস।

৭ · SRS — IEEE 830 থেকে ISO/IEC/IEEE 29148

Requirement-গুলো এক জায়গায় সাজিয়ে লেখা নথিকে বলে SRS (Software Requirements Specification). বহু বছর এর প্রচলিত নির্দেশিকা ছিল IEEE 830-1998 — “IEEE Recommended Practice for Software Requirements Specifications”. এটি একটি recommended practice, বাধ্যতামূলক মানদণ্ড নয়; তবু পাঠ্যবই, বিশ্ববিদ্যালয়ের project আর সরকারি-বেসরকারি চুক্তিতে এর তিন-অংশের কাঠামো আজও খুব পরিচিত। ২০১১ সালে ISO/IEC/IEEE 29148 IEEE 830-কে প্রতিস্থাপন করে, আর ২০১৮ সালে 29148-এর সংশোধিত সংস্করণ বেরোয়। 29148 শুধু SRS নয়, আরও কয়েকটি নথির বিষয়বস্তু বলে — যেমন stakeholder requirements specification (StRS) আর system requirements specification (SyRS) — আর requirement engineering-এর প্রক্রিয়াও বর্ণনা করে।

অংশ ১ আর ২ পাঠককে প্রেক্ষাপট দেয়: software কেন, কার জন্য, কোন বৃহত্তর ব্যবস্থার অংশ (product perspective), কারা ব্যবহার করবেন, কী কী অনুমান করা হয়েছে (যেমন “রোগীর কাছে SMS পাওয়ার মতো মোবাইল আছে”)। অংশ ৩-এ থাকে পরীক্ষাযোগ্য requirement — functional, performance, interface, constraint আর quality attribute (IEEE 830-এ “software system attributes”: reliability, availability, security, maintainability, portability). নিচের stepper-এ অংশ ৩.২-এর একটি feature-অংশ ধাপে ধাপে বানানো দেখুন।

৮ · Requirement-এর ID, attribute আর Agile দলে SRS

ID আর attribute

প্রতিটি requirement-এর একটি স্থায়ী, অনন্য ID চাই — REQ-BOOK-1, NFR-PERF-SEARCH. ID কখনো আবার ব্যবহার করবেন না: একটি requirement বাতিল হলে তার ID “Deleted” চিহ্ন নিয়ে থেকে যায়, যাতে পুরোনো test, commit বা আলোচনায় সেই ID-র মানে বদলে না যায়। অনেকে ক্রমিক নম্বর (REQ-017) নেন, অনেকে feature-এর সংক্ষিপ্ত রূপ (BOOK, CAN, PAY) — দুটোই চলে, যতক্ষণ স্থিতিশীল।

ID-র পাশে কয়েকটি requirement attribute রাখা হয়। 29148 আর বিভিন্ন টুল কয়েক ডজন attribute-এর কথা বলে; প্রচলিত মূলগুলো:

খেয়াল করুন, যাচাইয়ের চারটি প্রচলিত পদ্ধতি — test, demonstration, inspection, analysis. সব requirement test-এ যাচাই হয় না: “রোগীর তথ্য দেশের সার্ভারে রাখতে হবে” যাচাই হয় নকশা ও চুক্তি পরিদর্শন (inspection) দিয়ে; “১০ বছরে ১০ লাখ রোগীর রেকর্ড রাখার জায়গা” যাচাই হয় হিসাব (analysis) দিয়ে। Requirement লেখার সময়েই পদ্ধতিটি ঠিক করা মানে verifiable গুণটি নিশ্চিত করা। Testing-এর স্তর আর verification-validation-এর বিস্তারিত পর্ব ৪৫-এ।

Agile দলে SRS — নথি ছোট, চিন্তা নয়

Agile Manifesto (২০০১) বলে “comprehensive documentation-এর চেয়ে working software”. অনেকে এটিকে “নথি লাগবে না” পড়েন — কিন্তু Manifesto নিজেই বলে, ডান দিকের জিনিসেরও মূল্য আছে, বাঁ দিকেরটির মূল্য বেশি। বাস্তবে Agile দলে requirement-এর রূপ বদলায়:

• একটি বড় নথির বদলে জীবন্ত backlog: functional চাওয়াগুলো Product Backlog-এ user story হিসেবে, ক্রমাগত হালনাগাদ (পর্ব ০৫)। প্রতিটি story-র acceptance criteria-ই তার system requirement (পর্ব ২২)।
• NFR গল্পের বাইরে থাকে না: যে NFR সব story-তে খাটে (যেমন “p95 < 800 ms”, “সব পাতা WCAG 2.2 AA”), সেটি Definition of Done-এ বা আলাদা “constraint” তালিকায় রাখা হয়, যাতে প্রতিটি story-র সাথে যাচাই হয়। নইলে NFR কোনো sprint-এরই কাজ হয় না।
• হালকা কিন্তু স্থায়ী কাঠামো: অনেক দল একটি ছোট “product requirements” পাতা রাখে — উদ্দেশ্য, ব্যবহারকারী, অনুমান, constraint আর NFR — আর বাকিটা backlog-এ। Requirement-নথি Git repository-তে Markdown ফাইল হিসেবে রাখলে প্রতিটি বদল review আর history পায় (পর্ব ১৬-এর pull request প্রক্রিয়া)।
• নিয়ন্ত্রিত ক্ষেত্রে আনুষ্ঠানিক SRS এখনো লাগে: চিকিৎসা যন্ত্র, বিমান, রেলের সংকেত বা ব্যাংকিংয়ের মতো ক্ষেত্রে নিয়ন্ত্রক সংস্থা প্রায়ই লিখিত, trace করা requirement চায় (যেমন চিকিৎসা-যন্ত্রের software-এর জন্য IEC 62304 মানদণ্ডে requirement-এর নথি প্রত্যাশিত; দেশ ও ক্ষেত্রভেদে শর্ত আলাদা)। সেখানে Agile দলও ছোট ধাপে কাজ করে, কিন্তু নথিটি প্রতি ধাপে হালনাগাদ রাখে।

৯ · AI-এর যুগে requirement লেখা

AI কয়েক সেকেন্ডে পুরো একটি SRS-এর খসড়া লিখে দিতে পারে — সুন্দর শিরোনাম, নম্বর দেওয়া অংশ, শত শত “shall”. বিপদ এখানেই: দেখতে নিখুঁত লেখা আপনাকে মনে করায় কাজ শেষ, অথচ stakeholder-কে কেউ জিজ্ঞেস করেননি। Requirement-এর কাজে AI-এর কয়েকটি সাধারণ ভুল:

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

• প্রতিটি সংখ্যার উৎস (source) আছে, নইলে “অনুমান” চিহ্ন দিয়ে stakeholder-এর কাছে পাঠিয়েছি
• প্রতিটি বাক্যে একটি কর্তা, একটি shall, একটি প্রতিক্রিয়া — and/or বা TBD নেই
• প্রতিটি NFR-এ scale, meter আর সীমা (Must) আছে; percentile আর ভারের শর্ত লেখা
• ব্যর্থতার পথ (If…then) আর ক্ষেত্রের domain requirement বিশেষজ্ঞের সাথে মিলিয়েছি
• মানদণ্ডের নাম, সংস্করণ আর গুণের তালিকা মূল সূত্রে দেখেছি
• প্রম্পটে কোনো আসল রোগী, গ্রাহক বা চুক্তির গোপন তথ্য দিইনি