لماذا يجب على مهندس البرمجيات فهم متطلبات البرمجيات؟ دليل شامل

في عالم هندسة البرمجيات المتسارع، لا يقتصر دور مهندس البرمجيات على كتابة الأكواد فحسب، بل يتجاوز ذلك إلى فهم عميق لمتطلبات الحلول التي يبنيها. يهدف هذا المقال إلى تسليط الضوء على الأهمية المحورية لمتطلبات البرمجيات، العملية المرتبطة بها، والأهم من ذلك، مسؤولياتك كمهندس برمجيات في هذا المجال الحيوي. سنستعرض هنا رؤى مستخلصة من دليل IEEE SWEBOK، الذي يُعد مرجعاً شاملاً لهيئة المعرفة في هندسة البرمجيات (Software Engineering Body of Knowledge) وتُشرف عليه جمعية الحاسوب IEEE Computer Society، مع التركيز على تبسيط المفاهيم وتقديمها بشكل عملي ومفيد.

لماذا تُعد متطلبات البرمجيات بهذا القدر من الأهمية؟

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

ما هي متطلبات البرمجيات (Software Requirements)؟

قد تبدو متطلبات البرمجيات (Software Requirements) بسيطة في ظاهرها: يجب أن يقوم البرنامج بالوظيفة X لـ Y بحيث يحقق Z. إذا فكرت في أي مشكلة يمكن للبرمجيات حلها (أو برنامج موجود يحل مشكلة بالفعل) وتمكنت من استخلاص عدد كبير من المتطلبات، فهل هذا سهل؟ في الواقع، ليس كذلك بالنسبة لمعظم برمجيات المؤسسات. كيف تجمع متطلباتك؟ هل تأخذ في الاعتبار احتياجات وأولويات أصحاب المصلحة (stakeholders)؟ هل هذا حقاً مطلب لمستخدمي البرنامج؟ هل هناك قيود أو اعتبارات تقنية؟ كيف تعرف متى تم إنجاز العمل؟ هل يلبي تنفيذ المتطلب معياراً محدداً؟ وهكذا…

عندما تبدأ في التعمق في فكرة متطلبات البرمجيات، تكتشف أنها تخفي مجالاً معرفياً واسعاً وعميقاً. فما مدى عمق واتساع هذا المجال؟ يُعرّف دليل SWEBOK مجال متطلبات البرمجيات بأنه “يهتم باستخلاص متطلبات البرمجيات وتحليلها وتحديدها والتحقق من صحتها، بالإضافة إلى إدارة المتطلبات طوال دورة حياة المنتج البرمجي بأكملها”. إن حجم هذا المجال، وعدد الأنشطة ومدى تعقيد كل منها، أعطى مصداقية كافية لتخصيص فرع من فروع الهندسة يُعرف باسم “هندسة المتطلبات” (requirements engineering) يركز بشكل حصري على عملية المتطلبات.

قد توظف بعض المنظمات متخصصين في دور مهندس المتطلبات (requirements engineer)، خاصة في المؤسسات الكبيرة جداً التي تقدم حلولاً على مستوى الأنظمة، حيث تشمل حلولها المقترحة لمشاكل العملاء حلاً شاملاً يكون البرنامج مجرد مكون واحد منه. ولكن بشكل أكثر شيوعاً، تميل المنظمات إلى مشاركة مسؤولية هندسة المتطلبات من خلال أنشطة موزعة بين أدوار المشروع المختلفة، مثل المصممين (designers)، ومحللي الأعمال (business analysts)، ومالكي المنتجات (product owners)، وإدارة العروض أو العملاء، والكتاب التقنيين (technical writers)، ومهندسي/معماريي البرمجيات (software architects/engineers)، وغيرهم.

