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

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

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

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

‫أستاذ المقرر‪ -:‬د‪ .‬عبدالحفيظ الشويهدي‬
‫الفصل الدراسي‪ -:‬خريف ‪ 2005‬ف‬

‫تقرير عن‬

‫مواصفات المتطلبات‬
‫(‪)Requirements specification‬‬

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

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

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

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

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

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

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

‫‪2‬‬
‫يمكن أن تستخدم وسائل أخرى لوصف العمليات التي تحدث‪ ،‬وهذه الوسائل مثل شجرات القرار‬
‫(‪ )Tree Decision‬وجداول القرار (‪.)Tables Decision‬‬

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

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

‫مهم ان لعملية تحليل النظم‪ ،‬وه ذان المنتج ان‬
‫خالل دورة تط وير النظم‪ ،‬يوجد منتج ان نهائي ان ّ‬
‫هما‪-:‬‬
‫‪ -1‬وثيقة مواصفات المتطلبات (مواصفات المستخدم)‪.‬‬
‫‪ -2‬وثيقة مواصفات تصميم النظام الجديد‪.‬‬

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

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

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

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

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

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

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

‫‪4‬‬
 ‫‪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‬بعد تسلم العميل للنظام قد تظهر بعض المشاكل أو األخطاء التي لم تظهر خالل عملية‬
‫االختبار‪ ،‬والتي تجب على المطور إصالحها فيما يعرف بصيانة النظام‪.‬‬

‫دورة حياة أي منتج تبدأ بأول خطوة وهي تحديد المتطلبات وتتدرج إلى باقي الخطوات كما هي‬
‫مرتبة حتى الوصول إلى آخر خطوة وهي تسليم البرنامج وصيانته (إن دعت الحاجة)‪ ،‬إال أن‬
‫التجارب العملية تظهر أن هذا ليس ضروريا وأن دورة حياة تطوير البرامج قد تأخذ أنماط‬

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

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

‫أوال‪ :‬االجتماع مع العميل للتعرف على المتطلبات‪:‬‬

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

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

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

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

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

‫رابعا‪ :‬التثبت والتحقق من المتطلبات التي تم تسجليها في كال من وثيقة تعريف المتطلبات‬

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

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

‫‪ -1‬مقدمة وعرض عام يتم فيه شرح الغرض واألهداف للنظام المراد إعداده‪ ،‬مع توضيح‬
‫لأله داف ال تي س يتم إض افتها على النظ ام الس ابق‪ ،‬وك ذلك ع رض ع ام ألي معلوم ات‬
‫أخرى تخص المستخدم أو المصمم‪.‬‬
‫‪ -2‬وصف مختصر للوظ ائف ال تي س ينجزها النظ ام للمس تفيد‪ ،‬ب دون التط رق للتفاص يل مع‬
‫مراعاة أن يتم كتابة ذلك بأسلوب بسيط‪.‬‬
‫‪ -3‬ع رض لعملي ات المعالجة ال تي س يقوم بها النظ ام باس تخدام الرسم البي اني‪ ،‬وذلك باتب اع‬
‫داء من المخطط البي ئي للنظ ام ثم المخطط‬
‫األس اليب العلمية في رسم ه ذه المخطط ات ابت ً‬
‫العام ثم المخططات التفصيلية‪.‬‬
‫‪ -4‬أن يتم رسم المخطط ات البيانية التفص يلية بأس لوب النم اذج الحس ية لكي تمثل المعالجة‬
‫ال تي س يتم إجراءها والف ترة الزمنية لل دورات المختلفة ومتطلب ات ج ودة األداء وذلك من‬
‫وجهة نظر المستخدم‪.‬‬
‫‪ -5‬أن تحتوي الوثيقة على قاموس البيانات يحتوي على جميع المصطلحات المستخدمة في‬
‫المخططات البيانية‪ ،‬مع شرح لكل هذه المصطلحات‪.‬‬
‫‪ -6‬ش رح تفص يلي للمخطط ات التفص يلية عن ط رق الش رح الس ردي وج داول الق رار‬
‫وشجرات القرار وكذلك عبارات تعبيرية باللغة اإلنجليزية‪.‬‬
‫‪ -7‬مخطط ات توضح مخ ازن البيان ات وكيفية الوص ول إليها وانتقالها من مك ان إلى آخر‬
‫وذلك من وجهة نظر المستفيد‪.‬‬
‫‪ -8‬توض يح وتوثيق لجميع مخرج ات النظ ام ال تي س وف يحتاجها المس تفيدين وذلك عن‬
‫طريق إع داد نم وذج خ اص بكل تقري ر‪ ،‬يحت وي ه ذا النم وذج على بيان ات مث ل‪ -:‬رقم‬
‫التقرير‪ ،‬اسم التقرير‪ ،‬وسط اإلخراج للتقرير‪ ،‬الغرض من هذا التقرير‪ ،‬لمن يعطى هذا‬
‫التقرير‪ ،‬حجم التقرير‪ ،‬معدل االستخدام‪ ،‬محتويات التقرير‪.‬‬
‫‪ -9‬توضيح وتوثيق لجميع نماذج المدخالت التي سوف تستخدم إلدخال البيانات للنظام‪ ،‬مع‬
‫توثيق مواصفات هذه النماذج من خالل نماذج معدة لهذا الغرض تحدد مواصفات نماذج‬
‫المدخالت المقدمة من قبل المستخدم‪.‬‬

