المهره الأصيله
06-19-2007, 03:24 AM
http://img225.imageshack.us/img225/5357/bsmko7.gif
الدرس الثالث: دراسة المتطلبات
http://img224.imageshack.us/img224/1808/501ji9.gif
في هذا الدرس سوف نبدأ في دراسة أول (ولعلها أهم) خطوة في تطوير البرامج وهي تحديد متطلبات النظام
Capturing the requirements.
الهدف من تحديد المتطلبات هو فهم ما يتوقعه العميل والمستخدم من النظام (ما الذي يمكن للنظام أداؤه وما لا يمكنه أداؤه).فقد يكون النظام المطلوب تصميمه بديل لنظام أو لطريقة مستخدمة لأداء مهمة محددة، أو ممكن أن يكون نظام جديد يقدم خدمة جديدة لم يسبق تقديمها من قبل. فلكل نظام برمجي وظيفة معينة، تحدد بما يمكن له أن يقوم به من أجل أداء تلك الوظيفة.
المتطلبات: هي تعريف لشكل النظام أو وصف لما يستطيع هذا النظام أن يقوم به لأداء وظيفته التي سيصمم من أجلها.
خطوات تحديد المتطلبات:
أولا: الاجتماع مع العميل للتعرف على المتطلبات:
وهذه خطوة هامة جدا إذ أن بقية الخطوات التالية تعتمد عليها بشكل أساسي. لذا يجب علينا أن نستخدم كافة التقنيات المتاحة لنكتشف ما الذي يطلبه العميل والمستخدم، نبدأ بفهم وتحليل المشكلة التي تواجه المستخدم بكل أبعادها، نتعرف على العمليات والمصادر التي تتضمنها المشكلة والعلاقات التي تربطها معا و نحدد حدود النظام. وهذا يمكن أن يتم من خلال:
طرح الأسئلة على العميل، ومن المفيد أحيانا أن نطرح نفس السؤال ولكن بأسلوب مختلف أكثر من مرة فهذا يساعدنا على التأكد من أننا نفهم ما يقصده العميل بالتحديد.
عرض نظم مشابه للنظام المطلوب سبق تصميمها من قبل.
تصميم وعرض نماذج لأجزاء من النظام المطلوب أو للنظام بالكامل.
تقسم المتطلبات إلى عدة عناصر تشمل:
البيئة المحيطة بالنظام Physical Environment
وجهات الاستخدام Interfaces
المستخدمين وإمكاناتهم Users and human factors
وظائف النظام Functionality
التوثيق ation
البيانات Data
المصادر Resources
الأمن Security
ضمان الجودة Quality Assurance
ويجب التأكد من أن نناقش جميع هذه العناصر
ثانيا: تسجيل هذه المتطلبات في وثائق أو قاعدة بيانات، وعرضها على العميل ليوافق عليها باعتبار أنها ما يطلبه بالفعل
المتطلبات لا تصف فقط تدفق البيانات والمعلومات من وإلى النظام، وأما تصف كذلك القيود المفروضة على عمل النظام.
وبذلك فإن عملية تحديد المتطلبات تخدم ثلاثة أغراض:
أولا: تمكن المطورين من شرح فهمهم للطريقة التي يود المستخدمين أن يعمل بها النظام.
ثانيا: توضح للمصممين ماهية الوظائف والخصائص التي سيمتاز بها النظام,
وثالثا: توضح المتطلبات لفريق الاختبار ما الذي يجب إثباته لإقناع الزبون أن النظام الذي تم تطويره هو ما سبق أن طلبه بالضبط.
لذلك ولضمان أن كلا من المطورين والزبون متفاهمون تماما على ما يجب القيام به، فإن المتطلبات المسجلة حتى هذه الخطوة يجب أن تكون لها الصفات التالية:
1. أن تكون صحيحة Correct وخالية من الأخطاء.
2. أن تكون ثابتة consistent بمعنى أن لا يكون هناك أي تعارض بين متطلب وآخر.
3. أن تكون تامة Complete يجب أن يتم ذكر جميع الحالات المحتملة للنظام، المدخلات، المخرجات المتوقعة منه، ...الخ.
4. أن تكون واقعية realistic بمعنى أن تكون قابلة للتطبيق في الواقع.
5. أن تكون متعلقة بأمور ضرورة للعميل، ويتطلبها النظام.
6. أن يكون من الممكن التحقق منها verifiable
7. أن تكون قابلة للتتبع traceable
يطلق على هذه الوثائق "وثائق تعريف المتطلبات" Requirement Definition
ثالثا: إعادة تسجيل المتطلبات بشكل رياضي mathematical ليقوم المصممون بتحويل تلك المتطلبات إلى تصميم جيد للنظام في مرحلة التصميم.
لسنوات عديدة كان يتم الاكتفاء بوثيقة تعريف المتطلبات (التي تحدثنا عنها قبل قليل) والتي تكتب باستعمال اللغة الطبيعية (لغة البشر) لوصف وتسجيل متطلبات النظم بحيث يمكن للعميل أن يفهم كل كلمة موجودة بها، إلا أن ذلك يسبب العديد من المشاكل والتي يعود سببها في أغلب الأحيان إلى سوء تفسير بعض التعبيرات للمستخدمين من قبل المصمم أو العكس، فعلى سبيل المثال قد يطلق المستخدم على النظام التعبير (متوقف عن العمل) إذا كان النظام مشغول بعملية تسجيل احتياطي backup باعتبار أن لا يستجيب لأوامر المستخدم في هذه الحالة، بينما يعتبر المصمم أن النظام في هذه الحالة (مستمر في العمل) لأنه يقوم بمهمة أساسية!
لذا فأن الاعتماد على اللغة البشرية بشكل تام قد يؤدي إلى أخطاء كثيرة عند تصميم النظام، وينتج عنها نظام لا يقبله العميل لأنه لا يلبي متطلباته التي حددها من قبل، لذلك يتم كتابة نوع ثاني من الوثائق تسمى "وثائق مواصفات المتطلبات" Requirement specification وهي تكتب باستعمال وسائل وطرق خاصة ابتكرها مهندسو البرمجيات لكتابة المتطلبات باسلوب تقني بحت. منها على سبيل المثال: لغة النمذجة الموحدة UML Unified Modeling و هي لغة نمذجة رسومية تقدم لنا صيغة لوصف العناصر الرئيسية للنظم البرمجية.
الشكل التالي يعرض مثال على استعمال UML
http://img224.imageshack.us/img224/3783/img31pe1.gif
رابعا: التثبت والتحقق من المتطلبات[FONT=Tahoma] التي تم تسجليها في كلا من وثيقة تعريف المتطلبات (والتي تقدم للعميل) ووثيقة مواصفات المتطلبات (والتي تقدم للمصمم) للتأكد من صحتهما وشموليتهما وأن كلا منهما لا تعارض الثانية في أي نقطة، وإلا فإن النتيجة سوف تكون نظام لا يلبي طلبات العميل!.
http://img224.imageshack.us/img224/1808/501ji9.gif
•·.·´¯`·.·• (نهاية الدرس الثالث) •·.·´¯`·.·•
عودنا من جديد لتلقي الدورس
دامت قلوبكم عامرةً بذكر الله:
اختكم
المهره الأصيله
الدرس الثالث: دراسة المتطلبات
http://img224.imageshack.us/img224/1808/501ji9.gif
في هذا الدرس سوف نبدأ في دراسة أول (ولعلها أهم) خطوة في تطوير البرامج وهي تحديد متطلبات النظام
Capturing the requirements.
الهدف من تحديد المتطلبات هو فهم ما يتوقعه العميل والمستخدم من النظام (ما الذي يمكن للنظام أداؤه وما لا يمكنه أداؤه).فقد يكون النظام المطلوب تصميمه بديل لنظام أو لطريقة مستخدمة لأداء مهمة محددة، أو ممكن أن يكون نظام جديد يقدم خدمة جديدة لم يسبق تقديمها من قبل. فلكل نظام برمجي وظيفة معينة، تحدد بما يمكن له أن يقوم به من أجل أداء تلك الوظيفة.
المتطلبات: هي تعريف لشكل النظام أو وصف لما يستطيع هذا النظام أن يقوم به لأداء وظيفته التي سيصمم من أجلها.
خطوات تحديد المتطلبات:
أولا: الاجتماع مع العميل للتعرف على المتطلبات:
وهذه خطوة هامة جدا إذ أن بقية الخطوات التالية تعتمد عليها بشكل أساسي. لذا يجب علينا أن نستخدم كافة التقنيات المتاحة لنكتشف ما الذي يطلبه العميل والمستخدم، نبدأ بفهم وتحليل المشكلة التي تواجه المستخدم بكل أبعادها، نتعرف على العمليات والمصادر التي تتضمنها المشكلة والعلاقات التي تربطها معا و نحدد حدود النظام. وهذا يمكن أن يتم من خلال:
طرح الأسئلة على العميل، ومن المفيد أحيانا أن نطرح نفس السؤال ولكن بأسلوب مختلف أكثر من مرة فهذا يساعدنا على التأكد من أننا نفهم ما يقصده العميل بالتحديد.
عرض نظم مشابه للنظام المطلوب سبق تصميمها من قبل.
تصميم وعرض نماذج لأجزاء من النظام المطلوب أو للنظام بالكامل.
تقسم المتطلبات إلى عدة عناصر تشمل:
البيئة المحيطة بالنظام Physical Environment
وجهات الاستخدام Interfaces
المستخدمين وإمكاناتهم Users and human factors
وظائف النظام Functionality
التوثيق ation
البيانات Data
المصادر Resources
الأمن Security
ضمان الجودة Quality Assurance
ويجب التأكد من أن نناقش جميع هذه العناصر
ثانيا: تسجيل هذه المتطلبات في وثائق أو قاعدة بيانات، وعرضها على العميل ليوافق عليها باعتبار أنها ما يطلبه بالفعل
المتطلبات لا تصف فقط تدفق البيانات والمعلومات من وإلى النظام، وأما تصف كذلك القيود المفروضة على عمل النظام.
وبذلك فإن عملية تحديد المتطلبات تخدم ثلاثة أغراض:
أولا: تمكن المطورين من شرح فهمهم للطريقة التي يود المستخدمين أن يعمل بها النظام.
ثانيا: توضح للمصممين ماهية الوظائف والخصائص التي سيمتاز بها النظام,
وثالثا: توضح المتطلبات لفريق الاختبار ما الذي يجب إثباته لإقناع الزبون أن النظام الذي تم تطويره هو ما سبق أن طلبه بالضبط.
لذلك ولضمان أن كلا من المطورين والزبون متفاهمون تماما على ما يجب القيام به، فإن المتطلبات المسجلة حتى هذه الخطوة يجب أن تكون لها الصفات التالية:
1. أن تكون صحيحة Correct وخالية من الأخطاء.
2. أن تكون ثابتة consistent بمعنى أن لا يكون هناك أي تعارض بين متطلب وآخر.
3. أن تكون تامة Complete يجب أن يتم ذكر جميع الحالات المحتملة للنظام، المدخلات، المخرجات المتوقعة منه، ...الخ.
4. أن تكون واقعية realistic بمعنى أن تكون قابلة للتطبيق في الواقع.
5. أن تكون متعلقة بأمور ضرورة للعميل، ويتطلبها النظام.
6. أن يكون من الممكن التحقق منها verifiable
7. أن تكون قابلة للتتبع traceable
يطلق على هذه الوثائق "وثائق تعريف المتطلبات" Requirement Definition
ثالثا: إعادة تسجيل المتطلبات بشكل رياضي mathematical ليقوم المصممون بتحويل تلك المتطلبات إلى تصميم جيد للنظام في مرحلة التصميم.
لسنوات عديدة كان يتم الاكتفاء بوثيقة تعريف المتطلبات (التي تحدثنا عنها قبل قليل) والتي تكتب باستعمال اللغة الطبيعية (لغة البشر) لوصف وتسجيل متطلبات النظم بحيث يمكن للعميل أن يفهم كل كلمة موجودة بها، إلا أن ذلك يسبب العديد من المشاكل والتي يعود سببها في أغلب الأحيان إلى سوء تفسير بعض التعبيرات للمستخدمين من قبل المصمم أو العكس، فعلى سبيل المثال قد يطلق المستخدم على النظام التعبير (متوقف عن العمل) إذا كان النظام مشغول بعملية تسجيل احتياطي backup باعتبار أن لا يستجيب لأوامر المستخدم في هذه الحالة، بينما يعتبر المصمم أن النظام في هذه الحالة (مستمر في العمل) لأنه يقوم بمهمة أساسية!
لذا فأن الاعتماد على اللغة البشرية بشكل تام قد يؤدي إلى أخطاء كثيرة عند تصميم النظام، وينتج عنها نظام لا يقبله العميل لأنه لا يلبي متطلباته التي حددها من قبل، لذلك يتم كتابة نوع ثاني من الوثائق تسمى "وثائق مواصفات المتطلبات" Requirement specification وهي تكتب باستعمال وسائل وطرق خاصة ابتكرها مهندسو البرمجيات لكتابة المتطلبات باسلوب تقني بحت. منها على سبيل المثال: لغة النمذجة الموحدة UML Unified Modeling و هي لغة نمذجة رسومية تقدم لنا صيغة لوصف العناصر الرئيسية للنظم البرمجية.
الشكل التالي يعرض مثال على استعمال UML
http://img224.imageshack.us/img224/3783/img31pe1.gif
رابعا: التثبت والتحقق من المتطلبات[FONT=Tahoma] التي تم تسجليها في كلا من وثيقة تعريف المتطلبات (والتي تقدم للعميل) ووثيقة مواصفات المتطلبات (والتي تقدم للمصمم) للتأكد من صحتهما وشموليتهما وأن كلا منهما لا تعارض الثانية في أي نقطة، وإلا فإن النتيجة سوف تكون نظام لا يلبي طلبات العميل!.
http://img224.imageshack.us/img224/1808/501ji9.gif
•·.·´¯`·.·• (نهاية الدرس الثالث) •·.·´¯`·.·•
عودنا من جديد لتلقي الدورس
دامت قلوبكم عامرةً بذكر الله:
اختكم
المهره الأصيله