بشكل عام، من الصعب تطبيق عملية المتطلبات في مسار خطي عملياً، مثل منهجية الشلال (waterfall methodology). يتطلب ذلك استخلاص متطلبات البرمجيات من أصحاب المصلحة، وتصنيفها، وتخصيصها، ثم تسليمها في النهاية للتنفيذ من قبل فريق تطوير البرمجيات. غالباً ما لا يكون هذا ممكناً للحلول الناجحة على المدى الطويل وعلى نطاق واسع. فمتطلبات مشاريع البرمجيات الكبيرة لا تكون مفهومة تماماً أو محددة بشكل مثالي أبداً. بدلاً من ذلك، يتم تكرارها عادةً للوصول إلى مستوى كافٍ من الجودة والتفاصيل يسمح باتخاذ قرارات التصميم والمشتريات. تختلف هندسة المتطلبات عن هندسة البرمجيات في نوع العمل الذي تركز عليه. من المهم أن تفهم ارتباطك بعملية المتطلبات، حيث من المرجح أن تشارك بشكل عام في بعض أنشطة المتطلبات في مرحلة ما.

ما هو دور مهندس البرمجيات في متطلبات البرمجيات؟

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

• Elicitation (الاستخلاص): جمع المتطلبات للبرمجيات.
• Classification (التصنيف): تصنيف المتطلبات.
• Validation (التحقق): تأكيد المتطلب مع أصحاب المصلحة.
• Development & Implementation (التطوير والتنفيذ): بناء البرمجيات لتلبية المتطلب.
• Negotiation (التفاوض): التعامل مع تضارب المصالح بين أصحاب المصلحة.
• Verification (التحقق الفني): تقييم ما إذا كانت وظيفة البرنامج تلبي المتطلب.

من الجدير بالذكر أن هذا ليس تكراراً لعملية هندسة المتطلبات (requirements engineering process) بأكملها، حيث تتطلب الأخيرة مستوى أعمق من المشاركة وأنواعاً محددة من الأنشطة في مجالات معينة، مثل إدارة المتطلبات وتوثيقها. عادةً ما لا تكون إدارة المتطلبات وتوثيقها مسؤوليتك المباشرة، بل تكون مسؤولية أحد الأدوار الأخرى التي تشارك في مسؤولية المتطلبات.

أهمية الوصول إلى أنظمة إدارة المتطلبات

من الأهمية بمكان أن تعرف كيفية الوصول إلى نظام إدارة المتطلبات واستخدامه لتقييم التغييرات في المتطلبات وتحليل تأثيرها (impact analysis).

عند غياب نظام مخصص لإدارة المتطلبات

في بعض الحالات، قد لا يتم تسجيل المتطلبات وإدارتها في نظام متخصص. يمكن تسجيلها في أنواع أخرى من أنظمة التسجيل، مثل برامج تتبع المشكلات (issue tracking software)، أو أدوات إدارة المشاريع (project management tools)، أو حتى نظام التحكم في الإصدار (version control system). في حالات أخرى، لا تقوم المنظمات أو فرق المشروع بتطوير وسيلة لتوثيق وإدارة المتطلبات. بدلاً من ذلك، قد يعتمدون على رؤية القيادة (فرد أو فريق، والمثال الشائع هو مؤسس الشركة) و/أو لديهم موارد محدودة. قد يجادلون بأن تسجيل أو إدارة المتطلبات ليس ضرورياً.

عدم تسجيل وإدارة المتطلبات يمكن أن يشكل خطراً جدياً على المنظمة وعملية حلول البرمجيات. على سبيل المثال، ستضطر مؤسستك، التي تطور حلولاً لاحتياجات العملاء، إلى تلبية التزامات قانونية معينة. ستنص هذه الالتزامات على أن مكون برنامجك مصمم لتوفير وظائف معينة وقادر على تقديم مستوى خدمة محدد (SLAs). ولكن إذا نشأ نزاع (قانوني أو غير ذلك)، ربما بسبب وظيفة مفقودة، أو متطلب غير وظيفي (non-functional requirement) لم يعمل كما هو متوقع، أو حتى وقت/ميزانية تم إنفاقها على ميزات غير مرغوبة، فكيف يمكنك إثبات أن ما تم تنفيذه كان ما تم الاتفاق عليه من قبل أصحاب المصلحة كمتطلب وضروري؟

