2.8 سافٹ ویئر تقاضے

جائزہ اور محرکات

سافٹ ویئر تقاضا کسی ایسی صلاحیت یا شرط کا بیان ہے جو نظام کو اپنے اسٹیک ہولڈرز کے لیے قابل قبول ہونے کے لیے فراہم کرنی، پوری کرنی یا رکھنی ہو۔ تقاضوں کی انجینئرنگ، ان بیانات کو جاننے، تجزیہ کرنے، بیان کرنے، توثیق کرنے اور سنبھالنے کا نظم و ضبط والا کام، قدر کی زنجیر کے بالکل سامنے بیٹھتی ہے۔ آگے کی ہر چیز، فن تعمیر سے کوڈ تک قبولیت کی جانچ تک، تقاضوں کو پورا کرنے کی کوشش ہے۔ اس لیے جب تقاضے غلط، نامکمل یا مبہم ہوں تو غلط چیز کو درست طریقے سے بنانے پر لگی ساری محنت خالص ضیاع ہے، اور یہ سب سے مہنگا ضیاع ہے، کیونکہ آپ اسے سب سے دیر سے دریافت کرتے ہیں۔ سافٹ ویئر انجینئرنگ باڈی آف نالج (SWEBOK) کا سافٹ ویئر تقاضوں کا علمی شعبہ اسے حقیقی انجینئرنگ نظم و ضبط سمجھتا ہے، حقیقی کام کی کلیریکل تمہید نہیں۔

بڑی ٹیموں کے لیے تقاضے وہ مشترک فہم ہیں جو بہت سے لوگوں کو ایک مربوط نظام بنانے دیتا ہے۔ ایک ڈویلپر ارادہ اپنے ذہن میں رکھ سکتا ہے؛ بہت سی ٹیموں میں سینکڑوں لوگ نہیں رکھ سکتے۔ تقاضے ان کے درمیان معاہدہ بن جاتے ہیں جنہیں صلاحیت چاہیے اور جو اسے بناتے ہیں، ٹیموں میں کام تقسیم کرنے کی بنیاد، اور یہ جانچنے کا پیمانہ کہ کب کچھ “مکمل” ہے۔ وہ براہ راست دریافت (باب 11.1) سے جڑتے ہیں، جہاں مسائل اور مواقع ابھرتے ہیں؛ UX کی بنیادوں (باب 5.1) سے، جہاں آپ صارف کی ضروریات سمجھتے ہیں؛ APIs اور انٹرفیس ڈیزائن (باب 2.3) سے، جہاں انٹرفیس کی ذمہ داریاں طے ہوتی ہیں؛ فن تعمیر اور معیار کی خصوصیات (باب 3.1) سے، جہاں غیر فعلی تقاضے ساخت چلاتے ہیں؛ اور پراجیکٹ مینجمنٹ (باب 10.6) سے، جہاں دائرہ، لاگت اور شیڈول ان کے گرد منصوبہ بند ہوتے ہیں۔

انٹرپرائز اور سرکاری ترتیبوں میں تقاضے قانونی، معاہداتی اور حفاظتی وزن رکھتے ہیں۔ ضابطے کے پابند نظام کو دکھانا ہوتا ہے کہ ہر لازمی ذمہ داری (رسائی پذیری، رازداری، سلامتی، ریکارڈ کی برقراری، مالیاتی کنٹرول) تقاضے کے طور پر گرفت میں لی گئی، نافذ ہوئی، اور شواہد سے توثیق شدہ ہے۔ سرکاری خریداریاں اکثر تقاضوں کی تصریح کے گرد بنتی ہیں، اور ادائیگی، آڈٹ اور اعتماد کی تصدیق سب اس پر منحصر ہیں کہ ہر تقاضے کو اس ثبوت تک سراغ لگایا جائے کہ وہ پورا ہوا۔ یہاں تقاضے اچھے عمل سے زیادہ ہیں: یہ جوابدہی کی ریڑھ کی ہڈی ہیں۔

بنیادی اصول

• تقاضا ضرورت یا پابندی کا اظہار ہے، حل نہیں؛ وہ بتاتا ہے کیا اور کیوں، کیسے نہیں۔
• ہر تقاضا ضروری، بلا ابہام، قابل توثیق، قابل عمل اور قابل سراغ ہونا چاہیے۔
• تقاضے اسٹیک ہولڈرز کے ساتھ دریافت اور مذاکرات سے طے ہوتے ہیں، الگ تھلگ ایجاد نہیں ہوتے۔
• غیر فعلی تقاضے اور پابندیاں فن تعمیر کو اتنا ہی شکل دیتی ہیں جتنی فعلیت۔
• تقاضے ارتقا کرتے ہیں؛ تبدیلی کو جمانے یا نظر انداز کرنے کے بجائے سوچ سمجھ کر سنبھالیں۔
• سراغ پذیری، ضرورت سے تقاضے سے ڈیزائن سے ٹیسٹ سے شواہد تک، جوابدہی کا جوڑنے والا ٹشو ہے۔
• رسمی پن کی درست سطح خطرے، پیمانے اور ضابطے کے سیاق پر منحصر ہے، عادت پر نہیں۔

سفارشات

تقاضوں کو واضح طور پر متعین کریں اور ان کی درجہ بندی کریں

