أساس محلل الأعمال: إتقان خريطة أصحاب المصلحة ووثيقة المتطلبات التي يرث منها كل شيء

فريقك يملك بالفعل playbook الخاصين بـ stakeholder-map وrequirements-doc — الوصفات الجاهزة لبناء كل وثيقة خطوة بخطوة. هذه الوحدة هي الطبقة الأعلى من الوصفة. هنا تتقن الوثيقتين اللتين يرث منهما كل عمل آخر في Business Analyst، تبنيهما لمبادرة حقيقية، وتثبت — مقابل معيار حقيقي — أنك قادر على ذلك.

هذه الوحدة 1 من مسار Business Analyst المعتمد، وهي التي نتركها مفتوحة. اقرأها، أنجز التكليف، وستعرف بالضبط قيمة هذا العمق قبل أن تُخضع فريقًا كاملاً لبقية المسار.

كل متطلب يبني منه فريقك، وكل business case يُموَّل، وكل عنصر backlog يتولاه مهندس — كلها سحب من حسابين: من يملك فعلاً هذا القرار وما الذي طُلب فعلاً. معظم محللي الأعمال لا يموّلون هذين الحسابين بالكامل، فيبدأ جمع المتطلبات ممّن يوجد في الغرفة والأعلى صوتًا، ونصف “المتطلبات” ليست في الحقيقة سوى انطباعات. الأساس هو الساعتان اللتان تموّل فيهما الحسابين بشكل صحيح، وهما الوقت الأعلى قيمة في المسار كله.

لماذا الأساس هو الساعة الأعلى قيمة التي ستقضيها

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

وثيقتان تمنعان كلا نمطَي الفشل، بالترتيب. خريطة أصحاب المصلحة تجيب من هو فعلاً في هذه المبادرة — من يقرر، من ينفّذ العمل، من يجب استشارته، من يحتاج فقط أن يُبلَّغ — وتفرض اسم Accountable واحدًا بالضبط مسمّى لكل قرار حقيقي، بحيث لا يكون لسؤال “من وافق على هذا؟” أكثر من إجابة صادقة واحدة أبدًا. وثيقة المتطلبات تجيب ما الذي يُبنى فعلاً — الخلفية، حدود النطاق، المتطلبات الوظيفية وغير الوظيفية — مع تتبّع كل سطر بمفرده إلى صاحب المصلحة المسمّى الذي يُلبّي حاجته. ابنِ الخريطة أولاً، ثم الوثيقة، وكل ما يليهما — تحليل الفجوات، تحليل الخيارات، الـ business case، backlog قصص المستخدم، الموافقة على المتطلبات، الموجز التنفيذي — يرث كليهما: تحليل الفجوات يقيس الواقع مقابل متطلبات تملك بالفعل أصحابًا حقيقيين؛ الـ business case لا يحتاج تخمين من يوقّع الشيك؛ قصة المستخدم تتتبّع بوضوح إلى الشخص الفعلي الذي طلبها.

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

إتقان خريطة أصحاب المصلحة — الحكم الذي لا تستطيع الوصفة تعليمه

الـ playbook يمنحك الخطوات: أدرِج الجميع، قيّم التأثير والاهتمام، ابنِ جدول RACI. الإتقان هو الحكم داخل هذه الخطوات — القرارات التي يخطئها محلل مبتدئ ولا يخطئها محلل خبير.

