جمع المتطلبات وتوضيحها

جمع المتطلبات وتوضيحها

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

فئتا المتطلبات

لكل نظام نوعان متكاملان من المتطلبات، ولا بد من جمعهما كليهما قبل رسم أي هيكل.

المتطلبات الوظيفية (FR)

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

• يستطيع المستخدم رفع فيديو بحجم يصل إلى 5 GB.
• يوصل النظام رابطاً مختصراً يُعيد التوجيه إلى الأصلي في أقل من 50 ms.
• يستطيع الركاب تتبع موقع السائق مباشرةً على الخريطة.
• تعرض خدمة التغذية المنشوراتِ من الأشخاص الذين يتابعهم المستخدم مرتبةً حسب الحداثة.

المتطلبات الوظيفية تُنتج مباشرةً الكيانات الأساسية (المستخدم، الفيديو، الرابط، الرحلة) وواجهات API (POST /upload, GET /{shortCode}) لتصميمك. أخطئ في هذه وسيحل هيكلك كله مشكلةً لم يطلبها أحد.

المتطلبات غير الوظيفية (NFR)

المتطلبات غير الوظيفية تصف مدى جودة أداء النظام — صفات كالأداء والحجم والموثوقية والأمان. وهي تجيب عن: "ما القيود التي يجب أن يستوفيها النظام؟"

• الحجم: 500 مليون مستخدم نشط يومياً؛ 10 مليارات إعادة توجيه يومياً.
• زمن الاستجابة: زمن القراءة عند الشريحة التاسعة والتسعين < 100 ms؛ ترميز الفيديو خلال 5 دقائق.
• التوافرية: 99.99 % وقت تشغيل (52 دقيقة توقف في السنة).
• الاتساق: الاتساق التدريجي مقبول للإعجابات؛ يُشترط اتساق قوي لأرصدة المدفوعات.
• المتانة: الملفات المرفوعة يجب أن تصمد أمام فشل أي مركز بيانات منفرد.
• الأمان: تشفير جميع بيانات المستخدمين في وضع السكون وأثناء النقل؛ الامتثال لـ GDPR مطلوب.

المتطلبات غير الوظيفية هي اليد الخفية التي تفرض خيارات معمارية بعينها. هدف 99.99 % توافرية يستبعد قواعد البيانات أحادية العقدة. زمن قراءة أقل من 100 ms يستبعد جلب البيانات الطازجة من نسخة احتياطية بعيدة في كل مرة. هذه الأرقام تأتي من المُحاوِر أو وثيقة المنتج — لا تخترعها أبداً.

القيود والافتراضات

إلى جانب المتطلبات الوظيفية وغير الوظيفية، يجب عليك إبراز فئتين إضافيتين صراحةً:

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

الأسئلة الخمسة التوضيحية التي يجب دائماً طرحها

تختلف الأسئلة من مشكلة لأخرى، لكن هذه الخمسة تغطي الغالبية العظمى من سيناريوهات تصميم الأنظمة:

1. الحجم: "كم عدد المستخدمين النشطين يومياً الذين نتوقعهم؟ ما معدل الطلبات في الثانية عند الذروة؟" — هذا يحدد ما إذا كنت تحتاج معمارية أحادية أو عدة خدمات أو نظاماً موزعاً كاملاً.
2. نسبة القراءة إلى الكتابة: "هل هذا النظام ثقيل القراءة أم الكتابة أم متوازن؟" — نسبة 100:1 قراءة إلى كتابة تشير إلى التخزين المؤقت العدواني والنسخ الاحتياطية للقراءة. نسبة 1:1 تشير إلى تحسين معدل إنتاجية الكتابة.
3. حجم البيانات: "كم من البيانات سنخزّن؟ ما متوسط حجم الحمولة لكل سجل؟" — هذا يدفع اختيارات تقنية التخزين والحاجة إلى التجزئة.
4. الاتساق مقابل التوافرية: "هل يُقبَل أن يرى المستخدم بيانات قديمة قليلاً؟ ماذا يحدث لو حدّث مستخدمان السجل ذاته في آنٍ واحد؟" — هذا يتعلق مباشرةً بمقايضة نظرية CAP.
5. اتفاقية مستوى الخدمة للاستجابة: "ما وقت الاستجابة المقبول من منظور المستخدم؟ هل ثمة هدف لزمن الاستجابة عند الشريحة التاسعة والتسعين؟" — أقل من 10 ms يستلزم ذاكرات تخزين مؤقت داخل الذاكرة؛ أقل من 100 ms يتيح قواعد البيانات العلاقية المُفهرسة جيداً.

مثال عملي: تصميم مختصر روابط