زمروں کے نام جان بوجھ کر لیں۔ فعلی تقاضے بتاتے ہیں کہ نظام کو کیا کرنا ہے: وہ رویے، تبدیلیاں، اور خدمات جو وہ فراہم کرتا ہے۔ غیر فعلی تقاضے (معیار کی خصوصیات) بتاتے ہیں کہ اسے کتنی اچھی طرح کرنا ہے: کارکردگی، دستیابی، سلامتی، قابل استعمال ہونا، رسائی پذیری، دیکھ بھال کی اہلیت، اور مزید؛ یہ فن تعمیر (باب 3.1) سے سختی سے جڑے ہیں۔ پابندیاں حل پر ناقابل مذاکرات حدود ہیں: لازمی ٹیکنالوجیز، معیارات، بجٹ، قانونی قواعد، یا موجودہ نظاموں سے انٹرفیس۔ اور کاروباری تقاضوں (ادارہ نظام کیوں چاہتا ہے) کو صارف کے تقاضوں (صارفین کو کیا حاصل کرنا ہے) سے اور نظام کے تقاضوں (اس لیے سافٹ ویئر کو کیا کرنا ہے) سے الگ کریں۔ ان سطحوں کو گڈمڈ کریں تو جلد دائرے کی الجھن آتی ہے۔

مفروضوں کے بجائے حقیقی ذرائع سے جانیں

جاننا فعال دریافت ہے۔ تقاضے اسٹیک ہولڈرز سے انٹرویوز، ورکشاپس، مشاہدے، پروٹو ٹائپس، اور موجودہ نظاموں اور دستاویزات کے تجزیے کے ذریعے حاصل کریں۔ ہر متعلقہ اسٹیک ہولڈر ڈھونڈیں، بشمول ان کے جو نظر انداز کرنا آسان ہیں: آپریٹرز، آڈیٹرز، سپورٹ عملہ، اور نظام سے متاثر وہ لوگ جو اسے براہ راست استعمال نہیں کرتے۔ دریافت کو دریافت کی پائپ لائن (باب 11.1) اور UX تحقیق (باب 5.1) سے جوڑیں، تاکہ بیان کردہ خواہشات بنیادی ضروریات تک سراغ لگائی جا سکیں۔ ہر تقاضے کا ماخذ اور استدلال ریکارڈ کریں، کیونکہ یہ جاننا کہ تقاضا کیوں موجود ہے ٹھیک وہی ہے جو آپ کو بعد میں اسے محفوظ طریقے سے بدلنے دیتا ہے۔

تجزیہ کریں، مذاکرات کریں، اور ترجیح دیں

خام حاصل کردہ ضروریات ٹکراتی ہیں، ایک دوسرے پر چڑھتی ہیں، اور ممکن سے زیادہ بنتی ہیں۔ تجزیہ انہیں ہم آہنگ کرنے کا طریقہ ہے: تقاضوں کی درجہ بندی، تنازعات کی شناخت، عملی اہلیت اور خطرے کا وزن، اور اسٹیک ہولڈرز کے ساتھ ترجیحات پر مذاکرات۔ کھلے عام ترجیح دیں، مثلاً لازمی/ہونا چاہیے/ہو سکتا ہے کی تفریق یا قدر بمقابلہ لاگت کی درجہ بندی سے، تاکہ جب وقت کم پڑے تو آپ درست دائرہ کاٹیں۔ اور جہاں ماڈل وضاحت بڑھائے وہاں تقاضوں کو ماڈل کریں: عمل کے بہاؤ، حالت کے خاکے، ڈیٹا ماڈلز، اور انٹرفیس کی تعریفیں وہ خلا سامنے لاتی ہیں جو نثر چھپاتی ہے۔

رسمی پن کی درست سطح پر بیان کریں

تقاضے خطرے اور سامعین کے مطابق شکل میں لکھیں۔ اعلیٰ یقین دہانی والے سرکاری نظام کو IEEE 29148 جیسے معیار کے مطابق ترتیب شدہ رسمی تصریح کی ضرورت ہو سکتی ہے؛ تیز رفتار پروڈکٹ ٹیم تقاضے بیک لاگ میں قبولیت کے معیار کے ساتھ صارف کی کہانیوں کے طور پر گرفت میں لے سکتی ہے۔ دونوں صورتوں میں ہر تقاضا جوہری، قابل توثیق، اور “تیز”، “صارف دوست”، یا “وغیرہ” جیسے پھسلتے الفاظ سے پاک ہونا چاہیے۔ قبولیت کے معیار جوڑیں، تاکہ آپ تقاضا لکھتے وقت ہی طے کر دیں کہ اس کی توثیق کیسے ہوگی۔ اور ایک مستند ماخذ رکھیں، تقاضوں کو ای میلز، ٹکٹوں اور سلائیڈز میں بکھرنے دینے کے بجائے۔

تعمیر سے پہلے توثیق کریں

توثیق تصدیق کرتی ہے کہ جو تقاضے آپ نے بیان کیے وہ درست ہیں اور آپس میں جڑتے ہیں۔ اسٹیک ہولڈرز کے ساتھ ان کا ریویو کریں، منظرناموں سے گزریں، اور جہاں ممکن ہو تجریدی بیانات کو ٹھوس بنانے کے لیے پروٹو ٹائپس استعمال کریں۔ توثیق کسی بھی بعد کی اصلاح سے سستی ہے: تقاضوں کے ریویو میں پکڑا گیا نقص پروڈکشن میں پکڑے گئے اسی نقص کی لاگت کا ایک حصہ ہے۔

تقاضوں کو سنبھالیں اور سراغ پذیری برقرار رکھیں

