تحليل وتصميم نظم المعلومات

أكاديمية الدراسات العليا – طرابلس - ليبيا

مدرسة العلوم الهندسية والتطبيقية

قسم علوم الحاسوب

اسم المقرر:- تحليل وتصميم نظم المعلومات

أستاذ المقرر:- د. عبدالحفيظ الشويهدي

الفصل الدراسي:- خريف 2005 ف

تقرير عن

مواصفات المتطلبات

(Requirements specification)

إعداد:-  م.  أسامة محمد حسين الرجوبي

 

سنتناول في هذا البحث:-

* الأمور التي تساعد محلل النظم في فهم النظام وتحديد متطلبات المستخدم بالشكل الصحيح أثناء تحليل النظام.

* ما هي المواصفات التي يجب أن تكون لهذه المتطلبات. 

تحليل النظام:-

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

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

وللقيام بدور وصلة الاتصال بين المستخدم والمصمم يضع المحلل بعض الاختيارات الأساسية المتعلقة بطريقة الاتصال وهي:-

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

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

نماذج النظم:-

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

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

ويمكن تقسيم النماذج إلى نماذج منطقية(البيانات الموجودة بالنظام) ونماذج حسية(عمليات المعالجة).

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

1-     يعتبر النظام القائم دائما محدودا ومتمثلا في النهاية بقيوده الحسية، ويمكن أن تكون هذه القيود الحسية في الأجهزة أو في حدود إدارية أو في الأفراد أنفسهم.

2-     يمكن أن تنتج القيود الحسية عمليات غير فعالة أو غير صحيحة ومتضاربة منطقيا.

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

4-     إن معظم عمليات المعالجة والتطوير التي تحدث في نظام قائم تنمو في الحقيقة بمرور الوقت لتعويض عيوب النظام الحسي.

منتجات عملية تحليل النظام

خلال دورة تطوير النظم، يوجد منتجان نهائيان مهمّان لعملية تحليل النظم، وهذان المنتجان هما:-

1-     وثيقة مواصفات المتطلبات (مواصفات المستخدم).

2-     وثيقة مواصفات تصميم النظام الجديد.

وثيقة مواصفات المتطلبات (مواصفات المستخدم):-

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

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

وثيقة مواصفات تصميم النظام الجديد:-

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

وبالحصول على المنتج النهائي تكون عملية تحليل النظم قد بلغت مرحلة كافية بحيث تكون:-

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

·        مسئولية الاتصالات لعملية تحليل النظم في ملء الفراغ بين المستخدمين والفنيين قد أنجزت.

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

تعريف المتطلبات:-

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

The IEEE gave a definition of  requirements in (IEEE ANSI 1981)

“The requirements specification shall clearly and precisely describe the essential functions , performances, design constraints, attributes, and external interfaces. Each requirement shall be defined such that its achievement is capable of being objectively verified by a prescribed method, for example, inspection, demonstration , analysis or test”.

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

1-  عقد اجتماع مع العميل لتحديد متطلباته، هذه المتطلبات تشمل وصف النظام بجميع مكوناته.

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

3-  بعد موافقة العميل على التصميم يتم العمل على وضع التصاميم التفصيلية لأجزاء المشروع.

4-  كتابة البرنامج.

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

6-  تسليم النظام إلى العميل.

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

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

خطوات تحديد المتطلبات:

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

1) طرح الأسئلة على العميل، ومن المفيد أحيانا أن نطرح نفس السؤال ولكن بأسلوب مختلف أكثر من مرة فهذا يساعدنا على التأكد من أننا نفهم ما يقصده العميل بالتحديد.
2) عرض نظم مشابه للنظام المطلوب سبق تصميمها من قبل.
3) تصميم وعرض نماذج لأجزاء من النظام المطلوب أو للنظام بالكامل.
4) تقسم المتطلبات إلى عدة عناصر، ويجب أن يتم مناقشة جميع هذه العناصر وهي :
بيئة النظام - واجهات الاستخدام -المستخدمين وإمكاناتهم - وظائف النظام -التوثيق -البيانات -المصادر -الأمن -ضمان الجودة.
وتعتبر المقابلات الشخصية من أهم الطرق المهمة لتحديد الاحتياجات المطلوبة للمستخدم، وذلك للأسباب التالية:-

1-   تؤمن فرص للاتصالات بمسارين.

2-   تخلق اندفاع نشيط للمشروع سواء في متخصصي النظم أو المستخدمين.

3-   تعمل على تأسيس الثقة بين المستخدمين ومتخصصي النظم.

4-   تزيد من فرص المشاركة حتى ولو كانت وجهات نظر متعاكسة.

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