يجب أن تكون مؤسستك قادرة على إظهار الربط بين متطلبات الحل عالية المستوى (ما يحتاجه العميل كحل) ومتطلبات البرمجيات التي تم التحقق منها (ما وافق عليه أصحاب المصلحة على أنه يلبي الاحتياجات الوظيفية للحل، وليس بالضرورة تطابقاً واحداً لواحد) وصولاً إلى توثيق التنفيذ وتسجيل اختبارات القبول أو مستوى الخدمة التي تثبت الوظائف المقدمة.

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

استخلاص متطلبات البرمجيات (Elicitation)

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

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

من أين تأتي متطلبات البرمجيات؟

هناك العديد من مصادر المتطلبات، منها:

• الأهداف (المعروفة أيضاً باسم Business Concern، Critical Success Factor، إلخ).
• معرفة المجال (Domain Knowledge).
• أصحاب المصلحة (Stakeholders).
• قواعد العمل (Business rules).
• بيئة التشغيل (Operational environment).

مسؤولياتك في عملية استخلاص المتطلبات

إذا كنت مشاركاً في استخلاص المتطلبات من مصادرها، فستحتاج إلى:

• الاهتمام الخاص بالأهداف: غالباً ما تكون هذه الأهداف غامضة بشكل عام، مثل “يجب تنفيذ البرنامج باستخدام أفضل الممارسات” أو “يجب أن يكون البرنامج سهل الاستخدام”.
• تقييم القيمة النسبية لأولوية الحل: ودراسة الطرق منخفضة التكلفة نسبياً لتحقيقها.
• اكتساب أو توفير المعرفة حول مجال التطبيق (application domain): يوفر لك هذا معلومات أساسية تمنحك فهماً للأسباب الكامنة وراء المتطلبات. يُعد تطوير نماذج للمشكلة الواقعية، مثل نماذج علاقة الكيان (entity relationship models)، أمراً أساسياً لتحليل متطلبات البرمجيات الجيد. حاول التفكير باستخدام نهج أنطولوجي (ontological approach).
• تحديد وتمثيل وإدارة وجهات نظر أنواع مختلفة من أصحاب المصلحة: قد تكون المتطلبات متضاربة، أو متداخلة، أو تتطلب دوافع مختلفة في أجزاء من احتياجات أصحاب المصلحة المختلفين. من المهم أن تدرك الاحتياجات المختلفة، خاصة في التخطيط المسبق للتنفيذ، حيث يتم دمج الاحتياجات في التصميم.
• إظهار الحساسية لبيئة تشغيل الحل: ستخضع بيئة التشغيل لهيكل المنظمة وثقافتها وسياساتها الداخلية. المبدأ العام الذي يجب أن تسعى برمجياتك لتحقيقه هو عدم إدخال تغييرات غير مخططة أو قسرية على عمليات الأعمال في المنظمة.

تقنيات استخلاص متطلبات البرمجيات

بعض التقنيات الرئيسية التي قد تشارك فيها (مقدماً الخبرة التقنية) يمكن أن تشمل:

• إجراء مقابلات مع أصحاب المصلحة (stakeholder interviews).
• تحديد السيناريوهات (scenarios).
• بناء النماذج الأولية (prototypes).
• المراقبة في منطقة المشكلة.
• قصص المستخدم (user stories).

عند بناء النماذج الأولية، المبدأ العام الذي يجب أن تحاول اتباعه هو استخدام النماذج الأولية منخفضة الدقة (low fidelity prototypes) بشكل متكرر في هذه المراحل المبكرة. يُفضل ذلك لتجنب تركيز أصحاب المصلحة على الخصائص الثانوية أو العرضية. فالنموذج الأولي عالي الجودة يمكن أن يحد من مرونة التصميم بطرق غير مقصودة.

تصنيف متطلبات البرمجيات (Classification)

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