تقاضے بدلتے ہیں۔ آپ کا کام اس تبدیلی کو کنٹرول کرنا ہے، اس کی مزاحمت نہیں۔ تبدیلی کا عمل قائم کریں: ہر مجوزہ تبدیلی کو قبول کرنے سے پہلے اثر، لاگت، اور آگے کے اثرات کے لیے تولیں۔ تقاضوں کو متفقہ نکات پر بنیادی خط بنائیں اور ان کے ورژن رکھیں۔ دو طرفہ سراغ پذیری رکھیں جو ہر تقاضے کو آگے ڈیزائن، کوڈ اور ٹیسٹوں سے اور پیچھے اس ضرورت سے جوڑے جہاں سے وہ آیا۔ سراغ پذیری وہ دو سوال حل کرتی ہے جن پر بڑی ٹیمیں جیتی ہیں: اگر یہ ضرورت بدلے تو یہ کس چیز کو متاثر کرتی ہے؛ اور اس فراہم کردہ فیچر کے لیے کس ضرورت نے جواز دیا؟ ضابطے کے پابند سیاق میں سراغ کو قبولیت کے شواہد (ٹیسٹ کے نتائج، آڈٹ ریکارڈ، دستخط) تک بڑھائیں تاکہ آپ تعمیل کا محض دعویٰ کرنے کے بجائے مظاہرہ کر سکیں۔

ایجائل اور منصوبہ بند سیاق کے مطابق ڈھلیں

منصوبہ بند اور ضابطے کے پابند پروگراموں میں آپ رسمی تبدیلی کے کنٹرول کے ساتھ تقاضے کافی پہلے بیان اور بنیادی خط بناتے ہیں۔ ایجائل سیاق میں تقاضے ترجیحی، ارتقا پذیر بیک لاگ کے طور پر رہتے ہیں، نفاذ سے ذرا پہلے تفصیل پاتے ہیں اور چلتے سافٹ ویئر کے ذریعے مسلسل توثیق ہوتے ہیں۔ بنیادی سرگرمیاں دونوں میں ایک ہیں؛ صرف وقت، رسمی پن اور دستاویزات مختلف ہیں۔ بڑے ادارے اکثر دونوں ملاتے ہیں: وہ مستحکم، اعلیٰ یقین دہانی کی ذمہ داریاں رسمی طور پر بیان اور سراغ لگاتے ہیں، جبکہ پروڈکٹ کے رویے کی تکراری تفصیل کرتے ہیں۔ توازن خطرے سے چنیں، نظریے سے نہیں۔

سمجھوتے: فوائد اور نقصانات

طریقہ	کس کے لیے بہترین	فوائد	نقصانات
رسمی پیشگی تصریح	اعلیٰ یقین دہانی، ضابطے کے پابند، مقررہ دائرے کے معاہدے	مضبوط سراغ پذیری؛ واضح قبولیت کی بنیاد؛ قابل آڈٹ	تبدیلی میں سست؛ سیکھنے سے پہلے حد سے زیادہ بیان کرنے کا خطرہ
ایجائل بیک لاگ	مصروف اسٹیک ہولڈرز کے ساتھ ارتقا پذیر مصنوعات	تیز فیڈبیک؛ سیکھنے کے مطابق ڈھلتا ہے؛ نہ بنائے گئے دائرے پر کم ضیاع	طویل مدتی سراغ پذیری کمزور؛ آڈٹ اور معاہدہ مشکل
ہائبرڈ (رسمی پابندیاں + ایجائل رویہ)	ملی جلی ذمہ داریوں والے انٹرپرائز	جہاں اہم ہو وہاں سختی، باقی جگہ لچک	یہ فیصلہ کرنا پڑتا ہے کہ کون سے حصے کون سے ہیں

مرکزی کشمکش استحکام اور سیکھنے کے درمیان ہے۔ تقاضوں کو جلد جمانا آپ کو مضبوط قبولیت کی بنیاد اور آڈٹ کی اہلیت خرید دیتا ہے، مگر بناتے ہوئے جو سیکھیں اس کے مطابق ڈھلنے کی صلاحیت کی قیمت پر۔ انہیں مؤخر کرنا لچک خریدتا ہے، مگر طویل مدتی سراغ پذیری اور معاہداتی وضاحت کی قیمت پر۔ تقاضوں کی انجینئرنگ میں زیادہ سرمایہ کاری بھی قریب کی رفتار کو بعد میں کم دوبارہ کام کے بدلے دیتی ہے: ایسا سودا جو نظام کے پیمانے، عمر اور ناکامی کے نتیجے کے بڑھنے کے ساتھ ثمر دیتا ہے۔ سب سے بڑے منصوبے اور سب سے زیادہ ضابطے والے مضبوطی سے اعلیٰ سرمایہ کاری والی طرف بیٹھتے ہیں۔ کم داؤ کا اندرونی ٹول نہیں۔

اپنی ٹیم کے ساتھ بحث کے سوالات

1. ہمارے سب سے زیادہ خطرے والے نظام کے لیے اسٹیک ہولڈر کون شمار ہوتا ہے، اور کن کو ہم قبولیت تک چھوڑتے رہتے ہیں؟ بڑے پروگرام پر جو لوگ چھوٹ جاتے ہیں وہ شاذ ہی واضح صارف ہوتے ہیں: وہ آپریٹرز جو رات کے تین بجے اسے چلاتے ہیں، آڈیٹرز جنہیں اس کی تصدیق کرنی ہے، سپورٹ عملہ جو ناکامیاں سنبھالتا ہے، اور متاثر غیر صارفین جو کبھی لاگ ان نہیں کرتے مگر جن کا ڈیٹا آپ رکھتے ہیں۔ انہیں چھوڑیں تو آپ ان کے تقاضے سب سے مہنگے لمحے پر دریافت کرتے ہیں، قبولیت کے دوران یا ریگولیٹر کے پوچھنے کے بعد۔ اجلاس میں ٹھوس اسٹیک ہولڈر کا نقشہ لائیں اور اسے آزمائیں: ہر لازمی ذمہ داری (رسائی پذیری، رازداری، ریکارڈ کی برقراری، سلامتی) کے لیے اس شخص کا نام لیں جو اس کا مالک ہے اور وہ تقاضا جو اسے گرفت میں لیتا ہے۔ اگر آپ مالک کا نام نہیں لے سکتے تو آپ نے خلا پایا، اور حل یہ ہے کہ اس اسٹیک ہولڈر کو ابھی دریافت میں شامل کریں بجائے بعد میں ان کی ضروریات کو مقررہ فن تعمیر میں دوبارہ فٹ کرنے کے۔

