فائدہ:
- فنکشنل اور غیر فنکشنل ضروریات میں فرق کرنے اور مصنوعی ذہانت کی مدد سے واضح، قابل پیمائش تقاضوں کے تاثرات لکھنے کی صلاحیت
- انٹرویو کے نوٹس سے صارف کی کہانی، قبولیت کے معیار اور دائرہ کار کی حد کو نکالنے کے لیے ساختی اشارے کے ساتھ مصنوعی ذہانت کا استعمال کرنے کی صلاحیت
- ابہام، تضاد، اور گمشدہ قواعد کے لیے AI سے تیار کردہ تقاضوں کو چیک کرنے اور اسٹیک ہولڈرز سے ان کی تصدیق کرنے کی عادت ڈالنا
تقاضوں کا تجزیہ ایک مکمل، واضح اور قابل تصدیق طریقے سے وضاحت کرنے کا کام ہے کہ ایک نظام کو کیا کرنا چاہیے۔ یہ ان مراحل میں سے ایک ہے جہاں MIS ماہر سب سے زیادہ قیمت پیدا کرتا ہے۔ کیونکہ یہاں ایک غلطی پروجیکٹ کے اختتام پر تیزی سے بڑھتی ہے۔ ضروریات کے تجزیہ کی دو بنیادی اقسام ہیں۔ فنکشنل ضرورت اس کام کی وضاحت کرتی ہے جو سسٹم کو کرنا چاہیے: "سسٹم کو کسٹمر کو ای میل کرنا چاہیے جب وہ آرڈر کی تصدیق کرے۔" غیر فعال ضرورت کی وضاحت کرتی ہے کہ نظام کیسا ہونا چاہئے: خصوصیات جیسے کارکردگی، سیکورٹی، استعمال اور رسائی۔ "رپورٹ اسکرین اوسط لوڈ پر 2 سیکنڈ سے بھی کم وقت میں کھلنا چاہئے" ایک غیر فعال ضرورت ہے۔
ایک اچھی ضرورت کی تین خصوصیات ہوتی ہیں: یہ واضح ہے (اس کی ایک ہی تشریح ہے)، یہ قابل پیمائش ہے (اس کی جانچ کے قابل حد ہے)، اور یہ سراغ لگانے کے قابل ہے (یہ واضح ہے کہ اسے کس کاروبار کی ضرورت ہے)۔ "نظام تیز ہونا چاہیے" ان میں سے کسی کو پورا نہیں کرتا۔ "تیز" ساپیکش ہے، ماپا نہیں جا سکتا، ٹیسٹ نہیں کیا جا سکتا. اس مرحلے پر، AI تقاضوں کو تیار کرنے اور مبہم الفاظ کو پکڑنے میں ایک طاقتور مدد ہے۔ لیکن صرف اسٹیک ہولڈر فیصلہ کرتا ہے کہ کون سا کاروباری اصول حقیقی ہے۔
صارف کی کہانی اور قبولیت کا معیار
جدید تقاضوں کی تحریر میں ایک عام شکل صارف کی کہانی ہے: "ایک [کردار] کے طور پر، [مقصد] کے لیے، میں چاہتا ہوں [فیچر]۔" مثال: "ایک سیلز نمائندے کے طور پر، میں موبائل اسکرین سے ڈسکاؤنٹ کا حساب چاہتا ہوں تاکہ میں فیلڈ میں فوری حوالہ جات بنا سکوں۔" کہانی مختصر اور کاروبار پر مبنی ہے۔ یہ تکنیکی حل کو مسلط نہیں کرتا ہے۔
ہر کہانی میں قبولیت کا معیار ہونا چاہیے: قابل آزمائش شرائط جو کہانی کو "ٹھیک" مانے جانے کے لیے پورا ہونا ضروری ہے۔ اکثر استعمال ہونے والا پیٹرن "دیئے گئے/جب/پھر" پیٹرن ہے: "دی گئی: صارف VIP طبقہ میں ہے۔ کب: 10,000 TL سے زیادہ آرڈر کرتا ہے۔ پھر: سسٹم 5% رعایت کا اطلاق کرتا ہے۔" یہ پیٹرن ابہام کو ختم کرتا ہے کیونکہ یہ واضح طور پر حالت اور متوقع نتائج کو جوڑتا ہے۔
مشورہ: مصنوعی ذہانت کے مطابق صارف کی کہانی لکھتے وقت، یہ کہنا یقینی بنائیں کہ "ہر کہانی کے لیے دیے گئے/جب/پھر فارمیٹ میں قبولیت کے کم از کم 2 معیار بنائیں۔" جب ماڈل کو بینچ مارکس بنانے پر مجبور کیا جاتا ہے، تو ضرورت میں چھپے ہوئے خلاء نظر آنے لگتے ہیں۔
مرحلہ وار: AI کی مدد سے ضروریات کو نکالنا
مرحلہ 1 - خام ان پٹ جمع کریں۔ کال لاگز، ای میلز، موجودہ اسکرین شاٹس، شکایت کی فہرستیں۔ زیادہ حقیقی ان پٹ، کم من گھڑت.
مرحلہ 2 — کہانیوں کا پہلا سیٹ نکالیں۔ مصنوعی ذہانت کو خام ان پٹ دیں اور اس سے صارف کی کہانی کے مسودے تیار کریں۔ یہ مرحلہ مکمل فہرست نہیں بلکہ پہلا قدم ہے۔
مرحلہ 3 - قبولیت کا معیار شامل کریں۔ ہر کہانی کے لیے دیا گیا/جب/پھر معیار بنائیں۔ ایک کہانی جس کے لیے معیار تیار نہیں کیا جا سکتا دراصل اس کا مطلب ہے کہ اس کی کافی وضاحت نہیں کی گئی ہے۔
مرحلہ 4 - تضادات اور خلاء کے لیے اسکیننگ۔ AI سے پوچھیں "کیا ان تقاضوں کے درمیان کوئی تضاد، نقل، یا غیر متعینہ حالات ہیں؟" پوچھیں اور اسے چیک کریں۔ ایک انسان کے طور پر نتیجہ فلٹر کریں.
مرحلہ 5 - ترجیح دیں اور تصدیق کریں۔ کاروباری قدر اور عجلت کی بنیاد پر اسٹیک ہولڈرز کے ساتھ کہانیوں کو ترجیح دیں۔ ترجیحی فیصلہ کاروباری یونٹ سے تعلق رکھتا ہے، AI کا نہیں۔
غیر فعال تقاضوں کو مت بھولنا
زیادہ تر پراجیکٹس کو فیلڈ میں مشکلات کا سامنا کرنا پڑتا ہے کیونکہ وہ فنکشنل تقاضوں کو لکھتے وقت نان فنکشنل کو بھول جاتے ہیں۔ ایک رپورٹ "درست طریقے سے" کام کر سکتی ہے، لیکن اگر اسے کھلنے میں 45 سیکنڈ لگتے ہیں، تو کوئی بھی اسے استعمال نہیں کرے گا۔ مندرجہ ذیل جدول عام طور پر نظر انداز کیے جانے والے غیر فعال تقاضوں کی اقسام اور قابل پیمائش تحریری مثالیں دکھاتا ہے۔
نوع
برا اظہار
قابل پیمائش اظہار
کارکردگی
"تیز ہونا ضروری ہے"
"سوال کا جواب <2 سیکنڈ اوسط بوجھ پر"
رسائی
"ہر ایک کو اسے استعمال کرنے کے قابل ہونا چاہئے"
"WCAG 2.1 AA کے مطابق؛ مکمل کی بورڈ نیویگیشن"
سیکورٹی
"یہ محفوظ ہونا چاہئے"
"ذاتی ڈیٹا کو آرام سے خفیہ کیا جاتا ہے؛ رسائی کردار پر مبنی ہے"
دستیابی
"آسان ہونا چاہئے"
"نیا صارف بغیر تربیت کے 3 مراحل میں آرڈر مکمل کرتا ہے"
دستیابی/تسلسل
"کریش نہیں ہونا چاہیے"
"ماہانہ اپ ٹائم ≥ 99.5%"
تین چھوٹے کیسز: نمبرز کے حساب سے
کیس 1 - ایک ناقابل پیمائش ضرورت کی قیمت۔ اسکرین، جو ایک بینک میں اس ضرورت کے ساتھ تیار کی گئی تھی کہ "رپورٹ اسکرین جلد کھل جائے"، فیلڈ لوڈ کے تحت 22 سیکنڈ میں کھل گئی۔ ڈویلپر نے سوچا کہ وہ اپنے ماحول (2 سیکنڈ) میں لفظ "تیز" فراہم کر رہا ہے۔ اگر ضرورت کو "<3 sec at peak hour, actual throughput" کے طور پر لکھا جاتا تو مسئلہ جانچ میں پکڑا جاتا۔ دوبارہ ترقی کی لاگت 3 ہفتوں اور قابل پیمائش اضافی لاگت۔
کیس 2 - قبولیت کے معیار کے ذریعے حاصل کردہ خلا۔ ای کامرس پروجیکٹ میں "سسٹم اپلائی ڈسکاؤنٹ" کہانی کے لیے قبولیت کے معیار کو لکھتے ہوئے، اسٹیک ہولڈر نے دیکھا کہ کیا ہوگا اگر ڈسکاؤنٹ کوپن اور VIP ڈسکاؤنٹ سے متصادم ہے تو اس پر بالکل بھی بات نہیں کی گئی۔ ایک واحد دیا گیا/جب/پھر سوال نے براہ راست جانے سے پہلے دوہری رعایت کی غلطی کو روکا؛ اس خرابی کی وجہ سے اسی طرح کے منصوبوں میں آمدنی کا شدید نقصان ہوا۔
کیس 3 - AI کا بنایا ہوا اصول۔ ایک HR پروجیکٹ میں، AI نے تقاضوں کے مسودے میں یہ جملہ شامل کیا کہ "چھٹی کی درخواست 24 گھنٹوں کے اندر خود بخود منظور ہو جاتی ہے"۔ اجلاس میں ایسی کوئی خودکار منظوری پر بات نہیں کی گئی۔ ماڈل نے ایک اصول بنایا تھا جو "معقول" لگتا تھا۔ ہر ضرورت کے آگے، ماہر لکھتا ہے "ذریعہ: کون سا انٹرویو/دستاویز؟" کالم جوڑ کر، اس نے 4 غیر منبع جملے ہٹا دیئے۔
کمزور پرامپٹ / مضبوط اشارہ
کمزور اشارہ:
اس پروجیکٹ کے لیے صارف کی کہانیاں لکھیں۔
طاقتور اشارہ:
آپ کا کردار: آپ ایک MIS کاروباری تجزیہ کار ہیں۔ ذیل میں انٹرویو کے نوٹ سے صارف کی کہانیاں نکالیں۔ قواعد:- فارمیٹ: "ایک [کردار] کے طور پر، [مقصد] کے لیے، میں [خصوصیت] چاہتا ہوں۔" - دیے گئے/جب/پھر فارمیٹ میں ہر کہانی کے لیے قبولیت کے کم از کم 2 معیار لکھیں۔ [غیر یقینی] کوئی بھی قاعدہ جو نوٹ میں واضح نہیں ہے۔ فٹنگ۔ ایک الگ سیکشن میں قابل پیمائش غیر فعال ضروریات (کارکردگی، سیکورٹی، رسائی) لکھیں۔ انٹرویو نوٹ:[متن]
طاقتور پرامپٹ کہانی کی شکل، قبولیت کے معیار، ماخذ کا پتہ لگانے اور غیر فعال ضروریات کو ایک ساتھ نافذ کرتا ہے۔ اس سے آؤٹ پٹ کو کنٹرول کرنا آسان ہو جاتا ہے۔
چار کاپی ایبل ٹیمپلیٹس
1) ضروریات کی وضاحت:
ذیل میں ضرورت کا جائزہ لیں۔ ہر ایک بیان کو نشان زد کریں جو مبہم، ناقابل تسخیر، یا ایک سے زیادہ تشریح کے لیے کھلا ہو اور ہر ایک کے لیے ایک واضح سوال لکھیں۔ جواب نہ بنائیں۔ ضرورت: [متن]
2) تضاد سکیننگ:
نیچے دیے گئے تقاضوں کی فہرست میں، وہ آئٹمز تلاش کریں جو ایک دوسرے سے متصادم ہوں، بار بار ہوں، یا منطقی خلا چھوڑ دیں۔ آئٹم نمبر اور ایک جملے کے جواز کے ساتھ ہر ایک تلاش کی اطلاع دیں۔ فہرست: [متن]
3) قبولیت کا معیار پیدا کرنا:
درج ذیل صارف کی کہانی کے لیے قبولیت کے کم از کم 4 معیارات کو دیے/جب/پھر فارمیٹ میں لکھیں، بشمول حد اور استثنائی صورتیں۔ ان نکات کی بھی فہرست بنائیں جو غیر واضح رہیں۔ کہانی: [متن]
4) دائرہ کار کا خاکہ:
درج ذیل تقاضوں کے مطابق "دائرہ کار میں" اور "دائرہ کار سے باہر" آئٹمز کو دو کالم ٹیبل کے طور پر تیار کریں۔ کسی بھی آئٹم پر لیبل [تصدیق درکار ہے] جس کے بارے میں آپ کو یقین نہیں ہے۔ تقاضے: [متن]
عام غلطیاں
- اس کا حل سوچنا ضرورت ہے۔ "ڈراپ ڈاؤن مینو شامل کریں" ایک حل ہے، ضرورت نہیں۔ ضرورت کہتی ہے کہ "صارف کو متعین فہرست سے ملک منتخب کرنے کے قابل ہونا چاہیے"؛ آئی ٹی ٹیم حل تیار کرتی ہے۔
- غیر فعال کو چھوڑنا۔ بس "کیا کرنا ہے" لکھنا اور "کیسے ہونا ہے" کو بھول جانا (رفتار، سیکورٹی، رسائی) سب سے عام اور سب سے مہنگی خامی ہے۔
- لامحدود صفتوں کا استعمال۔ "تیز، آسان، محفوظ، صارف دوست" جیسے الفاظ بغیر کسی حد کے غلط ہیں۔
- AI نے جو قاعدہ بنایا ہے اس پر توجہ نہ دینا۔ ماڈل میں "معقول" کا اضافہ ہو سکتا ہے لیکن اصل میں بولے جانے والے اصول نہیں۔ ہر ضرورت کے لیے وسائل طلب کریں۔
- ترجیحات کو AI پر چھوڑنا۔ سب سے پہلے کیا کرنا ہے ایک کاروباری قدر کا فیصلہ؛ کاروباری یونٹ یہ دیتا ہے۔
احتیاط: تقاضوں کے تجزیے میں سب سے خطرناک جملہ "ہر کوئی پہلے سے ہی جانتا ہے"۔ بے ساختہ مفروضے اسے دستاویزات میں نہیں بناتے، اسے کبھی بھی کوڈ میں نہیں بناتے، اور میدان میں ابھرتے ہیں۔ AI سے پوچھیں "اس ضرورت میں کیا فرض کیا گیا ہے لیکن نہیں لکھا گیا؟" ان پوشیدہ مفروضوں کو ظاہر کرتا ہے۔
خلاصہ میں
تقاضوں کا تجزیہ اس بات کی وضاحت کرتا ہے کہ سسٹم کو واضح، قابل پیمائش اور قابل شناخت طریقے سے کیا کرنا چاہیے۔ فنکشنل تقاضے کام کی وضاحت کرتے ہیں، غیر فعال تقاضے خوبیوں کو بیان کرتے ہیں، اور مؤخر الذکر اکثر بھول جاتے ہیں۔ صارف کی کہانی اور دیا گیا/جب/پھر قبولیت کا معیار طاقتور ٹولز ہیں جو غیر یقینی صورتحال کو ختم کرتے ہیں۔ مصنوعی ذہانت نمایاں طور پر سٹوری بورڈز کی تیاری، قبولیت کے معیار، تنازعات کا پتہ لگانے اور سوالات کو واضح کرنے میں تیزی لاتی ہے۔ تاہم کاروباری اصول کی درستگی، دائرہ کار اور ترجیحی فیصلہ اور ہر جملے کا ماخذ انسان کی ذمہ داری ہے۔ کسی بھی ضرورت کو حتمی شکل نہ دیں جو غیر منبع اور بے حد ہے۔
درخواست کا کام
ایک خیالی "آن لائن اپائنٹمنٹ سسٹم" کے لیے ایک پیراگراف کی کاروباری درخواست لکھیں (مثلاً، "کلائنٹس کو آن لائن اپائنٹمنٹ لینے کے قابل ہونا چاہیے، عملے کو کیلنڈر دیکھنے کے قابل ہونا چاہیے")۔ (1) کم از کم 5 صارف کی کہانیاں اور ہر ایک کے لیے قبولیت کے 2 معیار بنائیں اس درخواست کے مضبوط اشارے کے ساتھ۔ (2) ماڈل کے ذریعہ تیار کردہ معیار میں کم از کم 2 پوشیدہ خلا تلاش کریں (جیسے ایک ہی وقت میں دوہری ملاقات، منسوخی کا اصول)۔ (3) کم از کم 3 غیر فعال ضروریات کو قابل پیمائش شکل میں شامل کریں۔ (4) کم از کم 3 اشیاء کو "دائرہ کار سے باہر" کے طور پر شناخت کریں۔ (5) ایک اصول کو نشان زد کریں جسے ماڈل نے بنایا ہو اور لکھیں کہ آپ اس کی تصدیق کیسے کریں گے۔
چیک لسٹ
- میں نے فنکشنل اور غیر فنکشنل تقاضے الگ الگ لکھے۔
- ہر ضرورت واضح، قابل پیمائش اور قابل آزمائش ہے۔
- ہر کہانی میں دیا گیا/جب/پھر قبولیت کا معیار ہے۔
- میں ہر ضرورت کے ماخذ (گفتگو/دستاویز) کا سراغ لگا سکتا ہوں۔
- میں نے ممکنہ قواعد کو نشان زد کیا جو AI نے بنائے تھے اور انہیں تصدیق کے لیے چھوڑ دیا۔
- میں نے بزنس یونٹ کے ساتھ مل کر ترجیحات کیں۔