• وظيفية / غير وظيفية (Functional / Non-functional):
  • المتطلبات الوظيفية (Functional requirements): تصف الوظائف التي يجب أن ينفذها البرنامج. على سبيل المثال، توفير قناة اتصال للمستخدم أو نقل البيانات من تنسيق إلى آخر. يمكن أن تُعرف أيضاً بميزات أو قدرات المنتج.
  • المتطلبات غير الوظيفية (Non-functional requirements): تعمل على فرض قيود معينة على الحل، وغالباً ما تكون من حيث الجودة. يمكن تصنيف هذه المتطلبات بشكل أكبر إلى أنواع عديدة من “القدرات” (-ilities) مثل التوافر (availability)، والموثوقية (reliability)، وقابلية الاسترداد (recoverability)، وقابلية الصيانة (maintainability)، وقابلية التوسع (scalability)، والأداء (performance)، والأمان (security)، إلخ.
• مشتقة / مفروضة / ناشئة (Derived / Imposed / Emergent):
  • هل المتطلب مشتق من متطلبات أخرى؟
  • هل المتطلب مفروض بشكل صريح من قبل صاحب مصلحة؟
  • هل المتطلب خاصية ناشئة (emergent property)؟ بمعنى آخر، لا يمكن معالجته بواسطة مكون واحد ولكنه يعتمد على كيفية تفاعل جميع مكونات البرنامج.
• عملية / منتج (Process / Product):
  • هل المتطلب متعلق بالمنتج؟ (مثال: “يجب أن يتحقق البرنامج من أهلية الشخص”).
  • هل المتطلب متعلق بالعملية؟ (مثال: “يجب تطوير البرنامج بشكل تدريجي واستخدام سير عمل التكامل المستمر والنشر المستمر (continuous integration and deployment workflows)”).
• الأولوية (Priority): موازنة تكلفة التطوير والتنفيذ مقابل الحاجة إلى التسليم. يمكن استخدام مقياس ثابت مثل إلزامي (mandatory)، مرغوب جداً (highly desirable)، مرغوب (desirable)، واختياري (optional).
• النطاق (Scope): يستخدم للنظر في التأثير على بنية البرنامج وتصاميم المكونات. غالباً ما تكون المتطلبات غير الوظيفية ذات نطاق عالمي.
• التقلب / الاستقرار (Volatility / Stability): إمكانية تغيير المتطلب خلال دورة حياة البرنامج. سيساعد هذا في تنفيذ تصاميم تتحمل التغييرات.

التحقق من صحة متطلبات البرمجيات (Validation)

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

إذا اتبعت منهجية تطوير تكرارية (iterative development method)، يمكن إجراء التحقق من صحة المتطلبات بانتظام، أو فصلها حسب النطاق حول مناطق حل محددة، أو تنفيذها على دفعات (chunks)، أو أي نوع آخر من الفصل الذي يكون منطقياً. عادةً ما يتضمن التحقق من صحة المتطلب قيام فريق الحل بإعادة عرض فهمهم للمتطلب لأصحاب المصلحة. يمكن أن يتضمن أيضاً تصميماً أولياً (تجارياً أو تقنياً، أو كليهما) يوضح كيفية تنفيذ كل من احتياجات أصحاب المصلحة. يتم إنشاء هذه الفهوم بشكل تكراري خلال مراحل التخطيط وتتكون عادةً من وجهات نظر فريق متعدد الوظائف (cross-functional team) (مصممين، محللي أعمال، خبراء تقنيين). في بعض الحالات، قد يتطلب التصميم بعض الأعمال التحضيرية قبل التنفيذ لإظهار فهم الفريق بشكل أفضل، عادةً في شكل نموذج أولي وظيفي (functional prototype).

أثناء التحقق من الصحة، قد لا يتمكن فريقك من تلبية متطلبات كل صاحب مصلحة بشكل مثالي. ستكون مسؤوليتك كخبير تقني هي إظهار ومناقشة المقايضات (tradeoffs) التي تتناسب مع القيود. يجب أن تكون مقبولة لأصحاب المصلحة الرئيسيين مع البقاء ضمن القيود المتعلقة بالميزانية والتقنية والتنظيمية وغيرها من التدابير.

استخدام النماذج الأولية الوظيفية (Functional Prototypes)

تُعد النماذج الأولية الوظيفية مفيدة لأنها تتيح ما يلي:

• التحقق من فهم المتطلبات.
• تفسير أسهل لافتراضات المهندس.
• الحصول على ملاحظات يمكن أن توفر متطلبات جديدة.