• Accountable ليس “أكثر شخص أقدمية في الغرفة”. الغريزة الأولى هي تسمية من يملك أكبر سلطة عمومًا، أو من تحدّث أكثر في اجتماع الانطلاق. الاختبار الفعلي أضيق: من، تحديدًا، يستطيع أن يقول نعم أو لا على هذا القرار بالذات ويجعل قراره ثابتًا؟ نائب رئيس يفوّض القرار لمدير ليس هو Accountable عن ذلك القرار — المدير هو كذلك، وتسمية النائب بدلاً منه تعني فقط أن الموافقة التي تحصل عليها لاحقًا ليست تلك التي تصمد فعلاً. اسأل “إن ساءت الأمور، اسم من سيُذكر على القرار” — هذا هو Accountable، لا “من هو الأهم من دُعي”.
• الصوت الأعلى ليس مرادفًا لـ Accountable، ولا حتى لـ Consulted. كل مبادرة فيها صاحب مصلحة يُرسل أكثر البريد الإلكتروني، يحضر كل اجتماع، وله آراء قوية في كل تفصيل — وأحيانًا يملك هذا الشخص سلطة حقيقية، وأحيانًا هو فقط متحمّس. قيّم التأثير والاهتمام كلًا على حدة وبصدق: صاحب مصلحة صوته عالٍ لكن تأثيره منخفض لا يزال يُسمع (غالبًا كـ Informed أو Consulted)، لكن تسميته Accountable لأنه مثابر هي كيف تنتهي وثيقة المتطلبات إلى تحسين تفضيلات الشخص الخطأ.
• صاحب مصلحة يرفض التفاعل هو علامة تحذير، لا فراغًا تملؤه بنفسك. حين لا يستجيب أحدهم لطلبات المقابلة، أو يعطي إجابات مبهمة، أو يصعب الوصول إليه ببساطة، يكون الإغراء أن تكتب ما كان سيقوله على الأرجح وتمضي — الموعد النهائي لا يهتم بأن Legal لم يردّ بعد. قاوم ذلك. سجّل حاجته كفجوة مفتوحة في الخريطة، تابعها عبر مديره أو جهة اتصال ثانية إن اضطررت، وإن كانت المبادرة فعلاً لا تحتمل الانتظار، تقدّم مع تسمية الفجوة صراحةً بدل افتراضها بصمت. المجهول المُقرّ به قابل للتصحيح؛ الحاجة المُختلَقة بثقة والتي تتضح خطأً هي متطلب مبني على كذبة لم يقلها أحد عمدًا.
• صاحب المصلحة عالي التأثير منخفض الاهتمام هو من يعضّك في الأسبوع السادس. لن يلاحقك طلبًا للتحديثات لأنه لا يهتم بعد — حتى يتضح أن ما استُبعد بهدوء من النطاق هو بالضبط ما كان يهتم به، وحينها يهتم بشدة، في أسوأ توقيت ممكن. تمييز هذه المجموعة صراحةً (الخطوة الثانية في الـ playbook) ليس رفاهية؛ إنه أعلى قيمة يقدّمها ما تفعله خريطة أصحاب المصلحة ولا تفعله قائمة اتصال عادية.

إتقان وثيقة المتطلبات — قابلية التتبّع هي الانضباط بأكمله

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

وثيقة متطلبات تصمد هي قابلة للتتبّع بالبناء، لا بإضافة لاحقة:

