تحليل متطلبات البرمجيات مع المثال

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

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

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

إذن ، في الأساس متطلبات البرنامج هي أ

  • وظيفية أو
  • غير وظيفية

حاجة التي يجب تنفيذها في النظام. عادةً ما يتم التعبير عن متطلبات البرامج كبيانات.

 

أنواع المتطلبات

  1. متطلبات العمل: إنها متطلبات عالية المستوى مأخوذة من دراسة جدوى المشاريع. على سبيل المثال، يوفر نظام الخدمة المصرفية عبر الهاتف المحمول خدمات مصرفية لجنوب شرق آسيا. متطلبات العمل التي تم تحديدها للهند هي ملخص الحساب وتحويل الأموال بينما بالنسبة لملخص الحساب الصيني و bill يتم تحديد الدفع كشرط عمل
الدولة الشركة التي تقدم الوظائف أو الخدمات المصرفية
الهند ملخص الحساب وتحويل الأموال
الصين ملخص الحساب و Bill الدفع
  1. Archiالمتطلبات الفنية والتصميمية: هذه المتطلبات أكثر تفصيلاً من متطلبات العمل. فهو يحدد التصميم العام المطلوب لتنفيذ متطلبات العمل. بالنسبة لمنظمتنا التعليمية archiستكون حالات الاستخدام الفنية والتصميمية هي تسجيل الدخول وتفاصيل الدورة وما إلى ذلك. وسيكون الشرط كما هو موضح أدناه.
حالة الاستخدام المصرفي مطلب
Bill الدفع تصف حالة الاستخدام هذه كيف يمكن للعميل تسجيل الدخول إلى شبكة الخدمات المصرفية واستخدام Bill تسهيلات الدفع.

سوف يتمكن العميل من رؤية لوحة القيادة المتميزة billق من المسجلين billers. يمكنه إضافة وتعديل وحذف أ billإيه التفاصيل. يمكن للعميل تكوين الرسائل القصيرة، هmail تنبيهات مختلفة billالإجراءات. يمكنه رؤية تاريخ الدفع الماضي bills.

الجهات الفاعلة التي تبدأ حالة الاستخدام هذه هي عملاء البنك أو موظفي الدعم.

  1. متطلبات النظام والتكامل: على المستوى الأدنى، لدينا متطلبات النظام والتكامل. وهو وصف تفصيلي لكل متطلبات. يمكن أن يكون في شكل قصص مستخدمين تصف بالفعل لغة الأعمال اليومية. المتطلبات وفيرة ديtails حتى يتمكن المطورون من البدء في البرمجة. هنا مثال على ذلك Bill وحدة الدفع حيث سيتم ذكر متطلبات إضافة ملف Biller
Bill الدفع المتطلبات الأساسية
أضف Billالمتطلبات البيئية
  • اسم موفر الأداة المساعدة
  • رقم علاقة العميل
  • المدفوعات التلقائية – نعم/لا
  • الدفع بالكامل Bill - نعم / لا
  • حد الدفع التلقائي – لا تدفع إذا Bill يتجاوز المبلغ المحدد

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

مصادر أخرى للمتطلبات

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

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

كيفية تحليل المتطلبات

فكر في مثال لنظام برمجي تعليمي حيث يمكن للطالب التسجيل في دورات مختلفة.

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

  • Atomic
  • تم تحديدها بشكل فريد
  • كامل
  • متسقة ولا لبس فيها
  • تعقبها
  • الأولوية
  • قابل للاختبار

تحليل المتطلبات

دعونا نفهم ذلك بمثال، هناك ثلاثة أعمدة في الجدول الموضح هنا،

  1. يشير العمود الأول إلى "جودة المتطلبات"
  2. يشير العمود الثاني إلى "متطلبات سيئة مع بعض المشاكل"
  3. العمود الثالث هو نفس العمود الثاني ولكن - "تم تحويله إلى متطلب جيد".
جودة المتطلبات مثال على الشرط السيئ مثال على الشرط الجيد
Atomic
  • سيكون الطلاب قادرين على التسجيل في دورات البكالوريوس والدراسات العليا
  • سيكون الطلاب قادرين على التسجيل في الدورات الجامعية
  • سيتمكن الطلاب من التسجيل في دورات الدراسات العليا