يجب أن تأخذ في الاعتبار أن أصحاب المصلحة قد يتشتتون بسبب المشكلات الجمالية أو مشكلات الجودة. يمكنك التخفيف من ذلك من خلال التواصل المستمر حول الأهمية الحقيقية للعرض التوضيحي – أي الوظائف الأساسية الكامنة. يتم تحديد كيفية بناء النموذج الأولي من قبل فريق مشروعك. يفضل بعض المؤيدين النماذج الأولية التي تتجنب البرمجيات تماماً (على غرار تلك التي يتم بناؤها عند استخلاص المتطلبات). يفضل آخرون نوعاً من عرض البرمجيات من خلال مجموعات أدوات التصميم (design tool-kits) أو تكرار مسودة سريعة البناء للبرنامج خلف عنصر تحكم ميزة (feature control). يجب أن يأخذ أي خيار يقرره فريقك في الاعتبار سرعة بناء النموذج الأولي مقابل فعالية إظهار الوظائف الأساسية.

تطوير وتنفيذ متطلبات البرمجيات (Development & Implementation)

عندما يتم التحقق من صحة المتطلب مع أصحاب المصلحة، يمكنك البدء في تطوير/تنفيذ المتطلب. في كثير من الحالات، ستعمل كمهندس معماري للبرمجيات (software architect) لأن عملية تحليل المتطلبات وتفصيلها تتطلب تحديد مكونات البنية/التصميم التي ستكون مسؤولة عن تلبية المتطلبات.

من المصالح الرئيسية لمؤسستك تحقيق الربح من الحل البرمجي. تقع على عاتقك مسؤولية محاولة استخدام الأساليب التي تقلل من تكلفة التطوير والصيانة. يمكنك تحقيق ذلك، على سبيل المثال، من خلال إعادة استخدام المكونات (داخلياً أو من منتجات أخرى)، واستخدام أنماط تصميم (design patterns) محددة جيداً، والعمل بأدوات/أطر عمل (tools/frameworks) مجربة وموثقة جيداً. يمكن أن يكون للمتطلبات المحددة، وخاصة القيود، تأثير كبير على تكلفة البرمجيات. على سبيل المثال، إذا كانت مجموعة مهاراتك في التنفيذ ضعيفة، أو ربما كان المتطلب يتعارض أو لا يتناسب مع البنية الحالية. يجب تحديد المقايضات الهامة بين هذه المتطلبات لفريق المشروع.

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

قصة المستخدم (User Story)

غالباً ما يعمل مهندس البرمجيات ضمن سياق مخرج قصة المستخدم (user story). قصة المستخدم هي تمثيل باللغة الطبيعية لتفاعل نوع معين من المستخدمين مع البرنامج والوظائف التي يجب أن يوفرها لهم. عادةً ما تتبع التنسيق التالي:

بصفتي <دور>، أرغب في <هدف/رغبة>، حتى <فائدة>

مثال: بصفتي مسؤول دورة تدريبية (course administrator)، أرغب في رؤية عدد الأشخاص المسجلين في الدورة، حتى أتمكن من معرفة السعة الحالية للدورة.

في بعض الحالات، ستأتي قصة المستخدم مصحوبة بتصميم أو نموذج أولي إذا كانت هذه مطلوبة في مرحلة التحقق من الصحة. من الممكن ألا تكون قصة المستخدم تتمحور حول المستخدم (user-centric) بل مشتقة من خاصية ناشئة (emergent property) أو متطلب غير وظيفي (non-functional requirement). في هذه الحالات، قد تتلقى المتطلب في سياق مخرج مختلف (مثل مواصفات أو مجموعة سيناريوهات).

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

قبل تنفيذ قصة المستخدم، تحقق مما يلي:

