Planning Good Requirements business Analysis التخطيط الجيد لمتطلبات تحليل الأعمال

 Planning Good Requirements business Analysis التخطيط الجيد لمتطلبات تحليل الأعمال

Planning Good Requirements business Analysis التخطيط الجيد لمتطلبات تحليل الأعمال

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

المتطلبات
  • يمكن أن يكون مستند المتطلبات الجيد جزءًا من مجموعة ذات متطلبات عالية المستوى مقسمة إلى متطلبات فرعية.

  • قد تتضمن أيضًا مواصفات مفصلة للغاية تتضمن مجموعة من المتطلبات الوظيفية التي تصف سلوك أو مكونات المنتج النهائي.

  • يجب أن تكون المتطلبات الجيدة موجزة ومحددة ، ويجب أن تجيب على السؤال ، "ماذا نحتاج؟" بدلاً من "كيف نلبي حاجة؟"

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

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

جمع وتحليل المتطلبات

المتطلب هو شرط أو قدرة يحتاجها صاحب المصلحة لحل مشكلة أو تحقيق هدف تنظيمي ؛ شرط أو قدرة يجب أن يفي بها أو يمتلكها النظام.

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

يجب أن تكون المتطلبات -

  • موثق
  • فعالة
  • قابل للقياس
  • قابل للاختبار
  • تعقبها

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

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

نهج الانتزاع

لاستنباط الأهداف ، اسأل خبير الأعمال ومدير التطوير وراعي المشروع الأسئلة التالية -

  • ما الأهداف التجارية للشركة التي سيساعد هذا المشروع في تحقيقها؟

  • لماذا نقوم بهذا المشروع الآن؟

  • ماذا سيحدث إذا فعلنا ذلك لاحقًا؟

  • ماذا لو لم نفعل ذلك على الإطلاق؟

  • من سيستفيد من هذا المشروع؟

  • هل الأشخاص الذين سيستفيدون منه يعتبرونه أهم تحسين يمكن إجراؤه في هذا الوقت؟

  • هل يجب علينا القيام بمشروع مختلف بدلاً من ذلك؟

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

أنواع مختلفة من المتطلبات

أكثر أنواع المتطلبات شيوعًا التي يهتم بها محلل الأعمال هي ما يلي -

متطلبات العمل

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

متطلبات المستخدم

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

وثيقة متطلبات المستخدم (URD) ​​أو مواصفات متطلبات المستخدم هي وثيقة تستخدم عادة في هندسة البرمجيات والتي تحدد ما يتوقع المستخدم أن يتمكن البرنامج من القيام به.

متطلبات النظام

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

المتطلبات الوظيفية

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

متطلبات غير مجدية

الشرط غير الوظيفي هو الذي يحدد المعايير التي يمكن استخدامها للحكم على تشغيل النظام بدلاً من السلوكيات المحددة. تتحدث بنية النظام عن خطة تنفيذ المتطلبات غير الوظيفية.

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

متطلبات الانتقال

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

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

التتبع وإدارة التغيير

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

توفر مصفوفة القدرة على تتبع المتطلبات (RTM) طريقة لتتبع المتطلبات الوظيفية وتنفيذها من خلال عملية التطوير. يتم تضمين كل متطلب في المصفوفة مع رقم القسم المرتبط به.

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

التتبع

قم بتضمين أعمدة لكل مما يلي في RTM -

  • وصف الشرط
  • مرجع المتطلبات في FRD
  • طريقة التحقق
  • مرجع المتطلبات في خطة الاختبار

مثال - ربط النقاط لتحديد العلاقات بين العناصر داخل مشروعك. إنه موصل لتدفق التدفق المشترك.

متطلبات الفكرة تصميم اختبار أهداف العمل

يجب أن تكون قادرًا على تتبع كل متطلباتك إلى هدفها التجاري الأصلي.

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

تاكيد الجودة

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

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

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

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

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

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

ملاحظة - أظهرت الأبحاث أن فرق المشروع يمكنها القضاء على 50-80٪ من عيوب المشروع من خلال إدارة المتطلبات بفعالية. وفقًا لمعهد هندسة البرمجيات في كارنيجي ميلون ، "60-80 بالمائة من تكلفة تطوير البرمجيات قيد التطوير".

الحصول على متطلبات الموافقة

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

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

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