كيف تكتب وثيقة متطلبات تطبيق موبايل قبل التعاقد؟ دليل عملي ونموذج جاهز

• فريق Triple

كيف تكتب وثيقة متطلبات تطبيق موبايل قبل التعاقد؟ دليل عملي ونموذج جاهز

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

كيف تكتب متطلبات تطبيق موبايل قبل التعاقد؟ دليل عملي مع نموذج SRS جاهز

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

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

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

كيف تكتب وثيقة متطلبات تطبيق قبل التعاقد؟

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

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

ما هي وثيقة متطلبات التطبيق Software Requirements؟

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

وقد تُسمى وثيقة مواصفات متطلبات البرمجيات (Software Requirements Specification)، واختصارها SRS، عندما تحتوي على مواصفات تفصيلية ومنظمة للنظام.

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

ويقدم معيار ISO/IEC/IEEE 29148:2018 مرجعًا دوليًا لهندسة المتطلبات، بما يشمل العمليات والمعلومات المستخدمة في تحديد المتطلبات وتوثيقها وإدارتها طوال دورة حياة النظام.

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

لماذا تحتاج إلى توثيق المتطلبات قبل التعاقد؟

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

ومن فوائدها العملية:

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

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

ما الفرق بين بريف المشروع ووثيقة SRS ونطاق العمل؟

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

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

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

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

أولًا: ابدأ بوصف فكرة التطبيق والمشكلة التي يحلها

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

لا تبدأ بقائمة طويلة من الشاشات أو التقنيات، بل اشرح المشكلة التي تريد حلها.

مثال على وصف غير واضح

«أريد تطبيقًا مثل تطبيقات حجز الخدمات، بتصميم احترافي وسريع. »

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

مثال على وصف أكثر دقة

«نريد تطوير تطبيق يسمح للأفراد في القاهرة بحجز خدمات الصيانة المنزلية، واختيار الموعد المناسب، وإرسال الطلب، ومتابعة حالته، مع لوحة تحكم لإدارة الخدمات ومقدمي الخدمة والحجوزات. »

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

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

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

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

ثانيًا: حدد المستخدمين وأنواع الحسابات والصلاحيات

من أكبر الأخطاء في تحليل متطلبات التطبيقات كتابة عبارة «التطبيق يحتوي على تسجيل دخول» دون تحديد أنواع المستخدمين وما يستطيع كل منهم فعله.

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

مثال على أنواع المستخدمين في تطبيق حجز خدمات

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

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

ما أهمية توثيق الصلاحيات؟

لأن الصلاحيات لا تتعلق بسهولة الاستخدام فقط، بل بالأمان وحماية البيانات أيضًا.

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

ثالثًا: اكتب المتطلبات الوظيفية Functional Requirements

المتطلبات الوظيفية هي وصف لما يجب أن يفعله التطبيق بالفعل.

وقد تشمل تسجيل الحسابات، والحجز، والدفع، والإشعارات، والبحث، وإدارة الطلبات.

كيف تحوّل وصفًا عامًا إلى متطلب واضح؟

الوصف الغامض: «التطبيق يدعم الحجوزات. »

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

لكن حتى هذا الوصف يحتاج إلى تفاصيل إضافية.

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

كل سؤال من هذه الأسئلة قد يمثل قاعدة عمل أو حالة استثنائية يجب توثيقها.

رابعًا: استخدم User Stories لشرح احتياجات المستخدم

تساعد قصص المستخدم (User Stories) على وصف الوظائف من وجهة نظر الشخص الذي سيستخدمها.

وتُستخدم عادةً الصيغة التالية:

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

مثال على قصة مستخدم

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

هذه الصياغة توضح المستخدم والهدف والفائدة، لكنها لا تصف جميع التفاصيل الفنية.

لذلك ينبغي ربط قصة المستخدم بمتطلبات محددة ومعايير قبول واضحة.

ما المقصود بمعايير القبول Acceptance Criteria؟

هي الشروط التي يجب تحققها حتى تعتبر الوظيفة مكتملة ومقبولة وفق الاتفاق.

