PMO-02.04 المرحلة 02: منهجية المشروع وتخصيصه
المستوى 1 ai

نموذج حالة استخدام الذكاء الاصطناعي

AI Use Case Canvas
tasleemat asset PMO-02.04 template --lang ar

ملخص التسليمة وحدود الحوكمة

المرحلة في دورة حياة المشروع

المرحلة 02: منهجية المشروع وتخصيصه

متطلبات مستوى الحجم

المستوى 1

عقد التحقق الآلي

ترتبط هذه التسليمة بمخطط JSON Schema متوافق مع معيار Draft 2020-12 لتمكين التحقق البنيوي والدلالي الآلي. 

tasleemat validate PMO-02.04 ./completed_data.json

قالب التسليمة بتنسيق Markdown

<!--
تعليمات النموذج الذكي: املأ العناصر النائبة [ أضف التفاصيل... ] بناءً على سياق المشروع.

توجيهات استيفاء الأقسام:

**١. تعريف حالة الاستخدام**
*  **اسم حالة الاستخدام:**
*  **مالك الأعمال:**
*  **بيان المشكلة:**
*  **الفئة المتأثرة:**
*  **الحل القائم:**

**٢. الحل المقترح**
*  **نمط الذكاء الاصطناعي:**
*  **وصف الحل:**
*  **الدور البشري:**
*  **حدود النطاق:**
*  **الافتراضات:**

**٣. البيانات**
*  **مصادر البيانات:**
*  **فئة البيانات وحجمها:**
*  **حالة جودة البيانات:**
*  **متطلبات التوسيم:**
*  **الاستخدام المسموح والوصول:**

**٤. القيمة والتكلفة**
*  **العرض القيمي:**
*  **منهج قياس القيمة:**
*  **المستفيدون:**
*  **كلفة التطوير:**
*  **كلفة التشغيل:**
*  **شرط تحقق القيمة:**

**٥. المخاطر والضوابط ومسار الحوكمة**
*  **المخاطر الرئيسة:**
*  **ضوابط المخاطر:**
*  **تقييم الجدوى:**
*  **مسار الحوكمة:**
*  **معايير الإيقاف:**
*  **المخرجات المرتبطة:**
-->


<h3 align="left">{{اسم_الشركة}}</h3>
<h2 align="left">{{اسم_حل_الذكاء_الاصطناعي}} - {{معرف_حالة_الاستخدام}}</h2>
 <h1 align="center">نموذج حالة استخدام الذكاء الاصطناعي</h1>

| **تاريخ الإعداد:** {{التاريخ_الحالي}} | **مالك منتج الذكاء الاصطناعي:** {{اسم_مالك_المنتج}} | **إعداد:** {{المُعِد}} |
| ---: | ---: | ---: |

---

## ١. تعريف حالة الاستخدام
<!-- ما اسم هذه الحالة وأين تقع في المحفظة، ومن يملك نتيجتها، والمشكلة بعبارة من يعانيها، ومن يطالها، وما يفعله الناس اليوم. -->

**اسم حالة الاستخدام:** [ أضف التفاصيل... ]

**مالك الأعمال:** [ أضف التفاصيل... ]

**بيان المشكلة:** [ أضف التفاصيل... ]

**الفئة المتأثرة:** [ أضف التفاصيل... ]

**الحل القائم:** [ أضف التفاصيل... ]

---

## ٢. الحل المقترح
<!-- فئة النهج، وما يفعله النظام، وما يبقى للإنسان، وما ليس مشمولًا، وما يجب أن يصح ليعمل. -->

**نمط الذكاء الاصطناعي:** [ أضف التفاصيل... ]

**وصف الحل:** [ أضف التفاصيل... ]

**الدور البشري:** [ أضف التفاصيل... ]

**حدود النطاق:** [ أضف التفاصيل... ]

**الافتراضات:** [ أضف التفاصيل... ]

---

## ٣. البيانات
<!-- صف واحد لكل مصدر: من أين يأتي، وما هو، وما معروف عن جودته، وما يتطلبه من توسيم، وما يُسمح باستعماله. -->

| مصدر البيانات | فئة البيانات وحجمها | حالة جودة البيانات | متطلبات التوسيم | الاستخدام المسموح والوصول |
| ---: | ---: | ---: | ---: | ---: |
| [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] |
| [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] |
| [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] | [ أضف التفاصيل... ] |

---

## ٤. القيمة والتكلفة
<!-- القيمة، وكيف تُقاس مقابل أي خط أساس، ومن يستفيد ومن يتحمل الكلفة، وكلفة التطوير مفصولة عن كلفة التشغيل. -->

**العرض القيمي:** [ أضف التفاصيل... ]

**منهج قياس القيمة:** [ أضف التفاصيل... ]

**المستفيدون:** [ أضف التفاصيل... ]

**كلفة التطوير:** [ أضف التفاصيل... ]

**كلفة التشغيل:** [ أضف التفاصيل... ]

**شرط تحقق القيمة:** [ أضف التفاصيل... ]

---

## ٥. المخاطر والضوابط ومسار الحوكمة
<!-- المخاطر الخاصة بهذه الحالة وما تنجر عنه، وما تغطيه الضوابط وما لا تغطيه، والجدوى، وترتيب مسارات الحوكمة، وما يوقف العمل. -->

**المخاطر الرئيسة:** [ أضف التفاصيل... ]