ثالثا: إعادة تسجيل المتطلبات بشكل رياضي ليقوم المصممون بتحويل تلك المتطلبات إلى تصميم جيد للنظام في مرحلة التصميم.
لسنوات عديدة كان يتم الاكتفاء بوثيقة تعريف المتطلبات والتي تكتب باستعمال اللغة الطبيعية لوصف وتسجيل متطلبات النظم بحيث يمكن للعميل أن يفهم كل كلمة موجودة بها، إلا أن ذلك يسبب العديد من المشاكل والتي يعود سببها في أغلب الأحيان إلى سوء تفسير بعض التعبيرات للمستخدمين من قبل المصمم أو العكس، فعلى سبيل المثال قد يطلق المستخدم على النظام التعبير (متوقف عن العمل) إذا كان النظام مشغول بعملية تسجيل احتياطي باعتبار أن لا يستجيب لأوامر المستخدم في هذه الحالة، بينما يعتبر المصمم أن النظام في هذه الحالة (مستمر في العمل) لأنه يقوم بمهمة أساسية!
لذا فأن الاعتماد على اللغة البشرية بشكل تام قد يؤدي إلى أخطاء كثيرة عند تصميم النظام، وينتج عنها نظام لا يقبله العميل لأنه لا يلبي متطلباته التي حددها من قبل، لذلك يتم كتابة نوع ثاني من الوثائق تسمى "وثائق مواصفات المتطلبات" Requirement specification Document وهي تكتب باستعمال وسائل وطرق خاصة ابتكرها مهندسو البرمجيات لكتابة المتطلبات بأسلوب تقني بحت. منها على سبيل المثال: لغة النمذجة الموحدة UML Unified Modeling Language و هي لغة نمذجة رسومية تقدم لنا صيغة لوصف العناصر الرئيسية للنظم البرمجية.

رابعا: التثبت والتحقق من المتطلبات التي تم تسجليها في كلا من وثيقة تعريف المتطلبات (والتي تقدم للعميل) ووثيقة مواصفات المتطلبات (والتي تقدم للمصمم) للتأكد من صحتهما وشموليتهما وأن كلا منهما لا تعارض الثانية في أي نقطة، وإلا فإن النتيجة سوف تكون نظام لا يلبي طلبات العميل!.

الأجزاء التي يجب أن تحتوي عليها وثيقة مواصفات المتطلبات:-

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

2-     وصف مختصر للوظائف التي سينجزها النظام للمستفيد، بدون التطرق للتفاصيل مع مراعاة أن يتم كتابة ذلك بأسلوب بسيط.

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

4-     أن يتم رسم المخططات البيانية التفصيلية بأسلوب النماذج الحسية لكي تمثل المعالجة التي سيتم إجراءها والفترة الزمنية للدورات المختلفة ومتطلبات جودة الأداء وذلك من وجهة نظر المستخدم.

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

6-     شرح تفصيلي للمخططات التفصيلية عن طرق الشرح السردي وجداول القرار وشجرات القرار وكذلك عبارات تعبيرية باللغة الإنجليزية.

7-     مخططات توضح مخازن البيانات وكيفية الوصول إليها وانتقالها من مكان إلى آخر وذلك من وجهة نظر المستفيد.

8-     توضيح وتوثيق لجميع مخرجات النظام التي سوف يحتاجها المستفيدين وذلك عن طريق إعداد نموذج خاص بكل تقرير، يحتوي هذا النموذج على بيانات مثل:- رقم التقرير، اسم التقرير، وسط الإخراج للتقرير، الغرض من هذا التقرير، لمن يعطى هذا التقرير، حجم التقرير، معدل الاستخدام، محتويات التقرير.

9-     توضيح وتوثيق لجميع نماذج المدخلات التي سوف تستخدم لإدخال البيانات للنظام، مع توثيق مواصفات هذه النماذج من خلال نماذج معدة لهذا الغرض تحدد مواصفات نماذج المدخلات المقدمة من قبل المستخدم.

10-                     وصف لمجموعة احتياجات من النظام تهم المستفيد، مثل زمن الاستجابة للنظام وحجم المعاملات الجارية والتوقيت ومعلومات عن الصلاحيات للمستخدمين وسرية المعلومات للنظام.

11-                     توثيق للمشاكل والأشياء التي مازالت غير واضحة ولم يتم تحديد طريقة للتعامل معها بَعِد.

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

>إن متطلبات الزبون التي يتم تسجيلها يجب أن يكون لها المواصفات التالية:-
$ أن تكون مكتوبة بأسلوب بسيط يستطيع المستخدم فهم دور الحاسوب في النظام.

$ أن تكون متعلقة بأمور ضرورة للعميل، ويتطلبها النظام.
$ أن تكون موضحة بالرسوم البيانية والمخططات.
$ أن تكون صحيحة وخالية من الأخطاء.

$أن يكون من الممكن التحقق منها.
 $أن تكون قابلة للتتبع.

 $أن تكون واقعية بمعنى أن تكون قابلة للتطبيق في الواقع.

 $أن تكون ثابتة بمعنى أن لا يكون هناك أي تعارض بين متطلب وآخر.
 $أن تكون تامة يجب أن يتم ذكر جميع الحالات المحتملة للنظام، المدخلات، المخرجات المتوقعة منه.

المراجع:-

1- ميشل بورز، دافيد آدمز، هارلان ميلز، تطوير نظم معلومات الحاسب الآلي تحليل وتصميم، ترجمة/ د. ابراهيم عبدالسلام، د. محمد نزيه الدريني، المملكة العربية السعودية، معهد الإدارة العامة، 1988ف .

2- د. فايز جمعة صالح النجار، نظم المعلومات الإدارية، الأردن- دار الحامد للنشر والتوزيع،  2005 ف.

3- منتديات أفق العرب - دروس بسيطة في هندسة البرامج Software Engineering للمستوى الثالث       _httpwww.arabsline.netvbarchiveindex.phpt-10148.html

3- Software Engineering A Dynamic Approach , By Stuart I. Wattam, Sigma press  UK, 1991.