تحليل وهيكلة المتطلبات الخام

تحليل وهيكلة المتطلبات الخام

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

الخطوة الأولى — جمع كل شيء وإبرازه أولًا

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

الخطوة الثانية — إزالة التكرار: الدمج دون فقدان الدقة

التكرار هو المشكلة الأكثر شيوعًا في المتطلبات الخام. في مشروع شركة لوجستية، يقول مدير المستودع "يجب أن يرسل النظام بريدًا إلكترونيًا عند تأخر الشحنة." ويقول مدير العمليات "يجب أن يتلقى السائقون إشعارات تأخير تلقائية." هل هذان المتطلبان متطابقان؟ ظاهريًا نعم، لكن بالفحص الدقيق يختلفان: مدير المستودع → بريد إلكتروني مقابل السائق → ربما رسالة نصية أو إشعار هاتفي.

قاعدة إزالة التكرار: ادمج فقط عندما تكون الحاجة الجوهرية متطابقة حقًا. عندما يختلف بيانان في الجمهور أو القناة أو المحفز — ولو قليلًا — أبقِهما منفصلَين أو أنشئ متطلبًا أبًا عامًا بمتطلبَين فرعيَّين. سجّل قرار الدمج ومعرّفات المصادر الأصلية حتى لا يضيع شيء.

أنماط التكرار الشائعة التي يجب مراقبتها:

• نفس الحاجة بمفردات مختلفة — "البحث في الطلبات" مقابل "استعراض الطلبات" مقابل "إيجاد الطلبات" (على الأرجح متطابقة).
• نفس الحاجة بنطاق مختلف — "التصدير إلى CSV" مقابل "التصدير إلى Excel وCSV وPDF" (الثانية أوسع؛ لا تُسقط النسخة الأغنى بصمت).
• نفس الميزة بمحفز مختلف — "إشعار العميل عند شحن الطلب" مقابل "إشعار العميل عند وصول الطلب" (حدثان متمايزان، وليسا تكرارًا).

الخطوة الثالثة — تحديد التعارضات وحلها

التعارضات أمر لا مفر منه عندما يكون لأصحاب المصلحة مصالح متنافسة. هناك ثلاثة أنواع:

1. التناقضات المباشرة — يشترط فريق المالية أن تكون جميع المعاملات خاضعة للمراجعة وغير قابلة للتغيير؛ ويريد فريق التسويق القدرة على تعديل أسعار العروض الترويجية بأثر رجعي. لا يمكن تحقيق الطلبَين كما هما.
2. التناقضات الضمنية — يحدد فريق تجربة المستخدم ألا تستغرق عملية الدفع أكثر من ثلاث نقرات؛ ويشترط فريق الامتثال أربع شاشات موافقة إلزامية. لم يذكر أي من الفريقَين قيود الآخر — لا يظهر التعارض إلا أثناء التحليل.
3. تعارضات الأولوية — متطلبان متوافقان منطقيًا لكن لا يمكن تسليمهما معًا في النقطة الزمنية أو الميزانية الحالية. هذا تعارض في الموارد لا في المنطق، ويُحلّ من خلال تحديد الأولويات (يُغطَّى في الدرس السادس) لا من خلال تعديل المتطلبات.

عملية الحل: (أ) وثّق التعارض صراحةً — اكتب الجملتين جنبًا إلى جنب؛ (ب) حدّد أصحاب المصلحة الذين يمتلكون كل موقف؛ (ج) جدوِل اجتماعًا قصيرًا مركّزًا مع هؤلاء الأشخاص فقط؛ (د) سجّل الحل المتفق عليه وضع علامة على العناصر الخام المتعارضة كـمحلول — انظر REQ-047. لا تحلّ التعارض بحذف أحد الجانبَين بصمت؛ سيلاحظ صاحب المصلحة الذي طرحه وسيتآكل الثقة.

الخطوة الرابعة — تجميع المتطلبات حسب الموضوع أو القدرة

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

