كيفية تنظيم المتطلبات كمحلل أعمال

⚡ ملخص ذكي

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

📚 فريف: متطلبات العمل هي وثيقة رسمية تحدد احتياجات أصحاب المصلحة لمشروع أو منتج بتفاصيل كافية لمناقشتها وتحليلها والتحقق من صحتها.
📋 طريقة العشر خطوات: التصنيف، والترتيب، والإدراج، والتحديد، والعرض، وجدول المحتويات، والأداة، وإزالة التشويش، والربط بالعملية، والتنسيق باستخدام الجداول والنقاط.
📈 التنسيقات التي يمكنك استخدامها: تُعتبر الجداول، وجداول البيانات، ومخططات سير العمل، والرسوم البيانية، ونماذج الكيانات والعلاقات، والنماذج الأولية، وقوالب الجمل المنظمة، جميعها عروضًا تقديمية صالحة.
🛠️ الأدوات التي يستخدمها محللو الأعمال: Jira مع Confluence و Jama Connect و DOORS Modern Requirements لـ Azure ديف أوبس, Miro, Lucidchart، وبلسميك، و Figma.
🎯 الجمهور أولاً: اعرض نفس المتطلبات بشكل مختلف للمديرين التنفيذيين والمطورين والمستخدمين النهائيين حتى يتمكن كل صاحب مصلحة من التصرف بناءً عليها بسرعة.
⚠️ تجنب الفخاخ: خلط بين "ماذا" و"كيف"، وصياغة غامضة، ونقص في المعلومات. tracالقدرة، وعدم إعطاء الأولوية، والتجاوزping تُعدّ الموافقة النهائية السبب الرئيسي لمعظم عمليات إعادة صياغة وثائق متطلبات العمل.

اقرأ المزيد

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

يمكن تقديم متطلبات العمل بأي من الطرق التالية:

جدول أو جدول بيانات
رسم تخطيطي (سير العمل)
رسم بياني
نموذج (مخطط العلاقة بين الكيان)
نموذج أولي أو محاكاة
جملة منظمة أو قالب نص

كيفية تنظيم وتقديم متطلبات العمل

فيما يلي خطوات كتابة وتنظيم المتطلبات كـ محلل الأعمال.

الخطوة 1) صنّف المتطلبات.

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

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

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

فعلى سبيل المثال، يهتم صاحب المصلحة ذو الخلفية التقنية فقط بالجانب التقني للمنتج.

الخطوة 4) استخدم معرفات فريدة.
If tracيصعب تحديد المتطلبات المتبادلة، لذا استخدم معرّفات فريدة لتسهيل ذلك. tracالقدرة على تسهيل الأمور.

الخطوة 5) عرض المتطلبات بالطريقة المفضلة لدى أصحاب المصلحة.
قد تحتاج إلى تقديم نفس المتطلبات بتنسيقات مختلفة لأصحاب المصلحة المختلفين - أحدهم يفضل عرضًا بيانيًا، بينما يفضل الآخر جملًا منظمة.

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

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

الخطوة 8) تنظيم وثائق المتطلبات حسب تدفق العملية.
قم بإزالة المتطلبات غير الضرورية من المستند، ونظم المتطلبات المتبقية حسب مسار العملية التي تدعمها.

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

الخطوة 10) استخدم الجدول والنقاط.
استخدم الجداول لعرض المتطلبات المعقدة والنقاط لتسليط الضوء على الجوانب الرئيسية لكل منها.

نصائح مفيدة لكتابة وتقديم وثيقة متطلبات العمل

لتحسين العرض و tracفيما يتعلق بمتطلبات العمل، فإن النصائح التالية مفيدة لأي محلل أعمال (BA).

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

تقنيات شائعة لتصور متطلبات الأعمال

إنّ الإسهاب في النصوص هو أسرع طريقة لخسارة أصحاب المصلحة. لذا، يُرفق محللو الأعمال كل متطلب نصي بصورة مرئية لتوضيح الغرض منه بنظرة سريعة. تظهر التقنيات التالية في دليل BABOK وفي معظم ممارسات تحليل الأعمال المؤسسية.

نموذج وتدوين عمليات الأعمال (BPMN): تُصوّر مخططات BPMN العمليات التجارية الشاملة من البداية إلى النهاية، بما في ذلك المجموعات والمسارات والبوابات والأحداث. وهي مثالية لتوضيح من يقوم بماذا ومتى.
مخططات حالات الاستخدام و Descriptأيونات: سجّل تفاعلات النظام مع الجهات الفاعلة والنتائج التي تتوقعها كل جهة فاعلة. مفيد لقوائم المهام القائمة على الميزات.
قصص المستخدمين مع معايير القبول: عبارات قصيرة من نوع "بصفتي... أريد... حتى..." مقترنة بمعايير "معطى-عندما-إذن". هذا هو التنسيق الافتراضي في فرق العمل الرشيقة.
مخططات الأسلاك والنماذج الأولية: شاشات منخفضة أو متوسطة الدقة تم إنتاجها في Figmaأو بلسميك، أو Axure مما يجعل متطلبات واجهة المستخدم ملموسة لأصحاب المصلحة غير التقنيين.
مخططات علاقات الكيانات (ERD): أظهر كيانات البيانات التي يجب أن يخزنها الحل والعلاقات بينها - وهو أمر بالغ الأهمية لمتطلبات إعداد التقارير والتكامل.
مخططات تدفق البيانات (DFD): Tracكيف تنتقل البيانات عبر العمليات والمخازن والجهات الفاعلة الخارجية، وخاصة في مشاريع التحليلات أو التكامل.

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