**ضوابط المخاطر:** [ أضف التفاصيل... ]

**تقييم الجدوى:** [ أضف التفاصيل... ]

**مسار الحوكمة:** [ أضف التفاصيل... ]

**معايير الإيقاف:** [ أضف التفاصيل... ]

**المخرجات المرتبطة:** [ أضف التفاصيل... ]

---

### الاعتماد والموافقات

| الدور | الاسم | التوقيع | التاريخ |
| ---: | ---: | ---: | ---: |
| **مالك المنتج / الأعمال** | {{اسم_مالك_الأعمال}} | _______________________ | [.... -.... -.... ] |
| **المسؤول التقني للذكاء الاصطناعي** | {{اسم_مسؤول_الذكاء_الاصطناعي}} | _______________________ | [.... -.... -.... ] |
| **راعي المشروع** | {{اسم_راعي_المشروع}} | _______________________ | [.... -.... -.... ] |
---


<div align="left" style="margin-top: 20px; font-size: 12px; color: #7f8c8d;">
  <span>سجل التدقيق الإلكتروني: Hash SHA256: {{رمز_تجزئة_التدقيق_SHA256}}</span> <br>
 <strong>النموذج:</strong> نموذج حالة استخدام الذكاء الاصطناعي | <strong>المرجع:</strong> PMO-02.04 <br>
 <i>تاريخ الإنشاء: {{وقت_الإنشاء}}، بواسطة <a href="https://github.com/fakhruldeen/Tasleemat/" style="color: #7f8c8d;">تسليمات</a></i>
</div>

دليل المستخدم وإرشادات الممارس

دليل نماذج تسليمات

المخرج: نموذج حالة استخدام الذكاء الاصطناعي

مرجع الوثيقة: PMO-02.03

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

1. مفهوم الوثيقة وطبيعتها

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

2. القيمة والأهمية الاستراتيجية

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

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

3. التوقيت ودواعي الإعداد والتحديث

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

4. الأدوار والمسؤوليات (RACI)

المسؤوليات: يملكه مالك الأعمال، ويجب أن يستطيع وصف الغرض من النظام دون الإشارة إلى النموذج؛ والمالك الذي يصف التقنية لم يُحدَّد بعد. ويُستكمل مع مسؤول الذكاء الاصطناعي أو تعلّم الآلة، المسؤول عن بيان الجدوى وعن تسمية الجزء غير المُثبت منها، ومع مسؤول حماية البيانات، المسؤول عن خانة الاستخدام المسموح والوصول. يراجعه مدير المشروع في ضوء دراسة الجدوى، ويعتمده راعي المشروع، وهو الشخص الذي ستُطبَّق عليه معايير الإيقاف بعد ذلك.

إرشادات التخصيص والمواءمة

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

المحاذاة والترابط المؤسسي

ينبغي أن يتسق نموذج حالة استخدام الذكاء الاصطناعي مع المستندات التالية: * دراسة الجدوى * خطة حوكمة الذكاء الاصطناعي * بطاقة نموذج الذكاء الاصطناعي * تقييم خصوصية البيانات وأخلاقياتها

5. إرشادات تعبئة الحقول والبيانات

لإتمام نموذج حالة استخدام الذكاء الاصطناعي بدقّة واحتراف، على المسؤول تعبئة الأقسام التالية استنادًا إلى سياق المشروع (مع التأكد من الرجوع إلى parameters.md للمتغيرات العامة للمشروع):

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

المحاذاة والترابط المؤسسي

6. نموذج تطبيقي معبأ (مثال استرشادي)

يتوفر نموذج تطبيقي مكتمل وعالي الجودة يوضح كيفية تعبئة واستخدام هذا المستند عملياً:

📖 النموذج التطبيقي المكتمل: 02_04_نموذج_حالة_استخدام_الذكاء_الاصطناعي_مثال.md

مطالبة التوليد للذكاء الاصطناعي وتعليمات الوكيل

نموذج حالة استخدام الذكاء الاصطناعي - دليل التوليد الذكي

تعليمات النظام: يحتوي هذا المستند على التوجيهات التفصيلية للذكاء الاصطناعي لتوليد وثيقة «الوثيقة المعتمدة». عند طلب صياغة أو استيفاء هذا النموذج، اتبع الإرشادات المحددة لكل قسم بدقة واحترافية، مع مراعاة سياق المشروع والمتغيرات المرجعية في parameters.md.

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

والأقسام الخمسة تتبع ترتيب ما يسأل عنه المراجع. التعريف يسمّي الحالة ومالك الأعمال والمشكلة بعبارة من يعانيها والفئة التي يطالها وما يفعله الناس اليوم. وآخر خانة فيه هي خط الأساس: فحل قائم بلا كلفة معلنة لا يمكن هزيمته، وأي مقترح يُقاس على بديل غير مسجَّل هو مقاس على لا شيء. قسم الحل يذكر فئة النهج وما يفعله النظام بعبارة يفهمها من ليس متخصصًا، وما يبقى للإنسان، وما هو مستثنى، وما يجب أن يصح ليعمل. قسم البيانات يسجّل كل مصدر باسمه ومالكه، لأن المصدر الموصوف بأنه «بيانات تاريخية» لا يمكن التحقق من الإذن عليه، والإذن هو أول ما يعطّل. القسم الرابع يبقى كلفة التطوير منفصلة عن كلفة التشغيل، ويذكر القيمة مقابل خط أساس لا كرقم عائد، ويفصل شرط تحقق القيمة عن شرط بناء النظام، إذ أكثر الأنظمة يُبنى بنجاح ولا تحقق شيئًا. والقسم الأخير يرتّب المخاطر الخاصة بهذه الحالة، ويقول ما لا تغطيه الضوابط، ويذكر أي جزء من الجدوى غير مُثبت، ويسرد مسارات الحوكمة بالترتيب، ويسجّل معايير الإيقاف.

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

