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

لماذا تفشل مشاريع هندسة النظم؟

لماذا تفشل المشاريع في الصناعات شديدة التنظيم؟ قام العديد من الباحثين بالتحقيق في سبب فشل مشاريع الأنظمة والبرامج. أجرت مجموعة Standish بحثًا في عام 2009 ، يسلط الضوء على أن معظم أسباب فشل المشاريع مرتبطة بالمتطلبات.

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

ما هي مواصفات المتطلبات؟

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

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

عملية هندسة المتطلبات

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

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

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

لماذا من المهم كتابة متطلبات جيدة؟

هناك العديد من الفوائد لامتلاك مواصفات المتطلبات الجيدة. بعضها مذكور أدناه:

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

ما الذي نحققه من خلال كتابة متطلبات عظيمة؟

هناك العديد من الأشياء التي تساعد المتطلبات العظيمة في تحقيقها. بعضها مذكور أدناه:

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

التحديات عند كتابة المتطلبات

هناك العديد من التحديات التي يواجهها الناس عند كتابة المتطلبات.

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

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

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

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

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

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

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

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

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

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

معايير متطلبات الكتابة؟

ستكون EARS منهجية فعالة هنا. انها تقف ل Eبالامر السهل Approach ل Requirements Syntax ، بواسطة أليستر مارفن. في هذه الطريقة نكتب لغة واضحة وموجزة ومفهومة. يعمل هذا على تحسين سير العمل الهندسي للمتطلبات بالكامل ويبسط العمل عن طريق جعل الأشياء سهلة الفهم. 

لتحقيق ذلك ، إليك بعض المبادئ التي يجب مراعاتها أثناء كتابة المتطلبات. أنها تشمل:

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

المكونات الأساسية لوثيقة المتطلبات:

الأقسام الرئيسية لمواصفات متطلبات البرامج هي:

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

خصائص وثيقة مواصفات متطلبات البرمجيات:

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

قواعد مجموعة المتطلبات الصحيحة

هناك قواعد معينة يجب أن تلتزم بها المتطلبات حتى يتم تسميتها "بالشكل الصحيح".

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

متطلبات الرؤية منصة ALM

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

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

وفي الختام

من أجل إنتاج برامج رائعة ، من المهم أن يكون لديك مواصفات متطلبات مكتوبة جيدًا. تحدد هذه الوثيقة احتياجات العميل وما يجب على النظام القيام به من أجل تلبية توقعاتهم. ومع ذلك ، فإن كتابة المتطلبات الجيدة يمكن أن تكون صعبة. هناك العديد من المعايير والإرشادات التي يجب اتباعها ، وهناك العديد من الطرق المختلفة لكتابتها اعتمادًا على اللغة والأدوات التي تستخدمها. متطلبات Visure توفر منصة ALM دورة تعلمك كيفية كتابة مواصفات المتطلبات الفعالة باستخدام أفضل الممارسات ومعايير الصناعة. تغطي الدورة جميع المكونات الأساسية لوثيقة المتطلبات ، من الهيكل إلى التنسيق ، وكذلك كيفية استخدام اللغات المختلفة لمتطلبات الكتابة. كما أنه يسلط الضوء على خصائص المتطلبات العظيمة حتى تتمكن من إنشاء مستندات سيحب فريقك العمل بها. إذا كنت تريد معرفة المزيد حول كتابة المتطلبات الفعالة ، فجرّب دورة مواصفات المتطلبات بواسطة Visure Requirements ALM Platform اليوم!