قالب سجل القرار من arc42

https://arc42.org/overview

1. المقدمة والأهداف

وصف موجز للمتطلبات والقوى الدافعة، ومقتطف (أو ملخص) من المتطلبات. أهم ثلاثة (خمسة كحد أقصى) أهداف جودة للبنية المعمارية لها أعلى أولوية لدى أصحاب المصلحة الرئيسيين. جدول بأصحاب المصلحة المهمين وتوقعاتهم من البنية المعمارية.

1.1 نظرة عامة على المتطلبات

المحتوى

وصف موجز للمتطلبات الوظيفية والقوى الدافعة ومقتطف (أو ملخص) من المتطلبات. روابط إلى وثائق المتطلبات (التي نأمل أن تكون موجودة)، مع بيان مكان العثور عليها.

الدافع

من وجهة نظر المستخدمين النهائيين، يُنشأ النظام أو يُعدَّل لتحسين دعم نشاط تجاري و/أو تحسين الجودة.

الشكل

وصف نصي موجز، ربما بصيغة جدولية لحالات الاستخدام. وإذا وُجدت وثائق متطلبات، فينبغي أن تحيل هذه النظرة العامة إليها.

اجعل هذه المقتطفات قصيرة قدر الإمكان. وازن بين قابلية قراءة هذه الوثيقة والتكرار المحتمل مقارنةً بوثائق المتطلبات.

1.2 أهداف الجودة

المحتوى

أهم ثلاثة (خمسة كحد أقصى) أهداف جودة للبنية المعمارية يكتسي تحقيقها أعلى أهمية لدى أصحاب المصلحة الرئيسيين. نعني فعلًا أهداف جودة للبنية المعمارية. لا تخلطها بأهداف المشروع. فهي ليست بالضرورة متطابقة. وتوفّر المعيار ISO 25010 نظرة عامة جيدة على المواضيع التي قد تهم.

الدافع

ينبغي أن تعرف أهداف الجودة لدى أهم أصحاب المصلحة لديك، لأنها ستؤثر في القرارات المعمارية الجوهرية. كن محددًا جدًا بشأن هذه الصفات، وتجنب العبارات الرنانة. فإذا كنت، بصفتك معماريًا، لا تعرف كيف ستُحكم جودة عملك …

الشكل

جدول بأهم أهداف الجودة وسيناريوهات محددة، مرتبة حسب الأولوية.

1.3 أصحاب المصلحة

المحتوى

نظرة عامة صريحة على أصحاب المصلحة في النظام، أي كل الأشخاص أو الأدوار أو المؤسسات التي

• ينبغي أن تعرف البنية المعمارية

• ينبغي إقناعها بالبنية المعمارية

• عليها العمل مع البنية المعمارية أو مع الشيفرة

• تحتاج إلى توثيق البنية المعمارية لعملها

• عليها اتخاذ قرارات بشأن النظام أو تطويره

الدافع

ينبغي أن تعرف كل الأطراف المشاركة في تطوير النظام أو المتأثرة به. وإلا فقد تواجه مفاجآت مزعجة لاحقًا في عملية التطوير. فهؤلاء الأطراف يحددون نطاق عملك ونتائجه ومستوى تفصيلها.

الشكل

جدول بأسماء الأدوار وأسماء الأشخاص وتوقعاتهم فيما يتعلق بالبنية المعمارية وتوثيقها.

2. القيود

كل ما يقيّد الفرق في قرارات التصميم والتنفيذ أو القرارات المتعلقة بالعمليات ذات الصلة. وقد يتجاوز أحيانًا الأنظمة الفردية ويسري على مؤسسات وشركات بأكملها.

المحتوى

أي متطلب يقيّد حرية المعماريين البرمجيين في قرارات التصميم والتنفيذ أو قرارات عملية التطوير. وتتجاوز هذه القيود أحيانًا الأنظمة الفردية وتسري على مؤسسات وشركات بأكملها.

الدافع