2. جب کوئی تقاضا بدلے تو کیا ہم تبدیلی منظور کرنے سے پہلے جواب دے سکتے ہیں کہ یہ کس چیز کو متاثر کرتا ہے؟ یہ اس کا عملی امتحان ہے کہ آپ کی دو طرفہ سراغ پذیری حقیقی ہے یا آرائشی۔ بڑے یا ضابطے کے پابند نظام میں ایک اصول کی تبدیلی ڈیزائن، کوڈ، ٹیسٹوں اور قبولیت کے شواہد میں لہریں بنا سکتی ہے، اور اسے اندھا منظور کرنا وہ طریقہ ہے جس سے آپ تعمیل جیسا لگنے والا نظام ریلیز کرتے ہیں جو خاموشی سے وہ اصول توڑتا ہے جو پہلے پورا کرتا تھا۔ اجلاس میں حالیہ تبدیلی کی درخواست لائیں اور اسے آگے سراغ لگانے کی کوشش کریں: اگر اس میں دوپہر بھر کی کھدائی لگے تو آپ کی سراغ پذیری اپنا کام نہیں کر رہی۔ جواب سے آپ کا تبدیلی کا عمل بدلنا چاہیے، تاکہ اثر کا جائزہ ہاتھ سے تلاش کے بجائے زندہ سراغ کے خلاف تیز استفسار ہو، اور بنیادی خطوط اور ورژننگ آپ کو بدلنے کے لیے مستحکم نکتہ دیں۔

3. ہمارے تقاضوں کا واحد مستند ماخذ کہاں رہتا ہے، اور اس سے باہر کتنی سچائی بکھری ہے؟ تقاضوں کا پھیلاؤ (اصل تصریح کا ای میلز، ٹکٹوں، سلائیڈز اور کسی کی یادداشت میں بکھرنا) بڑی ٹیموں کی سب سے عام ناکامیوں میں سے ہے، اور آڈٹ شدہ نظاموں میں مہلک ہے جہاں آپ کو دکھانا ہوتا ہے کہ کیا طے ہوا تھا۔ بلند آواز طے کریں کہ کون سا ریکارڈ کا نظام مستند ہے، اور وہاں اپنے ماخذ اور استدلال کے ساتھ اترنے تک کسی اور جگہ بیان کردہ ہر چیز کو مسودہ سمجھیں۔ شواہد لائیں: گنیں کہ حالیہ کتنے دائرے کے تنازعات اس پر ختم ہوئے کہ دو لوگ مختلف “حتمی” ورژن کا حوالہ دے رہے تھے۔ اگر گنتی صفر سے زیادہ ہے تو عمل ایک ماخذ میں یکجا کرنا اور ہر تقاضے کا استدلال لکھنا ہے، کیونکہ یہ جاننا کہ تقاضا کیوں موجود ہے ٹھیک وہی ہے جو آپ کو بعد میں اسے محفوظ طریقے سے بدلنے یا چھوڑنے دیتا ہے۔

4. کیا ہمارے غیر فعلی تقاضے فن تعمیر کو چلانے کے لیے کافی جلد گرفت میں آتے ہیں، یا ہم ساخت طے ہونے کے بعد انہیں دریافت کرتے رہتے ہیں؟ کارکردگی، دستیابی، سلامتی اور رسائی پذیری کی ذمہ داریاں زیادہ تر فیچرز سے زیادہ فن تعمیر کو شکل دیتی ہیں، اور بڑے پروگرام پر یہ وہ تقاضے ہیں جو اکثر بہت دیر سے سامنے آتے ہیں، جب ان کو پورا کرنے والی ساخت پہلے ہی کنکریٹ میں ڈھل چکی ہو۔ مقابل کھنچاؤ حقیقی ہے: فعلی رویہ وہ ہے جو اسٹیک ہولڈرز بلند آواز مانگتے ہیں اور جو اچھی ڈیمو ہوتا ہے، جبکہ “عروج کے بوجھ تلے سب سیکنڈ سے کم جواب” یا “WCAG رسائی پذیری کی مطابقت” کا تقاضا خلاف ورزی تک غیر مرئی رہتا ہے۔ اپنے سب سے زیادہ خطرے والے نظام کے غیر فعلی تقاضوں کی موجودہ فہرست لائیں، ہر ایک وقت کی لکیر پر کس نکتے پر لکھا گیا، اور کیا فن تعمیر (باب 3.1) نے انہیں واضح محرک کے طور پر پایا یا اخذ کیا۔ انٹرپرائز اور سرکاری ترتیبوں میں لازمی معیار کی ذمہ داریاں (انکرپشن، ریکارڈ کی برقراری، رسائی پذیری کا قانون) شامل کریں اور جانچیں کہ ہر ایک ڈیزائن کو دیا گیا تحریری، قابل پیمائش تقاضا ہے، مفروضہ نہیں، کیونکہ قبولیت کے بعد معیار کی خصوصیت دوبارہ لگانا وہ جگہ ہے جہاں بجٹ اور شیڈول خاموشی سے مرتے ہیں۔