• كل متطلب يسمّي صاحب مصلحته المصدر — لا “الشركة”. “FR-04: يجب أن يسمح النظام للمدراء بالموافقة على مصروفات تتجاوز 500 دولار” جملة. “FR-04: يجب أن يسمح النظام للمدراء بالموافقة على مصروفات تتجاوز 500 دولار — يتتبّع إلى Aisha Rahman (المالية)، التي تحتاج بقاء سلطة الموافقة مع أصحاب الميزانية” متطلب. الفرق هو هل يستطيع قارئ متشكك بعد ستة أشهر إيجاد الشخص الذي سيؤكد أنه ما زال مطلوبًا.
• المُعلَّم ليس فاشلًا. حين يُصاغ متطلب من انطباع عام لا من شيء قاله شخص محدد، هذا طبيعي — المقابلات فوضوية وتحدث فجوات — لكن يجب أن يبقى مُعلَّمًا بوضوح حتى يؤكده صاحب مصلحة حقيقي، لا أن يُطوى بهدوء كمحسوم لأنه يُقرأ بشكل جيد. العلامة هي الآلية التي تمنع “المعقول” من أن يصبح “المتّفق عليه” افتراضيًا.
• المتطلبات غير الوظيفية تحتاج الانضباط نفسه، مضاعفًا. لا أحد يتطوّع بقول “يجب أن يكون زمن الاستجابة أقل من ثانيتين” في مقابلة ما لم يُسأل مباشرة، لذا تُغفَل هذه الفئات باستمرار — ورقم مُختلَق هنا أسوأ من فجوة صادقة، لأن هدف أداء مُلفَّق يُقرأ كقيد حقيقي عند المهندس الذي يبني عليه.
• قائمة خارج النطاق هي المتطلب الذي يمنع أكبر عدد من النزاعات. قسم خارج النطاق غامض أو غائب يعني أن كل صاحب مصلحة يملأ الفجوة بافتراضه الخاص، والنزاع يظهر دومًا عند الموافقة النهائية، لا قبلها أبدًا. اجعله محددًا ومتعمَّدًا مثل قائمة داخل النطاق تمامًا — إنه يقوم بالعمل نفسه.
• ملف كنسي واحد، سجل مراجعات واحد. اللحظة التي يمكن فيها تعديل متطلب بهدوء في نسخة شخص ما دون تسجيل، تصبح قابلية التتبّع سليمة نظريًا وميتة عمليًا. سجل مراجعات مؤرَّخ — ما تغيّر، من وافق عليه — هو ما يبقي المتطلب قابلاً للتغيير فقط عمدًا وعلى السجل.

الأساس العربي — أصحاب مصلحة ثنائيو اللغة، تأليف لا ترجمة

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

• أجرِ المقابلة باللغة التي يفكّر بها صاحب المصلحة. مقابلة صاحب مصلحة تُجرى بلغته الثانية تُنتج عادة إجابة أرقّ وأكثر تحفّظًا من نفس المحادثة بلغته الأولى — ليس لأنه يعرف أقل، بل لأن الدقة هي أول ضحية لفجوة اللغة. إن كان أصحاب المصلحة الناطقون بالعربية لديك أكثر دقة بالعربية، أجرِ المقابلة بالعربية، ودع Claude يساعدك في صياغة الملاحظات ثنائية اللغة بدل إجبار المحادثة على الإنجليزية أولاً.
• ألّف وثيقة المتطلبات العربية من المقابلة، لا من المسودة الإنجليزية. ملف requirements-ar.md مُترجَم من requirements.md يحمل بنية الجملة الإنجليزية ويُقرأ كمذكرة مترجمة — بالضبط العلامة التي تجعل صاحب المصلحة يتصفّح بدل أن يقرأ عن قرب. اكتبه من نفس ملاحظات المصدر، بالسجل الذي تقرأ به فعلاً مجموعة أصحاب المصلحة، بنفس الطريقة التي تكتب بها النسخة الإنجليزية من الصفر.
• قابلية التتبّع تصمد أمام الترجمة فقط إن تحقّقت من ذلك. اطلب من Claude التحقّق من أن كل متطلب في الوثيقة العربية لا يزال يسمّي نفس صاحب المصلحة ويتتبّع إلى نفس اقتباس المقابلة كنظيره الإنجليزي — إعادة صياغة انزلقت بهدوء أثناء الترجمة هي كيف تتحوّل “يجب أن يُخطر النظام العميل” بهدوء إلى التزام أضعف مختلف في اللغة الأخرى.
• الأرقام والمصطلحات التقنية تبقى غربية؛ بوابة الموافقة تبقى نفسها. العملة والأرقام تبقى بالأرقام الغربية؛ مصطلح مثل RACI أو اسم نظام يبقى بالإنجليزية داخل النص العربي. ووثيقة المتطلبات العربية تجتاز نفس موافقة أصحاب المصلحة تمامًا التي تجتازها الإنجليزية — نمط الفشل الذي يجب التصميم ضده هو وثيقة باللغة الثانية تتخطى المراجعة لأن لا أحد في سلسلة الموافقة يقرأها عن قرب.

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

