يبدأ تحليل وتصميم النظم بفهم حاجة العمل، ثم تحديد كيفية بناء حل يلبيها. يسأل التحليل: ما المشكلة، وماذا يحتاج المستخدم؟ ويسأل التصميم: كيف ننظم البيانات والواجهات والإجراءات لتنفيذ المطلوب؟ تتصل المرحلتان، لكن اختيار شكل الشاشة لا يغني عن تحديد القاعدة التي يجب أن تعمل وراءها. [1]
التحليل: ابدأ بما يحدث فعلًا
تستخلص المتطلبات من احتياجات المستخدمين وأصحاب المصلحة، ثم توثق وتراجع وتربط بما سينفذ. تفيد المقابلات وحالات الاستخدام والمخططات في كشف ما لا يوضحه طلب عام مثل «نريد نظامًا سهلًا». ويجب التعامل مع التعارضات والتغييرات، لا اعتبار أول قائمة من الطلبات نهائية. [2]
في مثال تعليمي، يريد مركز تدريب تنظيم حجز قاعة. عبارة «أضف زر حجز» تصف جزءًا من الواجهة. أما «لا يعتمد النظام حجزين يتداخل زمنهما للقاعة نفسها» فتحدد سلوكًا يمكن فحصه. يحتاج المحلل أيضًا إلى معرفة من يعتمد الحجز، ومن يلغي طلبًا، وكيف يبلغ المستخدم بالنتيجة.
متطلبات وظيفية وأخرى تصف الجودة
المتطلب الوظيفي يحدد ما يؤديه النظام، مثل تسجيل حجز أو إلغائه. والمتطلب غير الوظيفي يصف شروطًا كالأداء أو الأمان أو قابلية الاستخدام. توثيق هذه الشروط وربطها بالمكونات والاختبارات يساعد على تقليل الالتباس عند التنفيذ والمراجعة. [2]
لا تكتفِ في مثال القاعة بوصف النظام بأنه «سريع وآمن». حدد سيناريو قياس الأداء وحجم الاستخدام المقبول مع الجهة المستفيدة، وعيّن الأدوار التي يسمح لها بتعديل الحجوزات. لا نختار هنا رقم سرعة عشوائيًا؛ المطلوب أن يصبح الشرط متفقًا عليه وقابلًا للتحقق.
التصميم: حوّل الحاجة إلى ترتيب واضح
يشمل التصميم بنية الحل، وواجهاته، وتنظيم قاعدة البيانات، وعلاقته بالأنظمة الأخرى. وقد يستخدم الفريق نموذجًا أوليًا للحصول على ملاحظات المستخدمين قبل استكمال التنفيذ. وثيقة التصميم تبين كيف ستترجم المتطلبات إلى أجزاء تعمل معًا؛ وليست مجرد رسم لشكل الأزرار. [1]
في نظام القاعة، يتضمن سجل الحجز معرف القاعة وبداية الفترة ونهايتها وحالة الطلب. ويحتاج التصميم إلى فحص التعارض قبل اعتماد الطلب، ثم إظهار تفسير مفهوم عند الرفض. هذه اختيارات تخدم المتطلب المحدد؛ لا يكفي حفظ طلبين في جدول إذا ظل التداخل ممكنًا عند اعتمادهما.
اربط المتطلب باختبار
عرّف في مثالنا أن نهاية الحجز تسمح ببداية حجز آخر فورًا. إذا كانت القاعة محجوزة من التاسعة إلى العاشرة، يرفض طلب من التاسعة والنصف إلى العاشرة والنصف، ويقبل طلب من العاشرة إلى الحادية عشرة عند عدم وجود حجز آخر. أما حجز الفترة نفسها لقاعة ثانية فلا يتعارض مع الأول.
هذه الحالات تفحص البداية والنهاية ومعرف القاعة. وإذا كانت المؤسسة تحتاج وقت تجهيز بين الحجزين، يتغير المتطلب وتتغير الاختبارات معه. لذلك لا تنقل حكم «مقبول» من مثالنا إلى مؤسسة تضع قاعدة زمنية مختلفة.
المراجعة تستمر أثناء التطوير
تأتي البرمجة والاختبارات والنشر والصيانة ضمن دورة التطوير. وقد يعمل الفريق بطريقة تكرارية فيعود إلى المتطلبات والتصميم بعد تجربة نسخة مبكرة. تختلف نماذج التطوير، وتبقى فائدة التحليل والتصميم في إبقاء الحل مرتبطًا بحاجات واضحة وأدلة على تلبيتها. [1]
المصادر ومتابعة القراءة
- IBM: دورة حياة تطوير البرمجيات؛ التحليل والتصميم والتطوير والاختبار (يفتح في نافذة جديدة)ibm.com
- IBM: إدارة المتطلبات وتوثيقها وتتبعها مع أصحاب المصلحة (يفتح في نافذة جديدة)ibm.com
أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.