• حسب المجال الوظيفي — تسجيل المرضى، حجز المواعيد، الإشعارات، التقارير. طبيعي للفرق المنظمة حول وحدات برمجية.
• حسب هدف المستخدم (مُمحوَر حول الميزات) — كل ما يحتاجه المريض لحجز موعد في مجموعة واحدة، بغض النظر عن الوحدة التقنية التي تلمسها. طبيعي لرسم خرائط قصص المستخدم وإدارة المتراكمات.
• حسب صاحب المصلحة — متطلبات المرضى، ومتطلبات الأطباء، ومتطلبات المشرفين. مفيد للتحقق: تراجع كل مجموعة من أصحاب المصلحة قسمها فقط.

لمعظم المشاريع، هيكل ثنائي المستوى يعمل جيدًا: موضوع رئيسي (إدارة المواعيد) يحتوي على عدد من المجموعات الفرعية (البحث عن الأوقات المتاحة، حجز الموعد، الإلغاء/إعادة الجدولة، قائمة الانتظار). تجنّب التعمق أكثر من ثلاثة مستويات — يفوق الحمل الإداري للهيكل العميق الفائدة المرجوة منه.

مثال عملي: سداد مدفوعات المتجر الإلكتروني

تخيّل أنك تلقيت هذه البنود الستة الخام من مشروع إعادة تصميم صفحة الدفع:

1. "يجب أن يتمكن العملاء من الدفع ببطاقة." (مدير التسويق)
2. "نحتاج Stripe لمدفوعات البطاقة." (المدير التقني)
3. "يجب أن يقبل النظام PayPal." (مدير نجاح العملاء)
4. "يجب أن تستوفي مدفوعات البطاقة متطلبات PCI-DSS." (المالية)
5. "يجب أن تُحمَّل صفحة الدفع في أقل من ثانيتين." (مدير تجربة المستخدم)
6. "يجب أن تكون صفحة الدفع سريعة." (مدير التسويق)

التحليل:

• البندان 1 و2 — دمج مع مراعاة الدقة: الحاجة الجوهرية هي الدفع بالبطاقة، لكن البند 2 يحدد تفصيلًا تقنيًا (Stripe). سجّلهما معًا؛ وضع علامة على البند 2 كقيد تصميمي لتقييمه، لا كمتطلب خالص.
• البندان 5 و6 — تكرار حقيقي: ادمجهما في متطلب أداء واحد؛ احتفظ بالمقياس المحدد في البند 5 (أقل من ثانيتين) بدلًا من الصياغة المبهمة "سريعة".
• البند 3 — لا تعارض مع البندَين 1/2؛ PayPal إضافي. أبقه متطلبًا منفصلًا.
• البند 4 — متطلب غير وظيفي (امتثال)؛ جمّعه منفصلًا تحت الأمن والامتثال.

بعد التحليل، لديك أربعة متطلبات بدلًا من ستة: دعم الدفع بالبطاقة، ودعم PayPal، وامتثال PCI-DSS، وأداء صفحة الدفع — مجمّعة في موضوعَين: طرق الدفع والمتطلبات غير الوظيفية.

الحفاظ على قابلية التتبع خلال العملية

يجب أن يكون كل قرار دمج أو تقسيم أو تجميع قابلًا للتتبع. عندما يقول متطلب رسمي في وثيقة SRS: "REQ-012: يجب أن يرسل النظام تذكيرات المواعيد عبر البريد الإلكتروني والرسائل النصية"، يجب أن يتمكن القارئ من معرفة العناصر الخام التي أنتجته (مثلًا R-04، وR-17، وR-23) وأصحاب المصلحة الذين طرحوها. هذا التتبع هو سجل مراجعتك وبوليصة تأمينك خلال نزاعات النطاق.

ملاحظة تتبع بسيطة في جدول البيانات — "REQ-012 مشتق من R-04 (مدير الجناح)، R-17 (ممثل المريض)، R-23 (مدير تكنولوجيا المعلومات) — تم الدمج لأن الحدث الإخطاري واحد مع توحيد القنوات" — تستغرق ثلاثين ثانية ويمكنها توفير ساعات من الجدل بعد أشهر.

الأخطاء الشائعة

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