تكليفك

ابنِ الوثيقتين الأساسيتين لـ مبادرة حقيقية واحدة — مبادرتك الخاصة (يُنصح بها: الناتج هو الأداة الفعلية التي يوافق عليها أصحاب مصلحتك) أو العلامة التجارية النموذجية Mizan، شركة برمجيات محاسبة خليجية توليها محللة أعمال حديثة التعيين، Noor Al-Suwaidi، عبر هذا المسار. افتح المجلد الذي يحتوي ملاحظاتك الخام في Claude Desktop، ووافق على كل قراءة في نافذة “Ask permissions”، واعمل في المحادثة — بلا حاجة لأي طرفية.

تسليم الوحدة 1 — أساس Business Analyst

ترجمة:
1. stakeholder-map.md  (صفحة واحدة)
   - القائمة الكاملة — كل شخص أو مجموعة معنية، غير مصفّاة مسبقًا
   - تقييم التأثير/الاهتمام مرتفع/متوسط/منخفض، مع تمييز المجموعة عالية
     التأثير منخفضة الاهتمام صراحةً
   - جملة واحدة لكل صاحب مصلحة عمّا يحتاجه تحديدًا
   - جدول RACI عبر قرارات المبادرة الرئيسية — اسم Accountable واحد
     بالضبط لكل قرار
   - قائمة فجوات مسمّاة لأي شيء ما زال غير مؤكَّد

2. requirements.md  (صفحة إلى صفحتين)
   - فقرة خلفية وتقسيم صريح داخل النطاق / خارج النطاق
   - متطلبات وظيفية، كل واحدة متتبّعة إلى صاحب مصلحة مسمّى وكلماته
     الفعلية
   - متطلبات غير وظيفية (الأداء، الأمان، الامتثال، سهولة الاستخدام)،
     مع تمييز الفجوات الصادقة بدل اختلاقها
   - قائمة أسئلة مفتوحة مرتّبة بالأولوية، كل واحد بمالك مسمّى للمتابعة
   - سجل مراجعات في الأعلى

مجموعات أصحاب المصلحة ثنائية اللغة: أضف requirements-ar.md، مؤلَّفًا من
ملاحظات المقابلة العربية — لا مترجمًا من الملف الإنجليزي.

Module 1 deliverable — the BA foundation

1. stakeholder-map.md  (one page)
   - the full roster — every person or group connected, not pre-filtered
   - influence/interest scored high/medium/low, with the high-influence/
     low-interest group flagged explicitly
   - one sentence per stakeholder on what they specifically need
   - a RACI table across the initiative's key decisions — exactly one
     Accountable name per decision
   - a named gap list for anything still unconfirmed

2. requirements.md  (one to two pages)
   - a background paragraph and an explicit in-scope / out-of-scope split
   - functional requirements, each traced to a named stakeholder and
     their actual words
   - non-functional requirements (performance, security, compliance,
     usability), with honest gaps flagged rather than invented
   - a prioritized open-questions list, each with a named owner to chase
   - a revision log at the top

Bilingual stakeholder groups: add requirements-ar.md, authored from the
Arabic interview notes — not translated from the English file.

دليل الأساس (Foundation toolkit) يمنحك قالبًا جاهزًا للتعبئة لكل من هذه الوثائق والـ prompts التي تبنيها، لتملأ بنية جاهزة بدل مواجهة صفحة فارغة.

كيف يُقيَّم العمل — المعايير

هذا هو الجزء الذي لا يملكه الـ playbook المجاني، والجزء الذي يجعل الاعتماد ذا معنى. ملفّاك يُقيَّمان مقابل خمسة معايير. كل معيار يحقق المعيار / يقترب / لم يتحقق بعد — و”يقترب” في أي معيار يعني إعادة صياغة، لا نجاحًا.

ترجمة:
معايير الأساس

