قرأت في مكان ما أن اثنين من كل ثلاثة مشاريع برمجية يكون مصيرها الفشل، إما لأنها لم تنجز في الوقت المحدد، أو لأنها تتطلب مصاريف أكثر من المتوقع، و الغالب لأنها لاتوافق متطلبات العميل، اما عني انا شخصياً فأستطيع أن أقول أن ثلاثة من كل ثلاثة مشاريع تأتيني كانت تفشل و كنت دائماً ما أرى تلك النظرة المؤلمة على وجه العميل، و التي أفهم منها أننا سنبدأ في حلقات لا تنتهي من التعديلات، بالرغم من أني متأكد من أن ما اتفقنا عليه مطابق تماماً لما قدمته، إذاً أين المشكلة ؟! ... بعد فترة طويلة من المعاناة عرفت أن هنالك مجال بحث يسمى "هندسة المتطلبات" و بعضهم يسميه "تحليل المتطلبات"، الموضوع واسع و متشعب، اممممممم لكن دعونا نأخذ شيء عملي بسيط يكون كثقافة عامة لمن لم يعجبه، و كمقدمة لمن أراد التوسع فيما بعد ... إذاً لنبدأ .. ماهو تعريف "متطلبات العميل"
متطلبات العميل
إذا كنا نتحدث عن مشروع برمجي فمصطلح “متطلبات العميل” يقصد به الوظائف التي يريدها العميل في البرنامج أو في موقع الإنترنت، و الحقيقة أن أكثر المشاكل التي تحدث بين المبرمجين و العملاء يكون مصدرها سوء فهم بينهم حول هذه النقطة تحديداً، فقد يطلب العميل شيء ولا ينفذه المبرمج، أو قد يجد المبرمج طلب من العميل لم يتم ذكره في الإتفاق (مع العلم أن هنالك أساليب حديثه لتجاوز مشكلة تغيير العميل لمتطلباته بعد إبرام العقد لكن هذا ليس له علاقة بموضوعنا هذا، بتفلسف عليكم :shy: ).
الـ Use Cases
هي طريقة للتعبيرعن “متطلبات العميل” بأسلوب بسيط يمكن أن يفهمه حتى غير التقنين، لنأخذ مثال يوضح كيفية تحويل “المتطلبات” إلى “Use Cases”.
مثال افتراضي
أحد العملاء طلب مني تطوير موقع على الإنترنت، يمكن للزائر من خلاله أن يستعرض المنتجات، وكذلك يمكنه أن يقوم بمراسلة مشرف الموقع. أما مشرف الموقع فيمكنه إضافة و حذف و تعديل المنتجات المعروضة في الموقع، كما يمكنه أن يقوم بتحميل ملفات إلى الموقع، إضافةً إلى قدرته على تصفح الرسائل المرسلة من قبل الزوار.
تحليل المثال
في المثال السابق يظهر لدينا نوعين من المستخدمين، “زائر” و “مشرف” (في الـ Use Cases نطلق على المستخدمين مسمى : Actors)، “الزائر” يمكنه القيام بالوظائف التاليه :
*استعراض المنتجات.
*مراسلة مشرف الموقع.
أما “المشرف” فيمكنه القيام بما يلي :
*إضافة منتج .
*حذف منتج .
*تعديل منتج .
*تحميل ملفات إلى الموقع.
*تصفح رسائل الزوار.
لتبدأ حصة الرسم
صدقني.. بالرغم من أن الـ “Use Cases” تعتبر أهم طرق التعبير عن المتطلبات إلا أن أساسياتها بغاية البساطة، انظر إلى الرسمة التالية :
فهمتها وهي طايرة صح ؟!بهذا الشكل نكون قد حولنا "متطلبات العميل" إلى "Use Cases" ... عن طريق تمثيل "المستخدمين-Actors" بشكل الإنسان المجرد :
و أما الوظائف فقد مثلناها في الرسم عن طريق الشكل البيضاوي ثم وصلناها بخط مع المستخدم(ِActor) الخاص بها.
هل يمكنك أن تحول أي برنامج أو نظام إلى هذا الشكل ؟ جرب بنفسك .. اختر أو تخيل فكرة أي برنامج ثم أحضر مجموعة من الاوراق البيضاء من مقاس A4 و قلم رصاص و ابدأ الرسم ^_^
كيف يمكن الإستفادة من الـ Use Cases :
كما ترى فإن الرسمة السابقة سهلة الفهم و يمكن لعميلك أن يفهمها حتى بدون شرح، ولكن توجد فائدة أخرى وهي انك أثناء برمجتك ستتمكن من معرفة الوظائف التي يجب عليك تنفيذها بالنظر إلى الرسم دون الحاجة للرجوع إلى العقود وقراءة النص المكتوب فيها و محاولة فهمه، بل و أكثر من ذلك، لو كان لديك فريق من المبرمجين من الأهسل ان يتم تبادل الـ Use Cases خصوصاً عندما يكون أحدهم أجنبي لايتحدث بنفس لغة بقية أفراد الفريق، فهو لا يستطيع قراءة العقود وفهمها، لكن يمكنه فهم كل مايحتاجه من خلال الـ Use Cases. إضافة إلى ذلك يمكن أن تستخدم الـ Use Cases مع العقد لتوضيح المتطلبات .
هل هذا هو كل شيء في الـ Use Cases:
لا هذا ليس كل شيء، توجد أشكال أخرى لها معاني خاصة في الـ Use Cases غير الاشكال السابقه، و توجد أساليب و تقنيات لجمع الـ Use Cases و ترتيبها ( الحقيقة أني تعمدت كسر أحد الأساليب المشهورة في الرسمة السابقه من أجل التبسيط )، ستكتشف المزيد إذا مارست عملية جمع متطلبات عملائك بهذه الطريقة.
مثال حقيقي
هذه صورة لـ Use Cases كتبته قبل أربع سنوات تقريباً لمشروع خاص هو غير مكتمل لكنه يعطي تصور عن كيف يمكن أن يكون شكل الـ Use Cases
"هذا الموضوع كتبته اعتماداً على ما في ذاكرتي فتجاوزا عن الأخطاء إن وجدت :shy: و أما تعريب بعض المصطلحات مثل كلمة Actors و التي عربتها بـ مستخدمين فهو اجتهاد شخصي لأن الترجمة الحرفية لم ترق لي"
و الحمد لله الذي تتم بنعمته الصالحات ...
تقبلوا أرق التحايا ..
محبكم / مازن بن عبد الله مليباري
http://www.mazen.ws
رد مع اقتباس
،،
المشاركة الأصلية كتبت بواسطة Egyptechno
