كتابة المواصفات

# مواصفات الكتابة

> إذا لاحظت عناصر نائبة غير مألوفة أو تحتاج للتحقق من الأدوات المتصلة، راجع [CONNECTORS.md](../../CONNECTORS.md).

اكتب مواصفات الميزة أو وثيقة متطلبات المنتج (PRD).

## الاستخدام

``` /write-spec $ARGUMENTS ```

## سير العمل

### 1. فهم الميزة

اسأل المستخدم عما يريد تحديده. اقبل أي مما يلي: - اسم الميزة ("دعم SSO") - بيان المشكلة ("يطلب العملاء الموثوقون باستمرار على المصادقة المركزية") - طلب المستخدم ("يريد المستخدمون تصدير بياناتهم على شكل CSV") - فكرة غامضة ("يجب أن نفعل شيئاً بشأن معدل التخلي عن الإعداد")

### 2. جمع السياق

اطلب من المستخدم ما يلي. كن حواريًا — لا تلقِ كل الأسئلة في آن واحد. اطرح الأسئلة الأكثر أهمية أولاً واملأ الفجوات أثناء تقدمك:

- **مشكلة المستخدم**: ما المشكلة التي يحلها هذا؟ من يواجهها؟ - **المستخدمون المستهدفون**: أي قطاع(ات) من المستخدمين يخدمها هذا؟ - **مقاييس النجاح**: كيف سنعرف أن هذا نجح؟ - **القيود**: القيود التقنية والجدول الزمني والمتطلبات التنظيمية والتبعيات - **الأعمال السابقة**: هل تمت محاولة هذا من قبل؟ هل هناك حلول موجودة؟

### 3. سحب السياق من الأدوات المتصلة

إذا كان **متتبع المشاريع** متصلاً: - ابحث عن التذاكر والملاحم أو الميزات ذات الصلة - اسحب أي متطلبات أو معايير قبول موجودة - حدد التبعيات على عناصر العمل الأخرى

إذا كانت **قاعدة المعرفة** متصلة: - ابحث عن المستندات والمواصفات أو مستندات التصميم ذات الصلة - اسحب نتائج البحث عن المستخدمين ذات الصلة - ابحث عن ملاحظات الاجتماعات أو سجلات القرارات ذات الصلة

إذا كان **التصميم** متصلاً: - اسحب النماذج الأولية والإطارات السلكية أو الاستكشافات التصميمية ذات الصلة - ابحث عن مكونات نظام التصميم ذات الصلة بالميزة

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

### 4. إنشاء وثيقة المتطلبات

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

- **بيان المشكلة**: مشكلة المستخدم وكيفية تأثرها والتأثير الناتج عن عدم حلها (2-3 جمل) - **الأهداف**: 3-5 نتائج محددة وقابلة للقياس مرتبطة بمقاييس المستخدم أو العمل - **المستبعدات**: 3-5 أشياء صراحة خارج نطاق التركيز، مع إيجاز الأساس المنطقي لكل منها - **قصص المستخدم**: الصيغة القياسية ("كمستخدم من نوع معين، أريد القدرة على القيام بـ ...")، مجمعة حسب الشخصية - **المتطلبات**: مقسمة إلى أساسية (P0)، مفضلة (P1)، واعتبارات مستقبلية (P2)، لكل منها معايير القبول - **مقاييس النجاح**: المؤشرات السابقة (تتغير بسرعة) والمؤشرات المتأخرة (تتغير بمرور الوقت)، مع أهداف محددة - **الأسئلة المفتوحة**: الأسئلة غير المحلولة موسومة بمن يحتاج للإجابة (الهندسة، التصميم، القانون، البيانات) - **الاعتبارات الزمنية**: المواعيد الحتمية والتبعيات والمراحل

### 5. المراجعة والتكرار

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

## بنية PRD

### بيان المشكلة - صف مشكلة المستخدم في 2-3 جمل - من يواجه هذه المشكلة وعدد المرات - ما هي تكلفة عدم حلها (معاناة المستخدم والتأثير التجاري والمخاطر التنافسية) - ارجع هذا إلى الأدلة: بحث المستخدمين وبيانات الدعم والمقاييس أو ملاحظات العملاء

### الأهداف - 3-5 نتائج محددة وقابلة للقياس يجب أن تحققها هذه الميزة - يجب أن يجيب كل هدف على السؤال: "كيف سنعرف أن هذا نجح؟" - يميّز بين أهداف المستخدم (ما يحصل عليه المستخدمون) والأهداف التجارية (ما تحصل عليه الشركة) - يجب أن تكون الأهداف نتائج وليست مخرجات ("تقليل الوقت إلى القيمة الأولى بنسبة 50%" وليس "بناء معالج الإعداد")

### المستبعدات - 3-5 أشياء لن تقوم هذه الميزة بها صراحة - القدرات المجاورة التي تقع خارج نطاق هذه النسخة - لكل مستبعد، اشرح بإيجاز سبب استبعاده (التأثير غير كافٍ أو معقد جداً أو مبادرة منفصلة أو مبكر جداً) - تمنع المستبعدات زحف نطاق التركيز أثناء التنفيذ وتعيّن التوقعات مع أصحاب المصلحة

### قصص المستخدم اكتب قصص المستخدم بالصيغة القياسية: "كمستخدم من نوع معين، أريد القدرة على فعل شيء معين حتى أتمكن من الحصول على فائدة معينة"

الإرشادات: - يجب أن يكون نوع المستخدم محددًا بشكل كافٍ ليكون ذا معنى ("مسؤول الشركة" وليس فقط "مستخدم") - يجب أن تصف الإمكانية ما يريدون تحقيقه وليس كيفية تحقيقه - يجب أن تشرح الفائدة "السبب" — ما هي القيمة التي تقدمها - أدرج الحالات الحدية: حالات الخطأ والحالات الفارغة والشروط الحدية - اشمل أنواع مستخدمين مختلفة إذا كانت الميزة تخدم شخصيات متعددة - رتب حسب الأولوية — القصص الأكثر أهمية أولاً

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