ينبغي للمعماريين أن يعرفوا بدقة أين يتمتعون بحرية في قرارات التصميم وأين يجب أن يلتزموا بالقيود. والقيود يجب التعامل معها دائمًا؛ ومع ذلك قد تكون قابلة للتفاوض.

الشكل

جداول بسيطة بالقيود مع شروح. وعند الحاجة يمكنك تقسيمها إلى قيود تقنية، وقيود تنظيمية وسياسية، واصطلاحات (مثل إرشادات البرمجة أو إدارة الإصدارات، أو اصطلاحات التوثيق أو التسمية)

3. السياق والنطاق

يحدد حدود نظامك عن شركاء الاتصال (الخارجيين) (الأنظمة المجاورة والمستخدمين). ويحدد الواجهات الخارجية. ويُعرض من منظور تجاري/مجالي (دائمًا) أو منظور تقني (اختياري)

المحتوى

نطاق النظام وسياقه، كما يوحي الاسم، يحدد حدود نظامك (أي نطاقك) عن كل شركاء الاتصال (الأنظمة المجاورة والمستخدمين، أي سياق نظامك). وبذلك يحدد الواجهات الخارجية.

عند الحاجة، ميّز السياق التجاري (المدخلات والمخرجات الخاصة بالمجال) عن السياق التقني (القنوات والبروتوكولات والعتاد).

الدافع

تُعد الواجهات المجالية والواجهات التقنية مع شركاء الاتصال من أهم جوانب نظامك. تأكد من فهمها فهمًا تامًا.

الشكل

• مخططات سياق متنوعة

• قوائم بشركاء الاتصال وواجهاتهم.

3.1 السياق التجاري

المحتوى

تحديد كل شركاء الاتصال (المستخدمين وأنظمة تقنية المعلومات، …) مع شروح للمدخلات والمخرجات أو الواجهات الخاصة بالمجال. ويمكنك اختياريًا إضافة صيغ خاصة بالمجال أو بروتوكولات اتصال.

الدافع

ينبغي أن يفهم كل أصحاب المصلحة أي بيانات تُتبادل مع بيئة النظام.

الشكل

كل أنواع المخططات التي تُظهر النظام صندوقًا أسود وتحدد الواجهات المجالية مع شركاء الاتصال.

وبدلًا من ذلك (أو إضافةً إليه) يمكنك استخدام جدول. عنوان الجدول هو اسم نظامك، وتحتوي الأعمدة الثلاثة على اسم شريك الاتصال والمدخلات والمخرجات.

3.2 السياق التقني

المحتوى

الواجهات التقنية (القنوات ووسائط النقل) التي تربط نظامك ببيئته. إضافةً إلى ربط المدخلات/المخرجات الخاصة بالمجال بالقنوات، أي شرح أي مدخل/مخرج يستخدم أي قناة.

الدافع

يتخذ كثير من أصحاب المصلحة قرارات معمارية بناءً على الواجهات التقنية بين النظام وسياقه. ولا سيما أن مصممي البنية التحتية أو العتاد هم من يقررون هذه الواجهات التقنية.

الشكل

مثلًا مخطط نشر UML يصف القنوات إلى الأنظمة المجاورة، مع جدول ربط يبيّن العلاقات بين القنوات والمدخلات/المخرجات.

4. استراتيجية الحل

ملخص للقرارات الجوهرية واستراتيجيات الحل التي تشكّل البنية المعمارية. وقد تشمل التقنية، والتفكيك على المستوى الأعلى، ونُهج تحقيق أهم أهداف الجودة، والقرارات التنظيمية ذات الصلة.

المحتوى

ملخص موجز وشرح للقرارات الجوهرية واستراتيجيات الحل التي تشكّل البنية المعمارية للنظام. وتشمل

• القرارات التقنية

• قرارات التفكيك على المستوى الأعلى للنظام، مثل استخدام نمط معماري أو نمط تصميم

• قرارات كيفية تحقيق أهداف الجودة الرئيسية

• القرارات التنظيمية ذات الصلة، مثل اختيار عملية تطوير أو إسناد مهام معينة إلى أطراف ثالثة.