على سبيل المثال، يمكن تحديد المعايير التالية لوظيفة حجز موعد:

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

توضحAtlassian في دليل معايير القبول أن ربط الوظائف بشروط محددة وقابلة للقياس يساعد الفرق على تحديد متى يكون العمل مكتملًا.

الميزة الأساسية لمعايير القبول هي تحويل عبارة «الوظيفة تعمل» إلى شروط يستطيع الطرفان اختبارها.

خامسًا: وثّق رحلة المستخدم والحالات الاستثنائية

لا يكفي أن تكتب قائمة بالشاشات التي سيحتوي عليها التطبيق.

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

مثال على رحلة حجز خدمة

يمكن وصف الرحلة كما يلي:

فتح التطبيق ← اختيار الخدمة ← تحديد العنوان ← اختيار الموعد ← مراجعة التفاصيل ← تأكيد الحجز ← عرض رقم الطلب.

ثم اكتب الحالات غير المعتادة.

ماذا يحدث إذا فشلت العملية؟

في مثال تطبيق الحجوزات، قد تحتاج إلى الإجابة عن الأسئلة التالية:

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

كل قرار ينبغي تسجيله بصورة واضحة.

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

هل تحتاج إلى تصميم جميع الشاشات أولًا؟

ليس بالضرورة. يمكن البدء بمخططات لمسار الاستخدام ورسومات أولية (Wireframes) توضح توزيع العناصر، ثم تطوير التصميم المرئي بعد الاتفاق على الوظائف.

المهم أن يكون سلوك النظام مفهومًا قبل اعتماد الجزء المرتبط به من التنفيذ.

سادسًا: حدد المتطلبات غير الوظيفية Non-functional Requirements

لا تقتصر وثيقة Software Requirements على الوظائف التي يراها المستخدم.

فهناك متطلبات تحدد مستوى الأداء والأمان والاعتمادية وسهولة الاستخدام الذي يجب أن يحققه النظام.

وتسمى المتطلبات غير الوظيفية (Non-functional Requirements).

ما أهم المتطلبات غير الوظيفية؟

كيف تكتب متطلب أداء قابلًا للقياس؟

لا تكتب فقط: «يجب أن يكون التطبيق سريعًا».

يمكنك بدلًا من ذلك تحديد هدف قابل للاختبار، مثل:

«في بيئة الاختبار المتفق عليها، ينبغي أن تستجيب عملية جلب قائمة الخدمات خلال ثانيتين أو أقل في 95% من الطلبات، عند حمل اختبار محدد. »

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

يجب الاتفاق على الأرقام الفعلية وظروف القياس مع الفريق التقني وفق طبيعة النظام والميزانية.

ماذا عن متطلبات الأمان؟

إذا كان التطبيق يتعامل مع بيانات المستخدمين، فمن المهم تحديد متطلبات حماية البيانات وتوثيق الحسابات وإدارة الجلسات والتخزين والاتصالات الآمنة.

ويمكن الاسترشاد بمعيار OWASP MASVS عند تحليل المتطلبات الأمنية الخاصة بتطبيقات الموبايل.

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

سابعًا: حدد متطلبات Backend ولوحة التحكم

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

وهذا قد يؤدي إلى عروض أسعار لا تشمل جميع مكونات المشروع.

ما الذي يجب توثيقه في Backend؟

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

كما يجب توضيح ما إذا كان هناك نظام قائم يمكن استخدامه أو ربط التطبيق به.

كيف تكتب متطلبات لوحة التحكم؟

لا تكتفِ بعبارة «نحتاج Admin Dashboard».

اكتب الوظائف الإدارية المطلوبة، مثل:

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

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

فلوحة التحكم التي تعرض الطلبات فقط تختلف عن نظام إداري يحتوي على صلاحيات متدرجة وتقارير مالية وعمليات اعتماد.

ثامنًا: وثّق التكاملات الخارجية قبل طلب عرض السعر

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

هذه التكاملات قد تؤثر على تكلفة البرمجة والاختبار والتشغيل.

ما الذي يجب تحديده لكل تكامل؟

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

