لماذا المتطلبات مهمة في هندسة البرمجيات؟

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

" برنامج العمل على التوثيق الشامل. " هذا جزء من بيان Agile.

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

لنبدأ بشرح بسيط لما هي المتطلبات من حيث تطوير البرمجيات.

ما هي متطلبات تطوير التطبيق؟

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

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

كيفية تحديد متطلبات البرامج

يمكن أن يكون هناك عدة أنواع من المتطلبات في تطوير البرامج.

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

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

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

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

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

متطلبات البرنامج

هناك نوعان من المتطلبات: وظيفية وغير وظيفية. بعبارات بسيطة ، يكون التمييز كما يلي:

المتطلبات الوظيفية هي ما هي المتطلبات - ما هو هذا النظام المصمم للقيام به؟ كما يوحي الاسم ، يصفون وظائف البرنامج.

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

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

المتطلبات الوظيفية الرئيسية ، في هذه الحالة ، ستكون:

1. يجب أن يكون التطبيق قادرًا على إرسال الرسائل.
2. يجب أن يدعم التطبيق نقل الملفات والوسائط.
3. إلخ.

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

1. يجب أن تقدم الخدمة وظائف كاملة في جميع المتصفحات الرئيسية: Microsoft Edge و Google Chrome (أحدث إصدارين) و Mozilla Firefox (أحدث إصدارين) و Opera و Safari (أحدث إصدار).
2. يجب دعم تخطيطات الهاتف المحمول.
3. إلخ.

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

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

بدون تحديد معلمات دقيقة ، من المستحيل فهم ما إذا كانت الميزة مصممة تمامًا كما ينبغي.

يجب تحليل المتطلبات وتوثيقها بدقة. لماذا ا؟ لأن الكثير من الأشياء يمكن أن تنحرف إذا لم تكن كذلك.

سيف ديموقليس للمتطلبات غير الموثقة

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

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

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

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

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

لضمان التطوير السلس للمشروع ، يجب أن يفهم كل عضو في الفريق جميع أجزاء المنتج وعملية تطويره بنفس الطريقة. للتأكد من أن المطورين يرون كل ميزة من ميزات المنتج تمامًا كما يفعل العميل ، يتم وضع مواصفات متطلبات البرامج (SRS).

الشيطان يكمن في التفاصيل: ما الذي يجعل مواصفات متطلبات البرامج جيدة؟

الآن ، يمكن أن تكون مواصفات متطلبات البرامج الفعلية مفصلة بشكل استثنائي أو يمكن أن تكون مجرد مخطط تفصيلي للميزات. مستوى التفاصيل يعتمد على عدد من العوامل.

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

بغض النظر عن مدى امتلاء وثائقك بالتكنولوجيا ، هناك قواعد عامة لإدارة متطلبات البرامج. يوجد أيضًا معيار رسمي: IEEE Std 830-1998 ، "الممارسة الموصى بها لمواصفات متطلبات البرامج." إليك ما يجب أن يكون عليه SRS الجيد ، وفقًا للمعيار:

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

• لا لبس فيه . أحد الأغراض الرئيسية لـ SRS هو القضاء على سوء التواصل. لهذا السبب يجب كتابة كل مواصفات المتطلبات للحصول على تفسير واحد ممكن فقط. ليس من غير المعتاد أن تتضمن SRS مسردًا.

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

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

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

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

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

• يمكن عزوها . يجب أن يكون من السهل تحديد مصدر كل متطلب منصوص عليه في SRS.

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

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

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

استنتاج

فيما يلي النقاط الأكثر شيوعًا عندما تكون متطلبات البرامج في متناول اليد:

• فهم الهدف
• تقدير تكاليف التطوير
• إنشاء جدول شامل
• تحديد الأولويات

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