‏إظهار الرسائل ذات التسميات Business Analysis تحليل الأعمال. إظهار كافة الرسائل
‏إظهار الرسائل ذات التسميات Business Analysis تحليل الأعمال. إظهار كافة الرسائل

Business Analysis - Requirements Management تحليل الأعمال - إدارة المتطلبات

 Business Analysis - Requirements Management تحليل الأعمال - إدارة المتطلبات

Business Analysis - Requirements Management تحليل الأعمال - إدارة المتطلبات

Business Analysis - Requirements Management تحليل الأعمال - إدارة المتطلبات

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

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

لماذا تفشل المشاريع

هناك العديد من الأسباب لفشل المشاريع ولكن بعض المجالات المشتركة تشمل ما يلي -

  • فشل السوق والاستراتيجية
  • فشل التنظيم والتخطيط
  • فشل الجودة
  • فشل القيادة والحوكمة
  • المهارات والمعرفة وفشل الكفاءة
  • الانخراط والعمل الجماعي وفشل الاتصال
مشروع

يتمثل جوهر المشكلة في أن المشروعات تزداد تعقيدًا ، وتحدث التغييرات وأن الاتصال يمثل تحديًا.

لماذا تقوم الفرق الناجحة بإدارة المتطلبات

تتمحور إدارة المتطلبات حول إبقاء فريقك متزامنًا وتوفير رؤية لما يجري داخل المشروع.

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

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

هيا لنبدأ مع الأساسيات

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

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

الأساسيات

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

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

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

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

الآن بعد أن حددنا قيمة إدارة المتطلبات على مستوى عالٍ ، دعنا نتعمق في الأساسيات الأربعة التي يمكن لكل عضو في الفريق وأصحاب المصلحة الاستفادة من فهمها -

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

هل يعلم الجميع ما نبنيه ولماذا؟ هذه هي قيمة إدارة المتطلبات.

التعاون والشراء من أصحاب المصلحة

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

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

أصحاب المصلحة

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

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

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

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






Business Analysis Use-Case Diagrams مخططات حالة استخدام تحليل الأعمال

 Business Analysis Use-Case Diagrams مخططات حالة استخدام تحليل الأعمال

Business Analysis Use-Case Diagrams مخططات حالة استخدام تحليل الأعمال


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

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

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

رسم مخططات حالة الاستخدام

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

حالة الاستخداماستخدم الرسم البياني

حالة الاستخدام 1 - يقوم كاتب المبيعات بسحب عنصر ما

  • يحدد العميل العنصر على العداد.
  • «يستخدم» انتقاد قارئ UPC.
  • يبحث النظام عن رمز UPC في وصف عنصر شراء قاعدة البيانات والسعر
  • يصدر النظام صوتًا مسموعًا.
  • يعلن النظام عن وصف العنصر والسعر عبر الإخراج الصوتي.
  • يضيف النظام السعر ونوع العنصر إلى الفاتورة الحالية.
  • يضيف النظام السعر لتصحيح الإجمالي الفرعي للضريبة

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

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

مثال Case حالة استخدام الانسحاب

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

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

حالة استخدام الانسحاب

العلاقات بين الفاعلين وحالات الاستخدام

يمكن تنظيم حالات الاستخدام باستخدام العلاقات التالية -

  • تعميم
  • جمعية
  • تمديد
  • تتضمن

التعميم بين حالات الاستخدام

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

التعميم بين حالات الاستخدام

الارتباط بين حالات الاستخدام

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

تمديد

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

يتم عرض علاقة التمديد كخط متقطع برأس سهم مفتوح موجه من حالة الاستخدام الممتدة إلى حالة الاستخدام الموسعة (الأساسية). السهم يسمى بالكلمة الأساسية «تمديد».

تتضمن

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

قم بتضمين العلاقة بين حالات الاستخدام الموضحة بسهم متقطع برأس سهم مفتوح من حالة الاستخدام الأساسية إلى حالة الاستخدام المضمنة. السهم يسمى بالكلمة الأساسية «تشمل».

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