كذلك يجب تحديد ما الذي سيحدث إذا تعطلت الخدمة أو تأخرت الاستجابة.

مثال: الدفع الإلكتروني

وصف «دفع إلكتروني» وحده غير كافٍ.

اسأل: ما وسائل الدفع المطلوبة؟ هل يوجد دفع جزئي؟ هل يمكن استرجاع الأموال؟ ماذا يحدث إذا أكد مزود الدفع العملية لكن التطبيق لم يستقبل النتيجة فورًا؟

ولا تنسَ التمييز بين المدفوعات مقابل المنتجات والخدمات المادية والمشتريات الرقمية داخل التطبيق، فقد تختلف سياسات Apple وGoogle بحسب طبيعة المنتج.

مثال: تطبيق يستهدف مصر والخليج

إذا كان التطبيق سيعمل في مصر والسعودية والإمارات، فلا يكفي كتابة «يدعم الدول الثلاث».

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

ولا ينبغي افتراض أن جميع التكاملات تعمل تلقائيًا في كل دولة.

تاسعًا: حدد البيانات التي يجمعها التطبيق وكيف تُستخدم

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

ما المعلومات التي يجب توثيقها؟

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

وينبغي تحديد الخدمات الخارجية التي ستتلقى بيانات من التطبيق، إن وجدت.

هل تحتاج إلى طلب جميع صلاحيات الهاتف؟

لا. يجب ربط كل صلاحية بوظيفة فعلية.

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

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

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

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

عاشرًا: حدد ما يدخل ضمن النسخة الأولى MVP وما يُؤجّل

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

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

كيف ترتب الأولويات؟

يمكن استخدام التصنيف التالي:

يُعرف هذا الأسلوب باسم MoSCoW Prioritization.

لكن يجب ألا يُستخدم تأجيل المزايا مبررًا لحذف متطلبات الأمان أو الاختبارات أو الوظائف التنظيمية الضرورية.

ويمكنك قراءة دليل تحديد النسخة الأولى MVP من Triple لمزيد من التفاصيل.

نموذج جاهز لكتابة وثيقة متطلبات تطبيق موبايل

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

وهو قالب عملي مبسط، وليس وثيقة SRS كاملة تتوافق تلقائيًا مع جميع بنود معيار ISO/IEC/IEEE 29148.

القسم الأول: البيانات العامة للمشروع

القسم الثاني: المستخدمون والصلاحيات

القسم الثالث: المتطلبات الوظيفية

استخدم النموذج التالي لكل وظيفة:

كرر هذا النموذج لكل وظيفة أساسية.

القسم الرابع: المتطلبات غير الوظيفية

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

إذا لم تكن تعرف القيمة الفنية المناسبة، اكتب «يُحدد بعد مراجعة الفريق التقني»، بدل اختراع رقم غير مدروس أو ترك البند غير مذكور.

القسم الخامس: التكاملات الخارجية

القسم السادس: نطاق المشروع والاستثناءات

حدد ما يشمله الإصدار الأول، وما لن يتضمنه صراحةً.

مثلًا: «الإصدار الأول لا يشمل تطبيقًا مستقلًا لمقدم الخدمة، ولا الدفع الإلكتروني، ولا دعم دولة ثانية«.

هذه أمثلة توضيحية فقط؛ اختر الاستثناءات التي تنطبق على مشروعك.

القسم السابع: معايير التسليم

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

كذلك حدد كيف سيتم اعتماد كل مرحلة ومن المسؤول عن الموافقة عليها.

القسم الثامن: الأسئلة المفتوحة

سجّل الأمور التي لم تُحسم بعد، مع اسم المسؤول عن اتخاذ القرار والموعد المستهدف.

فوجود سؤال مفتوح موثق أفضل من أن يفترض كل طرف إجابة مختلفة.

كيف تستخدم وثيقة المتطلبات للحصول على عروض أسعار دقيقة؟

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

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

ما المعلومات التي يجب أن يظهرها عرض السعر؟

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

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

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

كيف تربط وثيقة SRS بالعقد واستلام التطبيق؟