المحاذاة وسلسلة الاعتماديات: * المدخلات (المتطلبات السابقة): * إلزامي: تقييم جاهزية الذكاء الاصطناعي (PMO-02.03)، دراسة الجدوى وحالة الأعمال (PMO-01.01) * اختياري: رؤية المنتج (PMO-03.02)، تحليل المعنيين (PMO-03.05) * المخرجات (النماذج التابعة): * إلزامي: ميثاق المشروع (PMO-03.01)، خطة حوكمة الذكاء الاصطناعي (PMO-02.02)، وثائق المتطلبات (PMO-04.02.03) * اختياري: نموذج تخطيط قصص المستخدم (PMO-04.02.09)، بطاقة نموذج الذكاء الاصطناعي (PMO-02.05)

١. تعريف حالة الاستخدام

اسم حالة الاستخدام

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

القيمة المولَّدة: [ أضف التفاصيل... ]

مالك الأعمال

التعليمات: الشخص المسؤول عن النتيجة، ويجب أن يستطيع وصف الغرض من النظام دون الإشارة إلى النموذج. والمالك الذي يصف التقنية لم يُحدَّد بعد.

القيمة المولَّدة: [ أضف التفاصيل... ]

بيان المشكلة

التعليمات: المشكلة المحددة، بعبارة من يعانيها، مع كلفة تركها بلا حل. و«تحسين الكفاءة» هدف، أما «أخصائي يقضي أربعين دقيقة يوميًا في تسوية ثلاث جداول بيانات» فمشكلة يمكن قياس حجمها والتحقق منها لاحقًا.

القيمة المولَّدة: [ أضف التفاصيل... ]

الفئة المتأثرة

التعليمات: من يعيش المشكلة، وكم عددهم، وكم مرة تتكرر. والفئة هي ما يحوّل الإزعاج إلى كلفة، وهي أيضًا الفئة التي سيخضع النظام.

القيمة المولَّدة: [ أضف التفاصيل... ]

الحل القائم

التعليمات: ما يفعله الناس اليوم، وما يكلّفهم. والحل القائم بلا كلفة معلنة لا يمكن هزيمته، فخط الأساس هنا هو ما يُقاس عليه كل مقترح.

القيمة المولَّدة: [ أضف التفاصيل... ]

٢. الحل المقترح

نمط الذكاء الاصطناعي

التعليمات: فئة النهج، وما يجعله ملائمًا لهذه المشكلة لا لجارتها. فالتصنيف والترتيب والتوليد والتنبؤ وكشف الشذوذ تخفق بطرق مختلفة، وتسمية النمط هي ما يتيح توقع أوجه الفشل.

القيمة المولَّدة: [ أضف التفاصيل... ]

وصف الحل

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

القيمة المولَّدة: [ أضف التفاصيل... ]

الدور البشري

التعليمات: ما يبقى الإنسان يفعله، وعند أي نقاط يستطيع إيقاف النظام. والنظام الموصوف بأنه يساعد يستبدل شيئًا في الغالب، والمستبدل ينبغي أن يُسمّى كي يظهر التغيير لمن يتأثر به.

القيمة المولَّدة: [ أضف التفاصيل... ]

حدود النطاق

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

القيمة المولَّدة: [ أضف التفاصيل... ]

الافتراضات

التعليمات: ما يجب أن يصح ليعمل الحل، وما يحدث إن لم يصح كل منها. الافتراضات المسجَّلة بعد البناء سجل لما اعتُقد لا لما افتُرض.

القيمة المولَّدة: [ أضف التفاصيل... ]

٣. البيانات

مصادر البيانات

التعليمات: من أين تأتي كل المدخلات، مذكورةً بأسماء الأنظمة والمجموعات التي تملكها.

القيمة المولَّدة: [ أضف التفاصيل... ]

فئة البيانات وحجمها

التعليمات: أي بيانات هذه، بالحجم والتواتر. والتواتر هو الحقل الذي يُهمل أكثر من غيره، وهو الذي يحدد ما إذا كان النظام يُعاد تدريبه أم يُحدَّث أم يُترك ينحرف.

القيمة المولَّدة: [ أضف التفاصيل... ]

حالة جودة البيانات

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

القيمة المولَّدة: [ أضف التفاصيل... ]

متطلبات التوسيم

التعليمات: هل توجد أمثلة موسومة، ومن ينتجها، وبكم تكلّف. وهذا في الغالب أكبر بند مفرد في دراسة الجدوى، وهو الغائب عنها في الغالب.

القيمة المولَّدة: [ أضف التفاصيل... ]

الاستخدام المسموح والوصول

التعليمات: ما يجوز استعمال البيانات لأجله في هذه الحالة، ومن يوافق عليه. وحيث لا يجوز استعمال البيانات في تدريب النموذج، يتغير شكل الحل، وذلك خير أن يُعرف قبله لا بعده.

القيمة المولَّدة: [ أضف التفاصيل... ]

