--- title: "Systems analysis in IT — آئی ٹی میں سسٹم تجزیہ" source: "https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81" wiki: "systems-analysis.info/int" article: "Systems_analysis_in_IT_—_آئی_ٹی_میں_سسٹم_تجزیہ" language: "ur" categories: - "Category:Systems analysis" - "Category:Urdu" revision_id: 7619 wiki_created_at: 2026-09-07T01:04:31Z wiki_modified_at: 2026-09-07T01:04:31Z downloaded_at: 2026-09-07T23:19:52Z --- # Systems analysis in IT — آئی ٹی میں سسٹم تجزیہ **آئی ٹی میں سسٹم تجزیہ** (*Systems Analysis and Design*) — معلوماتی نظاموں کی منصوبہ بندی اور ترقی کا وہ طریقہ کار ہے جو تصور سے لے کر استعمال تک کے تمام مراحل کا احاطہ کرتا ہے، جس میں ضروریات کی شناخت، تقاضوں کی رسمی تشکیل، موضوعاتی شعبے اور عمل کی نمونہ سازی، نیز متبادل حل اور خطرات کا جائزہ شامل ہے۔ دوسرے الفاظ میں، آئی ٹی میں سسٹم تجزیہ ترقی کا وہ مرحلہ ہے جس میں ماہرین مسئلے کا مطالعہ کرتے ہیں، یہ طے کرتے ہیں کہ نظام کو کیا کرنا چاہیے، اور اس کی تخلیق کے لیے حل تیار کرتے ہیں۔ **کلاسیکی سسٹم تجزیہ** اطلاق کے وسیع شعبوں کا احاطہ کرتا ہے*,* نہ صرف سافٹ ویئر کی ترقی بلکہ تنظیمی تبدیلیاں، حکمت عملیاں اور دیگر پہلو بھی۔[1] [2] ## آئی ٹی میں سسٹم تجزیہ کا موضوع اور مقاصد **آئی ٹی میں سسٹم تجزیہ کا موضوع** معلوماتی نظام (سافٹ ویئر پروڈکٹ اور/یا سروس) ہے جو اپنے پورے دورِ حیات میں — تصور اور جواز سازی سے لے کر تکمیل اور استعمال تک — زیرِ نظر رہتا ہے۔ **سسٹم تجزیہ کا مقصد** — کاروباری ضروریات کو تقاضوں اور تعمیراتی فیصلوں کے ایک مربوط اور قابلِ تصدیق مجموعے میں بدلنا ہے: اسٹیک ہولڈرز کے اہداف اور پابندیوں کی شناخت اور دستاویز سازی، تقاضوں کی رسمی تشکیل، موضوعاتی شعبے اور عمل کی نمونہ سازی، متبادل حل کی عملیت اور خطرات کا جائزہ، اور منتخب تعمیر کا جواز پیش کرنا۔ نتیجے میں مربوط دستاویزات تیار ہوتی ہیں اور تقاضوں، منصوبہ بندی کے فیصلوں اور ٹیسٹوں کے درمیان قابلِ ردِّتفحص روابط قائم ہوتے ہیں۔ اس سے ترقیاتی عمل قابلِ انتظام اور زیرِ کنٹرول رہتا ہے۔ سسٹم تجزیہ کے مقاصد میں شامل ہیں: - **اسٹیک ہولڈرز کی ضروریات اور اہداف کی شناخت**۔ تجزیہ کار خریداروں، صارفین اور دیگر فریقینِ مفاد کی توقعات جمع کرتا اور واضح کرتا ہے؛ انٹرویو، سروے، مشاہدے اور موجودہ عمل کے تجزیے کا استعمال کیا جاتا ہے۔ نتیجے میں **تقاضوں کی ابتدائی تفصیلات** تیار ہوتی ہیں جو فعالی («نظام کو کیا کرنا چاہیے») اور غیر فعالی (قابلِ اعتماد، کارکردگی، سیکیورٹی وغیرہ) تقاضوں میں تقسیم ہوتی ہیں۔^{[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-SWEBOK-1)[\[2\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-Zowghi-2)} - **تقاضوں کی رسمی تشکیل اور دستاویز سازی**۔ درخواستوں کو قابلِ تصدیق تقاضوں میں بدلا جاتا ہے۔ ایک اچھی طرح مرتب تقاضہ واضح اور غیر مبہم، مکمل، غیر متضاد، قابلِ تصدیق اور اعلیٰ سطحی اہداف سے قابلِ ردِّتفحص ہونا چاہیے؛ تقاضوں کا مجموعہ — مربوط اور یکجا۔^{[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-ISO29148-3)[\[4\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-NASA7123-4)} عملی طور پر معیاری دستاویزات استعمال ہوتی ہیں: ISO/IEC/IEEE 29148 کے مطابق SRS (*Software Requirements Specification*)، نیز بعض شعبوں میں URS (*User Requirements Specification*) اور فعالی تفصیلات۔^{[\[5\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-5)[\[6\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-6)[\[7\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-7)} - **نظام کا تجزیہ اور نمونہ سازی**۔ یہ سمجھنے کے لیے کہ نظام *کیسے* کام کرے گا اور بیرونی دنیا سے کیسے تعامل کرے گا، ماڈل تیار کیے جاتے ہیں: استعمال کے منظرناموں کے لیے Use Case ڈایاگرام، ڈیٹا اور کاروباری عمل کے بہاؤ کے لیے DFD، کلاس/کمپوننٹ ڈایاگرام وغیرہ۔ ماڈل متبادل حل اور تعمیروں کے موازنے کی بنیاد بنتے ہیں۔^{[\[8\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-8)[\[9\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-9)[\[10\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-ISO42010-10)} - **عملیت کا جائزہ اور حل کا انتخاب**۔ *Feasibility study* (تکنیکی، تنظیمی، اقتصادی، وقتی عملیت) اور تعمیراتی متبادل کا موازنہ (*trade-off*) کیا جاتا ہے۔ معیارات (مثلاً، کارکردگی، توسیع پذیری، قابلِ ترمیم) کے مطابق تعمیر کے معیار کی جانچ کے لیے ATAM (*Architecture Tradeoff Analysis Method*) جیسے طریقے استعمال کیے جاتے ہیں۔^{[\[11\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-11)[\[12\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-ATAM-12)} مثلاً، یک پارچہ اور مائیکروسروس تعمیر کے درمیان انتخاب [3] صنعتی رہنمائی کی سفارشات کے مطابق واضح سمجھوتوں (آپریشنل پیچیدگی بمقابلہ آزاد توسیع اور ترسیل کی رفتار) پر مبنی ہوتا ہے۔^{[\[13\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-13)[\[14\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-14)} - **منصوبہ بندی کے آثار کی تیاری**۔ تجزیے کے نتیجے میں بنتے ہیں: - منظور شدہ تقاضوں کی تفصیلات (ان کی اہمیت کے ساتھ)، - نظام کا تصوراتی ماڈل (ڈایاگرام/تفصیلات)، - تعمیراتی اور منصوبہ بندی کے فیصلے (ڈیٹا اسکیما، بیرونی نظاموں کے انٹرفیس)، - تکمیلی منصوبہ (مراحل/ماڈیول)۔ - تقاضوں کی ڈیزائن عناصر اور ٹیسٹوں تک *قابلِ ردِّتفحص* (bidirectional traceability) یقینی بنانا انتہائی اہم ہے۔^{[\[15\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-15)[\[4\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-NASA7123-4)} آئی ٹی منصوبے کی کامیابی کا انحصار بڑی حد تک تقاضوں اور تعمیر کے ساتھ کام کرنے کے پختہ طریقوں پر ہے۔ McKinsey اور Oxford کی ایک تحقیق نے ظاہر کیا کہ بڑے آئی ٹی منصوبے اکثر بجٹ اور وقت کی حدود سے تجاوز کر جاتے ہیں۔ اس تحقیق نے یہ بھی اجاگر کیا کہ حکمتِ عملی کا صحیح انتظام، فریقینِ مفاد کے ساتھ تعامل اور تقاضوں کا درست اخذ کتنا اہم ہے۔ یہ سب منصوبے کی کامیابی یا ناکامی پر گہرا اثر ڈال سکتے ہیں۔^{[\[16\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-16)} ## آئی ٹی سسٹم تجزیہ میں طریقے اور روش **آئی ٹی میں سسٹم تجزیہ** نظامی سوچ کے اصولوں اور سافٹ ویئر ترقی کے لیے اپنائی گئی تکنیکوں پر مبنی ہے۔ عملی طور پر «سخت» اور «نرم» طریقے، ساختی روش، اعتراض پر مبنی اشارات، نیز عمل اور تقاضوں کی نمونہ سازی کی زبانیں باہم ملا کر استعمال کی جاتی ہیں۔ - **سخت اور نرم طریقے**۔ آئی ٹی منصوبوں میں سخت طریقہ (hard systems) پیشگی رسمی طور پر قابلِ تعریف اہداف اور تقاضوں، ٹوٹ پھوٹ اور «اوپر سے نیچے» منصوبہ بندی پر منحصر ہے۔ نرم طریقہ (soft systems) غیر واضح اہداف اور متعدد نقطہ ہائے نظر کی صورت میں استعمال ہوتا ہے: مسئلے کی سمجھ اور مطلوبہ تبدیلیوں کے اتفاق کے لیے Soft Systems Methodology (SSM) کے عناصر (مثلاً *rich picture*، بنیادی تعریفیں، CATWOE) استعمال کیے جاتے ہیں؛ پھر نتائج کو رسمی تقاضوں میں بدلا جاتا ہے۔^{[\[17\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-17)[\[18\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-18)} - **SSM (Soft Systems Methodology) روش**۔ اصلاً *پیٹر چیک لینڈ* نے تنظیمی تبدیلیوں کے لیے تیار کی گئی، SSM آئی ٹی کے پیش منصوبہ بندی مراحل میں مفید ہے: مشکلاتی صورتحال کی تحقیق اور بنیادی تعریفوں کی تشکیل (بشمول CATWOE کے ذریعے) سے لے کر تصوراتی ماڈل کا حقیقت سے موازنہ اور اسٹیک ہولڈرز کے درمیان اتفاق تک۔^{[\[19\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-19)[\[20\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-20)} - **منظم روشیں: SADT/IDEF0**۔ SADT نظام کو افعال کے درجاتی ڈھانچے کے طور پر ماڈل کرتی ہے؛ معیاری IDEF0 اشارہ (IEEE 1320.1) افعال اور ان کے I-C-O-M انٹرفیس (Inputs, Controls, Outputs, Mechanisms) کو محفوظ کرتا ہے۔ یہ طریقہ الگورتھم سے قطع نظر فعالی تجزیہ اور نظام کی حدود کے تعین کے لیے موزوں ہے۔^{[\[21\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-21)[\[22\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-22)} - **اعتراض پر مبنی تجزیہ:** UML اور SysML (MBSE)۔ UML تقاضوں اور ڈیزائن کے لیے بنیادی زبان بن گئی ہے (Use Case، کلاس، ترتیب اور دیگر ڈایاگرام) اور صارفین کے ساتھ منظرناموں کی توثیق میں مدد کرتی ہے؛ SysML نظامی انجینئرنگ کے لیے UML کو وسعت دیتی ہے (تقاضوں کے ڈایاگرام، پیرامیٹرک ڈایاگرام) اور MBSE طریقے پر مبنی ہے، جہاں ماڈل تقاضوں سے ٹیسٹ تک تمام مراحل میں مرکزی آثر ہوتا ہے۔^{[\[23\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-23)[\[24\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-24)[\[25\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-25)} - **کاروباری عمل کی نمونہ سازی:** BPMN۔ BPMN معیار کو عمل کی گرافیکی تفصیل (پول، کام کا بہاؤ، واقعات، گیٹ وے) کے لیے استعمال کیا جاتا ہے، جس میں تقاضوں اور انضمام کی تفصیلات میں *as-is/to-be* کا موازنہ شامل ہے۔^{[\[26\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-26)[\[27\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-27)} - **تقاضوں کی انجینئرنگ سے تعلق**۔ اس عمل میں elicitation–analysis–specification–validation–change management کے مراحل شامل ہیں؛ «اچھے تقاضے» کے معیار اور SRS کی ساخت ISO/IEC/IEEE 29148 میں مقرر ہے۔ ترجیح بندی کے لیے **MoSCoW** (Must/Should/Could/Won't) تکنیک اور کثیر المعیار انتخاب کے طریقے جیسے AHP استعمال ہوتے ہیں۔ لچکدار عمل میں سسٹم تجزیہ کی سرگرمی backlog refinement اور تقاضوں کی قابلِ ردِّتفحص میں ظاہر ہوتی ہے۔^{[\[28\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-28)[\[29\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-29)[\[30\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-30)[\[31\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-31)} - **نظامی انجینئرنگ سے تعلق**۔ پیچیدہ (سائبر فزیکل) نظاموں کے لیے V-ماڈل استعمال کیا جاتا ہے: «بائیں» شاخ پر — سسٹم تجزیہ اور تعمیر، «دائیں» پر — انضمام، تصدیق اور توثیق بائیں شاخ کے آثار سے وابستگی کے ساتھ۔ معیاری صفات کے مطابق تعمیر کی جانچ کے طریقوں میں ATAM (trade-off تجزیہ) شامل ہے۔^{[\[32\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-32)[\[33\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-33)} آئی ٹی میں سسٹم تجزیہ آزمودہ طریقوں کو یکجا کرتا ہے — وژن کے اتفاق کی نرم تکنیکوں سے لے کر رسمی اشارات اور معیارات تک۔ اوزاروں کا انتخاب مسئلے کی یقینیت کی سطح سے طے ہوتا ہے: زیادہ غیر یقینی صورت میں SSM اور فسیلیٹیشن کا کردار بڑھتا ہے، واضح حدود میں — رسمی ماڈل (UML/SysML, IDEF0, BPMN) اور ضوابط۔ ## آئی ٹی آرکیٹیکچر اور انٹرپرائز آرکیٹیکچر سے تعلق آئی ٹی منصوبوں میں سسٹم تجزیہ تعمیراتی منصوبہ بندی سے گہرا تعلق رکھتا ہے۔ تجزیہ کار اور آرکیٹیکٹ کے کردار ایک دوسرے سے ملتے ہیں: تجزیہ کار تقاضوں اور منطقی ماڈل کو مرتب کرتا ہے، آرکیٹیکٹ حل کا ہدف ڈھانچہ اور تکنیکی سمجھوتوں کا تعین کرتا ہے؛ کام مشترکاً ہوتا ہے۔ - **آئی ٹی نظاموں کی تعمیر**۔ محدود معنوں میں سافٹ ویئر آرکیٹیکچر اجزاء کی تنظیم، ان کے تعلقات اور وہ اصول ہیں جن کی رہنمائی میں حل تیار کیا جاتا ہے۔ تجزیہ کار کے لیے تعمیراتی انداز (تہہ در تہہ، کلائنٹ-سرور، مائیکروسروس، واقعہ پر مبنی وغیرہ) کو مدِّنظر رکھنا ضروری ہے، کیونکہ غیر فعالی تقاضے (قابلِ اعتماد، توسیع پذیری، قابلِ ترمیم) اکثر تعمیراتی فیصلے اور سمجھوتے طے کرتے ہیں۔^{[\[34\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-AzureStyles-34)[\[35\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-SEI_ATAM-35)} تجزیے کے ابتدائی مرحلے میں **تعمیراتی وژن** (high-level vision) بنایا جاتا ہے اور تقاضوں کی عملیت کی جانچ کے لیے حل کا خاکہ تیار کیا جاتا ہے (تفصیلات کی سطح روش پر منحصر ہے)۔^{[\[36\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-TOGAFIntro-36)} - **نمونے اور ابتدائی حل**۔ غیر فعالی تقاضوں کو پورا کرنے کے لیے تعمیراتی نمونے (architectural patterns) استعمال کیے جاتے ہیں۔ مثلاً، غیر ہم وقتی تعامل اور کمزور وابستگی کے لیے — واقعہ پر مبنی تعمیر میں پیغام بروکر کے ذریعے publish–subscribe۔^{[\[37\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-AzureEvent-37)} - **TOGAF (The Open Group Architecture Framework)**۔ انٹرپرائز آرکیٹیکچر کے سب سے زیادہ مستعمل فریم ورکس میں سے ایک؛ اس میں ADM (Architecture Development Method) اور تعمیر کے انتظام کے آثار (ذخیرہ، فہرستیں/میٹرکس، اصول) شامل ہیں۔ TOGAF میں تقاضوں کا انتظام ایک مسلسل عمل ہے جو ADM کے تمام مراحل میں ضم ہے۔^{[\[36\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-TOGAFIntro-36)} تقاضوں اور قابلِ ردِّتفحص کی حمایت کے لیے فہرستیں اور میٹرکس استعمال ہوتے ہیں (مثلاً، تقاضے ↔ سروسز، افعال ↔ اجزاء)، اور ***Architecture Building Blocks*** اور ***Solution Building Blocks*** میں فرق کیا جاتا ہے۔^{[\[38\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-38)[\[39\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-39)} انٹرپرائز کے اصول اور معیار متعلقہ فہرستوں میں محفوظ ہوتے ہیں اور منصوبہ بندی ٹیموں کے لیے بیرونی غیر فعالی **تقاضوں** کا کردار ادا کرتے ہیں۔^{[\[40\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-40)} ہدف تعمیر کے ساتھ حل کی مطابقت کی تصدیق آرکیٹیکچر کمپلائنس جائزے (Architecture Compliance Review) کے ذریعے کی جاتی ہے۔^{[\[41\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-41)} TOGAF طریقے میں ابتدائی **Architecture Vision** اور بعد میں تفصیلات (ڈیٹا/ایپلیکیشنز/ٹیکنالوجیز) کو ہجرت کے منصوبے اور تقاضوں کی تبدیلیوں کے انتظام کے ساتھ شامل کیا جاتا ہے۔^{[\[42\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-42)[\[43\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-43)} - **Zachman Framework**۔ انٹرپرائز آرکیٹیکچر کے آثار کی ایک قدیم اور بااثر آنٹالوجی، جو 6×6 میٹرکس (نقطہ ہائے نظر × «کیا/کیسے/کہاں/کون/کب/کیوں» پہلو) کی صورت میں پیش کی گئی ہے۔ «ڈیزائنر» کی قطار سسٹم تجزیہ اور منصوبہ بندی سے مطابقت رکھتی ہے؛ کالم ڈیٹا، افعال/عمل، کرداروں، مقام اور محرکات کا مکمل جائزہ یقینی بناتے ہیں۔ فریم ورک ایک درجہ بندی (روش نہیں) کے طور پر کام کرتا ہے اور انٹرپرائز کے ماحول میں حل کی تفصیل کی تکمیل کو یقینی بنانے میں مدد کرتا ہے۔^{[\[44\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-Zachman1987-44)} - **انٹرپرائز آرکیٹیکچر (Enterprise Architecture, EA) سے تعلق**۔ سسٹم تجزیہ کار EA کے تناظر میں کام کرتا ہے: نئے تقاضے کاروباری صلاحیتوں اور آپریشنل ماڈل سے منسلک ہوتے ہیں؛ انٹرپرائز کے معیار اور بنیادی پابندیاں (سیکیورٹی، مطابقت وغیرہ) لاگو ہوتی ہیں۔^{[\[45\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-45)[\[36\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-TOGAFIntro-36)} آغاز کے مرحلے میں ***Architecture Vision*** (اہداف/پابندیاں، کلی تقاضے) تشکیل دیا جاتا ہے، پھر تجزیہ کار وژن اور کارپوریٹ معیارات تک قابلِ ردِّتفحص برقرار رکھتے ہوئے تفصیلات دیتا ہے؛ معیارات کی خلاف ورزی تعمیراتی جائزوں میں سامنے آتی ہے اور حل کی نظرثانی ضروری ہو سکتی ہے۔^{[\[36\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-TOGAFIntro-36)[\[46\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-46)} خلاصہ: سسٹم تجزیہ اور تعمیراتی منصوبہ بندی «تقاضے → تعمیراتی فیصلے → معیاری صفات پر سمجھوتے» کی کڑی تشکیل دیتے ہیں۔ طریقوں (انداز/نمونے، TOGAF کے آثار، Zachman درجہ بندی) کا انتخاب منصوبے کی نوعیت اور کارپوریٹ آرکیٹیکچر کے ڈھانچے سے طے ہوتا ہے۔ ## عمل اور طریقے سسٹم تجزیہ سافٹ ویئر کی ترقی اور استعمال کے پورے دورِ حیات میں شامل ہوتا ہے، کاروباری اہداف، تعمیر اور فراہمی کو جوڑتا ہے۔ اس میں پیش منصوبہ بندی تحقیق، طریقے کا انتخاب، قابلِ تصدیق آثار کی تشکیل اور قابلِ اعتماد، کارکردگی، سیکیورٹی اور دیکھ بھال کے تقاضے شامل ہیں۔ کسکیڈ ماڈل میں تجزیہ منصوبہ بندی اور تکمیل سے پہلے کیا جاتا ہے، لچکدار طریقوں میں — تکرار کے ذریعے مستقل طور پر، اور DevOps میں — آپریشنل اہداف پر توجہ کے ساتھ۔ طریقے سے قطع نظر، تجزیہ قابلِ ردِّتفحص، تبدیلیوں اور خطرات کا انتظام، تعمیراتی سمجھوتوں کی دستاویز سازی اور ضابطہ جاتی پابندیوں کی پاسداری یقینی بناتا ہے، جس سے ترقی متوقع اور قابلِ انتظام بنتی ہے۔ - **کلاسیکی SDLC (Waterfall)**۔ System Analysis & Requirements Definition کا مرحلہ منصوبہ بندی اور تکمیل سے پہلے آتا ہے؛ تقاضے تفصیلی **SRS** میں بطور منصوبہ بندی اور معاہدوں کی بنیاد محفوظ ہوتے ہیں۔ مستحکم اور منظم شعبوں میں کارگر؛ تقاضوں کی «منجمدیت» کے خطرات SRR/جائزوں اور **CCB** کے ذریعے تبدیلیوں کے انتظام سے کم ہوتے ہیں۔^{[\[47\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-Royce-47)[\[48\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-DAU_SRR-48)[\[49\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-NASA_CCB-49)} - **لچکدار روشیں (Agile)**۔ تجزیہ مستقل ہے: حتمی SRS کی بجائے قبولیت کے معیار کے ساتھ user stories پر مشتمل پروڈکٹ بیک لاگ رکھا جاتا ہے، جسے backlog refinement میں بہتر کیا جاتا ہے؛ **BDD** (Given–When–Then) استعمال ہوتی ہے؛ مجموعی تعمیر کے ضیاع کا خطرہ ابتدائی تعمیراتی کام اور تقاضوں ↔ تکمیل/ٹیسٹ کی شفاف قابلِ ردِّتفحص سے پورا کیا جاتا ہے۔^{[\[50\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-MS_Agile-50)[\[51\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-MS_BDD-51)[\[52\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-MS_Trace-52)} - **DevOps اور SRE**۔ کثیر ریلیز کے لیے «بطور ڈیفالٹ» آپریشنل تقاضے درکار ہیں: آٹومیشن، مشاہدہ پذیری، واپسی۔ غیر فعالی تقاضے SLO/SLI کے طور پر مرتب کیے جاتے ہیں، error budget کا انتظام ہوتا ہے؛ بیک لاگ میں لاگ/میٹرکس/ٹریس/الرٹ کے کام شامل کیے جاتے ہیں؛ بغیر خلل ریلیز کے لیے — **blue/green** اور دیگر نمونے۔^{[\[53\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-SRE_SLO-53)[\[54\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-AzureMon-54)[\[55\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-AWS_BlueGreen-55)} - **تقاضوں اور خطرات کا انتظام**۔ ALM میں تقاضوں کے حالت اور کاموں/ریلیزز/خرابیوں سے روابط ہوتے ہیں؛ version control، تبدیلی کے اثر کا تجزیہ اور باقاعدہ دوبارہ ترجیح بندی لازمی ہے۔^{[\[56\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-Azure_Workflow-56)[\[57\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-Azure_Backlog-57)} - **معیار کی یقین دہانی (QA)**۔ معیار تقاضوں کے مرحلے پر رکھا جاتا ہے: جائزے، «Three Amigos»، *Acceptance Test Plan* کا خاکہ، قبولیت کے معیار کے خودکار ٹیسٹ (BDD/ATDD)۔^{[\[58\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-MS_Test-58)[\[59\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-MS_SpecFlow-59)} - **مشاہدہ پذیری اور قابلِ اعتماد**۔ تقاضوں میں قابلِ پیمائش اہداف اور کنٹرول طریقوں کے ساتھ SLA/SLO، MTTR اور MTBF شامل ہوتے ہیں؛ پیرامیٹر کاروبار/آپریشن کی طرف سے آتے ہیں اور تعمیر اور قابلِ اعتماد ٹیسٹ میں شامل کیے جاتے ہیں۔^{[\[60\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-IBM_MTTR-60)[\[61\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-GCloud_Obs-61)} ## میٹرکس اور آثار کا معیار سسٹم تجزیہ کار کے کام اور اس کے نتائج کے معیار کی جانچ کے لیے عام طور پر قبول شدہ معیار استعمال ہوتے ہیں۔ **معیاری تقاضے اور ماڈل** کامیاب منصوبے کی بنیاد ہیں، اس لیے انہیں پورے دورِ حیات (elicitation → specification → verification/validation → change management) میں منظم کیا جاتا ہے۔ تقاضوں کے معیار کی بنیادی صفات ISO/IEC/IEEE 29148 اور (تاریخی طور پر) IEEE 830 میں مقرر ہیں۔^{[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-ISO29148-3)[\[62\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-IEEE830-62)[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-SWEBOK-1)} - **درستگی (Correctness)** — تقاضہ اصل ضرورت کی عکاسی کرتا ہے اور موضوعاتی شعبے کے ماہرین سے مربوط ہے؛ توثیق (review/inspection، پروٹوٹائپ، منظرنامے) سے تصدیق ہوتی ہے۔^{[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-SWEBOK-1)[\[4\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-NASA7123-4)} - **تکمیل (Completeness)** — اہم پہلو اور شرائط کا احاطہ کیا گیا ہو۔ - *انفرادی تقاضے کی تکمیل*: ضروری تفصیلات فراہم ہوں (مثلاً، «خرابی پر اشارہ **سرخ حالت میں آتا ہے**»، نہ کہ محض «سرخ ہو جاتا ہے»)۔ - *تفصیلات کی تکمیل*: منظرنامے/کردار احاطہ شدہ ہوں، NFR مقرر ہوں؛ چیک لسٹوں اور کاروباری اہداف سے قابلِ ردِّتفحص سے حاصل ہو؛ تکمیل کا آزادانہ آڈٹ (QA/review) مفید ہے۔^{[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-NASA_SEH-63)} - **غیر ابہام (Unambiguity)** — عبارتیں صرف ایک طرح سمجھی جائیں؛ لغت، «نظام **کو A کرنا چاہیے جب B، اگر C**» جیسے سانچے، مثالیں؛ ڈایاگرام لیجنڈ کے ساتھ ہوں۔ جانچ — **«چار آنکھوں»** کا اصول۔^{[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-SWEBOK-1)} - **یکسانیت (Consistency)** — تقاضے ایک دوسرے اور بیرونی پابندیوں سے متضاد نہ ہوں؛ ساختی طریقہ، صفات کی خلاصہ جدولیں، ٹیم جائزے استعمال ہوتے ہیں؛ ضوابط/معیارات کی تصدیق کی جائے۔^{[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-NASA_SEH-63)} - **قابلِ تصدیق/قابلِ جانچ (Verifiability)** — حصول کی تصدیق ٹیسٹ/مظاہرے/تجزیے سے ہو؛ ناقابلِ تصدیق عبارتوں کو قابلِ پیمائش معیارات سے تبدیل کریں؛ NFR کے لیے میٹرکس مقرر کریں اور قبولیت کے معیار پہلے سے طے کریں۔^{[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-ISO29148-3)[\[63\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-NASA_SEH-63)} - **قابلِ ترمیم اور قابلِ ردِّتفحص (Modifiability & Traceability)** — منفرد ID، منطقی ساخت («ایک خیال — ایک پیراگراف»)، نقلوں کی غیر موجودگی؛ «تقاضہ ↔ ماخذ/ہدف/ڈیزائن/ٹیسٹ» روابط برقرار رکھے جائیں، **قابلِ ردِّتفحص میٹرکس (RTM)** رکھی جائے۔^{[\[64\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-NASA_RM-64)[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-ISO29148-3)} - **ترتیب بندی اور ترجیح بندی** — تقاضوں کے مجموعے کا معیار؛ **MoSCoW** اور MCDM (مثلاً **AHP**) تکنیک استعمال کریں؛ کاروبار کے ساتھ مشترکہ ترجیح بندی منصوبہ بندی اور خطرات پر اثر ڈالتی ہے۔^{[\[65\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-MoSCoW-65)[\[66\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-Saaty-66)} **تقاضوں کے معیار کی میٹرکس** (مثالیں):^{[\[63\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-NASA_SEH-63)[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-SWEBOK-1)} - تقاضوں کی خرابیوں کی کثافت (100 تقاضوں پر ملاحظات)؛ - بنیادی محفوظیت کے بعد تبدیلیوں کی تعداد؛ - coverage-میٹرکس: ٹیسٹ والے تقاضوں کا تناسب؛ کاروباری اہداف سے منسلک تقاضوں کا تناسب؛ - تقاضوں کا استحکام (مدت میں شامل/حذف کا کل سے تناسب)؛ - تفصیلات کا حجم/پیچیدگی (use case میں تقاضوں کی اوسط تعداد، تجزیے کی گہرائی)؛ - اسٹیک ہولڈرز کی اطمینان (سروے)۔ پختہ عمل میں (مثلاً **CMMI** سطح 3+) تقاضوں کے معیار کے ضوابط موجود ہیں: رسمی جانچیں، سانچوں کی مطابقت کے آڈٹ، میٹرکس کا اخذ/تجزیہ۔^{[\[67\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-SEI_CMMI-67)} اہم شعبوں میں (ہوا بازی، خلا وغیرہ) قابلِ اعتماد بڑھانے کے لیے **رسمی طریقے** استعمال کیے جاتے ہیں۔^{[\[68\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-NASA_FM-68)} ## عام غلطیاں آئی ٹی منصوبوں میں سسٹم تجزیہ کی غلطیاں اکثر ملتی ہیں: تقاضوں کی نامکمل اور غیر واضح تشکیل، تضادات، دھندلی حدیں، غیر فعالی پہلوؤں کو نظرانداز کرنا، چھوٹا ہوا انضمام اور دیر سے آنے والی سیکیورٹی۔ اس سے دوبارہ کام، تاخیر، اخراجات میں اضافہ اور خرابیاں جنم لیتی ہیں۔ عام مسائل، ان کے نتائج اور روک تھام کے طریقے۔ - **نامکمل اور چھوٹے ہوئے تقاضے**۔ خاص اختیارات والے کردار، حاشیہ معاملات اور NFR چھوٹ جاتے ہیں۔ *نتائج:* تعمیر کی نظرثانی اور آغاز کا التوا۔ بچاؤ کا طریقہ: چیک لسٹیں، «کیا ہو اگر…» دماغی طوفان، ٹیسٹرز کو جلد شامل کرنا، کاروباری اہداف سے قابلِ ردِّتفحص۔^{[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-SWEBOK-1)[\[69\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-SEI_Pitfalls-69)} - **غیر واضح، مبہم عبارتیں**۔ *نتائج:* ڈویلپر «غلط چیز» بناتے ہیں، خریدار غیر مطمئن۔ بچاؤ کا طریقہ: قابلِ پیمائش معیار، لغت، «A، جب B، اگر C» سانچے، peer‑review۔^{[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-ISO29148-3)[\[69\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-SEI_Pitfalls-69)} - **متضاد تقاضے**۔ *نتائج:* وضاحتوں میں تاخیر، انضمام پر نظرثانی۔ بچاؤ کا طریقہ: ساختی طریقہ، کاروباری قواعد/ضوابط کی تصدیق، تنازعات حل کرنے کی نشستیں، جائزوں پر یکسانیت کی جانچ۔^{[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-SWEBOK-1)} - **«سونے کی پلیٹ» کا سنڈروم (gold‑plating)**۔ *نتائج:* دائرے کی وسعت، پیچیدگی، خرابی کے نئے مقامات۔ بچاؤ کا طریقہ: ہر تقاضے کو ہدف/میٹرک سے جوڑنا؛ Agile میں — بیک لاگ میں اضافی نہ ڈالنا؛ scope محفوظ کرنا؛ YAGNI دیکھیں۔ - **جہاں ضرورت نہ ہو وہاں ضرورت سے زیادہ تفصیل**۔ بچاؤ کا طریقہ: *کیا/کیوں* (تقاضے) کو *کیسے* (ڈیزائن/تکمیل) سے الگ کریں؛ جہاں مناسب ہو *design‑free requirements* استعمال کریں۔^{[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-ISO29148-3)} - **تقاضوں کے انتظام میں خلل**۔ *نتائج:* ورژنوں میں الجھن، «غلط چیز» کی تکمیل۔ بچاؤ کا طریقہ: ALM میں واحد سچائی کا ماخذ، تاریخ اور حالت، RTM اور تبدیلی کے اثر کا تجزیہ؛ CCB کے ذریعے تبدیلیوں کا انتظام۔^{[\[64\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-NASA_RM-64)[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-SWEBOK-1)} - **صارفین کی شرکت کا فقدان**۔ بچاؤ کا طریقہ: انٹرویو، مشاہدہ، پروٹوٹائپ، باقاعدہ مظاہرے؛ اسٹیک ہولڈرز کے ساتھ واضح توثیق۔^{[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-SWEBOK-1)} - **بہت طویل «تجزیاتی فالج»**۔ بچاؤ کا طریقہ: کافی حد کا تعین، تکراریت اور timeboxing؛ MVP/اضافے کا آغاز اور رائے کی بنیاد پر اصلاح۔^{[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-SWEBOK-1)} - **غیر فعالی تقاضوں کو نظرانداز کرنا**۔ بچاؤ کا طریقہ: NFR کو الگ کریں (مثلاً FURPS+)، قابلِ پیمائش معیار مقرر کریں، انہیں ٹیسٹ منصوبے اور تعمیراتی فیصلوں میں شامل کریں۔^{[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-SWEBOK-1)[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-ISO29148-3)} - **رابطہ کاری کی غلطیاں اور «انسانی عنصر»**۔ حل: انٹرویو اور فسیلیٹیشن کی صلاحیت بڑھائیں، غیر جانبداری برقرار رکھیں، فیصلے اور تقاضوں کے ماخذ محفوظ کریں (اہداف سے قابلِ ردِّتفحص)۔^{[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-SWEBOK-1)} زیادہ تر مسائل عبارتوں کے معیار، تکمیل اور تقاضوں کی قابلِ انتظامیت پر مرکوز ہیں؛ ISO/IEC/IEEE 29148 کے معیارات اور SWEBOK کے طریقوں (قابلِ توثیق، قابلِ ردِّتفحص، تکراریت) کا اطلاق تاخیر اور نظرثانی کے خطرے کو نمایاں طور پر کم کرتا ہے۔^{[\[3\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-ISO29148-3)[\[1\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-SWEBOK-1)} ## حدود غیر یقینیت کو کم کرنے میں اپنی افادیت کے باوجود، سسٹم تجزیہ کی اپنی حدود ہیں: - **حقیقت متغیر اور پیچیدہ ہے۔** تمام عوامل کا احاطہ کرنا ناممکن ہے، خاص طور پر طویل المیعاد منصوبوں میں۔ کچھ تقاضے نظام کے آغاز کے بعد ہی سامنے آتے ہیں۔ غیر متوقع باتوں کو کم سے کم کرنے کی کوشش کرنا ضروری ہے، لیکن تبدیلیوں کے لیے تیار رہنا بھی ضروری ہے۔ - **تقاضے لوگوں پر منحصر ہیں۔** کاروباری ترجیحات، قوانین اور بازار بدل سکتے ہیں۔ سسٹم تجزیہ موجودہ حالت کو محفوظ کرتا ہے اور تمام بیرونی تبدیلیوں کا اندازہ نہیں لگا سکتا۔ موافقت کے لیے تقاضوں کو باقاعدگی سے اپ ڈیٹ کرنا اور تکراری طریقے سے کام کرنا ضروری ہے۔ - **صارفین ہمیشہ نہیں جانتے کہ وہ کیا چاہتے ہیں جب تک دیکھ نہ لیں۔** یہ ایک معروف حد ہے۔ پروٹوٹائپ بنانا اور لچکدار روشیں جیسے Agile اس مسئلے پر قابو پانے میں مدد کرتی ہیں۔ کاغذی تجزیے کی اپنی حدیں ہیں، اور درست ڈیٹا حاصل کرنے کے لیے تکمیل سے رائے ضروری ہے۔ - **وقت اور معیار کا توازن۔** ضرورت سے زیادہ تفصیلی تجزیہ پرانا پڑ سکتا ہے۔ اختراعی شعبوں میں کم سے کم قابلِ عمل پروڈکٹ (MVP) جلدی بنانا اور حقیقی ڈیٹا حاصل کرنا بہتر ہے۔ سسٹم تجزیہ مستحکم شعبوں میں کارگر ہے، لیکن تحقیقاتی منصوبوں (R&D) میں اس کا کردار محدود ہے۔ - **انسانی عنصر۔** بہترین روشیں بھی تجزیہ کار کی نااہلی یا خریدار کی عدم دستیابی کا ازالہ نہیں کر سکتیں۔ یہ ضروری ہے کہ عمل کے تمام شرکاء ملوث اور متحرک ہوں۔ ## آئی ٹی سسٹم تجزیہ پر جدید ٹیکنالوجیز کا اثر آئی ٹی میں سسٹم تجزیہ مسلسل تکنیکی اختراعات کے زیرِ اثر ارتقاء پذیر ہے۔ اکیسویں صدی کا تجزیہ کار ڈیٹا کی دھماکہ خیز ترقی، AI کے ہر جگہ نفاذ، تیز رفتار ترقیاتی سائیکل اور سیکیورٹی پر بڑھتی ہوئی توجہ کے ماحول میں کام کرتا ہے۔ کامیاب سسٹم تجزیہ کے عمل کے لیے نئے علوم (Data Science، سائبر سیکیورٹی، کلاؤڈ ٹیکنالوجیز) کی مہارت اور طریقوں کے اطلاق میں لچک ضروری ہے۔ - **ڈیٹا اور AI/ML: تجزیے میں کیا اضافہ ہوتا ہے**۔ AI والے نظاموں کے لیے شروع میں ہی اطلاق کے اہداف اور سیاق، ڈیٹا کے ذرائع اور معیار کے تقاضے، نیز ماڈل کے فیصلوں پر اعتماد کی میٹرکس (قابلِ اعتماد، سیکیورٹی، قابلِ توضیح، رازداری، انصاف پسندی) درج کیے جاتے ہیں۔ **TEVV** (testing, evaluation, verification, validation) جانچیں، آپریشن میں نگرانی اور ماڈل کو محفوظ طریقے سے بند کرنا/واپس کرنا منصوبہ بند کیا جاتا ہے۔ یہ اقدامات AI خطرے کے انتظام کے NIST ڈھانچے سے **GOVERN–MAP–MEASURE–MANAGE** افعال سے مطابقت رکھتے ہیں؛ انہیں SRS، تعمیر اور تصدیق/آپریشن کے منصوبوں میں شامل کیا جاتا ہے۔^{[\[70\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-NIST_AI_RMF-70)} - **DevSecOps: «بائیں جانب» اور بطور ڈیفالٹ سیکیورٹی**۔ **CI/CD** کے ہر مرحلے میں سیکیورٹی شامل کرنا معمول بن گیا ہے: خودکار جانچیں (SAST/DAST)، انحصارات اور کنٹینرز کی اسکیننگ، تعیناتی کی پالیسیاں، بنیادی مشاہدہ پذیری۔ قابلِ اعتماد آثر ذخیرے اور معیاری «سخت» تصاویر استعمال ہوتی ہیں؛ صفر اعتماد کے اصول لاگو ہوتے ہیں۔ سسٹم تجزیہ میں پہلے سے **پائپ لائن کی کنٹرول پوائنٹس** (مراحل کے گزرنے کی شرائط)، تقاضوں کا سیکیورٹی کنٹرولز سے تعلق اور ماحول کے درمیان منتقلی کے اصول (dev/test/stage/prod) بیان کیے جاتے ہیں۔^{[\[71\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-DoD_DevSecOps-71)} - **دستاویزات (آثار) میں کیا بدلتا ہے**۔ Big Data اور AI/ML کی موجودگی میں اور DevSecOps کے تحت کام کرتے ہوئے اہم دستاویزات میں کون سے حصے ظاہر ہوتے یا واضح ہوتے ہیں: - **SRS / تقاضوں کی تفصیلات**: AI کے اطلاق کے اہداف اور سیاق؛ ڈیٹا کے تقاضے (ماخذ، معیار، اخلاقی اور قانونی پابندیاں)؛ ماڈل کی میٹرکس (درستگی، قابلِ اعتماد، ردِّعمل کا وقت)؛ TEVV منصوبہ (testing, evaluation, verification, validation)؛ شفافیت/قابلِ توضیح اور رازداری کے تقاضے؛ ماڈل کو آپریشن سے بند/واپس کرنے کے معیار۔^{[\[70\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-NIST_AI_RMF-70)} - **تعمیر اور فیصلے (Architecture, ADR)**: خطرے کی ماڈلنگ کے نتائج؛ «بطور ڈیفالٹ سیکیورٹی» کے اقدامات (خفیہ کاری، رسائی کنٹرول، سیکرٹ مینجمنٹ، کم از کم اختیار کا اصول)؛ ڈیٹا/ماڈل استعمال کی پابندیاں؛ خطرات اور سمجھوتوں کی جانچ کے ساتھ ADR اندراجات۔^{[\[71\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-DoD_DevSecOps-71)[\[70\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-NIST_AI_RMF-70)} - **تصدیق اور توثیق کا منصوبہ (V&V / TEVV)**: ماڈل اور ڈیٹا کی جانچ کے منظرنامے؛ معیار کی میٹرکس کے قبولیت کی حدیں؛ ڈیٹا/ماڈل drift کی نگرانی؛ دوری کی دوبارہ جانچ اور دوبارہ توثیق کے طریقے۔^{[\[70\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-NIST_AI_RMF-70)} - **CI/CD پالیسیاں اور پائپ لائن «گیٹ»**: SAST/DAST، SCA (انحصارات)، کنٹینر اسکیننگ کی خودکار جانچیں؛ قابلِ اعتماد ذخیروں میں آثر کی دستخط اور ذخیرہ؛ ماحول کے درمیان ترقی کے اصول (dev/test/stage/prod) اور جانچ ناکام ہونے پر تعمیر روکنے کی شرائط؛ بطور ڈیفالٹ مشاہدہ پذیری کے تقاضے۔^{[\[71\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-DoD_DevSecOps-71)} - **ڈیٹا اور ماڈل کے انتظام کا منصوبہ**: ذرائع کا کیٹلاگ اور lineage؛ ڈیٹا کے معیار اور دستیابی کے معیار؛ dataset/ماڈل کے ورژن؛ تربیت کا شیڈول اور bias کنٹرول؛ رسائی اور ذخیرے کی پالیسی؛ ضرورت پڑنے پر ماڈل کو محفوظ طریقے سے غیر فعال کرنے اور ڈیٹا حذف کرنے کا منصوبہ۔^{[\[70\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-NIST_AI_RMF-70)} - **آپریشن اور مشاہدہ پذیری (Ops/Runbook)**: AI اعتماد کی میٹرکس اور SLO؛ آڈٹ اور لاگنگ؛ تنزلی/بے ضابطگیوں کے الرٹ؛ واقعات کے ردِّعمل کا منصوبہ؛ AI اجزاء کے لیے fallback/kill‑switch؛ رپورٹنگ اور واقعے کے بعد تجزیے کے تقاضے۔^{[\[70\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-NIST_AI_RMF-70)[\[71\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-DoD_DevSecOps-71)} - **قابلِ ردِّتفحص** (end‑to‑end): واضح روابط «**تقاضہ ↔ پائپ لائن میں کنٹرول/جانچ**» اور «**تقاضہ ↔ آپریشن میں ٹیسٹ/نگرانی**»، تاکہ پورے دورِ حیات میں سیکیورٹی اور معیار قابلِ اثبات طور پر جانچی جا سکے۔^{[\[71\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-DoD_DevSecOps-71)[\[70\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-NIST_AI_RMF-70)} - **سسٹم تجزیہ کار کا کردار**۔ - AI کا سیاق اور خطرات مناسب کرتا ہے (فاعلین، اطلاق کے منظرنامے، ڈیٹا کے مفروضے اور حدود)؛ - «**تقاضہ ↔ پائپ لائن میں سیکیورٹی کنٹرول**» کی قابلِ ردِّتفحص یقینی بناتا ہے؛ - پورے نظامی دورِ حیات میں قابلِ تصدیق غیر فعالی تقاضے (سیکیورٹی، شفافیت، مشاہدہ پذیری) مرتب کرتا ہے۔^{[\[70\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-NIST_AI_RMF-70)[\[71\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-DoD_DevSecOps-71)} ## کلاسیکی سسٹم تجزیہ سے فرق تاریخی طور پر «سسٹم تجزیہ» کی اصطلاح سافٹ ویئر ترقی سے زیادہ وسیع ہے۔ کلاسیکی سسٹم تجزیہ پیچیدہ بین الشعبہ مسائل (سماجی، اقتصادی، انتظامی) کو حل کرنے کا طریقہ ہے، جو نظامی سوچ اور مقداری طریقوں پر مبنی ہے، عام طور پر انتظامی فیصلوں کی حمایت کے لیے۔ آئی ٹی میں سسٹم تجزیہ سے مراد سافٹ ویئر انجینئرنگ کے شعبے میں ایک اطلاقی نظم ہے، جو معلوماتی نظاموں کی تخلیق پر مرکوز ہے۔ ذیل میں کلیدی فرق ہیں۔ - **اہداف اور تجزیے کا موضوع**۔ کلاسیکی تجزیہ بد ساختہ، «دھندلے» مسائل حل کرتا ہے اور موجودہ سماجی-تکنیکی نظاموں (شہری نقل و حمل کا جال، کمپنی کی حکمت عملی، ماحولیاتی پالیسی) کو بہتر بناتا ہے۔ موضوع — حقیقی نظام؛ مقصد — فیصلہ ساز کو عمل کا راستہ منتخب کرنے میں مدد۔ آئی ٹی میں سسٹم تجزیہ کا مقصد — ایک نیا معلوماتی نظام یا سافٹ ویئر پروڈکٹ ڈیزائن اور بنانا جو تقاضوں کو پورا کرے۔ موضوع — زیرِ منصوبہ نظام؛ توجہ — صارفین کو درکار رویہ اور خصوصیات۔ - **روش کی بنیادیں**۔ کلاسیکی مکاتب نظامی سوچ اور اکثر ریاضی پر مبنی ہیں۔ سخت طریقہ (hard systems) — مسئلے کی رسمی تشکیل، مقداری معیار، بہینہ سازی (جیسے *operations research* میں)۔ نرم روشیں (soft systems) نقطہ ہائے نظر کی کثرتیت کو تسلیم کرتی ہیں؛ مثال — *Soft Systems Methodology (SSM)*، جہاں گفتگو اور تصوراتی ماڈل کے ذریعے مطلوبہ تبدیلیوں پر اتفاق ہوتا ہے۔ آئی ٹی میں بنیاد — انجینئری نظم: تقاضوں کی انجینئرنگ، سافٹ ویئر ڈیزائن، تعمیراتی فریم ورک۔ معیاری عمل (ISO/IEC/IEEE 15288، 12207، 29148)، UML/SysML اشارات اور تبدیلیوں کے انتظام کے طریقے استعمال ہوتے ہیں۔ - **کردار اور آثار**۔ کلاسیکی تجزیہ میں «سسٹم تجزیہ کار» کا کردار اکثر غیر رسمی ہوتا ہے؛ نتائج — تجزیاتی رپورٹ، سفارشات، ریاضی کے ماڈل، «کیا ہو اگر» منظرنامے۔ آئی ٹی میں تجزیہ کار (یا کاروباری تجزیہ کار) کا کردار رسمی ہے؛ تقاضوں کی تفصیلات، نظام کے ماڈل (UML، ER)، انٹرفیس کی تفصیلات، user stories اور backlog تیار کیے جاتے ہیں — آثار جو ڈویلپرز اور ٹیسٹرز براہِ راست استعمال کرتے ہیں۔ - **دورِ حیات اور عمل**۔ کلاسیکی تجزیہ کا کوئی واحد سانچہ نہیں: مراحل مسئلے پر منحصر ہیں (SSM میں — صورتحال کے مطالعے سے تبدیلیوں کے نفاذ تک)۔ آئی ٹی میں معیاری SDLC چکر اپنائے جاتے ہیں: کسکیڈ ماڈل میں تقاضوں کے تجزیے کا الگ مرحلہ ہوتا ہے؛ تکراری اور لچکدار طریقوں میں تجزیہ ہر اسپرنٹ کی مستقل سرگرمی ہے۔ جدید طریقے (DevOps، CI/CD) تجزیے کے دائرے کو آپریشن تک وسیع کرتے ہیں: دیکھ بھال، مشاہدہ پذیری اور اپ ڈیٹ کے تقاضوں کو مدِّنظر رکھا جاتا ہے۔ یعنی آئی ٹی میں سسٹم تجزیہ ترقیاتی دورِ حیات میں ضم ہوتا ہے، جبکہ کلاسیکی تجزیہ اکثر منصوبہ جاتی/مشاورتی سرگرمی کے طور پر انجام دیا جاتا ہے۔ ## سسٹم تجزیہ کار **آئی ٹی میں سسٹم تجزیہ کار** — وہ ماہر جو معلوماتی نظاموں کی منصوبہ بندی اور ترقی میں نظامی سوچ کا ذمہ دار ہے: تقاضوں کی تشکیل اور توثیق، نمونہ سازی (UML/BPMN)، تعمیراتی فیصلوں کا اتفاق اور انضمام کی یقین دہانی۔ روسی فیڈریشن میں کردار اور اہلیت کے تقاضے پیشہ ورانہ معیار اور وفاقی ریاستی تعلیمی معیار میں مقرر ہیں۔ **پیشہ ورانہ سرگرمی کا بنیادی مقصد:** آئی ٹی سروس، خودکار نظام، خودکار معلوماتی نظام، خودکار کنٹرول سسٹم، سافٹ ویئر، معلوماتی پروڈکٹ یا ذریعہ (آگے — سسٹم) کی ماحول، اصل تقاضوں اور پابندیوں، خودکاری کے اہداف اور خودکار سرگرمی کے ساتھ مطابقت یقینی بنانا، نظام کے پورے دورِ حیات میں فریقینِ مفاد تک معیاری اور باہم مربوط منصوبہ بندی کے فیصلے پہنچا کر اور انفرادی ذمہ داروں کے کام کو شروع اور منظم کر کے (*پیشہ ورانہ معیار «سسٹم تجزیہ کار» (وزارت محنت روسی فیڈریشن کا حکم 27.04.2023 № 367н*)۔^{[\[72\]](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_note-72)} ## کلیدی اصطلاحات کی لغت ### بنیادی تصورات اور شرکاء - آئی ٹی میں سسٹم تجزیہ — وہ نظم جس کا موضوع معلوماتی نظام اپنے پورے دورِ حیات میں ہے، تصور سے آپریشن تک۔ - اسٹیک ہولڈرز — وہ افراد یا گروہ جو منصوبے میں دلچسپی رکھتے ہیں یا اس سے متاثر ہوتے ہیں (خریداران، صارفین، منتظمین)۔ - منصوبہ بندی کے آثار — منصوبے کے دوران بنائے جانے والے دستاویزات اور نتائج، جیسے تفصیلات، ماڈل، منصوبے اور فیصلے۔ ### تقاضے: اقسام اور دستاویز سازی - فعالی تقاضے — بیان کرتے ہیں کہ نظام کو کیا کرنا چاہیے؛ اس کے افعال اور رویہ۔ - غیر فعالی تقاضے — نظام کے معیاری صفات بیان کرتے ہیں (قابلِ اعتماد، کارکردگی، سیکیورٹی، استعمال میں آسانی، توسیع پذیری وغیرہ)۔ - تقاضوں کی تفصیلات (ابتدائی) — وہ دستاویز جس میں منصوبے کے ابتدائی مراحل میں جمع کیے گئے تقاضوں کا اصل مجموعہ ہوتا ہے۔ - SRS (Software Requirements Specification) — معیاری دستاویز جو بین الاقوامی معیارات (مثلاً ISO/IEC/IEEE 29148) کے مطابق سافٹ ویئر کے تقاضوں کی تفصیلی وضاحت کرتی ہے۔ - URS (User Requirements Specification) — وہ دستاویز جو کاروباری عمل اور حتمی صارف کی توقعات کے نقطہ نظر سے نظام کے صارفی تقاضوں کی وضاحت کرتی ہے۔ - تعمیراتی اہمیت کے تقاضے (ASR) — وہ تقاضے جو تعمیراتی فیصلوں اور سمجھوتوں پر نمایاں اثر ڈالتے ہیں۔ - کراس فنکشنل تقاضے (CFR) — غیر فعالی تقاضوں کا مترادف، ان کی مسلسل نوعیت پر زور دیتا ہے۔ - قبولیت کے معیار (Acceptance Criteria) — قابلِ تصدیق شرائط جن کی تکمیل پر کسی تقاضے کا کام قبول شدہ سمجھا جاتا ہے۔ - Definition of Ready (DoR) — بیک لاگ عنصر کی ترقی کے لیے تیاری کا معاہدہ (وضاحت، اندازہ، معیار)۔ - Definition of Done (DoD) — کام کی «تکمیل» کا معاہدہ (کوڈ، ٹیسٹ، دستاویزات، تعیناتی)۔ - پابندی (Constraint) — سخت شرط جو حل کو محدود کرتی ہے (مدت، پلیٹ فارم، معیار، لائسنس)۔ - مفروضہ (Assumption) — وہ قیاس جو بغیر ثبوت کے قبول کیا جائے، بعد میں توثیق ضروری ہو۔ - تقاضوں کا معیار — ISO 29148 کے مطابق خصوصیات: غیر ابہام، تکمیل، غیر تضاد، قابلِ تصدیق، جوہری۔ ### تقاضوں کی رسمی تشکیل، قابلِ ردِّتفحص اور ترجیح بندی - تقاضوں کی رسمی تشکیل — غیر رسمی درخواستوں کو واضح، قابلِ تصدیق اور غیر مبہم تقاضوں میں بدلنے کا عمل۔ - تقاضوں کی قابلِ ردِّتفحص — تقاضے کے دورِ حیات کو اس کے ماخذ سے تکمیل، جانچ اور تعیناتی تک ردِّتفحص کرنے کی صلاحیت۔ - Bidirectional traceability (دو طرفہ قابلِ ردِّتفحص) — تقاضوں، ڈیزائن کے عناصر اور ٹیسٹ منظرناموں کے درمیان دونوں سمتوں میں روابط ردِّتفحص کرنے کی صلاحیت۔ - MoSCoW — تقاضوں کی ترجیح بندی کی تکنیک جو انہیں Must-have (لازمی)، Should-have (ہونا چاہیے)، Could-have (ہو سکتا ہے) اور Won't-have (نہیں ہوگا) میں تقسیم کرتی ہے۔ - BDD (Behavior-Driven Development) — ترقی کا طریقہ جس میں ٹیسٹ صارف کے نقطہ نظر سے نظام کے رویے پر مبنی قدرتی زبان میں لکھے جاتے ہیں (Given–When–Then سانچہ)۔ ### اشارات اور نمونہ سازی - UML (Unified Modeling Language) — سافٹ ویئر نظاموں کے اجزاء کی تفصیل، تصویرکشی، تعمیر اور دستاویز سازی کے لیے گرافیکل نمونہ سازی کی معیاری زبان۔ - SysML (Systems Modeling Language) — نظامی انجینئرنگ کے لیے UML کی توسیع، جو پیچیدہ نظاموں کے مختلف پہلوؤں — تقاضوں، رویے، ساخت اور پیرامیٹر — کی نمونہ سازی کی حمایت کرتی ہے۔ - BPMN (Business Process Model and Notation) — کاروباری عمل کی گرافیکل وضاحت کا معیار، جو کام کا بہاؤ، واقعات، گیٹ وے اور پول ظاہر کرتا ہے۔ - MBSE (Model-Based Systems Engineering) — نظامی انجینئرنگ کا طریقہ جہاں ماڈل نظام کے دورِ حیات کے تمام مراحل میں تقاضوں سے جانچ تک مرکزی آثر ہوتا ہے۔ - ArchiMate — انٹرپرائز آرکیٹیکچر (کاروبار، ایپلیکیشنز، ٹیکنالوجیز) اور ان کے روابط کی اشارہ نگاری۔ - DMN (Decision Model and Notation) — کاروباری فیصلوں اور اصولوں کی جدولوں کی نمونہ سازی۔ - DFD (Data Flow Diagram) — ڈیٹا کے بہاؤ کے ڈایاگرام (سیاق، تجزیے کی سطحیں)۔ - ERD (Entity-Relationship Diagram) — موضوعاتی شعبے کا ماڈل جس میں اشیاء، روابط اور صفات ہیں۔ - CRUD-میٹرکس — Create/Read/Update/Delete آپریشنوں کا اشیاء اور کرداروں/افعال سے مطابقت۔ ### تعمیراتی انداز اور حل کی جانچ - یک پارچہ تعمیر — تعمیراتی طریقہ جس میں پورا نظام ایک واحد، غیر قابلِ تقسیم ماڈیول کے طور پر تیار کیا جاتا ہے۔ - مائیکروسروس تعمیر — تعمیراتی طریقہ جس میں نظام آزادانہ تعیناتی اور توسیع پذیر سروسز کے چھوٹے مجموعے کے طور پر بنایا جاتا ہے۔ - Trade-off (سمجھوتہ) — باہم متضاد خصوصیات یا حل کے درمیان انتخاب جہاں ایک خصوصیت بہتر ہونے سے دوسری خراب ہوتی ہے۔ - ATAM (Architecture Tradeoff Analysis Method) — سافٹ ویئر تعمیر کی جانچ کا طریقہ، معیاری صفات (مثلاً کارکردگی، توسیع پذیری) کے درمیان سمجھوتوں کے تجزیے کے لیے استعمال ہوتا ہے۔ ### انٹرپرائز آرکیٹیکچر اور فریم ورک - TOGAF (The Open Group Architecture Framework) — انٹرپرائز آرکیٹیکچر کے سب سے زیادہ مستعمل فریم ورکس میں سے ایک، جس میں تعمیر کی ترقی اور انتظام کے لیے ADM (Architecture Development Method) شامل ہے۔ - Zachman Framework — انٹرپرائز آرکیٹیکچر کے آثار کی آنٹالوجی، 6×6 میٹرکس کے طور پر پیش کی گئی، جو مختلف نقطہ ہائے نظر سے تعمیر کے مختلف پہلوؤں کی درجہ بندی کرتی ہے۔ ### تجزیے اور ترقیاتی عمل کے طریقے - سخت طریقہ (Hard Systems) — سسٹم تجزیہ کی روش جو پیشگی قابلِ رسمی اہداف اور تقاضوں، تجزیے اور «اوپر سے نیچے» منصوبہ بندی پر منحصر ہے، واضح طور پر طے شدہ کاموں کے لیے کارگر۔ - نرم طریقہ (Soft Systems) — سسٹم تجزیہ کی روش، جو غیر واضح اہداف اور اسٹیک ہولڈرز کے متعدد نقطہ ہائے نظر کی صورت میں استعمال ہوتی ہے، مسئلے کی سمجھ اور مطلوبہ تبدیلیوں کے اتفاق کی طرف مرکوز۔ - SSM (Soft Systems Methodology) — نرم نظامی طریقے کی ایک مخصوص روش جو پیٹر چیک لینڈ نے تیار کی، rich picture، بنیادی تعریفوں اور CATWOE جیسے اوزار استعمال کرتی ہے۔ - Waterfall (کسکیڈ ماڈل) — سافٹ ویئر ترقی کی کلاسیکی روش جہاں مراحل (تجزیہ، منصوبہ بندی، تکمیل، جانچ، نفاذ) یکے بعد دیگرے انجام پاتے ہیں، اگلا مرحلہ پچھلے کی مکمل تکمیل کے بعد شروع ہوتا ہے۔ - Agile — سافٹ ویئر ترقی کی لچکدار روشوں کا گروہ، تکراری ترقی، تبدیلیوں کے ساتھ موافقت، خریدار سے تعامل اور قدر کی مسلسل فراہمی پر مرکوز۔ ### انتخاب کے طریقے اور عام غلطیاں - AHP (Analytic Hierarchy Process) — کثیر المعیار انتخاب کا طریقہ جو پیچیدہ مسائل کو منظم کرنے اور معیاروں کے درجاتی ڈھانچے پر متبادل کا جائزہ لینے کی اجازت دیتا ہے۔ - Gold-plating («سونے کی پلیٹ» کا سنڈروم) — سسٹم تجزیہ کی غلطی جس میں ایسی فعالیت شامل کی جاتی ہے جو اسٹیک ہولڈرز کو درکار نہیں، جس سے منصوبے کے دائرے اور پیچیدگی میں اضافہ ہوتا ہے۔ ## حوالہ جات - ISO/IEC/IEEE 15288:2023 — System life cycle processes - ISO/IEC/IEEE 12207:2017 — Software life cycle processes - ISO/IEC/IEEE 29148:2018 — Requirements engineering - ISO/IEC/IEEE 42010:2022 — Architecture description - ISO/IEC 25010:2023 — Product quality model (SQuaRE) - ISO/IEC/IEEE 24748-2:2024 — Life cycle management — Guidelines for applying ISO/IEC/IEEE 15288 - ISO/IEC/IEEE 15289:2019 — Content of life-cycle information items (documentation) - ISO/IEC/IEEE 42020:2019 — Architecture processes - ISO/IEC/IEEE 29119-1:2022 — Software testing — Part 1: General concepts - IEEE Std 1012-2024 — System, Software, and Hardware Verification and Validation - UML 2.5.1 — OMG Specification - BPMN 2.0.2 — OMG Specification - SysML v1.7 — OMG Specification - TOGAF Standard, 10th Edition — The Open Group - ArchiMate 3.2 — The Open Group - SEI ATAM — Architecture Tradeoff Analysis Method - NASA Systems Engineering Handbook, SP-2016-6105 Rev2 (PDF) - SWEBOK Guide v4.0a — IEEE Computer Society (PDF) - Guide to the Systems Engineering Body of Knowledge (SEBoK) - BABOK Guide v3 — IIBA - Google SRE Books — Official site - Microsoft Azure Well-Architected Framework — Official docs - سسٹم تجزیہ آسان الفاظ میں۔ YouTube - آئی ٹی میں سسٹم تجزیہ آسان الفاظ میں۔ YouTube ## کتابیات - ISO/IEC/IEEE (2023). *15288: System Life Cycle Processes*. - INCOSE (2023). *INCOSE Systems Engineering Handbook*، 5ویں اشاعت۔ - ISO/IEC/IEEE (2018). *29148: Systems and Software Engineering — Life Cycle Processes — Requirements Engineering*. - IIBA (2015). *A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), v3*. - The Open Group (2022). *The TOGAF® Standard, 10th Edition*۔ سرکاری مفت نسخہ۔ - OMG (2017). *Unified Modeling Language (UML®) 2.5.1 Specification*۔ PDF۔ - OMG (2014). *Business Process Model and Notation (BPMN™) 2.0.2 Specification*۔ PDF۔ - OMG (2024). *Systems Modeling Language (SysML®) 1.7 Specification*۔ PDF۔ - The Open Group (2022). *ArchiMate® 3.2 Specification*۔ سرکاری مفت ڈاؤن لوڈ (لائسنس کے ساتھ)۔ - Bass, L.; Clements, P.; Kazman, R. (2021). *Software Architecture in Practice*، 4ویں اشاعت۔ - Wiegers, K.; Beatty, J. (2013). *Software Requirements*، 3ویں اشاعت۔ - Rozanski, N.; Woods, E. (2012). *Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives*، 2ویں اشاعت۔ - Meadows, D. (2008). *Thinking in Systems: A Primer*. - Senge, P. M. (2006). *The Fifth Discipline: The Art & Practice of the Learning Organization* (rev. ed.). - Blanchard, B. S.; Fabrycky, W. J. (2010). *Systems Engineering and Analysis*، 5ویں اشاعت۔ - Robertson, J.; Robertson, S. (2012). *Mastering the Requirements Process: Getting Requirements Right*، 3ویں اشاعت۔ - van Lamsweerde, A. (2009). *Requirements Engineering: From System Goals to UML Models to Software Specifications*. - Hull, E.; Jackson, K.; Dick, J. (2017). *Requirements Engineering*، 4ویں اشاعت۔ - Kendall, K. E.; Kendall, J. E. (2023). *Systems Analysis and Design*، 11ویں اشاعت۔ - Dennis, A.; Wixom, B. H.; Tegarden, D. (2021). *Systems Analysis and Design: An Object-Oriented Approach with UML*، 8ویں اشاعت۔ - Satzinger, J. W.; Jackson, R. B.; Burd, S. D. (2015). *Systems Analysis and Design in a Changing World*، 7ویں اشاعت۔ - Fowler, M. (2003). *UML Distilled: A Brief Guide to the Standard Object Modeling Language*، 3ویں اشاعت۔ - Delligatti, L. (2013). *SysML Distilled: A Brief Guide to the Systems Modeling Language*. - Silver, B. (2011). *BPMN Method and Style*، 2ویں اشاعت۔ - Lankhorst, M. et al. (2017). *Enterprise Architecture at Work: Modelling, Communication and Analysis*، 4ویں اشاعت۔ - Richards, M.; Ford, N. (2020). *Fundamentals of Software Architecture*. - Fairbanks, G. (2010). *Just Enough Software Architecture: A Risk-Driven Approach*. - Keeling, M. (2017). *Design It!: From Programmer to Software Architect*. - Evans, E. (2003). *Domain-Driven Design: Tackling Complexity in the Heart of Software*. - Vernon, V. (2013). *Implementing Domain-Driven Design*. - Brandolini, A. (2018). *Introducing EventStorming: An Act of Deliberate Collective Learning*. - Simsion, G.; Witt, G. (2015). *Data Modeling Essentials*، 4ویں اشاعت۔ - Silverston, L. (2008–2009). *The Data Model Resource Book*، Vols. 1–3 (rev. eds.). - Keeney, R. L.; Raiffa, H. (1993). *Decisions with Multiple Objectives: Preferences and Value Trade-Offs*، 2ویں اشاعت۔ - Saaty, T. L. (1980). *The Analytic Hierarchy Process*؛ (1990) *Decision Making for Leaders*. ## حواشی 1. ↑ ^{[1.00](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-SWEBOK_1-0)} ^{[1.01](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-SWEBOK_1-1)} ^{[1.02](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-SWEBOK_1-2)} ^{[1.03](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-SWEBOK_1-3)} ^{[1.04](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-SWEBOK_1-4)} ^{[1.05](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-SWEBOK_1-5)} ^{[1.06](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-SWEBOK_1-6)} ^{[1.07](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-SWEBOK_1-7)} ^{[1.08](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-SWEBOK_1-8)} ^{[1.09](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-SWEBOK_1-9)} ^{[1.10](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-SWEBOK_1-10)} ^{[1.11](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-SWEBOK_1-11)} ^{[1.12](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-SWEBOK_1-12)} IEEE Computer Society (2025). *Guide to the Software Engineering Body of Knowledge (SWEBOK), v4.0a*. Requirements Engineering: elicitation techniques. https://ieeecs-media.computer.org/media/education/swebok/swebok-v4.pdf 2. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-Zowghi_2-0) Zowghi, D.; Coulin, C. (2005/2014). *Requirements Elicitation: A Survey of Techniques, Approaches, and Tools*. https://eecs481.org/readings/requirements.pdf 3. ↑ ^{[3.00](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-ISO29148_3-0)} ^{[3.01](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-ISO29148_3-1)} ^{[3.02](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-ISO29148_3-2)} ^{[3.03](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-ISO29148_3-3)} ^{[3.04](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-ISO29148_3-4)} ^{[3.05](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-ISO29148_3-5)} ^{[3.06](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-ISO29148_3-6)} ^{[3.07](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-ISO29148_3-7)} ^{[3.08](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-ISO29148_3-8)} ^{[3.09](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-ISO29148_3-9)} ^{[3.10](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-ISO29148_3-10)} ^{[3.11](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-ISO29148_3-11)} ^{[3.12](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-ISO29148_3-12)} ISO/IEC/IEEE 29148 (2011/2018). *Systems and software engineering — Requirements engineering*. *ISO* overview page: «Defines the construct of a good requirement…». https://www.iso.org/standard/45171.html 4. ↑ ^{[4.0](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-NASA7123_4-0)} ^{[4.1](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-NASA7123_4-1)} ^{[4.2](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-NASA7123_4-2)} NASA (2020). *NPR 7123.1C — Systems Engineering Processes and Requirements*. Определение «well-formed (clear and unambiguous), complete, consistent, individually verifiable and traceable». https://nodis3.gsfc.nasa.gov/displayAll.cfm?Internal_ID=N_PR_7123_001C_&page_name=all 5. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-5) GMU (George Mason University). *IEEE Software Requirements Specification Template (SRS)*. https://cs.gmu.edu/~rpettit/files/project/SRS-template.doc 6. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-6) Westfall, L. (Cal Poly, .edu). *The What, Why, Who, When and How of Software Requirements* (упоминает URS). https://users.csc.calpoly.edu/~csturner/courses/300f06/readings/%5B3%5D_%20The_Why_What_Who_When_and_How_of_Software_Requirements.pdf 7. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-7) Stanford University IT (.edu). *Functional Specification Document Template*. https://uit.stanford.edu/sites/default/files/2017/08/30/Functional%20Specification%20Document%20Template.docx 8. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-8) Penn State (.edu). *Elements of a Use Case Diagram*. https://www.e-education.psu.edu/geog468/l8_p4.html 9. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-9) UC Irvine (.edu). *Data Flow Diagram*. https://www.security.uci.edu/program/risk-assessment/data-flow-diagram/ 10. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-ISO42010_10-0) ISO/IEC/IEEE 42010 (2011/2022). *Architecture description* — требования к описанию архитектуры и точкам зрения. https://standards.ieee.org/ieee/42010/5334/ 11. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-11) Cornell University (.edu). *CS 5150 — Feasibility Studies*. https://www.cs.cornell.edu/courses/cs5150/2015fa/slides/C1-feasibility.pdf 12. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-ATAM_12-0) Carnegie Mellon SEI. *Architecture Tradeoff Analysis Method (ATAM) — overview*. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/ 13. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-13) Microsoft Azure Architecture Center. *Architecture styles: microservices — benefits & complexity*. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/ 14. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-14) Google Cloud. *What Is Microservices Architecture? — Monolithic vs. microservices (обзор)*. https://cloud.google.com/learn/what-is-microservices-architecture 15. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-15) NASA (2023). *Requirements Management — Traceability, Bidirectional traceability (definitions)*. https://www.nasa.gov/reference/6-2-requirements-management/ 16. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-16) McKinsey (2012). *Delivering large-scale IT projects on time, on budget, and on value*. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value 17. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-17) University of Cambridge, IfM. *Soft Systems Methodology (SSM) — CATWOE, 3Es*. https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/ 18. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-18) Lancaster University (ePrints). *Soft Systems Methodology and root definitions*. https://eprints.lancs.ac.uk/id/eprint/48770/1/Document.pdf 19. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-19) University of Cambridge, IfM. *Soft Systems Methodology (SSM)*. https://www.ifm.eng.cam.ac.uk/research/dstools/soft-systems-methodology/ 20. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-20) UCL Discovery (.ac.uk). M. Haklay. *Soft System Methodology (SSM)*. https://discovery.ucl.ac.uk/1296/1/paper13.pdf 21. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-21) IEEE Std 1320.1-1998 (R2004). *Functional Modeling Language — Syntax and Semantics for IDEF0*. https://standards.ieee.org/ieee/1320.1/2003/ 22. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-22) ISO/IEC/IEEE 31320-1:2012. *IDEF0: Function Modeling*. https://cdn.standards.iteh.ai/samples/60615/9c848e7a1bc54042b774b3cb050872e7/ISO-IEC-IEEE-31320-1-2012.pdf 23. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-23) University of Washington (.edu). *UML Class Diagrams / UML overview (course material)*. https://courses.cs.washington.edu/courses/cse403/16au/lectures/L07.pdf 24. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-24) JHU/APL (.edu). *Modeling with SysML — tutorial*. https://www.jhuapl.edu/sites/default/files/2023-03/ModelingwithSysMLTutorial.pdf 25. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-25) MIT OCW (.edu). O. de Weck. *Introduction to Systems Modeling Languages (incl. SysML, MBSE)*. https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/23fea897f48d11f45593fa4be698d749_MIT16_842F15_Ses3_sysmodlg.pdf 26. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-26) IBM. *What is Business Process Modeling and Notation (BPMN)?*. https://www.ibm.com/think/topics/bpmn 27. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-27) IBM Docs. *Business Process Modeling Notation (BPMN) model*. https://www.ibm.com/docs/en/iis/11.5.0?topic=types-business-process-modeling-notation-bpmn-model 28. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-28) IEEE/ISO/IEC 29148:2018. *Systems and software engineering — Requirements engineering (overview)*. https://standards.ieee.org/ieee/29148/6937/ 29. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-29) King’s College London (.ac.uk). *What is MoSCoW prioritization?*. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/ 30. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-30) T. L. Saaty. *How to Make a Decision: The Analytic Hierarchy Process*. *Interfaces* 24(6), 1994. https://pubsonline.informs.org/doi/10.1287/inte.24.6.19 31. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-31) Microsoft Learn (Azure Boards). *Best practices for Agile project management — Refine each backlog*. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management 32. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-32) MIT OCW (.edu). *V-Model — Fundamentals of Systems Engineering*. https://ocw.mit.edu/courses/16-842-fundamentals-of-systems-engineering-fall-2015/resources/v-model/ 33. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-33) Carnegie Mellon SEI (.edu). *Architecture Tradeoff Analysis Method (ATAM) — overview*. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/ 34. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-AzureStyles_34-0) Microsoft Azure Architecture Center. *Architecture styles*. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/ 35. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-SEI_ATAM_35-0) Kazman, R.; Klein, M.; Clements, P. *ATAM: Method for Architecture Evaluation*. CMU/SEI Technical Report, 2000. https://www.sei.cmu.edu/documents/629/2000_005_001_13706.pdf 36. ↑ ^{[36.0](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-TOGAFIntro_36-0)} ^{[36.1](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-TOGAFIntro_36-1)} ^{[36.2](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-TOGAFIntro_36-2)} ^{[36.3](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-TOGAFIntro_36-3)} The Open Group. *Introduction — The TOGAF® Standard*. https://www.togaf.org/chap01.html 37. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-AzureEvent_37-0) Microsoft Azure Architecture Center. *Event-Driven Architecture style*. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven 38. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-38) Jonkers, H. et al. *ArchiMate® and the TOGAF® Framework*. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698909899/toc.pdf 39. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-39) Estrem, W. *Building Blocks Revisited*. The Open Group (presentation). https://archive.opengroup.org/public/member/proceedings/q411b/presentations/Estrem%20-%20Building%20Blocks%20Revisted.pdf 40. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-40) The Open Group. *Architecture Principles*. https://pubs.opengroup.org/onlinepubs/7499919799/toc.pdf 41. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-41) The Open Group. *IT Architecture Compliance*. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm 42. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-42) *The TOGAF® Standard, Version 9.2* (спецификация). The Open Group. https://university.sk/wp-content/uploads/2020/01/TOGAF_v9_2_specifikacia.pdf 43. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-43) Engelsman, W.; van Sinderen, M. *Supporting Requirements Management in TOGAF and ArchiMate*. The Open Group (white paper). https://pubs.opengroup.org/onlinepubs/7698999899/toc.pdf 44. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-Zachman1987_44-0) Zachman, J. A. *A Framework for Information Systems Architecture*. *IBM Systems Journal*, 26(3), 276–292, 1987. https://doi.org/10.1147/sj.263.0276 45. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-45) MIT CISR. *Classic Topics — Enterprise Architecture* (определение EA как «organizing logic for business process and IT capabilities…»). https://cisr.mit.edu/content/classic-topics-enterprise-architecture 46. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-46) The Open Group. *IT Architecture Compliance*. https://www.opengroup.org/architecture/togaf7-doc/arch/p4/comp/comp.htm 47. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-Royce_47-0) Royce, W. W. (1970). *Managing the Development of Large Software Systems*. IEEE WESCON. Репринт (PDF): https://www.praxisframework.org/files/royce1970.pdf 48. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-DAU_SRR_48-0) Defense Acquisition University. *System Requirements Review (SRR) — Acquipedia*. https://aaf.dau.edu/acquipedia/article/system-requirements-review-srr/ 49. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-NASA_CCB_49-0) NASA (2023). *Requirements Management — baseline, change control (CCB)*. https://www.nasa.gov/reference/6-2-requirements-management/ 50. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-MS_Agile_50-0) Microsoft Learn (Azure Boards). *Best practices for Agile project management — Refine each backlog*. https://learn.microsoft.com/en-us/azure/devops/boards/best-practices-agile-project-management 51. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-MS_BDD_51-0) MSDN Magazine (Microsoft). *BDD Primer: Behavior‑Driven Development with SpecFlow*. https://learn.microsoft.com/en-us/archive/msdn-magazine/2010/december/msdn-magazine-bdd-primer-behavior-driven-development-with-specflow-and-watin 52. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-MS_Trace_52-0) Microsoft Learn. *End‑to‑end traceability in Azure DevOps*. https://learn.microsoft.com/en-us/azure/devops/cross-service/end-to-end-traceability 53. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-SRE_SLO_53-0) Google SRE. *Service Level Objectives*; *Error Budget Policy*. https://sre.google/sre-book/service-level-objectives/ ; https://sre.google/workbook/error-budget-policy/ 54. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-AzureMon_54-0) Microsoft Learn. *Azure Monitor — Overview*. https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/overview 55. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-AWS_BlueGreen_55-0) AWS Whitepaper. *Blue/Green Deployments on AWS*. https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html 56. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-Azure_Workflow_56-0) Microsoft Learn. *Manage change — track, triage, and implement change requests*. https://learn.microsoft.com/en-us/azure/devops/cross-service/manage-change 57. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-Azure_Backlog_57-0) Microsoft Learn (Azure Boards). *Backlogs overview — create and manage your product backlog*. https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/backlogs-overview 58. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-MS_Test_58-0) Microsoft Learn (Azure Test Plans). *What is Azure Test Plans?*. https://learn.microsoft.com/en-us/azure/devops/test/overview 59. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-MS_SpecFlow_59-0) MSDN Magazine. *Behavior‑Driven Design with SpecFlow*. https://learn.microsoft.com/en-us/archive/msdn-magazine/2013/july/data-points-behavior-driven-design-with-specflow 60. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-IBM_MTTR_60-0) IBM. *MTTR vs. MTBF: What’s the difference?*. https://www.ibm.com/think/topics/mttr-vs-mtbf 61. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-GCloud_Obs_61-0) Google Cloud. *Google Cloud Observability*. https://cloud.google.com/products/observability 62. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-IEEE830_62-0) IEEE Std 830‑1998. *IEEE Recommended Practice for Software Requirements Specifications* (исторический стандарт). Учебная копия (PDF): https://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf 63. ↑ ^{[63.0](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-NASA_SEH_63-0)} ^{[63.1](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-NASA_SEH_63-1)} ^{[63.2](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-NASA_SEH_63-2)} ^{[63.3](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-NASA_SEH_63-3)} NASA. *Systems Engineering Handbook (NASA/SP‑2016‑6105 Rev2)*. https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf 64. ↑ ^{[64.0](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-NASA_RM_64-0)} ^{[64.1](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-NASA_RM_64-1)} NASA (2023). *Requirements Management — traceability, baseline, CCB*. https://www.nasa.gov/reference/6-2-requirements-management/ 65. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-MoSCoW_65-0) King’s College London (.ac.uk). *What is MoSCoW prioritization?*. https://kdl.kcl.ac.uk/faqs/what-is-moscow-prioritization/ 66. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-Saaty_66-0) Saaty, T. L. (1994). *How to Make a Decision: The Analytic Hierarchy Process*. *Interfaces* 24(6), 19–43. https://doi.org/10.1287/inte.24.6.19 67. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-SEI_CMMI_67-0) SEI / CMMI Institute. *Capability Maturity Model Integration (CMMI) — Overview*. https://www.sei.cmu.edu/cmmi/ 68. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-NASA_FM_68-0) NASA Langley. *What is Formal Methods?*; NASA‑GB‑002‑95 Guidebook. https://shemesh.larc.nasa.gov/fm/fm-what.html ; https://ntrs.nasa.gov/api/citations/19980228002/downloads/19980228002.pdf 69. ↑ ^{[69.0](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-SEI_Pitfalls_69-0)} ^{[69.1](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-SEI_Pitfalls_69-1)} SEI (CMU). *Common Testing Problems: Pitfalls to Prevent and Mitigate* (о типичных проблемах требований/трассируемости). https://www.sei.cmu.edu/blog/common-testing-problems-pitfalls-to-prevent-and-mitigate/ 70. ↑ ^{[70.0](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-NIST_AI_RMF_70-0)} ^{[70.1](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-NIST_AI_RMF_70-1)} ^{[70.2](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-NIST_AI_RMF_70-2)} ^{[70.3](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-NIST_AI_RMF_70-3)} ^{[70.4](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-NIST_AI_RMF_70-4)} ^{[70.5](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-NIST_AI_RMF_70-5)} ^{[70.6](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-NIST_AI_RMF_70-6)} ^{[70.7](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-NIST_AI_RMF_70-7)} NIST (2023). *Artificial Intelligence Risk Management Framework (AI RMF 1.0)*. NIST AI 100‑1. https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf 71. ↑ ^{[71.0](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-DoD_DevSecOps_71-0)} ^{[71.1](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-DoD_DevSecOps_71-1)} ^{[71.2](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-DoD_DevSecOps_71-2)} ^{[71.3](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-DoD_DevSecOps_71-3)} ^{[71.4](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-DoD_DevSecOps_71-4)} ^{[71.5](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-DoD_DevSecOps_71-5)} U.S. DoD CIO (2021). *DoD Enterprise DevSecOps Reference Design*. https://dodcio.defense.gov/Portals/0/Documents/Library/DevSecOpsReferenceDesign.pdf 72. [↑](https://systems-analysis.info/int/Systems_analysis_in_IT_%E2%80%94_%D8%A2%D8%A6%DB%8C_%D9%B9%DB%8C_%D9%85%DB%8C%DA%BA_%D8%B3%D8%B3%D9%B9%D9%85_%D8%AA%D8%AC%D8%B2%DB%8C%DB%81#cite_ref-72) Профессиональный стандарт «Системный аналитик» (приказ Минтруда РФ от 27.04.2023 № 367н).