• وجود معايير قبول (acceptance criteria) مناسبة، مكتوبة أو متفق عليها مع أصحاب المصلحة، والتي تحدد كيفية تحقيق أهداف قصة المستخدم بالتنفيذ. سيشكل هذا الأساس لاختبارات القبول (acceptance tests) للميزة (بمعنى آخر، الاختبارات التي تثبت أن المتطلب قد تم تحقيقه). قد يشكل هذا أيضاً جزءاً من تعريف الفريق لـ “الانتهاء” ("done") أو الاكتمال.
• أن تصميم النموذج الأولي (إذا تم إنشاؤه) قابل للتطبيق ويمكن أن يتناسب مع البنية الحالية، والمهارات الهندسية، والأدوات المعتمدة للاستخدام في المشروع.
• أي افتراضات تدعم المتطلب. يمكن أن يسلط هذا الضوء على فجوات في المعرفة، أو مشاكل محتملة، أو سيناريوهات/حالات حافة (edge cases) أخرى لم يتم أخذها في الاعتبار وتتطلب مزيداً من التوضيح من أصحاب المصلحة.

التفاوض على متطلبات البرمجيات (Negotiation)

عند تنفيذ متطلب ما، من المحتمل ألا يتم تلبية كل مصلحة من مصالح أصحاب المصلحة بشكل مثالي. يمكن أن يحدث هذا، على سبيل المثال، بين المتطلبات الوظيفية وغير الوظيفية، أو عندما يؤثر تنفيذ متطلب واحد على مصلحة صاحب مصلحة آخر. في معظم الحالات، من غير الحكمة أن تتخذ قراراً من جانب واحد. بدلاً من ذلك، تقع على عاتقك مسؤولية تقييم المشكلة، والتواصل ببساطة، والتفاوض على مقايضات (tradeoffs) مقبولة لأصحاب المصلحة الرئيسيين مع البقاء ضمن القيود المتعلقة بالميزانية والتقنية والتنظيمية وغيرها.

التحقق من متطلبات البرمجيات (Verification)

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

يتحقق مهندس البرمجيات من المتطلب باستخدام اختبار قبول (acceptance test). يوضح اختبار القبول كيف تم إكمال المتطلب (تلبية معايير القبول) من خلال إظهار سلوك المستخدم النهائي وهو يقوم بأعماله مع البرنامج كما هو محدد في المتطلب. في المتطلبات التي يصعب فيها إظهار التحقق، مثل المتطلبات غير الوظيفية، قد تكون هناك حاجة إلى محاكاة مصممة. على سبيل المثال، لاختبار حمل الأداء لبرنامج ينفذ عملية استيعاب، يمكن إنشاء برنامج اختبار لمحاكاة مئات أو آلاف التطبيقات للنظام في اختبار قبول الصندوق الأسود (black-box acceptance test).

مع تطور البرمجيات بمرور الوقت، قد يؤثر تنفيذ متطلب جديد عن غير قصد على تحقيق متطلب تم تنفيذه مسبقاً. يمكن الحماية من هذا التراجع (regression) عن طريق أتمتة اختبارات القبول. يمكنك العثور على العديد من الأدوات والمكتبات المتاحة للغات البرمجة المستخدمة بشكل عام من قبل المؤسسات التي تمكن من أتمتة اختبارات القبول. لا تخلط بين اختبار القبول ومسؤوليتك الوحيدة في الاختبار. حاول تغطية التنفيذ بشكل كافٍ باختبارات أخرى غير القبول، مثل اختبارات الوحدة (unit tests) أو اختبارات التكامل (integration tests).

تختلف اختبارات القبول في مستوى التعقيد اعتماداً على معايير القبول. يمكن للمنظمات المختلفة أيضاً استخدام مصطلحات وممارسات مختلفة، مما يعني أنه يمكن الخلط بينها وبين أنواع أخرى من الاختبارات أو الإشارة إليها بأسماء مختلفة، مثل اختبار شامل (end-to-end testing)، أو اختبار وظيفي (functional testing)، أو اختبار السيناريو (scenario testing). قد يكون لمؤسستك أيضاً معايير أو تنسيقات صارمة يتم فيها عرض اختبارات القبول. تذكر أن جوهر كل اختبار قبول هو ببساطة تحقق رسمي من أن الحل المنفذ يلبي متطلب البرنامج عن طريق محاكاة سلوكيات المستخدم على تطبيق قيد التشغيل مقابل المنتج النهائي.

الخلاصة التقنية

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