٤. القيمة والتكلفة

العرض القيمي

التعليمات: ما الذي يتغير ولمن، معبَّرًا عنه كتغيير في العملية لا كرقم عائد. والعائد المحسوب قبل كلفة التشغيل رقم لا يصمد أمام أي مراجعة.

القيمة المولَّدة: [ أضف التفاصيل... ]

منهج قياس القيمة

التعليمات: كيف تُقاس القيمة، مقابل أي خط أساس، ومن يقوم بذلك. والقيمة بلا خط أساس دعوى، وخط الأساس مسجَّل عادة في كلفة الحل القائم أعلاه.

القيمة المولَّدة: [ أضف التفاصيل... ]

المستفيدون

التعليمات: من يستفيد، ومن يتحمل كلفة التغيير. وهما في الغالب ليسا الشخصين الأشخاص نفسيهم، وهذا النموذج هو المكان الذي تصبح فيه الفئة الثانية مرئية.

القيمة المولَّدة: [ أضف التفاصيل... ]

كلفة التطوير

التعليمات: كم ستكلّف العملية، وما الذي يشمله. والكلفة المستثناة هي كلفة التشغيل أدناه، وذكر الاستثناء هو ما يُبقي المجموع صادقًا.

القيمة المولَّدة: [ أضف التفاصيل... ]

كلفة التشغيل

التعليمات: كم ستكلّف كل وحدة عمل، وعند أي حجم. الكلفة لكل وحدة لا الإجمالي، لأن الإجمالي يتناسب مع الحجم وسؤال الجدوى يُطرح لكل وحدة.

القيمة المولَّدة: [ أضف التفاصيل... ]

شرط تحقق القيمة

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

القيمة المولَّدة: [ أضف التفاصيل... ]

٥. المخاطر والضوابط ومسار الحوكمة

المخاطر الرئيسة

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

القيمة المولَّدة: [ أضف التفاصيل... ]

ضوابط المخاطر

التعليمات: ما هو قائم لكل خطر، وما لا يغطيه. النصف الثاني هو النصف المفيد، والضابط الذي يغطي كل شيء هو ضابط وُصف ولم يُصمَّم.

القيمة المولَّدة: [ أضف التفاصيل... ]

تقييم الجدوى

التعليمات: هل هذا تكنولوجياً، مكنة ممكن، عند أي نضج، وما غير مُثبت. وبيان جدوى لا يقول أي جزء غير مُثبت هو بيان بأن كله مُثبت.

القيمة المولَّدة: [ أضف التفاصيل... ]

مسار الحوكمة

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

القيمة المولَّدة: [ أضف التفاصيل... ]

معايير الإيقاف

التعليمات: أي نتيجة تُوقف هذا الاستخدام. والاستخدام الذي لا معايير إيقاف له التزام، والالتزام الذي يدخل بلا شرط خروج هو نمط الفشل الذي وُجد هذا الحقل لمنعه.

القيمة المولَّدة: [ أضف التفاصيل... ]

المخرجات المرتبطة

التعليمات: دراسة الجدوى، وخطة الحوكمة، وبطاقة النموذج، وتقييم الخصوصية الخاصة بهذه الحالة، ليجد القارئ والحامل للوحة القرارات المعتمدة عليها.

القيمة المولَّدة: [ أضف التفاصيل... ]

PMO-02.04 المرحلة 02: منهجية المشروع وتخصيصه دراسة حالة واقعية مكتملة
تاريخ الإعداد
2026-03-15
مالك منتج الذكاء الاصطناعي
أ. مريم الخطيب (كبير ملاك المنتجات)
إعداد
م. فيصل الحربي، PMP (مدير المشروع)

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

🏆 نموذج استرشادي مكتمل (Gold Standard): يوضح هذا المستند التطبيق العملي المتكامل لهذا النموذج وفق معايير تسليمات (PMO-02.04). كافة الأسماء والبيانات الواردة هي لأغراض العرض التوضيحي والمحاكاة المؤسسية الفرضية.

شركة القمة للحلول المؤسسية المتقدمة

المساعد المعرفي الذكي لمؤسسة القمة - UC-AI-2026-04

نموذج حالة استخدام الذكاء الاصطناعي

١. تعريف حالة الاستخدام

اسم حالة الاستخدام: الإصدار 1.0 (معتمد رسمياً)

مالك الأعمال: أ. إلينا فانس، PfMP (مدير المحفظة والتحول المؤسسي)

بيان المشكلة: تشتت البيانات عبر أنظمة قديمة معزولة يؤدي إلى بطء معالجة الطلبات وارتفاع تكاليف التشغيل

الفئة المتأثرة: تم تحديده وتوثيقه بالتفصيل ليتوافق مع أهداف المشروع والمتطلبات التشغيلية لشركة القمة.

الحل القائم: تم تحديده وتوثيقه بالتفصيل ليتوافق مع أهداف المشروع والمتطلبات التشغيلية لشركة القمة.

٢. الحل المقترح

نمط الذكاء الاصطناعي: نموذج لغوي كبير مدعوم بالتوليد المعزز بالاسترجاع (RAG) لتحليل البيانات المؤسسية

وصف الحل: نشر منظومة سحابية متكاملة مدعومة بمحرك ذكاء اصطناعي لمعالجة البيانات والربط اللحظي بين الفروع

