كتابة متطلبات البرنامج لصاحب العمل: قصص مستخدم تنجح
اكتب متطلبات البرنامج في صورة «قصص مستخدم» قصيرة تقول من يحتاج ماذا ولماذا، ولكلٍّ منها «معايير قبول» تقول كيف ستتحقق من أنها تعمل. ورتّبها بأولويات MoSCoW ليتضح الأساسي منها. ثم أضف قائمة قصيرة بالصفات التي يحتاجها النظام كله: اللغات، والأجهزة، والسرعة، والأمان، ومدة الاحتفاظ بالبيانات، والتكاملات. صِف الحاجة والاختبار، لا الشاشة. وعندها يستطيع المطوّر أن يبنيها ويسعّرها ويثبت أنها تعمل.
وهذه الصيغة ليست بيروقراطية؛ بل هي أرخص طريقة لتجعل ثلاثة مورّدين يسعّرون الشيء نفسه، ولتحسم الخلافات عند الاعتماد بالإشارة إلى جملة اتفق عليها الجميع.
الجواب المختصر
- قصة المستخدم: «بصفتي [الدور]، أريد [شيئًا]، لكي [الفائدة]».
- معايير القبول: «بافتراض [الموقف]، عندما [الإجراء]، فإن [النتيجة]»، تُكتب للحالة المعتادة وللاستثناءات.
- الأولويات: ضروري، ومهم، ومرغوب، وليس هذه المرة.
- صفات النظام: العربية والإنجليزية، والأجهزة، وأزمنة الاستجابة، وصلاحيات الوصول، وسجل التدقيق، ومدة الحفظ، والاستضافة، والتكاملات.
- اترك جانبًا: تصاميم الشاشات، واختيارات التقنية، والكلمات الغامضة مثل «سريع» أو «سهل الاستخدام» دون مقياس.
لماذا تفشل المتطلبات
تفشل معظم وثائق المتطلبات بإحدى طريقتين. بعضها قائمة أمنيات من المزايا بلا أسباب، فلا يعرف أحد أيها المهم. وبعضها يصف الشاشات والأزرار بالتفصيل، فيبني المورّد ما رُسم بالضبط، ومعه الأجزاء الخاطئة.
وكلتاهما تفوّتان الشيئين اللذين يحتاجهما المطوّر: الغرض من كل ميزة، وطريقة لمعرفة متى اكتملت.
قصص المستخدم: من، وماذا، ولماذا
صيغة قصة المستخدم («بصفتي… أريد… لكي…») تُعرف بصيغة Connextra، نسبةً إلى الشركة البريطانية التي ابتُكرت فيها عام 2001، بحسب تحالف Agile Alliance. وكل قصة تتسع في جملة واحدة:
بصفتي مدير فرع، أريد اعتماد طلبات الشراء التي تقل عن 500 ريال عُماني من هاتفي، لكي لا تتوقف الطلبات أثناء سفر المدير العام.
والجزء الذي يبدأ بـ«لكي» هو الأهم، والأكثر إهمالًا. فهو يخبر المطوّر بالمشكلة التي تحلّها الميزة، ما يتيح له أن يقترح طريقة أبسط لحلّها.
ومن أدوات الفحص المفيدة قائمة INVEST، وهي قائمة من مقال كتبه بيل ويك عام 2003، ويصفها تحالف Agile Alliance بأنها مجموعة معايير مقبولة على نطاق واسع لتقييم جودة قصة المستخدم. فالقصة الجيدة مستقلة، وقابلة للتفاوض، وذات قيمة، وقابلة للتقدير، وصغيرة، وقابلة للاختبار.
معايير القبول: كيف ستعرف أنها تعمل
تحتاج كل قصة إلى معايير يمكن اختبارها. وقالب «بافتراض – عندما – فإن» (Given–When–Then)، الذي يصفه تحالف Agile Alliance بأنه قالب يوجّه كتابة اختبارات القبول لقصة المستخدم، يؤدي الغرض جيدًا:
بافتراض طلب شراء بقيمة 450 ريالًا عُمانيًا من أمين مستودع في فرعي، عندما أعتمده، فإن حالته تصبح «معتمد»، ويُشعَر أمين المستودع، ويُسجَّل الاعتماد باسمي ووقته.
ثم اكتب الاستثناءات، لأنها حيث تنجح الأنظمة أو تفشل:
بافتراض طلب شراء بقيمة 600 ريال عُماني، عندما أفتحه، فإنني أستطيع الاطلاع عليه دون اعتماده، ويُحال إلى المدير العام.
وتصبح هذه المعايير حالات الاختبار عند الاعتماد. ويشرح مقال اختبار قبول المستخدم كيف تستخدمها.
الأولويات: كن صادقًا فيما هو «ضروري»
ضع على كل قصة أولوية وفق طريقة MoSCoW: ضروري (Must)، أو مهم (Should)، أو مرغوب (Could)، أو ليس هذه المرة (Won’t). وتأتي الطريقة من إطار DSDM الذي يتولاه اليوم اتحاد Agile Business Consortium، وهو ينصح بأن يبقى الجهد المخصص للضروري عادةً عند 60% أو أقل، مع رصيد من «المرغوب» يقارب 20%.
والانضباط أهم من النسب.
«إن كان كل شيء ضروريًا، فلا شيء ضروري. وأول ما سيسقط حين يضيق الوقت سيُختار عندها بالمصادفة، لا باختيارك.» — عبدالقادر وهيبة، مؤسس «ذوات» ورئيسها التنفيذي
ويشرح مقال النسخة الأولى من نظام منشأتك كيف تقرر ما هو أساسي حقًا.
صفات النظام: ما ينطبق على كل شيء
بعض المتطلبات ليست مزايا، بل صفات للنظام كله، فاكتبها مرة واحدة:
- اللغات: العربية والإنجليزية، مع التخطيط من اليمين إلى اليسار، والترتيب والبحث بالعربية. ويسرد مقال بناء برمجيات ثنائية اللغة ما يتطلبه ذلك.
- المستخدمون والأجهزة: كم شخصًا، وبأي أدوار، وعلى أي أجهزة.
- السرعة: مثلًا: «تظهر نتائج البحث خلال ثانيتين في 95% من عمليات البحث». استخدم رقمًا.
- الوصول والتدقيق: من يستطيع رؤية ماذا وتغييره، مع سجل بمن فعل ذلك. ويتناول مقال صلاحيات الوصول وسجلات التدقيق التصميم.
- مدة الاحتفاظ بالبيانات: للفواتير والسجلات المحاسبية، توجب المادة 70 من قانون ضريبة القيمة المضافة عشر سنوات بعد نهاية السنة الضريبية التي قُدّم عنها الإقرار، وخمس عشرة سنة للعقارات.
- البيانات الشخصية: ما تحتفظ به عن الأشخاص، وكيف يدعم النظام قانون حماية البيانات الشخصية في عُمان. ويتناول مقال الخصوصية بالتصميم القرارات التي تُتخذ مبكرًا.
- التكاملات: كل نظام يتبادل معه البيانات، وفي أي اتجاه، وبأي تكرار.
- الاستضافة: أين يُسمح للبيانات أن تعيش. ويشرح مقال قواعد الاستضافة السحابية في عُمان القيود.
متطلبات ضعيفة وقوية جنبًا إلى جنب
| ضعيف | قوي |
|---|---|
| «يجب أن يكون النظام سريعًا.» | «تظهر نتائج البحث خلال ثانيتين في 95% من عمليات البحث.» |
| «أضف قائمة منسدلة للفرع.» | «بصفتي أمين مستودع، أريد أن يُملأ فرعي تلقائيًا، لكي لا أقدّم طلبًا باسم فرع خاطئ.» |
| «المديرون يعتمدون الطلبات.» | «مديرو الفروع يعتمدون ما دون 500 ريال عُماني، وما فوق ذلك يُحال إلى المدير العام.» |
| «ادعم العربية.» | «كل شاشة وبريد وملف PDF متاح بالعربية والإنجليزية، مع تخطيط من اليمين إلى اليسار في العربية.» |
| «تقارير حسب الحاجة.» | «بصفتي المدير المالي، أريد تصدير مشتريات كل فرع شهريًا إلى Excel، لكي أطابقها مع دفتر الأستاذ.» |
قالب من صفحة واحدة
لكل إجراء ضمن النطاق، تكفي غالبًا صفحة واحدة:
- الإجراء والغرض منه: جملة واحدة، مرتبطة بـخريطة الإجراء.
- المستخدمون: الأدوار المعنية.
- القصص: من خمس إلى خمس عشرة قصة، لكلٍّ منها أولوية.
- معايير القبول: لكل قصة ضرورية أو مهمة، الحالة المعتادة والاستثناءات الرئيسية.
- الأسئلة المفتوحة: ما لم تقرره بعد، ومن يقرره.
أضف صفحة واحدة لصفات النظام للمشروع كله، فيصبح لديك موجز يستطيع أي مورّد كفء أن يسعّره. وأعطِ الموجز نفسه لكل مورّد، كما يوصي مقال كيف تختار شريكًا برمجيًا في عُمان، فتصبح أسعارهم قابلة للمقارنة.
أسئلة شائعة
هل أحتاج إلى مواصفات كاملة قبل طلب العروض؟ لا. فمجموعة واضحة من القصص المرتبة، مع معايير قبول للأساسي منها، تكفي لتقدير على شكل نطاق. والتفاصيل تنمو مع تقدم المشروع، ويمكن أن تنتجها معك مرحلة الاستكشاف.
من يكتب قصص المستخدم؟ من يملكون العمل ويؤدّونه، بمساعدة من يدير الاستكشاف. فالقصص التي تكتبها الإدارة وحدها، أو المورّد وحده، تميل إلى تفويت الاستثناءات.
كم قصة مستخدم يحتاج نظام الأعمال؟ يتوقف ذلك على النطاق. فالإجراء الواحد قد يحتاج من عشر قصص إلى عشرين، والنظام متعدد الأقسام أكثر بكثير. والعدد أقل أهمية من تغطية الحالات الحقيقية.
ما الذي توصي «ذوات» صاحب العمل بأن يكتبه بنفسه؟ ينصح عبدالقادر وهيبة، مؤسس «ذوات» ورئيسها التنفيذي، أصحابَ الأعمال بأن يكتبوا الحاجة والاختبار، وأن يتركوا الشاشات لمن يتقاضون أجرًا على تصميمها. فإن استطعت أن تقول من يحتاج ماذا، ولماذا، وكيف ستتحقق منه، فقد أدّيت دورك.
هل تتغير المتطلبات بعد توقيع العقد؟ ستتغير. فاتفقوا مسبقًا على طريقة التعامل مع التغييرات: كيف تُقدَّر، ومن يعتمدها، وما الذي يخرج من النطاق لإفساح المجال لها. فمعاملة كل تغيير على أنه نزاع ضارة بقدر قبول كل تغيير بلا ثمن.
المصادر: Agile Alliance — قالب قصة المستخدم (صيغة Connextra) · Agile Alliance — INVEST · Agile Alliance — Given-When-Then · Agile Business Consortium — أولويات MoSCoW · قانون ضريبة القيمة المضافة الصادر بالمرسوم السلطاني رقم 121/2020، المادة 70
تريد مساعدة في تحويل إجراءاتك إلى متطلبات يستطيع المورّد تسعيرها؟ هذا هو العمل الذي وُجدت له خطوة «الاستكشاف» لدى «ذوات» في البرمجيات المخصصة وأنظمة الأعمال. احجز مكالمة.