الدافع

تشكّل هذه القرارات حجر الزاوية لبنيتك المعمارية. وهي الأساس لكثير من القرارات التفصيلية الأخرى أو قواعد التنفيذ.

الشكل

اجعل شرح هذه القرارات الرئيسية موجزًا.

بيّن دوافع ما قررته ولماذا قررته على هذا النحو، استنادًا إلى بيان مشكلتك وأهداف الجودة والقيود الرئيسية. وأحِل إلى التفاصيل في الأقسام التالية (القسم 5 للتفاصيل البنيوية، والقسم 8 للمفاهيم العابرة).

يمكنك استخدام قائمة بنُهج الحل أو جدول.

5. عرض لبنات البناء

التفكيك الساكن للنظام، وتجريدات للشيفرة المصدرية، تُعرض على هيئة تسلسل هرمي من الصناديق البيضاء (تحوي صناديق سوداء)، حتى مستوى التفصيل المناسب.

المحتوى

يعرض عرض لبنات البناء التفكيك الساكن للنظام إلى لبنات بناء (وحدات ومكونات وأنظمة فرعية وأصناف وواجهات وحزم ومكتبات وأطر وطبقات وأقسام ومستويات ودوال وماكرو وعمليات وبنى بيانات، …) إضافةً إلى اعتمادياتها (علاقات وارتباطات، …)

هذا العرض إلزامي في كل توثيق معماري. وبالقياس على المنزل، هو المخطط الأرضي.

الدافع

حافظ على نظرة عامة على شيفرتك المصدرية بجعل بنيتها مفهومة عبر التجريد.

يتيح لك هذا التواصل مع أصحاب المصلحة بمستوى مجرد دون الكشف عن تفاصيل التنفيذ.

الشكل

عرض لبنات البناء مجموعة هرمية من الصناديق السوداء والبيضاء (انظر الشكل أدناه) مع أوصافها.

5.1 الصندوق الأبيض للنظام الكلي

هنا تصف تفكيك النظام الكلي باستخدام قالب الصندوق الأبيض التالي. وهو يتضمن

• مخططًا عامًا

• دافعًا للتفكيك

• أوصاف الصناديق السوداء للبنات البناء المتضمَّنة. ونقدم لك لذلك بدائل:

  • استخدم جدولًا لنظرة موجزة وعملية على كل لبنات البناء المتضمَّنة وواجهاتها

  • استخدم قائمة بأوصاف الصناديق السوداء للبنات البناء وفق قالب الصندوق الأسود (انظر أدناه). وبحسب الأداة التي تختارها، قد تكون هذه القائمة فصولًا فرعية (في الملفات النصية) أو صفحات فرعية (في الويكي) أو عناصر متداخلة (في أداة نمذجة).

  • (اختياري:) واجهات مهمة لا تُشرح في قوالب الصناديق السوداء للبنة بناء، لكنها مهمة جدًا لفهم الصندوق الأبيض.

وبما أن طرق تحديد الواجهات كثيرة جدًا، فلا نقدم قالبًا محددًا لها.

وفي أفضل الأحوال يكفيك الأمثلة أو التواقيع البسيطة.

5.2 المستوى 2

هنا يمكنك تحديد البنية الداخلية لـ(بعض) لبنات البناء من المستوى 1 صناديقَ بيضاء.

عليك أن تقرر أي لبنات البناء في نظامك مهمة بما يكفي لتبرير وصف تفصيلي كهذا. فضّل الأهمية على الشمول. حدّد لبنات البناء المهمة أو المفاجئة أو الخطرة أو المعقدة أو المتقلبة. واترك الأجزاء العادية أو البسيطة أو المملة أو الموحَّدة من نظامك

5.2.1 الصندوق الأبيض للبنة البناء 1

يحدد البنية الداخلية للبنة البناء 1.

استخدم قالب الصندوق الأبيض (انظر أعلاه).

6. عرض وقت التشغيل