الدور البشري: مراجعة واعتماد بشري إلزامي من قِبل مدراء القطاعات المعنية لكافة العمليات الاستثنائية وذات الأثر المالي.

حدود النطاق: المقرات الرئيسية والفروع ومراكز التوزيع؛ يستثنى نقاط البيع الطرفية القديمة.

الافتراضات: تم تحديده وتوثيقه بالتفصيل ليتوافق مع أهداف المشروع والمتطلبات التشغيلية لشركة القمة.

٣. البيانات

مصدر البيانات فئة البيانات وحجمها حالة جودة البيانات متطلبات التوسيم الاستخدام المسموح والوصول
نشر وتجهيز البنية السحابية وقواعد البيانات الموحدة نشر وتجهيز البنية السحابية وقواعد البيانات الموحدة نشر وتجهيز البنية السحابية وقواعد البيانات الموحدة معتمد ومطابق للمعايير القياسية لشركة القمة معتمد ومطابق للمعايير القياسية لشركة القمة
أتمتة دورة المشتريات والمستودعات والربط المباشر أتمتة دورة المشتريات والمستودعات والربط المباشر أتمتة دورة المشتريات والمستودعات والربط المباشر معتمد ومطابق للمعايير القياسية لشركة القمة معتمد ومطابق للمعايير القياسية لشركة القمة
بناء لوحات المؤشرات التفاعلية والتحليلات المتقدمة بناء لوحات المؤشرات التفاعلية والتحليلات المتقدمة بناء لوحات المؤشرات التفاعلية والتحليلات المتقدمة معتمد ومطابق للمعايير القياسية لشركة القمة معتمد ومطابق للمعايير القياسية لشركة القمة

٤. القيمة والتكلفة

العرض القيمي: تم تحديده وتوثيقه بالتفصيل ليتوافق مع أهداف المشروع والمتطلبات التشغيلية لشركة القمة.

منهج قياس القيمة: احتساب صافي القيمة الحالية (NPV)، فترة استرداد رأس المال (Payback Period)، ومعدل العائد الداخلي (IRR).

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

كلفة التطوير: 5,200,000 ريال سعودي موزعة على خدمات الاستشارات والهندسة والتهيئة.

كلفة التشغيل: 1,200,000 ريال سعودي سنوياً لاشتراكات السحابة والدعم الفني المتقدم.

شرط تحقق القيمة: تم تحديده وتوثيقه بالتفصيل ليتوافق مع أهداف المشروع والمتطلبات التشغيلية لشركة القمة.

٥. المخاطر والضوابط ومسار الحوكمة

المخاطر الرئيسة: تم تحديده وتوثيقه بالتفصيل ليتوافق مع أهداف المشروع والمتطلبات التشغيلية لشركة القمة.

ضوابط المخاطر: تم تحديده وتوثيقه بالتفصيل ليتوافق مع أهداف المشروع والمتطلبات التشغيلية لشركة القمة.

تقييم الجدوى: جدوى فنية واقتصادية عالية بمعدل عائد داخلي (IRR) يبلغ 28% وفترة استرداد 2.2 سنة.

مسار الحوكمة: مراجعة واعتماد بشري إلزامي من قِبل مدراء القطاعات المعنية لكافة العمليات الاستثنائية وذات الأثر المالي.

معايير الإيقاف: تجاوز التكاليف للحد الأقصى المعتمد بنسبة 20% دون جدوى واضحة، أو فشل معايير الأمان السيبراني الحرجة.

المخرجات المرتبطة: مستودع النماذج السحابي الآمن (Model Registry Artifacts v2.4)

الاعتماد والموافقات

الدور الاسم التوقيع التاريخ
مالك المنتج / الأعمال أ. سلطان الدوسري (نائب الرئيس للعمليات) [معتمد إلكترونياً] 2026-03-18
المسؤول التقني للذكاء الاصطناعي د. ريان السليمان (رئيس فريق الذكاء الاصطناعي) [معتمد إلكترونياً] 2026-03-18
راعي المشروع د. منى الغامدي (نائب الرئيس لتقنية المعلومات) [معتمد إلكترونياً] 2026-03-18
---
النموذج: نموذج حالة استخدام الذكاء الاصطناعي | المرجع: PMO-02.04
تاريخ الإنشاء: 2026-03-15 10:00 بتوقيت مكة المكرمة، بواسطة تسليمات

مخطط JSON Schema (معيار Draft 2020-12)

