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

الفخ ديال التصنيف

واحد الغلط شائع فالهندسة ديال السوفتوير هو أننا كنسميو أي «قاعدة» (rule) بأنها Non-Functional Requirement (NFR). إلا كانت القاعدة كتحكم كيفاش البيزنس كيخدم—مثلاً «المريض ما يمكنش يحجز جوج مواعيد فدقة وحدة»—هادي راها Business Rule ماشي technical constraint. قواعد البيزنس كتقول لينا شنو خاص يوقع (behavior)، أما القيود التقنية ومتطلبات الجودة كتقول لينا كيفاش خاص السيستيم يخدم (performance, durability, environment).

قواعد البيزنس (Business Rules) مقابل القيود التقنية (Technical Constraints)

قواعد البيزنس هي سلوكيات نقدروا نشوفوها ونقيسوها. غالباً كتكون عبارة عن منطق (logic) خاصو يكون صحيح باش العملية تدوز. كنختبروها بـ functional test cases (Given/When/Then).

القيود التقنية هي حدود ما فيهاش النقاش. بحال لغة البرمجة اللي مفروضة، القوانين ديال حماية المعطيات (GDPR)، أو ليميت ديال الماتيريال. هادو كنتأكدو منهم بـ audits أو بـ environment checks.

متطلبات الجودة (NFRs) هي خصائص ديال الخدمة ديال السيستيم. كلمات بحال «سريع» أو «سيكوريزي» ما عندهم حتى معنى تقني؛ خاصنا نحولوهم لمقاييس ملموسة.

مثال تطبيقي: بورتال مواعيد ديال كلينيك

تخيل بورتال فين المرضى كيحجزوا مواعيد مع الطبا. خاصنا نحولو الطلبات الغامضة ديال الكليان لـ requirement matrix قابلة للاختبار.

جدول تحويل المتطلبات

طلب الكليان	التصنيف	المتطلب التقني الدقيق	كيفاش نقيسوه (Acceptance Measure)
“ما يكونش double booking”	Business Rule	السيستيم خاصو يرفض الحجز إلا كان الطبيب عندو موعد آخر فديك الساعة.	Test case: نحاول نحجز 10:00 صباحاً عند Dr. X جوج مرات → المرة الثانية خاصها تفشل.
”يكون سريع”	Quality (Perf)	نتائج البحث على المواعيد خاصها تطلع فقل من 2 ثواني لـ 50 مستخدم فدقة وحدة.	Load test: 50 virtual users → 95th percentile response time ≤ 2s.
”دخول سيكوريزي”	Business Rule (Auth)	غير اللي عندو rôle ‘Patient’ اللي يقدر يحجز؛ وغير ‘Admin’ اللي يقدر يلغي مواعيد ناس آخرين.	Auth test: مريض يحاول يلغي موعد ديال Admin → 403 Forbidden.
”المعطيات تكون محمية”	Quality (Durability)	إلا طاح السيستيم (crash)، ما خاصناش نفقدو أكثر من 5 دقائق ديال البيانات.	Recovery test: نديرو crash → نتأكدو أن RPO ≤ 5 min.
”يخدم فالتاتليت”	Technical Constraint	الـ frontend خاصو يكون compatible مع Chrome v110+ فـ Android و iOS.	Compatibility test: تجربة يدوية فـ OS/Browser اللي محددين.

التعامل مع الحالات غير الطبيعية (Unhappy Path)

المتطلبات خاصها تبين شنو غادي يوقع إلا فشل شي مسار، ماشي تفرض mechanism بلا سبب. إلا جوج مرضى طلبو نفس الموعد عند نفس الطبيب فدقة وحدة، خاص على الأكثر حجز واحد ينجح والآخر ياخد نتيجة ديال conflit مفهومة. Constraint فالـ DB ولا طريقة مناسبة ديال concurrency خاصها تضمن هادشي؛ تزيد version فـ جوج rows جداد مستقلين ديال المواعيد ما كافياش.

إلا العيادة عندها شروط ديال التأمين ولا التخصص، خاص نسولو عليها ونتأكدو منها. doctorId اللي جا من client ما خاصوش يدوز من checks ديال authorization ولا eligibility. ما نخترعوش سياسة ديال التأمين ملي كنحوّلو كلام عام لمتطلبات.

تمرين

السيناريو: الكلينيك بغاو يزيدو «قاعدة ديال الإلغاء»: المواعيد اللي تالغات قل من 24 ساعة قبل الوقت ديالها، كيخلص عليها المريض غرامة، إلا إذا قدم شهادة طبية.

المطلوب: صنف هاد المتطلب واكتب كيفاش نقدروا نختبروه (acceptance measure).

الجواب :

• التصنيف: Business Rule (Domain Logic).
• كيفاش نقيسوه: نديرو test case لموعد غدا مع 10:00 صباحاً. نحاولوا نلغيوه اليوم مع 11:00 صباحاً (قل من 24 ساعة). نتأكدو أن السيستيم كريا Fee (غرامة) وربطها بـ Patient. من بعد، نعاودو نفس التست ولكن نزيدو MedicalExcuse (شهادة طبية)؛ ونتأكدو أن الغرامة ما تكراتش.