من يُعدّ وثيقة SRS؟

من المسؤول عن وثيقة SRS؟

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

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

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

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

من يكتب وثيقة SRS؟

يكتب وثيقة مواصفات متطلبات البرمجيات محلّلو أعمال ومهندسو أنظمة متخصّصون. وتحدّد وثيقة SRS التي نُعدّها المتطلبات الوظيفية وغير الوظيفية، مستندةً إلى معيار ISO/IEC/IEEE 29148. ويمنح هذا المعيار الدولي الفرقَ إطاراً دقيقاً لتحديد سلوك البرمجيات دون أي غموض.

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

وتبقى مهمة الكتابة على عاتق الشريك التقني، فلا يضطرّ فريقكم إلى صياغة أدلّة تقنية معقّدة. ونُعدّ وثيقة متطلبات الأعمال (BRD)، ووثيقة تصميم البرمجيات (SDD)، ووثيقة مواصفات متطلبات البرمجيات (SRS) بمتطلباتها الوظيفية وغير الوظيفية، ونتّفق عليها معكم قبل بدء العمل الهندسي. وبهذا يبقى تركيزكم على الأولويات التشغيلية، بينما يتولّى المهندسون نماذج النظام.

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

ما الغرض من وثيقة SRS؟

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

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

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

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

ما طريقة إعداد وثيقة SRS؟

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

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

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

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

ما المعايير التي تحكم إعداد المتطلبات؟

تستند هندسة المتطلبات الحديثة إلى أطر هندسية معترف بها عالمياً. ويُقصد بـ SRS في المعيار IEEE 830-1998 مواصفات متطلبات البرمجيات. وقد أرسى ذلك الإطار التاريخي التعريفات الأساسية لجودة المواصفات، وتقسيمها الوظيفي، ومعايير التحقّق منها في قطاع البرمجيات كلّه.

وقد حلّ المعيار ISO/IEC/IEEE 29148:2011 محلّ IEEE 830-1998. ويحدّث المعيار الحالي ممارسات المتطلبات لتواكب البنى الحديثة، ودورات التحقّق المتكرّرة، وبيئات التكامل المعقّدة. وتصف منظمة ISO المعيار ISO/IEC/IEEE 29148:2018 بأنه المعيار الذي يحدّد عمليات هندسة المتطلبات وعناصر المعلومات التي تنتج عنها.

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

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

ما إجراءات الحماية التنظيمية التي يجب أن تتضمّنها الوثيقة؟

في الإمارات، يجب أن تدمج مواصفات البرمجيات المؤسّسية متطلبات خصوصية البيانات وحوكمتها منذ البداية. ونتعامل مع البيانات الشخصية استناداً إلى قانون حماية البيانات الشخصية الإماراتي (PDPL) منذ مرحلة تصميم البنية. وتحديد هذه القواعد مبكراً يجعل مكوّنات النظام وآليات التخزين وواجهات API ملتزمة بالقيود القانونية دون إعادة عمل.

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

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

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

كيف يدير فريقنا مرحلة التنفيذ بعد اعتماد المواصفة؟

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

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

وعند التسليم تتسلّمون الشيفرة المصدرية والوثائق الفنية والاختبارات وكل بيانات الدخول، فلا ارتهان للمورّد (Vendor Lock-in)، ويمكنكم الاستعانة بفريق آخر لاحقاً. ونحن فريق محلّي مقرّه دبي، ونعمل بالعربية والإنجليزية. وعند إطلاق برمجياتكم، تحتفظون بالملكية الكاملة لكل أصل رقمي.

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

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

أبرز النقاط

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

المصادر

1. وثائق مواصفات المتطلبات: تعريف النظام ومتطلبات النظام ومتطلبات البرمجيات (دليل SWEBOK) (swebokwiki.org)
2. استنباط المتطلبات وعملية المتطلبات (دليل SWEBOK) (swebokwiki.org)
3. IEEE 830-1998: الممارسة الموصى بها لمواصفات متطلبات البرمجيات (standards.ieee.org)
4. معيار ISO/IEC/IEEE 29148 لهندسة المتطلبات (iso.org)