سلوك لبنات البناء في صورة سيناريوهات، تغطي حالات الاستخدام أو الميزات المهمة، والتفاعلات عند الواجهات الخارجية الحرجة، والتشغيل والإدارة، إضافةً إلى سلوك الأخطاء والاستثناءات.

المحتوى

يصف عرض وقت التشغيل السلوك الملموس لبنات بناء النظام وتفاعلاتها على هيئة سيناريوهات من المجالات التالية:

• حالات الاستخدام أو الميزات المهمة: كيف تنفذها لبنات البناء؟

• التفاعلات عند الواجهات الخارجية الحرجة: كيف تتعاون لبنات البناء مع المستخدمين والأنظمة المجاورة؟

• التشغيل والإدارة: الإطلاق والبدء والإيقاف

• سيناريوهات الأخطاء والاستثناءات

ملاحظة: المعيار الرئيسي لاختيار السيناريوهات الممكنة (التسلسلات وسير العمل) هو صلتها بالبنية المعمارية. وليس من المهم وصف عدد كبير من السيناريوهات. بل الأفضل توثيق مجموعة تمثيلية مختارة.

الدافع

ينبغي أن تفهم كيف تؤدي (نسخ) لبنات بناء نظامك عملها وتتواصل وقت التشغيل. وستدوّن أساسًا سيناريوهات في توثيقك لتوصيل بنيتك المعمارية إلى أصحاب المصلحة الأقل رغبة أو قدرة على قراءة النماذج الساكنة وفهمها (عرض لبنات البناء، وعرض النشر).

الشكل

توجد تدوينات كثيرة لوصف السيناريوهات، مثل

• قائمة مرقّمة بالخطوات (بلغة طبيعية)

• مخططات الأنشطة أو مخططات التدفق

• مخططات التسلسل

• BPMN أو EPC (سلاسل عمليات الأحداث)

• آلات الحالة

• إلخ.

6.n سيناريو وقت التشغيل n (1، 2، 3، إلخ)

أدرج مخطط وقت التشغيل أو وصفًا نصيًا للسيناريو.

أدرج وصفًا للجوانب اللافتة في التفاعلات بين نسخ لبنات البناء الموضحة في هذا المخطط.

7. عرض النشر

البنية التحتية التقنية بما فيها البيئات والحواسيب والمعالجات والطوبولوجيات. ربط لبنات البناء (البرمجية) بعناصر البنية التحتية.

المحتوى

يصف عرض النشر:

• البنية التحتية التقنية المستخدمة لتشغيل نظامك، بعناصر بنية تحتية مثل المواقع الجغرافية والبيئات والحواسيب والمعالجات والقنوات وطوبولوجيات الشبكة وعناصر البنية التحتية الأخرى، و

• ربط لبنات البناء (البرمجية) بعناصر البنية التحتية تلك.

كثيرًا ما تُشغَّل الأنظمة في بيئات مختلفة، مثل بيئة التطوير وبيئة الاختبار وبيئة الإنتاج. وفي هذه الحالات ينبغي أن توثّق كل البيئات ذات الصلة.

وثّق عرض النشر خصوصًا عندما يُشغَّل برنامجك نظامًا موزعًا على أكثر من حاسوب أو معالج أو خادم أو حاوية، أو عندما تصمم وتبني معالجاتك ورقائقك العتادية.

ومن منظور البرمجيات يكفي التقاط عناصر البنية التحتية اللازمة لإظهار نشر لبنات بنائك. ويمكن لمعماريي العتاد أن يتجاوزوا ذلك ويصفوا البنية التحتية بأي مستوى من التفصيل يحتاجون إلى تدوينه.

الدافع

لا تعمل البرمجيات بدون عتاد. ويمكن لهذه البنية التحتية الأساسية أن تؤثر في نظامك و/أو بعض المفاهيم العابرة، وستؤثر فيها بالفعل. ولذلك ينبغي أن تعرف البنية التحتية.

الشكل