العقد الرقمي المعياري لتمكين التحقق الآلي من بيانات التسليمة بواسطة أداة tasleemat. 
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://tasleemat.pmo/schemas/completed/PMO-02.04.schema.json",
  "title": "Completed AI Use Case Canvas Data Contract",
  "description": "Additive structural schema validating completed AI Use Case Canvas artifact data payloads (PMO-02.04).",
  "type": "object",
  "properties": {
    "artifact_id": {
      "type": "string",
      "const": "PMO-02.04"
    },
    "metadata": {
      "type": "object",
      "properties": {
        "project_name": {
          "type": "string",
          "minLength": 1
        },
        "project_code": {
          "type": "string"
        },
        "date_prepared": {
          "type": "string",
          "format": "date"
        },
        "project_manager": {
          "type": "string",
          "minLength": 1
        },
        "prepared_by": {
          "type": "string",
          "minLength": 1
        },
        "version": {
          "type": "string"
        },
        "status": {
          "type": "string",
          "enum": [
            "draft",
            "baselined",
            "in_review",
            "approved"
          ]
        }
      },
      "required": [
        "project_name",
        "date_prepared",
        "project_manager",
        "prepared_by"
      ]
    },
    "use_case_identification": {
      "type": "object",
      "properties": {
        "use_case_name": {
          "type": "string",
          "minLength": 1,
          "description": "What this use case is called, and where it sits in the portfolio. Naming it makes it possible to say that a later system is the same use case grown, which is usually the difference between a second business case and a repeat of the first."
        },
        "business_owner": {
          "type": "string",
          "minLength": 1,
          "description": "The person accountable for the outcome, who must be able to say what the system is for without reference to the model. An owner who describes the technology has not been identified."
        },
        "problem_statement": {
          "type": "string",
          "minLength": 1,
          "description": "The specific problem, in the words of the person who has it, with the cost of leaving it unsolved. \"Improve efficiency\" is a goal; \"a specialist spends forty minutes a day reconciling three spreadsheets\" is a problem that can be sized and later checked."
        },
        "affected_population": {
          "type": "string",
          "minLength": 1,
          "description": "Who experiences the problem, how many, and how often. The population is what converts an annoyance into a cost, and it is also the population the system will act upon."
        },
        "current_workaround": {
          "type": "string",
          "minLength": 1,
          "description": "What people do today, and what it costs them. A workaround with no stated cost cannot be beaten, so the baseline here is what any proposal is measured against."
        }
      },
      "required": [
        "use_case_name",
        "business_owner",
        "problem_statement",
        "affected_population",
        "current_workaround"
      ]
    },
    "proposed_solution": {
      "type": "object",
      "properties": {
        "ai_pattern": {
          "type": "string",
          "minLength": 1,
          "description": "The class of approach, and what makes it fit this problem rather than a neighbouring one. Classification, ranking, generation, forecasting and anomaly detection fail differently, and naming the pattern is what lets the failure modes be anticipated."
        },
        "solution_description": {
          "type": "string",
          "minLength": 1,
          "description": "What the system does, in one paragraph a non-specialist can check. If the description requires the model architecture to be understood, the description is not yet a description."
        },
        "human_role": {
          "type": "string",
          "minLength": 1,
          "description": "What a person still does, and at which points they can stop the system. A system described as assisting usually replaces something, and the thing replaced should be named so the change is visible to those affected."
        },
        "scope_boundary": {
          "type": "string",
          "minLength": 1,
          "description": "What this use case explicitly does not include. Scope stated only as a positive is unbounded, and an unbounded use case absorbs its neighbours' costs."
        },
        "assumptions": {
          "type": "string",
          "minLength": 1,
          "description": "What must be true for the solution to work, and what happens if each is not. Assumptions recorded after the build are records of what was believed, not of what was assumed."
        }
      },
      "required": [
        "ai_pattern",
        "solution_description",
        "human_role",
        "scope_boundary",
        "assumptions"
      ]
    },
    "data": {
      "type": "object",
      "properties": {
        "data_sources": {
          "type": "string",
          "minLength": 1,
          "description": "Where each input comes from, as a named system or collection with an owner. A source named only as \"historical data\" cannot be checked for permission, and permission is the first thing that blocks."
        },
        "data_category_and_volume": {
          "type": "string",
          "minLength": 1,
          "description": "What kind of data, at what volume and frequency. Frequency is the field most often omitted and the one that determines whether the system is retrained, refreshed or left to drift."
        },
        "data_quality_status": {
          "type": "string",
          "minLength": 1,
          "description": "What is known about completeness, consistency and timeliness, and what has not been checked. Recording what was not checked is as useful as recording what was, because it bounds the confidence of the estimate."
        },
        "labelling_requirement": {
          "type": "string",
          "minLength": 1,
          "description": "Whether labelled examples exist, who will produce them, and at what cost. This is usually the largest single line in the business case, and it is usually absent from it."
        },
        "permitted_use_and_access": {
          "type": "string",
          "minLength": 1,
          "description": "What the data may be used for within this use case, and who approves it. Where the data cannot be used for model training, the shape of the solution changes, and that is better known before than after."
        }
      },
      "required": [
        "data_sources",
        "data_category_and_volume",
        "data_quality_status",
        "labelling_requirement",
        "permitted_use_and_access"
      ]
    },
    "value_and_cost": {
      "type": "object",
      "properties": {
        "value_proposition": {
          "type": "string",
          "minLength": 1,
          "description": "What changes for whom, expressed as a change in the process rather than a return figure. A return calculated before the operating cost is a number that survives no review."
        },
        "value_measurement_method": {
          "type": "string",
          "minLength": 1,
          "description": "How the value will be measured, against what baseline, and by whom. Value stated without a baseline is a claim, and the baseline is usually already recorded in the current-workaround cost above."
        },
        "beneficiaries": {
          "type": "string",
          "minLength": 1,
          "description": "Who gains, and who bears the cost of the change. These are rarely the same people, and the form is the place where the second group becomes visible."
        },
        "build_cost": {
          "type": "string",
          "minLength": 1,
          "description": "What it will cost to build, and what is included. The cost that is excluded is the operating cost below, and stating the exclusion is what keeps the total honest."
        },
        "operating_cost": {
          "type": "string",
          "minLength": 1,
          "description": "What it will cost to run per unit of work, and at what volume. Cost per unit rather than total, because the total scales with volume and the viability question is asked per unit."
        },
        "value_realisation_condition": {
          "type": "string",
          "minLength": 1,
          "description": "What must be true for the value to be realised, as distinct from for the system to be built. Most systems are built successfully and deliver nothing, and the difference is nearly always one of these conditions."
        }
      },
      "required": [
        "value_proposition",
        "value_measurement_method",
        "beneficiaries",
        "build_cost",
        "operating_cost",
        "value_realisation_condition"
      ]
    },
    "risks_controls_and_governance_route": {
      "type": "object",
      "properties": {
        "key_risks": {
          "type": "string",
          "minLength": 1,
          "description": "The risks specific to this use case, ranked, with the consequence if each materialises. A generic risk register applied here records that data may be biased without saying for whom or how it would be detected."
        },
        "risk_controls": {
          "type": "string",
          "minLength": 1,
          "description": "What is in place for each risk, and what it does not cover. The second half is the useful half, and a control that covers everything is a control that has been described rather than designed."
        },
        "feasibility_assessment": {
          "type": "string",
          "minLength": 1,
          "description": "Whether this is technically feasible, at what maturity, and what is unproven. A feasibility statement that does not say which part is unproven is a statement that all of it is proven."
        },
        "governance_route": {
          "type": "string",
          "minLength": 1,
          "description": "Which governance artefacts this use case must pass through, and in what order. The order is the content: privacy, then fairness, then approval, because a system approved before its data is assessed cannot be un-approved."
        },
        "kill_criteria": {
          "type": "string",
          "minLength": 1,
          "description": "What result would cause this use case to be stopped. A use case with no kill criteria is a commitment, and a commitment entered without an exit condition is the failure mode this field exists to prevent."
        },
        "related_artefacts": {
          "type": "string",
          "minLength": 1,
          "description": "The business case, AI governance plan, model card and privacy assessment for this use case, so that a reader holding the canvas can find the decisions that depend on it."
        }
      },
      "required": [
        "key_risks",
        "risk_controls",
        "feasibility_assessment",
        "governance_route",
        "kill_criteria",
        "related_artefacts"
      ]
    }
  },
  "required": [
    "artifact_id",
    "metadata",
    "use_case_identification",
    "proposed_solution",
    "data",
    "value_and_cost",
    "risks_controls_and_governance_route"
  ]
}
📋 قاموس تعريفات حقول النموذج (المواصفة التفصيلية) 
{
  "_llm_instructions": "Fill out the 'project_title' and 'date_prepared' properties, and the 'value' property of each field below, based on the available project context. Refer to parameters.md for the shared project variables. Name the model version, the group affected, and the threshold that triggers action, rather than recording a category; a governance plan that says 'encrypted', 'minimised' and 'monitored' describes an intention and not a system, and the difference only becomes visible when something goes wrong and no one can say what was in force.",
  "form_name": "AI Use Case Canvas",
  "document_reference": "PMO-02.04",
  "project_title": "",
  "date_prepared": "",
  "fields": {
    "f01_Use_Case_Name": {
      "section": "Use Case Identification",
      "label": "Use Case Name",
      "guidance": "What this use case is called, and where it sits in the portfolio. Naming it makes it possible to say that a later system is the same use case grown, which is usually the difference between a second business case and a repeat of the first.",
      "value": ""
    },
    "f02_Business_Owner": {
      "section": "Use Case Identification",
      "label": "Business Owner",
      "guidance": "The person accountable for the outcome, who must be able to say what the system is for without reference to the model. An owner who describes the technology has not been identified.",
      "value": ""
    },
    "f03_Problem_Statement": {
      "section": "Use Case Identification",
      "label": "Problem Statement",
      "guidance": "The specific problem, in the words of the person who has it, with the cost of leaving it unsolved. \"Improve efficiency\" is a goal; \"a specialist spends forty minutes a day reconciling three spreadsheets\" is a problem that can be sized and later checked.",
      "value": ""
    },
    "f04_Affected_Population": {
      "section": "Use Case Identification",
      "label": "Affected Population",
      "guidance": "Who experiences the problem, how many, and how often. The population is what converts an annoyance into a cost, and it is also the population the system will act upon.",
      "value": ""
    },
    "f05_Current_Workaround": {
      "section": "Use Case Identification",
      "label": "Current Workaround",
      "guidance": "What people do today, and what it costs them. A workaround with no stated cost cannot be beaten, so the baseline here is what any proposal is measured against.",
      "value": ""
    },
    "f06_AI_Pattern": {
      "section": "Proposed Solution",
      "label": "AI Pattern",
      "guidance": "The class of approach, and what makes it fit this problem rather than a neighbouring one. Classification, ranking, generation, forecasting and anomaly detection fail differently, and naming the pattern is what lets the failure modes be anticipated.",
      "value": ""
    },
    "f07_Solution_Description": {
      "section": "Proposed Solution",
      "label": "Solution Description",
      "guidance": "What the system does, in one paragraph a non-specialist can check. If the description requires the model architecture to be understood, the description is not yet a description.",
      "value": ""
    },
    "f08_Human_Role": {
      "section": "Proposed Solution",
      "label": "Human Role",
      "guidance": "What a person still does, and at which points they can stop the system. A system described as assisting usually replaces something, and the thing replaced should be named so the change is visible to those affected.",
      "value": ""
    },
    "f09_Scope_Boundary": {
      "section": "Proposed Solution",
      "label": "Scope Boundary",
      "guidance": "What this use case explicitly does not include. Scope stated only as a positive is unbounded, and an unbounded use case absorbs its neighbours' costs.",
      "value": ""
    },
    "f10_Assumptions": {
      "section": "Proposed Solution",
      "label": "Assumptions",
      "guidance": "What must be true for the solution to work, and what happens if each is not. Assumptions recorded after the build are records of what was believed, not of what was assumed.",
      "value": ""
    },
    "f11_Data_Sources": {
      "section": "Data",
      "label": "Data Sources",
      "guidance": "Where each input comes from, as a named system or collection with an owner. A source named only as \"historical data\" cannot be checked for permission, and permission is the first thing that blocks.",
      "value": ""
    },
    "f12_Data_Category_and_Volume": {
      "section": "Data",
      "label": "Data Category and Volume",
      "guidance": "What kind of data, at what volume and frequency. Frequency is the field most often omitted and the one that determines whether the system is retrained, refreshed or left to drift.",
      "value": ""
    },
    "f13_Data_Quality_Status": {
      "section": "Data",
      "label": "Data Quality Status",
      "guidance": "What is known about completeness, consistency and timeliness, and what has not been checked. Recording what was not checked is as useful as recording what was, because it bounds the confidence of the estimate.",
      "value": ""
    },
    "f14_Labelling_Requirement": {
      "section": "Data",
      "label": "Labelling Requirement",
      "guidance": "Whether labelled examples exist, who will produce them, and at what cost. This is usually the largest single line in the business case, and it is usually absent from it.",
      "value": ""
    },
    "f15_Permitted_Use_and_Access": {
      "section": "Data",
      "label": "Permitted Use and Access",
      "guidance": "What the data may be used for within this use case, and who approves it. Where the data cannot be used for model training, the shape of the solution changes, and that is better known before than after.",
      "value": ""
    },
    "f16_Value_Proposition": {
      "section": "Value and Cost",
      "label": "Value Proposition",
      "guidance": "What changes for whom, expressed as a change in the process rather than a return figure. A return calculated before the operating cost is a number that survives no review.",
      "value": ""
    },
    "f17_Value_Measurement_Method": {
      "section": "Value and Cost",
      "label": "Value Measurement Method",
      "guidance": "How the value will be measured, against what baseline, and by whom. Value stated without a baseline is a claim, and the baseline is usually already recorded in the current-workaround cost above.",
      "value": ""
    },
    "f18_Beneficiaries": {
      "section": "Value and Cost",
      "label": "Beneficiaries",
      "guidance": "Who gains, and who bears the cost of the change. These are rarely the same people, and the form is the place where the second group becomes visible.",
      "value": ""
    },
    "f19_Build_Cost": {
      "section": "Value and Cost",
      "label": "Build Cost",
      "guidance": "What it will cost to build, and what is included. The cost that is excluded is the operating cost below, and stating the exclusion is what keeps the total honest.",
      "value": ""
    },
    "f20_Operating_Cost": {
      "section": "Value and Cost",
      "label": "Operating Cost",
      "guidance": "What it will cost to run per unit of work, and at what volume. Cost per unit rather than total, because the total scales with volume and the viability question is asked per unit.",
      "value": ""
    },
    "f21_Value_Realisation_Condition": {
      "section": "Value and Cost",
      "label": "Value Realisation Condition",
      "guidance": "What must be true for the value to be realised, as distinct from for the system to be built. Most systems are built successfully and deliver nothing, and the difference is nearly always one of these conditions.",
      "value": ""
    },
    "f22_Key_Risks": {
      "section": "Risks, Controls and Governance Route",
      "label": "Key Risks",
      "guidance": "The risks specific to this use case, ranked, with the consequence if each materialises. A generic risk register applied here records that data may be biased without saying for whom or how it would be detected.",
      "value": ""
    },
    "f23_Risk_Controls": {
      "section": "Risks, Controls and Governance Route",
      "label": "Risk Controls",
      "guidance": "What is in place for each risk, and what it does not cover. The second half is the useful half, and a control that covers everything is a control that has been described rather than designed.",
      "value": ""
    },
    "f24_Feasibility_Assessment": {
      "section": "Risks, Controls and Governance Route",
      "label": "Feasibility Assessment",
      "guidance": "Whether this is technically feasible, at what maturity, and what is unproven. A feasibility statement that does not say which part is unproven is a statement that all of it is proven.",
      "value": ""
    },
    "f25_Governance_Route": {
      "section": "Risks, Controls and Governance Route",
      "label": "Governance Route",
      "guidance": "Which governance artefacts this use case must pass through, and in what order. The order is the content: privacy, then fairness, then approval, because a system approved before its data is assessed cannot be un-approved.",
      "value": ""
    },
    "f26_Kill_Criteria": {
      "section": "Risks, Controls and Governance Route",
      "label": "Kill Criteria",
      "guidance": "What result would cause this use case to be stopped. A use case with no kill criteria is a commitment, and a commitment entered without an exit condition is the failure mode this field exists to prevent.",
      "value": ""
    },
    "f27_Related_Artefacts": {
      "section": "Risks, Controls and Governance Route",
      "label": "Related Artefacts",
      "guidance": "The business case, AI governance plan, model card and privacy assessment for this use case, so that a reader holding the canvas can find the decisions that depend on it.",
      "value": ""
    }
  }
}