كيف تكتب متطلبات نظام لا يُساء فهمها

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

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

لماذا يُساء فهم المتطلبات

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

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

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

ولا يظهر هذا الفرق في الاجتماعات، لأن كل طرف يسمع الكلمة ويملؤها بما يعرفه. يظهر حين يجلس الموظف أمام الشاشة لأول مرة، أي في أغلى وقت لتصحيحه.

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

قصص المستخدم: من، وماذا، ولماذا

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

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

اكتب قصة واحدة لكل هدف، واجعلها صغيرة بما يكفي لتُبنى وتُختبر وحدها. والقصة التي تحتاج إلى فقرة كاملة لشرحها هي في الغالب عدة قصص يجب فصلها.

وتجنب أن تبدأ القصة بالشاشة أو الزر. «أريد زراً لتصدير الطلبات» يصف حلاً، أما «أريد أن أرسل طلبات اليوم إلى شركة الشحن قبل الظهر» فيصف حاجة قد يكون لها حل أبسط من التصدير.

قواعد العمل والاستثناءات: اكتب ما «يعرفه الجميع»

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

لنفترض أن شركة توزيع تكتب قواعدها كما يلي:

1. لا يُشحن طلب يجعل رصيد العميل المستحق يتجاوز حده الائتماني، إلا بموافقة مدير المبيعات.
2. الخصم الذي يزيد على الحد المسموح للمندوب يحتاج إلى اعتماد مدير الفرع.
3. لا يُلغى طلب بعد خروجه من المستودع؛ يُعالج بمرتجع.
4. يُحجز المخزون عند اعتماد الطلب، لا عند إدخاله.

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

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

معايير القبول وأمثلة المدخلات والمُخرَجات

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

• تظهر في القائمة الطلبات المعتمدة فقط، ولا تظهر الطلبات المعلقة أو الملغاة.
• تُرتب الطلبات حسب موعد التسليم، والأقرب أولاً.
• يُميَّز الطلب الذي فات موعد تسليمه.
• لا يرى أمين المستودع أسعار البيع ولا بيانات الحد الائتماني.

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

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

لغة مشتركة، ومراجعة، واعتماد

مسرد المصطلحات

كل مؤسسة تستخدم كلمات بمعانٍ خاصة بها. «الطلب» عند المبيعات قد يعني عرض السعر، وعند المستودع يعني أمر الشحن. اكتب مسرداً قصيراً يعرّف كل مصطلح يتكرر في المتطلبات، واستخدمه في القصص والقواعد والشاشات بالمعنى نفسه.

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

المراجعة مع من يقومون بالعمل

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

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

من يعتمد

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

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

قائمة تحقق قبل أن يصل المتطلب إلى البرمجة

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

المتطلب الواضح هو الذي يقرؤه شخصان مختلفان فيبنيان منه الشيء نفسه.

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