توثيق البرمجيات: الفرق بين النسختين

[مراجعة غير مفحوصة][مراجعة غير مفحوصة]
تم حذف المحتوى تمت إضافة المحتوى
لا ملخص تعديل
سطر 17:
إن تنوع وتعقد عملية توثيق المتطلبات تجعل منه تحدياً. فقد تكون المتطلبات ضمنية بحيث يصعب توضيحها. لذا يصعب الجزم بالكمية والماهية والوسيلة اللازمة للتوثيق؛ كما يصعب تحديد ما يجب أن يترك لمرحلتي توثيق التصميم والمعمارية. هذا بالإضافة إلى صعوبة معرفة كيف يتعامل الأشخاص المختلفون مع المتطلبات وكيف يقرأونها. لذا، غالباً ما يبقى توثيق المتطلبات غير مكتمل (أو قد لا يتم إنشاؤه أصلاً). بدون التوثيق الملائم للمتطلبات، يصبح التحكم بالتغيير المطلوب إجراؤه على المتطلبات أمراً أكثر صعوبة وأكثر عرضة للخطأ، ما يقلل من جودة البرمجية وزمن تجهيزها للاستخدام (فتصبح كلفتها عالية).
ترتبط الحاجة لتوثيق المتطلبات بدرجة تعقد وصعوبة المنتج وتأثيره ومتوسط العمر المتوقع للبرمجية. فإذا كانت البرمجية معقدة جداً أو يتم برمجتها من قبل العديد من الأشخاص (كبرمجيات [[الهواتف المحمولة]]) فإن المتطلبات تساعد في هذه الحالة على توضيح ما الذي يجب إنجازه. أما إذا كانت البرمجية حرجة من حيث تأثيرها السلامة وقد يكون لها تأثير سلبي على حياة الإنسان (مثلاً نظم التحكم بالطاقة النووية أو المعدات الطبية) فإن توثيق المتطلبات يصبح أكثر أهمية ويكون في هذه الحالة إلزامياً. إذا كان متوقعاً أن لا يزيد عمر تشغيل البرمجية عن شهر أو شهرين (مثلاً يُستخدم تطبيق للهواتف المحمولة خلال حملة دعائية لفترة محدودة) فإن توثيق المتطلبات لا يكون مهماً. إذا كانت البرمجية إصداراً أولياً بحيث يبنى عليها لاحقاً فإن التوثيق يساعد كثيراً في إدارة التغيير المطلوب تنفيذه لتطوير البرمجية.
غالباً ما يتم تحديد المتطلبات في ملفات متطلبات (مثلاً ملفات [[معالجات النصوص|معالج نصوص|معالجات النصوص]] كـ Word أو [[معالجات الجداول|معالج جداول|معالجات الجداول]] كـ Excel. وهذه الملفات تساعد في التحكم في درجة الصعوبة المتزايدة أو تغيير طبيعة توثيق المتطلبات.
 
=== توثيق المعمارية\ التصميم ===