تم تحديدها بشكل فريد 1- سيتمكن الطلاب من التسجيل في دورات البكالوريوس 1- سيتمكن الطلاب من التسجيل في دورات الدراسات العليا
  1. التسجيل في الدورة
  2. سيكون الطلاب قادرين على التسجيل في الدورات الجامعية
  3. سيتمكن الطلاب من التسجيل في دورات الدراسات العليا
كامل سيقوم المستخدم الأستاذ بتسجيل الدخول إلى النظام من خلال تقديم اسم المستخدم وكلمة المرور والمعلومات الأخرى ذات الصلة يقوم الأستاذ المستخدم بتسجيل الدخول إلى النظام من خلال إدخال اسم المستخدم وكلمة المرور ورمز القسم الخاص به
متسقة ولا لبس فيها سيكون للطالب إما دورات جامعية أو دورات دراسات عليا ولكن ليس كليهما. ستكون بعض الدورات مفتوحة لكل من طلاب المرحلة الجامعية والدراسات العليا سيكون لدى الطالب إما خريجون جامعيون أو خريجون بعد التخرج ولكن ليس كلاهما
تعقبها هل تريد الحفاظ على معلومات الطالب المعينة لـ BRD req.ID؟ الحفاظ على معلومات الطالب - المعينة لمعرف طلب BRD 4.1
الأولوية الطالب المسجل-الأولوية 1الحفاظ على معلومات المستخدم-الأولوية 1تسجيل الدورات-الأولوية 1عرض بطاقة التقرير-الأولوية 1 تسجيل الطالب-الأولوية 1الحفاظ على معلومات المستخدم-الأولوية 2تسجيل الدورات-الأولوية 1عرض بطاقة التقرير-الأولوية3
قابل للاختبار سيتم تحميل كل صفحة من صفحات النظام في إطار زمني مقبول سيتم تحميل صفحات تسجيل الطلاب والتسجيل في النظام خلال 5 ثواني


الآن دعونا نفهم كل من هذه المتطلبات في details بدءا من Atomجيم.

Atomic

Atomic

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

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

تم تحديدها بشكل فريد

تم تحديدها بشكل فريد

وبالمثل، فإن جودة المتطلبات التالية هي التحقق مما تم تحديده بشكل فريد، لدينا هنا متطلبان منفصلان ولكن كلاهما لهما نفس المعرف رقم 1. لذلك، إذا كنا نشير إلى متطلباتنا بالإشارة إلى رقم المعرف، ولكن ليس من الواضح ما هو المتطلب الدقيق الذي نشير إليه إلى المستند أو أي جزء آخر من النظام حيث أن كلاهما لهما نفس المعرف رقم 1. لذا، عند الانفصال باستخدام المعرفات الفريدة، سيتم إعادة إرجاع المتطلب الجيد كقسم 1 - تسجيلات الدورة التدريبية، وله متطلبان: 1.1 هوية التسجيل في دورات البكالوريوس بينما 1.2 هوية التسجيل في دورات الدراسات العليا.

كامل

كامل

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

متسقة لا لبس فيها

متسقة لا لبس فيها

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

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

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

تعقبها

تعقبها

يجب أن يكون كل متطلب قابلاً للتتبع لأن هناك بالفعل مستويات مختلفة من المتطلبات، وقد رأينا بالفعل أنه في الأعلى كانت لدينا متطلبات عمل، ومن ثم لدينا archiالمتطلبات الفنية والتصميمية تليها متطلبات تكامل النظام.

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

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

لذا فإن إمكانية التتبع هذه موجودة في جميع أنحاء المشروع بأكمله

الأولوية

الأولوية الطالب المسجل-الأولوية 1
الحفاظ على معلومات المستخدم-الأولوية 1
التسجيل في الدورات-الأولوية 1
عرض بطاقة التقرير-الأولوية 1
تسجيل الطالب-الأولوية 1
الحفاظ على معلومات المستخدم-الأولوية 2
التسجيل في الدورات-الأولوية 1
عرض بطاقة التقرير-الأولوية3

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

قابل للاختبار

قابل للاختبار سيتم تحميل كل صفحة من صفحات النظام في إطار زمني مقبول سيتم تحميل صفحات تسجيل الطلاب والتسجيل في النظام خلال 5 ثواني

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

وفي الختام

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