1. كل متطلب يتتبّع        لا متطلب يقوم على انطباع عام غير مُعلَّم.
   إلى اسم                كل واحد يسمّي صاحب مصلحة حقيقي وكلماته
                          الفعلية، أو يُعلَّم بوضوح كغير مؤكَّد.

2. Accountable واحد        كل قرار رئيسي في جدول RACI يحمل مالك
   بالضبط لكل قرار         Accountable واحدًا مسمّى — لا صفر، لا اثنين.
                          أصحاب المصلحة أصحاب الصوت العالي لكن غير
                          الـ Accountable مُصنَّفون بشكل صحيح في مكان
                          آخر من جدول RACI.

3. أصحاب المصلحة عالو      هذه المجموعة مُحدَّدة صراحةً في الخريطة، لا
   التأثير منخفضو          مدفونة داخل القائمة العامة.
   الاهتمام مُعلَّمون

4. الوثيقة تطابق البنية     الخلفية، داخل النطاق/خارج النطاق، المتطلبات
   المعتمدة                 الوظيفية وغير الوظيفية، الأسئلة المفتوحة
                          بمالكين، سجل مراجعات. لا شيء ناقص، لا شيء
                          مُختلَق لملء فجوة.

5. السجل العربي صحيح       وثيقة المتطلبات العربية مؤلَّفة من ملاحظات
   (أصحاب مصلحة ثنائيو      المصدر، لا مترجمة؛ كل متطلب لا يزال يتتبّع
   اللغة)                   إلى نفس صاحب المصلحة والاقتباس كنظيره
                          الإنجليزي.

Foundation rubric

1. Every requirement traces      No requirement rests on a general
   to a name                     impression left unflagged. Each names
                                 a real stakeholder and their actual
                                 words, or is visibly flagged as
                                 unconfirmed.

2. Exactly one Accountable       Every key decision in the RACI has one
   per decision                  — not zero, not two — named Accountable
                                 owner. Loud-but-not-Accountable
                                 stakeholders are correctly placed
                                 elsewhere in the RACI.

3. High-influence/low-interest   This group is explicitly identified in
   stakeholders are flagged      the map, not buried inside the general
                                 roster.

4. The document fits the        Background, in-scope/out-of-scope,
   canonical schema              functional + non-functional requirements,
                                 open questions with owners, a revision
                                 log. Nothing missing, nothing invented
                                 to fill a gap.

5. Arabic register is right     The Arabic requirements doc is authored
   (bilingual stakeholders)     from source notes, not translated; every
                                 requirement still traces to the same
                                 stakeholder and quote as the English
                                 version.

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

المعيار، موضّحًا — نموذج إجابة مُنجَز (Mizan)

لا حاجة لتخمين شكل “يحقق المعيار”. إليك مقتطف ناجح للعلامة التجارية النموذجية — علامتك التجارية لا تحتاج أن تبدو هكذا، بل تحتاج فقط أن تتجاوز المعيار نفسه. هذه وثائق Noor Al-Suwaidi، محللة الأعمال حديثة التعيين في Mizan، أُنجزت الأسبوع الذي طلبت فيه الشريكة المؤسِّسة Dana Al-Qassimi منها إدارة عملية المتطلبات الرسمية لميزة “الاعتراض على رسوم” الموجّهة للعملاء — الحماية المُنتجية التي حدّدتها Dana استجابةً مباشرة لحادثة الفوترة المزدوجة في 1 مارس، والتي تحتاج الآن موافقة رسمية عبر Support وFinance وData وEngineering قبل كتابة أي سطر برمجي.

ترجمة:
stakeholder-map.md — "الاعتراض على رسوم" (مقتطف)