ربما يكون مخطط النشر الأعلى مستوى موجودًا بالفعل في القسم 3.2 بوصفه السياق التقني، مع بنيتك التحتية كصندوق أسود واحد. وفي هذا القسم ستقرّب العدسة إلى هذا الصندوق الأسود باستخدام مخططات نشر إضافية.

• توفّر UML مخططات نشر للتعبير عن ذلك العرض. استخدمها، ربما مع مخططات متداخلة، عندما تكون بنيتك التحتية أكثر تعقيدًا.

• عندما يفضّل أصحاب المصلحة (العتاد) لديك أنواعًا أخرى من المخططات بدلًا من مخطط النشر في UML، فاسمح لهم باستخدام أي نوع قادر على إظهار عُقد البنية التحتية وقنواتها.

7.1 البنية التحتية، المستوى 1

صِف (عادةً بمزيج من المخططات والجداول والنص):

• توزيع نظامك على مواقع وبيئات وحواسيب ومعالجات متعددة، إلخ، والروابط المادية بينها

• المبرر أو الدافع المهم لهيكل النشر هذا

• خصائص الجودة و/أو الأداء للبنية التحتية

• ربط النواتج البرمجية (لبنات البناء) بعناصر البنية التحتية

للبيئات المتعددة أو عمليات النشر البديلة، انسخ ذلك القسم من arc42 لكل البيئات ذات الصلة. **

7.2 البنية التحتية، المستوى 2

هنا يمكنك إدراج البنية الداخلية لـ(بعض) عناصر البنية التحتية من المستوى 1 للبنية التحتية.

انسخ بنية المستوى 1 لكل عنصر مختار.

8. المفاهيم العابرة

بوجه عام، اللوائح الأساسية ونُهج الحل ذات الصلة في أجزاء متعددة (← عابرة) من النظام. وغالبًا ما ترتبط المفاهيم بلبنات بناء متعددة. ضمّن مواضيع متنوعة مثل نماذج المجال والأنماط والأساليب المعمارية وقواعد استخدام تقنية معينة وقواعد التنفيذ.

المحتوى

يصف هذا القسم المفاهيم العابرة (ممارسات وأنماطًا ولوائح أو أفكار حلول). وغالبًا ما ترتبط هذه المفاهيم بلبنات بناء متعددة. وقد تشمل مواضيع مختلفة كثيرة.

الدافع

تشكّل المفاهيم أساس السلامة المفاهيمية (الاتساق والتجانس) للبنية المعمارية. ومن ثمّ فهي إسهام مهم في تحقيق الصفات الداخلية لنظامك.

وهذا هو الموضع في القالب الذي خصصناه لمواصفات متماسكة لمثل هذه المفاهيم.

وكثير من هذه المفاهيم يرتبط بعدة من لبنات بنائك أو يؤثر فيها.

الشكل

يمكن أن يتنوع الشكل:

• أوراق مفاهيم بأي بنية

• تنفيذات نموذجية، خصوصًا للمفاهيم التقنية

• مقتطفات نماذج عابرة أو سيناريوهات باستخدام تدوينات العروض المعمارية

بنية هذا القسم

اختر فقط المواضيع الأكثر لزومًا لنظامك وخصص لكل منها عنوانًا من المستوى 2 في هذا القسم (مثل 8.1 و8.2 إلخ).

• لا تحاول تغطية كل مواضيع المخطط المذكور.

خلفية

كثيرًا ما تتعلق بعض المواضيع داخل الأنظمة بلبنات بناء أو عناصر عتاد أو عمليات تطوير متعددة. وقد يكون أسهل توصيل أو توثيق مثل هذه المواضيع العابرة في موقع مركزي، بدلًا من تكرارها في وصف لبنات البناء أو عناصر العتاد أو عمليات التطوير المعنية.

وقد تتعلق بعض المفاهيم بكل عناصر النظام، وبعضها قد يكون ذا صلة بقليل منها فقط.

9. القرارات المعمارية

قرارات معمارية مهمة أو مكلفة أو حرجة أو واسعة النطاق أو خطرة، بما فيها مبرراتها.

المحتوى

