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