القائمة (الجولة الأولى، غير مصفّاة):
  Layla Al-Nasser     قائدة CX، Support — تتولى الفريق الذي سيفرز كل
                     اعتراض يُرفع عبر المسار الجديد.
  Youssef Hamdan     محلل مالي، Finance — يتولى التسوية؛ الاعتراضات
                     تلامس نفس دفتر الأستاذ الذي أصابته حادثة 1 مارس.
  Maya Haddad        محللة أعمال، Data — حدّدت بالفعل السبب الجذري
                     لخلل 1 مارس؛ تملك قائمة العملاء المتأثرين.
  Bilal Al-Mansouri  Engineering — يتولى وحدة الفوترة التي ستُبنى
                     الميزة داخلها.
  Dana Al-Qassimi    شريكة مؤسِّسة، رئيسة المنتج — الراعية؛ حدّدت
                     الحماية استجابةً للحادثة.

التأثير / الاهتمام / الحاجة:
  Layla Al-Nasser     مرتفع / مرتفع.  تحتاج ظهور الاعتراضات في قائمة
                      انتظار واحدة مع العميل والمبلغ، حتى لا يبحث
                      الوكلاء في التذاكر يدويًا.
  Youssef Hamdan      مرتفع / متوسط.  يحتاج وسم الرسم المُعترَض عليه
                      بشكل مميّز عن الاسترداد في دفتر الأستاذ، حتى
                      لا يُشوَّه الإقفال الشهري بهدوء.
                      مُعلَّم: تأثير مرتفع، اهتمام متوسط — لن يلاحق
                      التحديثات، لكنه سيمنع الموافقة على متطلب وسم
                      دفتر الأستاذ إن كان خطأً.
  Bilal Al-Mansouri   مرتفع / مرتفع.  يحتاج حسم الحالات الحدّية
                      (تم الاسترداد بالفعل، مُقفَل بالفعل في المالية)
                      قبل أن يقدّر البناء.
  Dana Al-Qassimi     مرتفع / مرتفع.  تحتاج بقاء نطاق النسخة الأولى
                      مقتصرًا على المسار الأساسي — لا زحف نطاق نحو
                      نظام إدارة حالات نزاعات كامل.

RACI (القرارات الرئيسية):
  القرار                            Responsible    Accountable      Consulted            Informed
  النطاق النهائي للنسخة الأولى       Noor           Dana             Layla, Bilal         Youssef
  منطق وسم دفتر الأستاذ             Noor           Youssef          Bilal                Layla
  تصميم قائمة انتظار Support         Noor           Layla            Bilal                Dana
  تاريخ الإطلاق                     Bilal          Dana             Layla, Youssef       Maya

قائمة الفجوات: لا يوجد شيء غير مؤكَّد — تم تأكيد جميع أسماء
Accountable الأربعة مباشرة مع كل مالك قبل تعميم هذه الخريطة.

stakeholder-map.md — "Dispute a charge" (excerpt)

Roster (initial pass, unfiltered):
  Layla Al-Nasser    CX Lead, Support — owns the team that will triage
                     every dispute raised through the new flow.
  Youssef Hamdan     Finance Analyst — owns reconciliation; disputes
                     touch the same ledger the March 1 incident hit.
  Maya Haddad        Business Analyst, Data — already root-caused the
                     March 1 bug; holds the affected-customer list.
  Bilal Al-Mansouri  Engineering — owns the billing module the feature
                     will be built into.
  Dana Al-Qassimi    Co-founder, Head of Product — sponsor; specced the
                     safeguard in response to the incident.

Influence / interest / need:
  Layla Al-Nasser     High / High.  Needs disputes visible in one queue
                      with the customer and amount, so agents don't
                      search tickets manually.
  Youssef Hamdan      High / Medium.  Needs a disputed charge tagged
                      distinctly from a refund in the ledger, so it
                      doesn't silently distort the monthly close.
                      FLAGGED: high influence, medium interest — won't
                      chase for updates, but will block sign-off on the
                      ledger-tagging requirement if it's wrong.
  Bilal Al-Mansouri   High / High.  Needs the edge cases (already
                      refunded, already closed in finance) decided
                      before he estimates the build.
  Dana Al-Qassimi     High / High.  Needs the v1 scope to stay to the
                      core flow — no scope creep into a full disputes
                      case-management system.