قرارات معمارية مهمة أو مكلفة أو واسعة النطاق أو خطرة، بما فيها مبرراتها. ونعني بـ«القرارات» اختيار بديل واحد بناءً على معايير معطاة.

استخدم تقديرك لتقرر هل يُوثَّق القرار المعماري هنا في هذا القسم المركزي أم يُفضَّل توثيقه محليًا (مثلًا داخل قالب الصندوق الأبيض للبنة بناء واحدة). وتجنّب النصوص المكررة. وأحِل إلى القسم 4، حيث دوّنت بالفعل أهم قرارات بنيتك المعمارية.

الدافع

ينبغي أن يتمكن أصحاب المصلحة في نظامك من فهم قراراتك وتتبّعها.

الشكل

• سجل ADR (سجل قرار البنية المعمارية) لكل قرار مهم

• قائمة أو جدول، مرتبان حسب الأهمية والعواقب، أو

• بمزيد من التفصيل في صورة أقسام منفصلة لكل قرار

خلفية (عن سجلات ADR)

قطع التوثيق الأصغر أسهل في القراءة والإنشاء والصيانة. وفيما يتعلق بالقرارات المعمارية، كثيرًا ما تكون فرق التطوير:

• على علم بالقرار، لأنه مرئي مثلًا في الشيفرة المصدرية، لكنها

• تجهل الدافع وراء ذلك القرار (انظر Nygard 2011)

ولذلك ينبغي أن توثّق بضعة قرارات مهمة مع دافعها وتعليلها

مقترحنا بشأن القرارات

احتفظ بمجموعة من القرارات ذات الأثر المعماري، وهي القرارات التي تؤثر في البنية أو خصائص الجودة أو الاعتماديات والواجهات المهمة (خصوصًا الخارجية) أو تقنيات البناء (شكرًا لـMichael Nygard على هذا المقترح).

10. متطلبات الجودة

متطلبات الجودة في صورة سيناريوهات، مع شجرة جودة لتقديم نظرة عامة رفيعة المستوى. وكان ينبغي أن تُوصف أهم أهداف الجودة في القسم 1.2 (أهداف الجودة).

المحتوى

يحتوي هذا القسم على كل متطلبات الجودة ذات الصلة.

وقد وُصف أهم هذه المتطلبات بالفعل في القسم 1.2 (أهداف الجودة)، ولذلك ينبغي أن يُشار إليها هنا فقط. وفي هذا القسم 10 ينبغي أن تدوّن أيضًا متطلبات الجودة الأقل أهمية، التي لن تخلق مخاطر عالية إن لم تتحقق بالكامل (لكنها قد تكون مستحبة).

الدافع

بما أن متطلبات الجودة سيكون لها تأثير كبير في القرارات المعمارية، فينبغي أن تعرف أي الصفات مهمة فعلًا لأصحاب المصلحة لديك، بطريقة محددة وقابلة للقياس.

مزيد من المعلومات

راجع نموذج الجودة Q42 الواسع على https://quality.arc42.org.

10.1 نظرة عامة على متطلبات الجودة

المحتوى

نظرة عامة أو ملخص لمتطلبات الجودة.

الدافع

