عاش كل محلل أعمال الفشل نفسه: ثلاث مقابلات تنتج ثلاث مجموعات ملاحظات ناقصة، فيبني أحدهم من الذاكرة، وما يُشحن لا يُرضي أحدًا لأن لا أحد دوّن ما طُلب فعلًا أو من طلبه. الحل هو وثيقة متطلبات — BRD خفيفة ببنية واحدة معتمدة: الخلفية، ما هو داخل النطاق وخارجه، المتطلبات الوظيفية وغير الوظيفية مع تتبّع كل منها إلى حاجة صاحب مصلحة مسمّاة، والأسئلة المفتوحة التي لم تُحسَم بعد. ابنِها مرة واحدة وكل عمل آخر لمحلل الأعمال يصبح أوضح، لأن 'ما نبنيه' يشير أخيرًا إلى وثيقة واحدة. هذه هي الماذا؛ تحليل الفجوات، وتحليل الخيارات، وحالة العمل، وسجلّ قصص المستخدم، والاعتماد النهائي، وإحاطة التنفيذيين، كلها الكيف وما الفائدة المبنيّة فوقها.
- ملاحظات مقابلاتك الخام، أو نصوص اجتماعات، أو ملخّص فوضوي لمحادثة مع أصحاب المصلحة — نصوص ملصقة أو ملفات، مهما كانت خامًا.
- ملف
stakeholder-map.mdمن رسم خريطة أصحاب المصلحة (إن كنت قد بنيته) — كل متطلب هنا يحتاج مالكًا مسمّى من تلك الخريطة، فأحضره إن وُجد. - أي بيان نطاق قائم، أو ميثاق مشروع، أو عرض انطلاقة، حتى لو كان أوليًا، بحيث يوفّق Claude بينه وبين ما اتُّفق عليه بدل البدء من فراغ.
-
استخرج الخلفية وصِغ حدود النطاق
افتح المجلد الذي يضم ملاحظات مقابلاتك في Claude Desktop واطرح سؤالك في المحادثة — لا حاجة لأي Terminal. قبل أي متطلبات، ثبّت الحدود: لماذا توجد هذه المبادرة، وما هو داخلها وخارجها صراحةً. خط نطاق غامض هو أكبر سبب واحد للخلافات لاحقًا.
أنت تطلباقرأ ملاحظات المقابلات هذه وأي مواد انطلاقة. صُغ قسم خلفية (لماذا توجد هذه المبادرة، وما المشكلة التي تحلّها، في ثلاث إلى أربع جمل) وحدود نطاق: قائمة نقطية لما هو داخل النطاق وأخرى لما هو خارجه. حيث تكون الملاحظات غامضة حول انتماء أمر ما للنطاق، لا تخمّن — أدرجه تحت 'يحتاج قرار نطاق' بدلًا من ذلك.ما تحصل عليه فقرة خلفية مُحكمة مع قائمتين واضحتين — داخل النطاق وخارجه — وقائمة ثالثة صادقة بقرارات النطاق التي لا تزال بحاجة إلى قرار حقيقي. تلك القائمة الثالثة غالبًا أثمن ناتج للجلسة كلها.
قاوم ترك Claude يحسم غموض النطاق بمفرده. حدّ نطاق مُختلَق هو بالضبط نوع الناتج المعقول-لكن-غير-المتّفَق-عليه الذي وُجدت هذه الوثيقة لمنعه.
-
صِغ المتطلبات الوظيفية — مع تتبّع كل منها إلى حاجة صاحب مصلحة مسمّاة
حوّل الملاحظات إلى متطلبات وظيفية: ما يجب أن يفعله الحل فعليًا. التتبّع ليس اختياريًا — كل متطلب يحمل اسم صاحب المصلحة (من خريطتك) الذي تلبّي حاجته.
أنت تطلبمن هذه الملاحظات وملف stakeholder-map.md، صِغ المتطلبات الوظيفية — ما يجب أن يفعله الحل، متطلب واحد لكل سطر، وصياغة كل منها على شكل 'يجب أن يسمح النظام/العملية بـ...'. لكل متطلب، سمِّ صاحب المصلحة تحديدًا الذي تعود إليه، مع اقتباس أو إعادة صياغة ما قاله فعليًا. ضع علامة على أي متطلب صغته من انطباع عام لا من شيء قاله صاحب مصلحة مسمّى تحديدًا.ما تحصل عليه قائمة متطلبات وظيفية مرقّمة حيث يقرأ كل سطر مثل 'FR-04: يجب أن يسمح النظام للمدراء باعتماد مصاريف تتجاوز 500 دولار — يعود إلى: عائشة رحمن (المالية)، التي تحتاج صلاحية الاعتماد لتبقى مع أصحاب الميزانية'، مع تمييز غير المرتكزة على حاجة مسمّاة بشكل منفصل.
المتطلب المميَّز ليس خاطئًا — فقط لم يؤكّده أحد بعد. اطلب من صاحب مصلحة حقيقي تأكيده قبل أن يدخل الوثيقة كأمر محسوم.
-
صِغ المتطلبات غير الوظيفية والقيود
المتطلبات الوظيفية تحدّد ماذا يفعل الحل؛ غير الوظيفية تحدّد كيف يؤدّيه — الأداء، الأمان، الامتثال، سهولة الاستخدام، التوفّر. هذه تُغفَل باستمرار لأن لا أحد يسأل عنها في مقابلة ما لم يُطلَب منه ذلك.
أنت تطلبمن الملاحظات نفسها، صِغ المتطلبات غير الوظيفية: توقّعات الأداء، قيود الأمان أو الامتثال، احتياجات سهولة الاستخدام، توقّعات التوفّر/زمن التشغيل، وأي قواعد للتعامل مع البيانات وردت. حيث لا تغطّي الملاحظات فئة غير وظيفية واضحة، لا تخترع رقمًا — ضع علامة عليها كسؤال مفتوح لصاحب المصلحة المناسب (مثل 'لم يُذكر توقّع لزمن الاستجابة — أكّد ذلك مع فريق العمليات').ما تحصل عليه قائمة قصيرة من المتطلبات غير الوظيفية مع مجموعة فجوات صادقة مميَّزة — الفئات التي لم يتطرّق إليها أحد بعد في المقابلات، مسمّاة بحيث يذهب أحدهم للسؤال بدل الاعتماد الصامت على افتراض.
-
اجمع الأسئلة المفتوحة — القائمة غير المحسومة، لا المخفية
كل جهد لجمع المتطلبات يكشف أمورًا لم يجب عليها أحد بعد. تسميتها صراحة، مع مالك لمتابعتها، هو ما يمنعها من أن تُفترَض بصمت.
أنت تطلبراجع كل ما صيغ حتى الآن واجمع قائمة أسئلة مفتوحة واحدة: كل قرار نطاق أو متطلب أو بند غير وظيفي لا يزال غير محسوم، مع صاحب المصلحة تحديدًا (بالاسم، من stakeholder-map.md) الذي يحتاج إلى الإجابة عنه. رتّب القائمة بحسب مدى تعطيلها للعمل اللاحق — الأسئلة التي تعطّل اعتماد النطاق أولًا.ما تحصل عليه قائمة أسئلة مفتوحة مرتّبة بالأولوية — كل واحدة تسمّي شخصًا حقيقيًا يجب سؤاله، لا سؤالًا بلاغيًا معلّقًا في الوثيقة.
هذه القائمة ميزة، لا عيب. وثيقة متطلبات بلا أسئلة مفتوحة بعد جولة مقابلات واحدة غالبًا افترضت بصمت تجاوز غموض حقيقي.
-
اجمع كل شيء في ملف requirements.md الجامع الواحد
اجمع كل شيء في ملف واحد، مرتّب وقابل للمسح السريع. هذه هي الوثيقة التي يقرأ منها كل عمل لاحق لمحلل الأعمال — تحليل الفجوات، تحليل الخيارات، حالة العمل، سجلّ قصص المستخدم، الاعتماد النهائي، إحاطة التنفيذيين — فهي تحتاج بنية ثابتة يمكن التنبّؤ بها.
أنت تطلباجمع كل شيء في ملف requirements.md واحد: الخلفية، داخل النطاق/خارجه، المتطلبات الوظيفية (كل منها يعود إلى صاحب مصلحة)، المتطلبات غير الوظيفية، وقائمة الأسئلة المفتوحة مع ملّاكها. أضف سجل مراجعات قصيرًا أعلى الملف (التاريخ، ما تغيّر، من اعتمده) بحيث تكون التغييرات متعمّدة لا صامتة. اجعل كل متطلب في سطر واحد قدر الإمكان بحيث تبقى الوثيقة كاملة قابلة للمسح السريع.ما تحصل عليه ملف
requirements.mdواحد جاهز للاستخدام — المرجع الذي يرثه كل تحليل فجوات وحالة عمل وسجلّ ومسار اعتماد، مع سجل مراجعات بحيث لا يتغيّر متطلب إلا بتعمّد وعلى السجل.احفظ هذا الملف في جذر مجلد مشروعك. من الآن فصاعدًا، لسؤال كل عمل لاحق الأول — 'بماذا اتّفقنا فعليًا أن نبنيه؟' — جواب واحد: أشِر إلى requirements.md.
- يغذّي كل عمل في المرحلتين 2 و3: تحليل الفجوات يقيس العملية الحالية في مقابل هذه المتطلبات؛ تحليل الخيارات وحالة العمل يقيّمان الحلول في مقابلها؛ سجلّ قصص المستخدم يفكّك المتطلبات الوظيفية إلى قصص؛ الاعتماد النهائي يُضفي طابعًا رسميًا على اعتماد هذه الوثيقة تحديدًا؛ إحاطة التنفيذيين تلخّصها إلى الأعلى.
- اربطها بخريطة العملية: إذا كانت المبادرة تمسّ سير عمل قائمًا، شغّل حوّل ملاحظات المقابلات إلى خريطة عملية حالية واضحة بالتوازي مع هذا — نقاط الألم التي تكشفها غالبًا تصبح متطلبات غير وظيفية أو قرارات حدّ نطاق هنا.
- حوّلها إلى skill قابلة لإعادة الاستخدام (Power Track): حمّل requirements.md كـ skill أو أمر
/tracebackبحيث يُتحقّق من أي صياغة لاحقة — قصة، حالة اختبار، شريحة إحاطة — تلقائيًا في مقابل المتطلبات المتّفَق عليها (انظر تبويب Features). - حدّث الإصدار عند تغيّر حقيقي فقط: أعِد تشغيل خطوة عندما يغيّر صاحب مصلحة حاجته فعليًا — لا تعدّل تتبّع متطلب بصمت؛ ارفع رقم سجل المراجعات بحيث يعرف أي بانٍ لاحق أنه تغيّر ولماذا.
- متطلب بلا صاحب مصلحة مسمّى ليس متطلبًا — إنه تخمين. التتبّع هو الضمان بأكمله: إذا صاغه Claude من انطباع عام لا من شيء قاله شخص محدَّد، يبقى مميَّزًا حتى يؤكّده صاحب مصلحة حقيقي، ولا يتقدّم إلى البناء.
- 'المعقول' ليس 'المتّفَق عليه'. يمكن لـ Claude صياغة وثيقة متطلبات متماسكة الظاهر من ملاحظات رقيقة، لكن التماسك ليس إجماعًا — كل متطلب وظيفي وغير وظيفي يحتاج اعتمادًا حقيقيًا من أصحاب المصلحة، لا مجرد اتساق داخلي، قبل أن يُبنى عليه تحليل الفجوات أو حالة العمل.
- المتطلبات غير الوظيفية هي ما ينساه الجميع السؤال عنه. إذا لم تكن قيود الأداء أو الأمان أو الامتثال في الملاحظات، لا تدع افتراضًا معقول الظاهر يتسلّل دون تمييز — رقم زمن تشغيل مُختلَق أسوأ من 'لم يُحدَّد بعد' صادقة.
- زحف النطاق يبدأ بخط خارج-نطاق غامض. إذا لم يكن 'خارج النطاق' صريحًا ومحدّدًا، سيقرأ كل صاحب مصلحة الفجوة بشكل مختلف، ويعود الخلاف في أسوأ وقت ممكن — عادةً قبيل الاعتماد النهائي مباشرة.
ستحصل في النهاية على ملف `requirements.md` واحد — الخلفية، حدود النطاق، المتطلبات الوظيفية وغير الوظيفية مع تتبّع كل منها إلى صاحب مصلحة مسمّى، وقائمة أسئلة مفتوحة مرتّبة بالأولوية — يرثه كل عمل لاحق لمحلل الأعمال، من تحليل الفجوات إلى إحاطة التنفيذيين، كسجلّ متّفَق عليه واحد لما يُبنى ولمن.
أسئلة يطرحها الناس
- بمَ تختلف هذه عن BRD كاملة أو PRD؟
- هي الجوهر الخفيف لـ BRD — الخلفية، النطاق، المتطلبات الوظيفية وغير الوظيفية، الأسئلة المفتوحة — تُنتَج بسرعة كافية لإنجازها في جلسة واحدة لكل جولة مقابلات، لكنها منضبطة بما يكفي في التتبّع (كل متطلب يسمّي صاحب مصلحته) بحيث يمكن توسيعها إلى BRD أكمل أو تسليمها لفريق المنتج لصياغة PRD دون إعادة كل العمل الأساسي. هي *الماذا*، لا مواصفة نهائية جاهزة للهندسة.
- ماذا يحدث إذا تعذّر تتبّع متطلب إلى صاحب مصلحة مسمّى؟
- يبقى مميَّزًا، لا محذوفًا ولا مُمرَّرًا بصمت. يكشفه Claude تحديدًا كغير مرتكز بحيث تذهب للبحث عن الشخص الحقيقي الذي ينبغي أن يعود إليه — انطباع عام من الملاحظات ليس حاجة صاحب مصلحة، وكامل قيمة هذه الوثيقة أن هذا التمييز يُفرَض في كل مرة.
- هل أحتاج خريطة أصحاب المصلحة قبل أن أبدأ هذا؟
- تجعل خطوة التتبّع أسرع وأدقّ بكثير — فأنت تتتبّع إلى أسماء وأدوار قيّمتها مسبقًا، لا تخمّنها أثناء الصياغة. يمكنك البدء بدونها، لكن كل متطلب سيحتاج مالكًا مسمّى في النهاية، فابنِ stakeholder-map.md أولًا إن استطعت.
- من يعتمد التغييرات على requirements.md بعد بنائه؟
- أصحاب المصلحة المعتمِدون المسمّون في جدول RACI الخاص بك، لا محلل الأعمال وحده ولا Claude. عامِل أي تغيير بعد الاعتماد النهائي كتحديث مُراجَع ومسجَّل — سجل المراجعات أعلى الملف موجود بالضبط لهذا: بحيث لا يتغيّر متطلب إلا بتعمّد وعلى السجل، وهو ما يُضفي عليه الاعتماد النهائي طابعًا رسميًا لاحقًا.