5. ہمارے ہر نظام کے لیے رسمی پن کی کون سی سطح درست ہے، اور کیا ہم اسے خطرے سے چنتے ہیں یا عادت سے؟ ایک بڑا ادارہ عموماً نظاموں کا پھیلاؤ چلاتا ہے، پھینکنے والے اندرونی ٹول سے لے کر زندگی یا حفاظت کے ضابطے والے پلیٹ فارم تک، اور سب پر ایک رسم لگانا یا کم خطرے کے کام کو کاغذی کارروائی میں دفن کرتا ہے یا زیادہ خطرے کے کام کو کم بیان شدہ چھوڑ دیتا ہے۔ کھنچاؤ رسمی پیشگی تصریح کی آڈٹ کی اہلیت اور مضبوط قبولیت کی بنیاد اور ارتقا پذیر بیک لاگ کے تیز فیڈبیک اور کم ضیاع کے درمیان ہے، اور زیادہ تر انٹرپرائز کے لیے ایماندار جواب سوچا سمجھا امتزاج ہے: مستحکم، اعلیٰ یقین دہانی کی ذمہ داریاں رسمی بنائیں اور سراغ لگائیں جبکہ پروڈکٹ کے رویے کی تکراری تفصیل کریں۔ اپنے نظاموں کی مختصر فہرست لائیں جو ناکامی کے نتیجے، ضابطے کے خطرے، اور تبدیلی کی شرح کے لحاظ سے درجہ بند ہو، اور ہر ایک کے لیے وہ رسمی پن نام زد کریں جو آپ دراصل استعمال کرتے ہیں بمقابلہ وہ جس کا خطرہ جواز دیتا ہے۔ سولیسیٹیشن اور IEEE 29148 جیسے معیار سے جڑے سرکاری پروگرام کے لیے رسمی پن جزوی طور پر معاہدہ طے کرتا ہے، اس لیے بحث یہ ہے کہ آپ اوپر ایجائل تفصیل کہاں لگا سکتے ہیں بغیر اس سراغ پذیری کو توڑے جس پر آڈٹ منحصر ہے۔

6. کیا ہمارے سب سے زیادہ خطرے والے نظام کا ہر تقاضا قابل توثیق ہے، اور کیا ہر ایک کے پاس قبولیت کے معیار ہیں جو تقاضا لکھتے ہی لکھے گئے؟ جس تقاضے کی توثیق نہ ہو سکے وہ تقاضا نہیں، خواہش ہے، اور “تیز”، “محفوظ”، یا “صارف دوست” جیسے پھسلتے الفاظ ریویو پاس کر جاتے ہیں ٹھیک اس لیے کہ انہیں کوئی ناکام نہیں کر سکتا۔ بڑی ٹیم کے لیے یہ دو بار اہم ہے: ناقابل توثیق تقاضے قبولیت پر دائرے کے تنازعات پیدا کرتے ہیں، اور یہ کہنا ناممکن بناتے ہیں کہ کوئی فیچر کب واقعی مکمل ہے۔ متصادم غور رفتار ہے، کیونکہ ہر تقاضے کے ساتھ قابل پیمائش معیار اور توثیق کا طریقہ جوڑنا نثر لکھنے سے آگے سست ہے، مگر یہ سب سے مہنگی دیر کی دوبارہ تحریر کے خلاف سب سے سستا دفاع ہے۔ حالیہ تقاضوں کا نمونہ لائیں اور ہر ایک کو سادہ پیمانے پر جانچیں: کیا وہ جوہری ہے، کیا قابل پیمائش ہے، اور کیا یہ نام لیتا ہے کہ اسے کیسے جانچا جائے گا۔ ضابطے کے پابند اور سرکاری سیاق میں جانچ کو شواہد تک بڑھائیں: وہ تقاضا جس کے پاس سراغ شدہ، پاس ہونے والے قبولیت کے شواہد نہ ہوں فراہم شدہ نہیں سمجھا جاتا چاہے سافٹ ویئر کچھ بھی کرتا دکھائی دے، اس لیے قبولیت کے معیار اس تعمیل کے ریکارڈ کا بیج ہیں جو آپ کو آخرکار پیش کرنا ہوگا۔

شعبہ جاتی نقطۂ نظر

اسٹارٹ اپ۔ چھوٹی ٹیم اور کم رن وے کے ساتھ تقاضے جتنا ممکن ہو ہلکے رکھیں: تصریح کی دستاویز کے بجائے ایک مشترک بیک لاگ میں قبولیت کے معیار کے ساتھ صارف کی کہانیاں۔ یہاں بھی جو نظم و ضبط ثمر دیتا ہے وہ بنانے سے پہلے حقیقی صارفین سے بات کرنا اور ہر کہانی کا ماخذ اور استدلال ریکارڈ کرنا ہے، تاکہ جو ہفتہ آپ غلط فیچر بنانے میں ضائع کرتے وہ ہفتہ آپ بچا لیں۔ رسمی سراغ پذیری چھوڑ دیں، مگر وہ گفتگو کبھی نہ چھوڑیں جو بتاتی ہے کہ اصل ضرورت کیا ہے۔