‫‪8‬‬
‫وصف لمجموعة احتياجات من النظام تهم المستفيد‪ ،‬مثل زمن االستجابة للنظام‬ ‫‪-10‬‬
‫وحجم المع امالت الجارية والت وقيت ومعلوم ات عن الص الحيات للمس تخدمين وس رية‬
‫المعلومات للنظام‪.‬‬
‫توثيق للمشاكل واألشياء التي مازالت غير واضحة ولم يتم تحديد طريقة للتعامل‬ ‫‪-11‬‬
‫معها َب ِعد‪.‬‬
‫توض يح لآللية ال تي س يتم عن طريقها تق ديم ال دعم والت دريب والص يانة للنظ ام‬ ‫‪-12‬‬
‫الجديد بعد إعداده وتركيبه لدى الجهة المستفيدة‪.‬‬

‫‪‬إن متطلبات الزبون التي يتم تسجيلها يجب أن يكون لها المواصفات التالية‪-:‬‬
‫‪ ‬أن تكون مكتوبة بأسلوب بسيط يستطيع المستخدم فهم دور الحاسوب في النظام‪.‬‬
‫‪ ‬أن تكون متعلقة بأمور ضرورة للعميل‪ ،‬ويتطلبها النظام‪.‬‬
‫‪ ‬أن تكون موضحة بالرسوم البيانية والمخططات‪.‬‬
‫‪ ‬أن تكون صحيحة وخالية من األخطاء‪.‬‬
‫‪‬أن يكون من الممكن التحقق منها‪.‬‬
‫‪‬أن تكون قابلة للتتبع‪.‬‬
‫‪‬أن تكون واقعية بمعنى أن تكون قابلة للتطبيق في الواقع‪.‬‬
‫‪‬أن تكون ثابتة بمعنى أن ال يكون هناك أي تعارض بين متطلب وآخر‪.‬‬
‫‪‬أن تكون تامة يجب أن يتم ذكر جميع الحاالت المحتملة للنظام‪ ،‬المدخالت‪ ،‬المخرجات‬
‫المتوقعة منه‪.‬‬

‫المراجع‪-:‬‬

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

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

‫‪9‬‬
Software Engineering ‫ دروس بس يطة في هندسة ال برامج‬- ‫ منت ديات أفق الع رب‬-3
httpwww.arabsline.netvbarchiveindex.phpt-10148.html_ ‫للمستوى الثالث‬

3- Software Engineering A Dynamic Approach , By Stuart I.

Wattam, Sigma press UK, 1991.

10