دعنا نستعرض مرحلة جمع المتطلبات لمختصر روابط — وهي مسألة تصميم أنظمة كلاسيكية.

المتطلبات الوظيفية المستخرجة عبر الحوار:

• يستطيع المستخدم إرسال رابط طويل واستقبال رمز قصير (مثلاً short.ly/aB3xK).
• كل من يزور الرابط القصير يُعاد توجيهه إلى الأصلي في أقل من 50 ms.
• اختياري: يمكن للمستخدمين إنشاء اختصارات مخصصة.
• اختياري: يمكن أن تنتهي صلاحية الروابط بعد مدة زمنية قابلة للضبط.
• خارج النطاق (تم التأكيد): لوحة التحليلات، حسابات المستخدمين، الخطط المدفوعة.

المتطلبات غير الوظيفية المستخرجة:

• 100 مليون رابط جديد يومياً؛ 10 مليارات إعادة توجيه يومياً (100:1 قراءة/كتابة).
• زمن إعادة التوجيه عند الشريحة 99 أقل من 50 ms.
• توافرية 99.99 % — الخدمة مضمّنة على نطاق واسع في محتوى خارجي.
• الروابط بمجرد إنشائها غير قابلة للتعديل؛ الاتساق التدريجي للنسخ الاحتياطية مقبول.
• الاحتفاظ بالبيانات: تخزين الروابط لمدة 5 سنوات على الأقل.

الافتراضات المُعلنة صراحةً:

• متوسط طول الرابط الطويل ≈ 100 بايت؛ الرمز القصير ≈ 7 أحرف.
• تقدير التخزين: 100 مليون × 365 × 5 سنوات × ≈ 500 بايت/سجل ≈ 91 TB على مدى 5 سنوات.
• معدل طلبات إعادة التوجيه عند الذروة ≈ 10 مليارات / 86,400 ثانية ≈ 115,000 طلب/ثانية (مع عامل ذروة 3× ≈ 345,000 طلب/ثانية).

جمع المتطلبات كحوار

في المقابلة، جمع المتطلبات هو حوار منظم وليس استجواباً. النموذج الذهني المفيد هو القمع: ابدأ بعمومية ثم ضيّق تدريجياً.

تحديد الأولويات: إطار MoSCoW في تصميم الأنظمة

ليست كل ميزة ذات أهمية متساوية. طبّق إطار MoSCoW على المتطلبات الوظيفية:

• Must Have (يجب توافره): النظام بلا فائدة بدونها. (اختصار الروابط، إعادة التوجيه.)
• Should Have (ينبغي توافره): قيمة عالية، لكن يمكن شحنه في تكرار لاحق. (اختصارات مخصصة، مدة الانتهاء.)
• Could Have (يُحبذ توافره): جيد لو أتاح الوقت. (توليد رمز QR.)
• Won't Have (لن يتوفر الآن): خارج النطاق صراحةً. (لوحة التحليلات، الفوترة.)

في مقابلة مدتها 45 دقيقة، التصميم من أجل كل "يُحبذ" هو فخ. وضع الميزات صراحةً في "لن يتوفر الآن" يُظهر تحديد الأولويات على مستوى المهندسين الكبار ويُبقي التصميم مُركّزاً على ما يهم فعلاً.

توثيق المتطلبات

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

النظام: مختصر الروابط

الوظيفي (يجب توافره):
  - POST /shorten  → قبول رابط طويل، إرجاع رمز قصير
  - GET  /{code}   → إعادة توجيه إلى الرابط الأصلي (<50 ms)

الوظيفي (ينبغي توافره):
  - دعم الاختصارات المخصصة
  - انتهاء صلاحية الرابط (مدة قابلة للضبط)

خارج النطاق: التحليلات، حسابات المستخدمين، الميزات المدفوعة

غير الوظيفي:
  - الحجم: 100 مليون كتابة/يوم، 10 مليارات قراءة/يوم (100:1)
  - زمن الاستجابة: الشريحة 99 لإعادة التوجيه < 50 ms
  - التوافرية: 99.99 %
  - الاتساق: تدريجي للقراءات مقبول؛ قوي للكتابات
  - التخزين: ~91 TB على مدى 5 سنوات

الافتراضات:
  - متوسط حجم السجل ~500 بايت
  - معدل طلبات القراءة عند الذروة ~345,000 طلب/ثانية
  - توزيع المستخدمين عالمي

هذه الوثيقة هي عقد بنيتك. كل قرار تتخذه من هنا يجب أن يرتبط بأحد هذه البنود. إذا كان مكوّن مقترح لا يخدم أي متطلب، احذفه.