تحليل متطلبات البرمجيات مع المثال
تشارلز مور
⚡ ملخص ذكي
يقوم تحليل متطلبات البرمجيات بتقسيم احتياجات أصحاب المصلحة إلى عبارات وظيفية وغير وظيفية، ويصنفها على مستويات الأعمال والهندسة المعمارية والنظام، ثم يتحقق من كل منها مقابل سمات الجودة لضمان قابلية الاختبار. tracمواصفات قابلة للتطبيق وذات أولوية.
متطلبات البرمجيات هي احتياجات وظيفية أو غير وظيفية يجب تلبيتها في النظام. وتعني الاحتياجات الوظيفية توفير خدمة معينة للمستخدم.
على سبيل المثال، في سياق تطبيق مصرفي، فإن المتطلب الوظيفي هو أنه عندما يختار العميل "عرض الرصيد"، يجب أن يكون قادراً على عرض أحدث رصيد لحسابه.
قد يكون متطلب البرنامج غير وظيفي، مثل متطلب الأداء. على سبيل المثال، قد ينص متطلب غير وظيفي على أن يتم تحميل كل صفحة من صفحات النظام للمستخدمين في غضون 5 ثوانٍ.
إذن ، في الأساس متطلبات البرنامج هي أ
- وظيفي أو
- غير وظيفية
حاجة التي يجب تنفيذها في النظام. عادةً ما يتم التعبير عن متطلبات البرامج على شكل عبارات.
أنواع المتطلبات
متطلبات العملهذه متطلبات عامة مستقاة من دراسة جدوى المشروع. على سبيل المثال، يوفر نظام الخدمات المصرفية عبر الهاتف المحمول خدمات مصرفية لجنوب شرق آسيا. المتطلب التجاري المحدد للهند هو ملخص الحساب وتحويل الأموال، بينما هو للصين ملخص الحساب ودفع الفواتير.
| الدولة | الشركة التي تقدم الوظائف أو الخدمات المصرفية |
|---|---|
| الهند | ملخص الحساب وتحويل الأموال |
| الصين | ملخص الحساب و Bill الدفع |
Archiالمتطلبات الفنية والتصميميةهذه المتطلبات أكثر تفصيلاً من متطلبات العمل، وهي التي توجه بنية الحل. فهي تحدد التصميم العام اللازم لتنفيذ متطلبات العمل. بالنسبة للمؤسسات التعليمية، تشمل حالات الاستخدام النموذجية في البنية والتصميم تسجيل الدخول، وتفاصيل المقرر الدراسي، والتسجيل. ويكون المتطلب كما هو موضح أدناه.
| حالة الاستخدام المصرفي | متطلبات |
|---|---|
| Bill الدفع | تصف حالة الاستخدام هذه كيف يمكن للعميل تسجيل الدخول إلى شبكة الخدمات المصرفية واستخدام Bill نظام الدفع. يمكن للعميل الاطلاع على لوحة تحكم تعرض الفواتير المستحقة للجهات المسجلة. كما يمكنه إضافة بيانات جهة إصدار الفاتورة أو تعديلها أو حذفها. ويمكنه أيضًا ضبط تنبيهات الرسائل النصية القصيرة والبريد الإلكتروني لمختلف إجراءات الفوترة، بالإضافة إلى استعراض سجل الفواتير المدفوعة سابقًا. يبدأ استخدام هذا النظام عادةً عملاء البنك أو موظفي الدعم. |
متطلبات النظام والتكاملعلى أدنى مستوى، لدينا متطلبات النظام والتكامل. وهي توفر وصفًا تفصيليًا لكل متطلب. ويمكن صياغتها على شكل قصص مستخدم مكتوبة بلغة الأعمال اليومية. تحتوي المتطلبات على تفاصيل وافية تُمكّن المطورين من البدء في البرمجة. Bill يوضح المثال التالي لوحدة الدفع متطلبات إضافة جهة إصدار الفواتير.
| Bill الدفع | متطلبات الدراسة |
|---|---|
| إضافة Billالمتطلبات البيئية | اسم مزود الخدمة، رقم العميل، الدفع التلقائي - نعم/لا، دفع المبلغ بالكامل Bill - نعم/لا، حد الدفع التلقائي - لا تدفع إذا Bill يتجاوز المبلغ المحدد |
قد لا تتلقى أحيانًا أي متطلبات أو وثائق لمشروع ما. مع ذلك، توجد مصادر أخرى لمعلومات المتطلبات يمكنك الاعتماد عليها لتصميم برنامجك أو اختباره. فيما يلي قائمة بهذه المصادر.
مصادر أخرى للمتطلبات
- نقل المعرفة من الزملاء أو الموظفين الذين يعملون بالفعل في هذا المشروع
- ناقش المشروع مع محلل الأعمال ومدير المنتج وقائد المشروع والمطورين
- قم بتحليل الإصدار السابق من النظام الذي تم تنفيذه بالفعل
- تحليل وثائق المتطلبات القديمة للمشروع
- Revاطلع على تقارير الأخطاء السابقة؛ يتم تحويل بعض تقارير الأخطاء إلى طلبات تحسين قد يتم تنفيذها في الإصدار الحالي
- راجع دليل التثبيت، إن وجد، لمعرفة عمليات التثبيت المطلوبة.
- قم بتحليل المعرفة بالمجال أو الصناعة التي يحاول الفريق تطبيقها
أياً كان مصدر المتطلبات الذي تستخدمه، قم بتوثيقها بتنسيق مشترك واطلب من أعضاء الفريق ذوي الخبرة مراجعتها.
كيفية تحليل المتطلبات
لنأخذ مثالاً على نظام برمجيات تعليمية حيث يمكن للطالب التسجيل في دورات مختلفة.
دعونا ندرس كيفية تحليل المتطلبات. يجب أن يحافظ كل متطلب على مجموعة من سمات الجودة القياسية، والتي تشمل ما يلي:
- Atomic
- تم تحديدها بشكل فريد
- اكتملت
- متسقة ولا لبس فيها
- Tracداهية
- الأولوية
- قابل للاختبار
يوضح الجدول التالي كل سمة بثلاثة أعمدة:
- يشير العمود الأول إلى "جودة المتطلبات"
- يشير العمود الثاني إلى "متطلبات سيئة مع بعض المشاكل"
- يُظهر العمود الثالث نفس المتطلب "مُحوّلاً إلى متطلب جيد".
| جودة المتطلبات | مثال على الشرط السيئ | مثال على الشرط الجيد |
|---|---|---|
| Atomic | سيكون الطلاب قادرين على التسجيل في دورات البكالوريوس والدراسات العليا | سيتمكن الطلاب من التسجيل في برامج البكالوريوس. سيتمكن الطلاب من التسجيل في برامج الدراسات العليا. |
| تم تحديدها بشكل فريد | 1- سيتمكن الطلاب من التسجيل في برامج البكالوريوس. 1- سيتمكن الطلاب من التسجيل في برامج الدراسات العليا. | التسجيل في المقررات الدراسية. سيتمكن الطلاب من التسجيل في مقررات البكالوريوس. سيتمكن الطلاب من التسجيل في مقررات الدراسات العليا. |
| اكتملت | سيقوم المستخدم الأستاذ بتسجيل الدخول إلى النظام من خلال تقديم اسم المستخدم وكلمة المرور والمعلومات الأخرى ذات الصلة | يقوم الأستاذ المستخدم بتسجيل الدخول إلى النظام من خلال إدخال اسم المستخدم وكلمة المرور ورمز القسم الخاص به |
| متسقة ولا لبس فيها | سيكون للطالب إما دورات جامعية أو دورات دراسات عليا ولكن ليس كليهما. ستكون بعض الدورات مفتوحة لكل من طلاب المرحلة الجامعية والدراسات العليا | سيكون لدى الطالب إما خريجون جامعيون أو خريجون بعد التخرج ولكن ليس كلاهما |
| Tracداهية | هل تريد الحفاظ على معلومات الطالب المعينة لـ BRD req.ID؟ | الحفاظ على معلومات الطالب - المعينة لمعرف طلب BRD 4.1 |
| الأولوية | الطالب المسجل - الأولوية 1. الحفاظ على معلومات المستخدم - الأولوية 1. التسجيل في المقررات الدراسية - الأولوية 1. عرض بطاقة التقرير - الأولوية 1 | تسجيل الطالب - الأولوية 1. صيانة معلومات المستخدم - الأولوية 2. التسجيل في المقررات الدراسية - الأولوية 1. عرض بطاقة التقرير - الأولوية 3 |
| قابل للاختبار | سيتم تحميل كل صفحة من صفحات النظام في إطار زمني مقبول | سيتم تحميل صفحات تسجيل الطلاب والتسجيل في النظام خلال 5 ثواني |
دعونا نفهم كل سمة من هذه السمات بمزيد من التفصيل، بدءًا من Atomجيم.
Atomic
ينبغي أن يكون كل متطلب ذريًا، أي أن يكون على أدنى مستوى من التفصيل ولا يمكن تقسيمه إلى مكونات فرعية. تقارن الأمثلة التالية بين المتطلبات الذرية وغير الذرية.
استكمالاً لمثال نظام مجال التعليم: الشرط غير المناسب هنا هو "سيتمكن الطلاب من التسجيل في برامج البكالوريوس والدراسات العليا". هذا الشرط غير مناسب لأنه غير مُجزأ، إذ يخلط بين كيانين مختلفين، برامج البكالوريوس والدراسات العليا. أما الشرط المناسب المقابل فيفصله إلى شرطين: أحدهما يغطي التسجيل في برامج البكالوريوس، والآخر يغطي التسجيل في برامج الدراسات العليا.
تم تحديدها بشكل فريد
السمة النوعية التالية هي التحديد الفريد. في المثال السيئ، يشترك متطلبان منفصلان في نفس المعرّف (ID#1). إذا أشار فريق إلى متطلب باستخدام معرّفه، يصبح من غير الواضح أيّهما المقصود. أما المتطلب الجيد فيجمعهما تحت القسم 1 - التسجيل في المقررات الدراسية، مع المتطلبات الفرعية 1.1 (التسجيل في مقررات البكالوريوس) و1.2 (التسجيل في مقررات الدراسات العليا).
اكتملت
ينبغي أن تكون جميع المتطلبات كاملة. على سبيل المثال، ينصّ المتطلب غير المناسب هنا على أن "يسجّل الأستاذ دخوله إلى النظام بإدخال اسم المستخدم وكلمة المرور ومعلومات أخرى ذات صلة". عبارة "معلومات أخرى ذات صلة" مبهمة. أما المتطلب الكامل فيُحدّد بدقة الحقول المطلوبة، مثل رمز القسم، التي يجب على الأستاذ إدخالها.
متسقة لا لبس فيها
ينبغي أن تكون جميع المتطلبات متسقة وواضحة. في المثال السيئ، ينص أحد المتطلبات على أن "الطالب سيدرس إما مقررات البكالوريوس أو مقررات الدراسات العليا، وليس كليهما"، بينما ينص متطلب آخر على أن "بعض المقررات ستكون متاحة لطلاب البكالوريوس وطلاب الدراسات العليا على حد سواء".
يشير الشرط الأول إلى تقسيم الدورات إلى فئتين حصريتين، لكن الشرط الثاني يتناقض مع ذلك من خلال فتح بعض الدورات لكلا المجموعتين.
يحل الشرط الجيد هذا التعارض من خلال النص بوضوح على أن كل دورة مصنفة إما على أنها دورة جامعية أو دورة دراسات عليا، ولا يمكن للطالب التسجيل إلا في دورات من فئة واحدة.
Tracداهية
يجب أن يكون كل شرط tracممكن لأن المتطلبات موجودة على مستويات متعددة: الأعمال، والهندسة المعمارية والتصميم، والنظام والتكامل.
عندما تقوم بتحويل متطلبات العمل إلى متطلبات معمارية وتصميمية، أو المتطلبات المعمارية والتصميمية إلى متطلبات النظام والتكامل، tracيجب الحفاظ على المرونة. ينبغي أن يرتبط كل متطلب من متطلبات العمل بواحد أو أكثر من متطلبات التصميم المعماري. في المثال غير الصحيح "الاحتفاظ بمعلومات الطلاب - هل يرتبط بمعرف متطلب BRD؟"، فإن معرف المتطلب مفقود.
يسجل الشرط الجيد نفس البيان ولكنه يرتبط صراحةً بمعرف شرط BRD رقم 4.1. يجب أن يحمل كل شرط ما يلي: tracخريطة القدرةpingينبغي أن تتوافق متطلبات النظام والتكامل أيضًا مع التعليمات البرمجية التي تنفذها ومع حالات الاختبار التي تتحقق منها.
Tracوبالتالي، فإن الكفاءة تمتد من البداية إلى النهاية عبر المشروع بأكمله.
الأولوية
يجب تحديد أولويات كل متطلب لكي يعرف الفريق ما يجب تنفيذه أولاً وما يمكن تأجيله. في المثال السيئ، تم تعيين كل من تسجيل الطلاب، وتحديث بيانات المستخدمين، وتسجيل المقررات، وعرض بطاقة التقرير كأولوية 1. لا يمكن أن تكون جميع المتطلبات ذات أولوية 1، لذا يجب ترتيبها بشكل واقعي. في المثال الجيد، تم منح تسجيل الطلاب وتسجيل المقررات أعلى أولوية (1)، وتحديث بيانات المستخدمين أولوية 2، وعرض بطاقة التقرير أولوية 3.
قابل للاختبار
ينبغي أن يكون كل متطلب قابلاً للاختبار. المثال السيئ، "سيتم تحميل كل صفحة من النظام في إطار زمني مقبول"، غير قابل للاختبار لسببين. أولاً، قد تعني عبارة "كل صفحة" عشرات الصفحات، مما يزيد من جهد الاختبار بشكل كبير. ثانياً، "الإطار الزمني المقبول" غير محدد - مقبول لمن، وما هو المعيار الذي يُقاس عليه؟ المتطلب الجيد يحل هاتين المشكلتين من خلال تسمية الصفحات المحددة ("صفحات تسجيل الطلاب وتسجيل المقررات") وتحديد هدف قابل للقياس وهو 5 ثوانٍ.