وثيقة المتطلبات ليست بديلًا عن عقد التطوير.

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

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

ماذا يحدث عند طلب وظيفة جديدة؟

إذا قررت إضافة ميزة بعد بدء التطوير، يمكن استخدام إجراء منظم يسمى Change Request.

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

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

هل يجب تحديد ملكية الكود؟

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

كما ينبغي تحديد ملكية حسابات Apple Developer وGoogle Play والاستضافة والخدمات المرتبطة بالتطبيق.

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

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

ما الأخطاء الأكثر شيوعًا عند كتابة متطلبات التطبيقات؟

هناك أخطاء قد تجعل الوثيقة طويلة لكنها لا تزال غير كافية للتنفيذ.

كتابة أسماء وظائف دون وصف سلوكها

مثل «تسجيل دخول» أو «إشعارات» أو «لوحة تحكم كاملة».

الحل هو وصف ما يحدث، ومن يستطيع استخدام الوظيفة، وما حالات النجاح والفشل.

التركيز على الشاشات ونسيان النظام الخلفي

قد تحتوي الشاشة على عناصر بسيطة، لكنها تعتمد على صلاحيات وقواعد بيانات وتكاملات معقدة.

لذلك وثّق العمليات وليس المظهر فقط.

تجاهل الحالات الاستثنائية

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

هذه الحالات قد تسبب مشكلات حقيقية بعد الإطلاق إذا لم تُناقش أثناء التحليل.

عدم تحديد ما هو خارج النطاق

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

اكتب الاستثناءات صراحةً.

استخدام عبارات غير قابلة للاختبار

مثل «تصميم عصري جدًا» أو «تطبيق سريع للغاية» أو «أعلى مستوى أمان».

استبدلها بأوصاف ومعايير يمكن مراجعتها واختبارها بما يناسب المشروع.

عدم تحديث الوثيقة بعد الاتفاق على التغييرات

إذا تغيرت متطلبات المشروع، يجب أن تعكس الوثيقة الإصدار المعتمد الجديد.

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

قائمة مراجعة قبل إرسال متطلبات التطبيق لشركة البرمجة

قبل طلب عرض السعر، راجع البنود التالية:

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

كيف تساعدك Triple في تحليل وتوثيق متطلبات تطبيقك؟

تقدم Triple خدمات تطوير تطبيقات الموبايل لأندرويد وiOS، وتشمل بحسب نطاق المشروع تحديد المتطلبات، وتصميم مسارات المستخدم والواجهات، وتطوير النظام الخلفي والتطبيق، والاختبارات وتجهيز النشر.

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

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

كيف تجهز متطلبات تطبيقك قبل التعاقد؟

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

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

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

وثيقة المتطلبات الجيدة لا تصف فكرتك فقط؛ بل تجعلها واضحة بما يكفي ليتمكن فريق آخر من فهمها وتقديرها وتنفيذها واختبارها دون الاعتماد على افتراضات غير مكتوبة.

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

1- ما هي وثيقة SRS في تطوير تطبيقات الموبايل؟

هي وثيقة مواصفات متطلبات البرمجيات (Software Requirements Specification)، وتصف وظائف النظام وقيوده ومتطلبات الأداء والأمان والتكامل ومعايير القبول، بما يساعد على توحيد فهم المشروع بين الأطراف.

2- هل يجب أن أكتب وثيقة المتطلبات بنفسي قبل التواصل مع شركة البرمجة؟

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

3- ما الفرق بين المتطلبات الوظيفية وغير الوظيفية؟

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

4- هل تكفي وثيقة متطلبات من ثلاث صفحات للحصول على عرض سعر؟

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

5- هل يمكن تغيير متطلبات التطبيق بعد توقيع العقد؟

نعم، إذا كان هناك اتفاق على آلية إدارة التغييرات. ينبغي توثيق التغيير وتقدير أثره على التكلفة والمدة والمخرجات، ثم اعتماده وفق الإجراءات المتفق عليها قبل تنفيذه.

6- كيف أعرف أن شركة البرمجة نفذت المتطلبات بالشكل الصحيح؟

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