الرسم البياني الموضح أدناه هو مثال على مخطط بسيط لحالة الاستخدام مع تمييز جميع العناصر.

تتضمن

المبادئ الأساسية للتطبيق الناجح لحالات الاستخدام

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

نموذج حالة الاستخدام

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

معرف حالة الاستخدام:
اسم حالة الاستخدام:
انشأ من قبل:آخر تحديث بواسطة
تاريخ الإنشاء:تاريخ آخر تحديث
الممثل:
وصف:
الشروط المسبقة:
شروط المشاركة:
أفضلية:
تردد الاستخدام:
المسار الطبيعي للأحداث:
الدورات البديلة:
استثناءات:
يشمل:
متطلبات خاصة:
الافتراضات:
ملاحظات وقضايا:









Business Analysis - Use-Cases تحليل الأعمال - حالات الاستخدام

 Business Analysis - Use-Cases تحليل الأعمال - حالات الاستخدام

Business Analysis - Use-Cases تحليل الأعمال - حالات الاستخدام

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

ما هي واقعة الاستخدام؟

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

الفاعل هو Who of the system ، بمعنى آخر هو المستخدم النهائي.

في هندسة البرمجيات والأنظمة ، حالة الاستخدام هي قائمة من الخطوات ، تحدد عادةً التفاعلات بين الدور (المعروف في UML بـ "الفاعل") والنظام ، لتحقيق هدف. يمكن أن يكون الفاعل نظامًا بشريًا أو خارجيًا.

تحدد حالة الاستخدام تدفق الأحداث في النظام. يهتم أكثر بما يقوم به النظام من أجل أداء تسلسل الإجراءات.

فوائد واقعة الاستخدام

توفر حالة الاستخدام الفوائد التالية -

  • إنها وسيلة سهلة لالتقاط المتطلبات الوظيفية مع التركيز على القيمة المضافة للمستخدم.

  • حالات الاستخدام سهلة الكتابة والقراءة نسبيًا مقارنة بأساليب المتطلبات التقليدية.

  • تجبر حالات الاستخدام المطورين على التفكير من منظور المستخدم النهائي.

  • حالة الاستخدام تُشرك المستخدم في عملية المتطلبات.

تشريح حالة الاستخدام

الاسم : الاسم الوصفي الذي يوضح الغرض من حالة الاستخدام.

الوصف يصف ما تفعله حالة الاستخدام في جملتين.

الفاعل : اذكر أي ممثلين يشاركون في واقعة الاستخدام.

الشرط المسبق الشروط التي يجب توافرها قبل البدء في حالة الاستخدام.

تدفق الأحداث وصف التفاعل بين النظام والممثل.

شرط آخر وصف حالة النظام بعد أن تأخذ حالة الاستخدام مجراها.

إرشادات لقالب حالة الاستخدام

وثق كل حالة استخدام باستخدام النموذج الوارد في نهاية هذا الفصل. يقدم هذا القسم وصفًا لكل قسم في نموذج حالة الاستخدام.

تحديد حالة الاستخدام

  • معرف حالة الاستخدام - امنح كل حالة استخدام معرفًا رقميًا فريدًا ، في شكل هرمي: يمكن تجميع حالات الاستخدام ذات الصلة XY في التسلسل الهرمي. يمكن إرجاع المتطلبات الوظيفية إلى حالة الاستخدام المصنفة.

  • اسم حالة الاستخدام - حدد اسمًا موجزًا ​​وموجه نحو النتائج لحالة الاستخدام. تعكس هذه المهام التي يحتاجها المستخدم ليتمكن من إنجازها باستخدام النظام. قم بتضمين فعل واسم. بعض الأمثلة -

    • عرض معلومات رقم الجزء.

    • قم يدويًا بتمييز مصدر النص التشعبي وإنشاء ارتباط بالهدف.

    • ضع طلبًا للحصول على قرص مضغوط به إصدار البرنامج المحدث.

تاريخ حالة الاستخدام