چھوٹا کاروبار۔ غالباً آپ کے پاس کاروباری تجزیہ کار یا تقاضوں کا ماہر نہیں، اس لیے کام اس پر آتا ہے جو گاہک کے سب سے قریب ہو، اور خریدنے بمقابلہ بنانے کا سوال غالب ہے۔ تقاضوں کو ان نتائج کی مختصر، ترجیحی فہرست کے طور پر پیش کریں جو آپ کو چاہییں، پھر اسے مخصوص تعمیر بیان کرنے کے بجائے تیار شدہ ٹولز کا جائزہ لینے کے لیے استعمال کریں۔ بنیادی ضرورت کو فروخت کنندہ کی فیچر فہرست سے الگ رکھنے میں سخت رہیں، کیونکہ “ہمیں پروڈکٹ X چاہیے” لکھا تقاضا خاموشی سے وہ سستے اختیارات بند کر دیتا ہے جو اصل ضرورت پوری کر دیتے۔

بڑا ادارہ۔ پیمانہ تقاضوں کو وہ معاہدہ بنا دیتا ہے جو بہت سی ٹیموں کو ایک مربوط نظام بنانے دیتا ہے، اس لیے ترجیح مستقل لاگو معیاری عمل ہے: متعین زمرے، ضرورت سے ٹیسٹ تک دو طرفہ سراغ پذیری، واحد مستند ماخذ، اور بنیادی خطوط کے ساتھ کنٹرول شدہ تبدیلی۔ کاروباری، صارف اور نظام کے تقاضے واضح طور پر الگ کریں اور غیر فعلی تقاضے فن تعمیر کو محرک کے طور پر دیں، تاکہ دائرہ اور معیار کی ذمہ داریاں ٹیموں میں بکھر نہ جائیں۔ مستحکم، اعلیٰ یقین دہانی کی ذمہ داریوں کے لیے رسمی تصریح کو پروڈکٹ کے رویے کی ایجائل تفصیل کے ساتھ ملائیں، اور توازن کو خطرے سے منظم کریں، کسی ایک ٹیم کی ترجیح سے نہیں۔

حکومت۔ خریداری کے قواعد اکثر پورا معاہدہ تقاضوں کی تصریح کے گرد بناتے ہیں، جو اکثر IEEE 29148 جیسے معیار کے مطابق ترتیب شدہ ہوتی ہے، اس لیے درستگی اور مکمل پن معاہداتی ہیں، اختیاری نہیں۔ تقاضوں کی سراغ پذیری کا میٹرکس رکھیں جو ہر تقاضے کو ڈیزائن، ٹیسٹ کیسز اور قبولیت کے شواہد سے جوڑے، کیونکہ فروخت کنندہ کی ادائیگی، آڈٹ، اور عمل کی اجازت سب دکھائی گئی کوریج پر منحصر ہیں۔ شفافیت اور عوامی جوابدہی معیار اور بلند کرتی ہیں: رسائی پذیری، رازداری اور ریکارڈ کی برقراری کی لازمی ذمہ داریاں ہر ایک کو واضح، قابل توثیق تقاضے کے طور پر ظاہر ہونی چاہئیں، اور بغیر سراغ شدہ، پاس ہونے والے شواہد کا تقاضا سادہ طور پر فراہم نہیں ہوا۔

مثالیں

اسٹارٹ اپ۔ شیڈولنگ ایپ بنانے والا چار افراد کا اسٹارٹ اپ رسمی تصریح کے بجائے مشترک بیک لاگ میں قبولیت کے معیار کے ساتھ صارف کی کہانیوں کے طور پر تقاضے گرفت میں لیتا ہے۔ کیلنڈر ہم آہنگی کا فیچر لکھنے سے پہلے بانی ایک دوپہر پانچ ممکنہ گاہکوں سے بات کرنے میں گزارتا ہے اور سیکھتا ہے کہ اصل ضرورت دو ٹولز کے پار دوہری بکنگ سے بچنا ہے، نہ کہ وہ ہم آہنگی جس کا انہوں نے فرض کیا تھا۔ وہ ایک گفتگو کہانی کو نئی شکل دیتی ہے اور غلط چیز بنانے کا ایک ہفتہ بچاتی ہے۔ اس پیمانے پر بھی وہ ہر کہانی کا ماخذ اور استدلال لکھتے ہیں، تاکہ ترجیحات بدلنے پر وہ یہ دوبارہ بحث کیے بغیر کہ وہ کیوں موجود تھا، دائرہ چھوڑ یا دوبارہ بنا سکیں۔

بڑا ادارہ۔ ایک کثیر قومی بینک اپنا قرض شروع کرنے کا پلیٹ فارم بدلتا ہے۔ تقاضوں کی ٹیم کاروباری تقاضے (منظوری کا وقت کم کرنا، قرض کے ضوابط پورے کرنا)، صارف کے تقاضے (قرض افسران کو ایک نظر میں پیشکشوں کا موازنہ کرنا ہے)، اور نظام کے تقاضے (پلیٹ فارم کو تین بنیادی نظاموں سے ملنا ہے) الگ کرتی ہے۔ غیر فعلی تقاضے (عام استفسارات پر سیکنڈ سے کم جواب، 99.95% دستیابی، ذاتی ڈیٹا کی انکرپشن) واضح طور پر گرفت میں لیے جاتے اور فن تعمیر (باب 3.1) کو محرک کے طور پر دیے جاتے ہیں۔ ہر تقاضا بیک لاگ کے ذریعے خودکار قبولیت کے ٹیسٹوں تک سراغ لگایا جاتا ہے۔ اس لیے جب ریگولیٹر پوچھتا ہے کہ کسی مخصوص قرض کا اصول کیسے نافذ ہوتا ہے تو ٹیم بس اصول سے اس ٹیسٹ تک سراغ کی پیروی کرتی ہے جو اس کی توثیق کرتا ہے۔