أدوات شائعة لتنظيم وثائق متطلبات الأعمال

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

جيرا مع كونفلوينس: هذا هو المزيج الافتراضي للفرق المرنة. تُخزَّن المتطلبات على شكل قصص ملحمية وقصص في Jira، مدعومة بصفحات Confluence التي تحتوي على سرد BRD والمخططات.
جاما كونكت: منصة مؤسسية تركز على إدارة المتطلبات، ووضع الخطوط الأساسية، والتشغيل المباشر tracإمكانية الاستخدام في الصناعات الخاضعة للتنظيم مثل الأجهزة الطبية والفضاء.
IBM Engineering Requirements أبواب الإدارة: أداة راسخة تُستخدم في الدفاع والسيارات والأنظمة بالغة الأهمية للسلامة، حيث يجب أن يكون كل متطلب على ما يرام. tracقابل للتطوير.
Modern Requirements لـ Azure عمليات التطوير: يمتد Azure DevOps مع مراجعة، وتوقيع، ووضع خط الأساس، وتصدير وثائق متطلبات العمل (BRD) بنمط Word مباشرة من عناصر العمل.
Miro or Lucidchart: تُستخدم أدوات السبورة البيضاء وأدوات الرسم التخطيطي لصياغة BPMN وERDs ورحلات المستخدم وملاحظات ورش العمل التي تغذي لاحقًا وثيقة متطلبات العمل الرسمية (BRD).
بلسميك و Figma: أدوات تصميم النماذج الأولية التي تحافظ على متطلبات واجهة المستخدم مرئية بدلاً من كونها نصية.

اختر مجموعة الأدوات المناسبة لحجم المشروع واحتياجات التدقيق. يمكن للمشاريع الصغيرة البدء باستخدام Confluence وJira، بينما تحتاج البرامج الخاضعة للتنظيم عادةً إلى Jama أو DOORS لتلبية المتطلبات. tracعمليات تدقيق الأهلية.

أخطاء شائعة عند عرض متطلبات العمل

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

خلط ماذا وكيف: انزلاقping إن إدراج تفاصيل التنفيذ في بيان المتطلبات يُقيد فريق التصميم بالحل قبل اكتمال التحليل.
صياغة غامضة: كلمات مثل "سريع" أو "سهل الاستخدام" أو "مرن" لا يمكن اختبارها. استبدلها بمعايير قبول قابلة للقياس.
صيغة واحدة تناسب جميع أصحاب المصلحة: إن عرض نفس وجهة النظر على المديرين التنفيذيين والمطورين والمستخدمين النهائيين لا يرضي أيًا منهم عادةً. لذا، يجب تعديل التنسيق ليناسب الجمهور المستهدف.
مفقود tracالقدرة: لا يمكن الدفاع عن المتطلبات التي لا ترتبط بأهداف العمل وعناصر التصميم وحالات الاختبار عند وصول طلب تغيير.
لا توجد أولوية: إن تقديم مئات المتطلبات دون استخدام MoSCoW أو نظام التقييم المرجح أو إطار مماثل يجبر أصحاب المصلحة على الجدال حول النطاق بدلاً من القيمة.
مستندات زائدة عن الحاجة: إنّ حشر كلّ المخططات والسجلات والتفسيرات في ملف PDF واحد من 200 صفحة يُخفي المتطلبات المهمة. قسّم وثيقة متطلبات العمل (BRD) إلى أقسام منطقية مع جدول محتويات واضح.
تخطىping تسجيل خروج: إن تقديم وثيقة متطلبات العمل دون الحصول على موافقة رسمية يفتح الباب أمام توسع نطاق المشروع وتبادل الاتهامات لاحقاً أثناء التسليم.

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

الأسئلة الشائعة

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

يمكن لبرنامجي Copilot و GPT صياغة هيكل BRD، وتوسيع قصص المستخدم، وإنشاء معايير القبول الأولية من ملاحظات الاجتماع. Revلا يزال المراجعون يؤكدون أن كل متطلب قابل للاختبار، وغير غامض، ومرتبط باحتياجات أصحاب المصلحة قبل وضع خط الأساس للوثيقة.

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

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

مصفوفة تتبع المتطلبات (RTM) هي وثيقة تربط كل متطلب بأصله، وعنصر التصميم، ومكون الكود، وحالة الاختبار. وهي تدعم كلاً من الاتجاهين الأمامي والخلفي. tracالقدرة على التكيف، وحماية نطاق العمل أثناء طلبات التغيير، وتقديم الأدلة أثناء عمليات التدقيق.

لا توجد أداة واحدة هي الأفضل. تستخدم فرق العمل المرنة Jira مع Confluence، بينما تستخدم البرامج الخاضعة للتنظيم Jama Connect أو IBM الأبواب، و Microsoft تستخدم المتاجر Modern Requirements لـ Azure DevOps. اختر الأداة التي تتناسب مع حجم الفريق واحتياجات التدقيق ومتطلبات التكامل.

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

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