RACI (key decisions):
  Decision                          R              A               C                    I
  Final v1 scope                    Noor           Dana            Layla, Bilal         Youssef
  Ledger-tagging logic              Noor           Youssef         Bilal                Layla
  Support queue design              Noor           Layla           Bilal                Dana
  Go-live date                      Bilal          Dana            Layla, Youssef       Maya

Gap list: none unconfirmed — all four Accountable names confirmed
directly with each owner before this map was circulated.

ترجمة:
requirements.md — "الاعتراض على رسوم" (مقتطف)

الخلفية
  بعد حادثة الفوترة المزدوجة في 1 مارس (11 عميلًا تحمَّلوا رسومًا
  زائدة بين 300 و1,200 درهم)، طلبت Dana Al-Qassimi عملية متطلبات
  رسمية عابرة للفرق لميزة اعتراض ذاتية الخدمة على الرسوم موجّهة
  للعملاء، بدل ترقيع سريع لمرة واحدة — هذا يلامس Support وFinance
  وData وEngineering ويحتاج موافقة رسمية قبل أي بناء.

داخل النطاق
  - أداة موجّهة للعميل لوسم رسم محدد كمُعترَض عليه
  - قائمة انتظار واحدة يرى فيها Support كل الرسوم المُعترَض عليها
    مع العميل والمبلغ
  - وسم في دفتر الأستاذ يُبقي الرسم المُعترَض عليه مميّزًا عن الاسترداد

خارج النطاق (النسخة الأولى)
  - معالجة استرداد آلية — يوافق إنسان دومًا على كل استرداد
  - نظام إدارة حالات عام للنزاعات غير المتعلقة بالفوترة
  - إعادة وسم الرسوم بأثر رجعي من قبل إطلاق هذه الميزة

FR-01  يجب أن يسمح النظام للعميل بوسم أي رسم على حسابه كمُعترَض عليه.
       يتتبّع إلى: Layla Al-Nasser (Support) — "نصف تذاكرنا في مارس
       كانت لعملاء ليس لديهم طريقة ليقولوا 'هذا يبدو خاطئًا' سوى
       مراسلتنا."

FR-02  يجب أن يمنع النظام وسم رسم مرتين — محاولة ثانية تُظهر الحالة
       الحالية "مُعترَض عليه".
       يتتبّع إلى: Bilal Al-Mansouri (Engineering) — أُثير أثناء تحديد
       النطاق كخطر حالة مزدوجة واضح.

FR-03  يجب أن يسم النظام الرسم المُعترَض عليه بشكل مميّز عن الاسترداد
       في دفتر الأستاذ، ولا يجب أن يغيّر مبلغ الرسم حتى تحسمه Finance.
       يتتبّع إلى: Youssef Hamdan (Finance) — "حادثة 1 مارس علّمتنا أن
       تعديلاً صامتًا في دفتر الأستاذ يجعل التسوية تستغرق ضعف الوقت."

NFR-01 يجب أن تظهر الاعتراضات في قائمة انتظار Support خلال 60 ثانية من
       وسمها.
       يتتبّع إلى: Layla Al-Nasser — لم يُعطَ اتفاقية مستوى خدمة (SLA)
       رسمية؛ مُعلَّم كسؤال مفتوح، لا مُختلَق كرقم صارم.

الأسئلة المفتوحة (مرتّبة بالأولوية)
  1. ما هي اتفاقية مستوى الخدمة لاستجابة Support لاعتراض مُوسَّم؟ —
     المالك: Layla Al-Nasser. يمنع: الموافقة على تصميم قائمة الانتظار.
  2. هل يُعلّق رسم مُعترَض عليه أي سير عمل تحصيل أو متابعة سداد على
     تلك الفاتورة؟ — المالك: Youssef Hamdan. يمنع: الموافقة على FR-03.
  3. هل يتطلّب الوسم رمز سبب، أم نص حر فقط؟ — المالك: Bilal Al-Mansouri.
     يمنع: تقدير النسخة الأولى.