كثيرًا ما نصادف عشرات (أو حتى مئات) من متطلبات الجودة التفصيلية. وفي قسم النظرة العامة هذا ينبغي أن تحاول التلخيص، مثلًا بوصف فئات أو مواضيع (كما يقترح ISO 25010:2023 أو Q42

وإذا كانت هذه الأوصاف الملخِّصة دقيقة ومحددة وقابلة للقياس بما يكفي، فيمكنك تخطي القسم 10.2.

الشكل

استخدم جدولًا بسيطًا يحتوي كل سطر فيه على فئة أو موضوع ووصف موجز لمتطلب الجودة. وبدلًا من ذلك، يمكنك استخدام خريطة ذهنية لهيكلة متطلبات الجودة هذه.

وفي الأدبيات وُصفت أيضًا فكرة شجرة سمات الجودة، التي تضع المصطلح العام «الجودة» جذرًا وتستخدم تدقيقًا شجريًا للمصطلح «الجودة». وقد أدخل [Bass+21] مصطلح «Quality Attribute Utility Tree» لهذا الغرض.

10.2 سيناريوهات الجودة

المحتوى

تجعل سيناريوهات الجودة متطلبات الجودة ملموسة وتتيح البت في تحققها (بمعنى معايير القبول). تأكد من أن سيناريوهاتك محددة وقابلة للقياس.

نوعان من السيناريوهات مفيدان بوجه خاص:

• تصف سيناريوهات الاستخدام (وتُسمى أيضًا سيناريوهات التطبيق أو سيناريوهات حالات الاستخدام) استجابة النظام وقت التشغيل لمحفّز معين. ويشمل ذلك السيناريوهات التي تصف كفاءة النظام أو أداءه. مثال: يستجيب النظام لطلب المستخدم خلال ثانية واحدة.

• تصف سيناريوهات التغيير الأثر المطلوب لتعديل النظام أو توسعته أو لتعديل بيئته المباشرة. مثال: تُنفَّذ وظيفة إضافية أو تتغير متطلبات سمة جودة، ويُقاس جهد التغيير أو مدته.

الشكل

تتضمن المعلومات النموذجية للسيناريوهات التفصيلية ما يلي:

بالصيغة القصيرة (المفضلة في نموذج Q42):

• السياق/الخلفية: أي نوع من النظام أو المكوّن، وما البيئة أو الحالة؟

• المصدر/المحفّز: من أو ما الذي يبدأ سلوكًا أو ردّ فعل أو إجراءً أو يطلقه.

• المقياس/معايير القبول: استجابة تتضمن قياسًا أو مقياسًا

أما الصيغة الطويلة للسيناريوهات (المفضلة لدى SEI و[Bass+21]) فهي أكثر تفصيلًا وتتضمن المعلومات التالية:

• معرّف السيناريو: معرّف فريد للسيناريو.

• اسم السيناريو: اسم موجز ووصفي للسيناريو.

• المصدر: الكيان (مستخدم أو نظام أو حدث) الذي يبدأ السيناريو.

• المحفّز: الحدث أو الشرط المُطلِق الذي يجب أن يعالجه النظام.

• البيئة: السياق التشغيلي أو الشرط الذي يواجه فيه النظام المحفّز.

• الناتج: لبنات البناء أو العناصر الأخرى من النظام المتأثرة بالمحفّز.

• الاستجابة: النتيجة أو السلوك الذي يظهره النظام ردًّا على المحفّز.

• مقياس الاستجابة: المعيار أو المقياس الذي تُقيَّم به استجابة النظام.

انظر أيضًا

منذ يناير 2023، يوفّر arc42 نموذج جودة عمليًا، يقترح وسم متطلبات الجودة بوسوم هاشتاغ أو تسميات مثل #flexible وصفات #efficient و#usable و#operable و#testable و#secure و#safe و#reliable.

11. المخاطر والدَّين التقني

المخاطر التقنية المعروفة أو الدَّين التقني المعروف. ما المشكلات المحتملة داخل النظام أو حوله؟ ما الذي يضايق فريق التطوير؟

المحتوى

قائمة بالمخاطر التقنية أو الديون التقنية المحددة، مرتبة حسب الأولوية

الدافع

«إدارة المخاطر هي إدارة المشاريع للكبار» (Tim Lister، Atlantic Systems Guild).

وينبغي أن يكون هذا شعارك في الكشف المنهجي عن المخاطر والديون التقنية في البنية المعمارية وتقييمها، وهو ما سيحتاج إليه أصحاب المصلحة الإداريون (مثل مديري المشاريع ومالكي المنتجات) ضمن تحليل المخاطر الشامل وتخطيط القياس.

الشكل

قائمة بالمخاطر و/أو الديون التقنية، تتضمن على الأرجح تدابير مقترحة لتقليل المخاطر أو تخفيفها أو تجنبها أو لتقليل الديون التقنية.