حکومت۔ ایک قومی ایجنسی رسمی سولیسیٹیشن کے ذریعے فوائد کی اہلیت کا نظام خریدتی ہے۔ معاہدہ IEEE 29148 کے مطابق ترتیب شدہ تقاضوں کی تصریح پر لنگر انداز ہے، جو فعلی اہلیت کے قواعد، لازمی رسائی پذیری کی مطابقت، رازداری اور ریکارڈ کی برقراری کی پابندیوں، اور سلامتی کے کنٹرولز کا احاطہ کرتی ہے۔ تقاضوں کی سراغ پذیری کا میٹرکس ہر تقاضے کو ڈیزائن کے عناصر، ٹیسٹ کیسز اور قبولیت کے شواہد سے جوڑتا ہے۔ فروخت کنندہ کی ادائیگیاں اور عمل کی اجازت (پروڈکشن میں نظام چلانے کی رسمی منظوری) دونوں دکھائی گئی کوریج پر منحصر ہیں۔ بغیر سراغ شدہ، پاس ہونے والے قبولیت کے شواہد کا تقاضا سادہ طور پر فراہم شدہ نہیں سمجھا جاتا، چاہے سافٹ ویئر کچھ بھی کرتا دکھائی دے۔

کاروباری جواز: محرکات، ROI اور TCO

تقاضوں کی انجینئرنگ کی معاشی دلیل نقائص کو دیر سے ٹھیک کرنے کی لاگت پر ٹکی ہے۔ صنعتی مطالعات مسلسل پاتے ہیں کہ تقاضوں کے نقائص پراجیکٹ کی ناکامی کی سب سے عام اور مہنگی وجوہات میں ہیں، اور یہ کہ نقص ٹھیک کرنے کی لاگت تقاضوں کے مرحلے سے پروڈکشن تک کئی درجوں تک چڑھتی ہے۔ اس لیے تقاضوں کو واضح اور توثیق کرنے پر خرچ کیا گیا پیسہ دراصل لیوریج ہے: آگے کی معمولی سرمایہ کاری آپ کو غلط چیز بنانے، ٹیسٹ کرنے اور چلانے سے بچاتی ہے۔

تقاضوں کی ملکیت کی کل لاگت میں نظام کی پوری عمر میں دریافت، تصریح، ٹولنگ اور تبدیلی کے انتظام کی جاری محنت شامل ہے؛ یہ ایک بار کی لاگت نہیں۔ اس کے مقابل ناقص تقاضوں کی لاگت کھڑی ہے: دوبارہ کام، دائرے کے تنازعات، شیڈول سے تجاوز، ناکام قبولیت، معاہداتی جرمانے، اور ضابطے کے پابند ماحول میں جرمانے یا اجازت کا نقصان۔ قیادت کے لیے تقاضوں کی پختگی کو خطرے میں کمی اور پیش گوئی کی اہلیت کے طور پر پیش کریں۔ تقاضوں کی تبدیلی، نقص کی اصل، اور فراہم شدہ کام کا وہ حصہ ٹریک کریں جو توثیق شدہ ضرورت تک سراغ لگایا جا سکے، اور انہیں پراجیکٹ مینجمنٹ کی پیش گوئی (باب 10.6) سے جوڑیں۔ واپسی فیچر کے طور پر ظاہر نہیں ہوتی۔ یہ ان ناکامیوں اور دوبارہ کام کی صورت میں ظاہر ہوتی ہے جو کبھی ہوئے ہی نہیں۔

ضد نمونے اور خامیاں

• تقاضوں کے بھیس میں حل: بنیادی ضرورت کے بجائے چنی ہوئی ٹیکنالوجی یا اسکرین کا ڈھانچہ بیان کرنا، بہتر اختیارات بند کرتا ہے۔
• مبہم زبان: “تیز”، “محفوظ”، “بدیہی” بغیر قابل پیمائش معیار کے، تقاضے کو ناقابل توثیق بناتے ہوئے۔
• گولڈ پلیٹنگ: وہ تقاضے گرفت میں لینا جو کسی اسٹیک ہولڈر کو واقعی نہیں چاہییں، دائرہ اور لاگت پھلاتے ہوئے۔
• غائب غیر فعلی تقاضے: کارکردگی، سلامتی، یا رسائی پذیری کی ذمہ داریاں فن تعمیر طے ہونے کے بعد ہی دریافت کرنا۔
• تقاضوں کا پھیلاؤ: ای میلز، ٹکٹوں اور سلائیڈز میں بکھری سچائی، بغیر مستند ماخذ کے۔
• منجمد یا بے قابو تبدیلی: یا تو ہر تبدیلی سے انکار، یا اثر کے جائزے کے بغیر ہر تبدیلی قبول کرنا۔
• کوئی سراغ پذیری نہیں: یہ جواب دینے میں ناکامی کہ تبدیلی کس چیز کو متاثر کرتی ہے یا فیچر کیوں موجود ہے، آڈٹ شدہ نظاموں میں مہلک۔
• تجزیے کا مفلوج پن: لامتناہی تصریح جو چلتے سافٹ ویئر سے سیکھنے میں تاخیر کرتی ہے۔
• نظر انداز اسٹیک ہولڈرز: آپریٹرز، آڈیٹرز، اور متاثر غیر صارفین قبولیت تک چھوڑ دیے گئے۔

پختگی کا ماڈل