سجل المراجعات
  2026-07-01  الإصدار 0.1  مُسوَّد من مقابلات أصحاب المصلحة.  Noor Al-Suwaidi.

requirements.md — "Dispute a charge" (excerpt)

Background
  Following the March 1 double-billing incident (11 customers
  overcharged AED 300–1,200), Dana Al-Qassimi requested a formal,
  cross-team requirements process for a self-serve "dispute a charge"
  feature, rather than a one-off patch — this touches Support, Finance,
  Data, and Engineering and needs proper sign-off before any build.

In scope
  - A customer-facing control to flag a specific charge as disputed
  - A single queue where Support sees all flagged charges with
    customer and amount
  - Ledger tagging that keeps a disputed charge distinct from a refund

Out of scope (v1)
  - Automated refund processing — a human still approves every refund
  - A general case-management system for non-billing disputes
  - Retroactively re-flagging charges from before this feature ships

FR-01  The system shall let a customer flag any charge on their
       account as disputed.
       Traced to: Layla Al-Nasser (Support) — "half our March tickets
       were customers with no way to say 'this looks wrong' except
       emailing us."

FR-02  The system shall prevent a charge from being flagged twice —
       a second attempt shows the existing "Flagged" state.
       Traced to: Bilal Al-Mansouri (Engineering) — raised during
       scoping as an obvious duplicate-state risk.

FR-03  The system shall tag a disputed charge distinctly from a refund
       in the ledger, and shall not alter the charge amount until
       Finance resolves it.
       Traced to: Youssef Hamdan (Finance) — "March 1 taught us that a
       silent adjustment to the ledger is how a reconciliation takes
       twice as long."

NFR-01 Disputes must appear in the Support queue within 60 seconds of
       being flagged.
       Traced to: Layla Al-Nasser — no formal SLA given; flagged as an
       open question, not invented as a hard number.

Open questions (prioritized)
  1. What's the SLA for Support to respond to a flagged dispute? —
     owner: Layla Al-Nasser. Blocks: queue design sign-off.
  2. Does a disputed charge pause any dunning/collection workflow on
     that invoice? — owner: Youssef Hamdan. Blocks: FR-03 sign-off.
  3. Does flagging require a reason code, or free text only? — owner:
     Bilal Al-Mansouri. Blocks: v1 estimate.

Revision log
  2026-07-01  v0.1  Drafted from stakeholder interviews.  Noor Al-Suwaidi.

ما أثبتّه — وما الذي يلي

اجتياز المعايير يعني أنك أنجزت شيئًا لا يستطيع المسار المجاني اعتماده: بنيت خريطة أصحاب مصلحة ووثيقة متطلبات حقيقية بمستوى مهني وأثبتّ الحكم الكامن وراءهما. هذه هي مرحلة الأساس في “Certified Business Analyst with Claude”.

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

• الوحدة 2 — تحليل الفجوات والخيارات: قياس العملية كما هي فعليًا مقابل هذه المتطلبات، وترجيح الحلول عبر business case حقيقي.
• الوحدة 3 — الـ backlog والموافقة، الوحدة 4 — الموجز التنفيذي، الوحدة 5 — SWOT والمخاطر والانضباط التشغيلي، ثم المشروع الختامي — مبادرة كاملة من خريطة أصحاب المصلحة إلى تسليم موافَق عليه، تُقيَّم ضمن الاعتماد.

أولاً، اجعل ما بنيته قابلاً لإعادة الاستخدام. احصل على دليل الأساس — ملف CLAUDE.md الخاص بـ Business Analyst والقالبين اللذين يحوّلان الوثائق التي كتبتها للتو إلى ملفات يثبّتها فريقك بأكمله ويرثها. وإن كنت تُطبّق هذا عبر فريق، فـ دليل التشغيل هو طبقة الأمان والموافقة التي تقع تحت كل هذا.