إدارة المتطلبات

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

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

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

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

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

تشمل تكاليف العمل ما يلي: "ما هو القسم الذي لديه الميزانية لهذا؟" "ما هو معدل العائد المتوقع على المنتج الجديد في السوق؟" "ما هو معدل العائد الداخلي في خفض تكاليف التدريب والدعم إذا قمنا بإنشاء نظام جديد أسهل في الاستخدام؟"

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

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

تتمثل مخرجات مرحلة دراسة الجدوى في الميزانية والجدول الزمني للمشروع.

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

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

في معظم الحالات، لا يُجدي الابتعاد عن المتطلبات الأصلية إلى هذا الحد. لذا، تُصبح وثيقة المتطلبات أداةً بالغة الأهمية تُساعد الفريق على اتخاذ قرارات بشأن تغييرات التصميم. ^{[ 8 ]}

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

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

يكاد لا يكتمل أي مشروع لتطوير البرمجيات دون طلب بعض التعديلات عليه. قد تنجم هذه التعديلات عن تغيرات في بيئة استخدام المنتج النهائي، أو تغيرات في بيئة العمل، أو تغييرات في اللوائح، أو أخطاء في التعريف الأصلي للمتطلبات، أو قيود تقنية، أو تغيرات في بيئة الأمان، وما إلى ذلك. تشمل أنشطة إدارة تغييرات المتطلبات استلام طلبات التغيير من أصحاب المصلحة، وتسجيلها، وتحليلها وتحديد مدى ملاءمتها وآلية تنفيذها، وتنفيذ طلب التغيير ، وضمان جودة التنفيذ، وإغلاق طلب التغيير. بعد ذلك، تُجمع بيانات طلبات التغيير وتُحلل، وتُستخلص منها المقاييس المناسبة وتُدمج في مستودع المعرفة المؤسسية. ^{[ 9 ]}

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