هنا ، نذكر أسماء الأشخاص الذين هم أصحاب المصلحة في وثيقة Usecase.

  • تم الإنشاء بواسطة - أدخل اسم الشخص الذي وثق حالة الاستخدام هذه في البداية.

  • تاريخ الإنشاء - أدخل التاريخ الذي تم فيه توثيق حالة الاستخدام في البداية.

  • تم التحديث الأخير بواسطة - أدخل اسم الشخص الذي أجرى آخر تحديث لوصف حالة الاستخدام.

  • تاريخ آخر تحديث - أدخل التاريخ الذي تم فيه تحديث حالة الاستخدام مؤخرًا.

تعريف حالة الاستخدام

فيما يلي تعريفات المفاهيم الأساسية لحالة الاستخدام -

الممثل

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

وصف

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

الشروط المسبقة

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

أمثلة

  • تم مصادقة هوية المستخدم.
  • يتوفر في كمبيوتر المستخدم ذاكرة خالية كافية لبدء المهمة.

شروط ما بعد

صف حالة النظام في نهاية تنفيذ حالة الاستخدام. قم بترقيم كل حالة نشر.

أمثلة

  • يحتوي المستند على علامات SGML صالحة فقط.
  • تم تحديث سعر العنصر في قاعدة البيانات بقيمة جديدة.

أفضلية

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

تردد الاستخدام

قدر عدد المرات التي سيتم فيها تنفيذ حالة الاستخدام هذه من قبل الجهات الفاعلة لكل وحدة زمنية مناسبة.

الدورة العادية للأحداث

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

الدورات البديلة

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

استثناءات

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

يشمل

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

متطلبات خاصة

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

الافتراضات

أدرج أي افتراضات تم إجراؤها في التحليل أدت إلى قبول حالة الاستخدام هذه في وصف المنتج وكتابة وصف حالة الاستخدام.

ملاحظات وقضايا

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

إدارة التغيير والتحكم في الإصدار

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








Business Analysis Software Requirements Specification مواصفات متطلبات برامج تحليل الأعمال

 Business Analysis Software Requirements Specification مواصفات متطلبات برامج تحليل الأعمال

Business Analysis Software Requirements Specification مواصفات متطلبات برامج تحليل الأعمال

مواصفات متطلبات البرنامج (SRS) هي مستند يُستخدم كوسيط اتصال بين العملاء. مواصفات متطلبات البرامج في أبسط أشكالها هي مستند رسمي يستخدم في توصيل متطلبات البرامج بين العميل والمطور.

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

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

الغرض من SRS

SRS هي أداة اتصال بين العميل / العميل ومحلل الأعمال ومطوري النظام وفرق الصيانة. يمكن أن يكون أيضًا عقدًا بين المشتري والمورد.

  • سيعطي أساسًا ثابتًا لمرحلة التصميم
  • يدعم إدارة المشروع والتحكم فيه
  • يساعد في التحكم في النظام وتطوره

يجب أن تكون مواصفات متطلبات البرنامج كاملة ومتسقة وقابلة للتتبع وغير غامضة وقابلة للتحقق.

يجب تناول ما يلي في مواصفات النظام -

  • تحديد وظائف الأنظمة
  • تحديد التقسيم الوظيفي للأجهزة / البرامج
  • تحديد مواصفات الأداء
  • حدد تقسيم أداء الأجهزة / البرامج
  • تحديد متطلبات الأمان
  • تحديد واجهة المستخدم (دليل المستخدم)
  • تقديم رسومات / تعليمات التثبيت
  • قالب مواصفات متطلبات البرامج

مراجعة التاريخ


تاريخوصفمؤلفتعليقات
<تاريخ><الإصدار 1><اسمك><المراجعة الأولى>

الموافقة على الوثيقة

تم قبول مواصفات متطلبات البرامج التالية والموافقة عليها من قبل الجهات التالية -

التوقيعاسم مطبوععنوانتاريخ
<اسمك>قيادة البرمجيات المهندس.
أحمد مدرب