• سطح 1، آغاز۔ تقاضے مضمر یا زبانی ہیں، غیر مستقل اور ردعملی طور پر گرفت میں لیے گئے۔ دائرے کے تنازعات اور دوبارہ کام عام ہیں؛ کوئی سراغ پذیری، کوئی قبولیت کے معیار، اور کوئی متعین عمل نہیں۔
• سطح 2، ترقی۔ کچھ ٹیمیں تقاضے لکھتی اور فی پراجیکٹ ٹریک کرتی ہیں، بنیادی ترجیح اور فی البدیہہ تبدیلی کے انتظام کے ساتھ۔ عمل موجود ہیں مگر ٹیم اور شخص کے لحاظ سے بدلتے ہیں، اس لیے زمرے، رسمی پن اور معیار پورے ادارے میں غیر مستقل ہیں۔
• سطح 3، معیار بندی۔ معیاری تقاضوں کا عمل دستاویزی اور پورے ادارے میں نافذ ہے: متعین زمرے، دریافت اور توثیق کے عمل، تصنیف کے وقت جڑے قبولیت کے معیار، واحد مستند ماخذ، اور ضرورت سے ٹیسٹ تک دو طرفہ سراغ پذیری، ایجائل یا منصوبہ بند سیاق کے مطابق مستقل ڈھلی ہوئی۔
• سطح 4، انتظام۔ عمل ڈیٹا سے ناپا اور کنٹرول کیا جاتا ہے۔ تقاضوں کی تبدیلی، نقص کی اصل، سراغ پذیری کی کوریج، اور فراہم شدہ کام کا وہ حصہ جو توثیق شدہ ضرورت تک سراغ لگایا جا سکے بنیادی خطوط کے مقابل ٹریک ہوتے ہیں؛ سراغ پذیری قبولیت کے شواہد اور تعمیل تک بڑھتی ہے؛ اور تقاضوں کے اشاریے پراجیکٹ کی پیش گوئی (باب 10.6) کو کھلاتے ہیں، تاکہ تبدیلی اور معیار کے فیصلے رائے کے بجائے شواہد پر ٹکیں۔
• سطح 5، ہم آہنگی۔ تقاضوں کا عمل مسلسل بہتر اور پورے ادارے میں مربوط ہے۔ رسمی پن خطرے اور نتیجے کے مطابق موافق طور پر ٹیون ہوتا ہے، دریافت اور سراغ پذیری کی ٹولنگ دریافت، فن تعمیر اور ترسیل سے جڑی ہے، اور ادارہ اپنی پیمائش کی تاریخ استعمال کرتا ہے تاکہ بار بار آنے والے تقاضوں کے نقائص کوڈ تک پہنچنے سے پہلے روکے۔

بحث کے لیے خیالات

• جب کوئی سینئر اسٹیک ہولڈر تقاضا حل کے طور پر بیان کرے تو آپ حقیقی تقاضے کو قبل از وقت حل سے کیسے الگ کرتے ہیں؟
• آپ کے سب سے زیادہ خطرے والے نظام بمقابلہ کم ترین خطرے والے کے لیے تقاضوں کے رسمی پن کی درست سطح کیا ہے، اور فیصلہ کون کرتا ہے؟
• آپ تیز رفتار ایجائل بیک لاگ میں دو طرفہ سراغ پذیری کو بیوروکریٹک بوجھ بنے بغیر موجودہ کیسے رکھتے ہیں؟
• آپ کے ادارے میں کون سے غیر فعلی تقاضے سب سے زیادہ دیر سے دریافت ہوتے ہیں، اور کیوں؟
• ضابطے کے پابند پروگرام میں کافی قبولیت کا ثبوت کیا ہے کہ تقاضا پورا ہوا؟
• AI کی معاونت والے دریافت اور تصریح کے ٹولز کو آپ کے تقاضوں کا عمل کیسے بدلنا چاہیے، اور وہ کون سے نئے خطرات متعارف کراتے ہیں؟

اہم نکات

• تقاضے ضروریات اور پابندیاں بیان کرتے ہیں، حل نہیں؛ انہیں ضروری، بلا ابہام، قابل توثیق اور قابل سراغ ہونا چاہیے۔
• فعلی، غیر فعلی اور پابندی کے تقاضے، اور کاروباری، صارف اور نظام کی سطحیں الگ کریں۔
• حقیقی اسٹیک ہولڈرز سے جانیں، تجزیہ اور ترجیح کریں، موزوں رسمی پن پر بیان کریں، تعمیر سے پہلے توثیق کریں، اور تبدیلی سنبھالیں۔
• ضرورت سے قبولیت کے شواہد تک دو طرفہ سراغ پذیری جوابدہی کی ریڑھ کی ہڈی ہے، خاص طور پر ضابطے کے پابند ماحول میں۔
• ایجائل اور منصوبہ بند سیاق ایک ہی سرگرمیاں بانٹتے ہیں؛ وہ وقت، رسمی پن اور دستاویزات میں مختلف ہیں، اس لیے خطرے سے چنیں۔
• ناقص تقاضوں کی لاگت دیر سے ادا ہوتی ہے اور کئی گنا ہو جاتی ہے؛ آگے سرمایہ کاری دوبارہ کام اور ناکام قبولیت کے خلاف لیوریج ہے۔

حوالہ جات اور مزید مطالعہ

• IEEE and ISO/IEC, Guide to the Software Engineering Body of Knowledge (SWEBOK), Software Requirements knowledge area
• Karl Wiegers and Joy Beatty, Software Requirements
• ISO/IEC/IEEE 29148, Systems and software engineering: Life cycle processes: Requirements engineering
• Suzanne Robertson and James Robertson, Mastering the Requirements Process
• Dean Leffingwell, Agile Software Requirements
• Mike Cohn, User Stories Applied
• Ian Sommerville, Software Engineering (requirements engineering chapters)