‫‪‬‬

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

‫يعد تحليل المتطلبات أمًر ا بالغ األهمية لنجاح أو فشل مشروع‬

‫األنظمة أو البرامج‪ ]3[ .‬يجب أن تكون المتطلبات موثقة ‪ ،‬وقابلة‬
‫للتنفيذ ‪ ،‬وقابلة للقياس ‪ ،‬وقابلة لالختبار ‪ ،‬وقابلة للتتبع ‪ ،‬وذات صلة‬
‫باحتياجات أو فرص العمل المحددة ‪ ،‬ومحددة بمستوى من التفاصيل‬
‫‪.‬يكفي لتصميم النظام‬

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

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

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

‫موضوعات تحليل المتطلبات‬

‫تحديد أصحاب المصلحة‬
‫راجع تحليل أصحاب المصلحة لمناقشة األشخاص أو المنظمات (الكيانات القانونية مثل الشركات وهيئات المعايير) التي لها مصلحة‬
‫مشروعة في النظام‪ .‬قد يتأثرون به إما بشكل مباشر أو غير مباشر‪ .‬كان التركيز الجديد الرئيسي في التسعينيات هو التركيز على‬
‫تحديد أصحاب المصلحة ‪ .‬من المعترف به بشكل متزايد أن أصحاب المصلحة ال يقتصرون على المنظمة التي تستخدم المحلل‪.‬‬
‫‪:‬أصحاب المصلحة اآلخرون سيشملون‬

‫)أي شخص يقوم بتشغيل النظام (عادي ومشغل صيانة‬

‫)كل من يستفيد من النظام (مستفيد وظيفي ‪ ،‬سياسي ‪ ،‬مالي ‪ ،‬اجتماعي‬
‫أي شخص يشارك في شراء أو شراء النظام‪ .‬في منظمة منتجات السوق الشامل ‪ ،‬تعمل إدارة المنتجات والتسويق والمبيعات‬
‫‪.‬أحياًن ا كمستهلكين بديلين (عمالء السوق الشامل) لتوجيه تطوير المنتج‬
‫)المنظمات التي تنظم جوانب من النظام (المالية ‪ ،‬والسالمة ‪ ،‬وغيرها من الجهات التنظيمية‬
‫) األشخاص أو المنظمات المعارضة للنظام (أصحاب المصلحة السلبيون ؛ انظر أيًض ا حالة إساءة االستخدام‬
 ‫‪.‬المنظمات المسؤولة عن األنظمة التي تتفاعل مع النظام قيد التصميم‬
‫‪‬‬ ‫‪.‬تلك المنظمات التي تتكامل أفقًي ا مع المنظمة التي يصمم المحلل النظام لها‬

‫)‪ (JRD‬جلسات تطوير المتطلبات المشتركة‬

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

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

‫قوائم متطلبات نمط العقد‬

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

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

‫نقاط القوة‬
‫‪.‬يوفر قائمة مرجعية بالمتطلبات‬
‫‪.‬تقديم عقد بين راعي المشروع والمطورين‬
‫‪.‬بالنسبة لنظام كبير يمكن أن يوفر وصًف ا عالي المستوى يمكن من خالله اشتقاق متطلبات المستوى األدنى‬

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

‫بديل لقوائم المتطلبات‬

‫‪.‬قصص المستخدمين القتراح المتطلبات في اللغة اليومية ‪ Agile Software Development‬كبديل لقوائم المتطلبات ‪ ،‬يستخدم‬

‫أهداف قابلة للقياس‬

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

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

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

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

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

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

‫أنواع المتطلبات‬
‫[‪1‬‬ ‫]يتم تصنيف المتطلبات بعدة طرق‪ .‬فيما يلي تصنيفات مشتركة للمتطلبات التي تتعلق باإلدارة الفنية‪:‬‬

‫متطلبات العميل‬
‫بيانات الحقائق واالفتراضات التي تحدد توقعات النظام من حيث أهداف المهمة ‪ ،‬والبيئة ‪ ،‬والقيود ‪ ،‬ومقاييس الفعالية والمالءمة‬
‫العمالء هم أولئك الذين يؤدون الوظائف األساسية الثمانية لهندسة األنظمة ‪ ،‬مع التركيز بشكل خاص على المشغل ‪(MOE / MOS).‬‬
‫باعتباره العميل الرئيسي‪ .‬ستحدد المتطلبات التشغيلية االحتياجات األساسية ‪ ،‬وعلى األقل تجيب على األسئلة المطروحة في القائمة‬
‫]التالية‪1[ :‬‬

‫التوزيع أو النشر التشغيلي ‪ :‬أين سُي ستخدم النظام؟‬

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

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

‫متطلبات غير مجدية‬

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

‫المتطلبات المشتقة‬
‫المتطلبات الضمنية أو المحولة من متطلبات المستوى األعلى‪ .‬على سبيل المثال ‪ ،‬قد يؤدي طلب المدى الطويل أو السرعة العالية إلى‬
‫[‪1‬‬
‫]متطلبات التصميم لوزن منخفض‪.‬‬
‫المتطلبات المخصصة‬
‫متطلب يتم إنشاؤه عن طريق تقسيم أو تخصيص متطلب عالي المستوى إلى متطلبات متعددة ذات مستوى أدنى‪ .‬مثال‪ :‬قد ينتج عن‬
‫]عنصر وزنه ‪ 100‬رطل يتكون من نظامين فرعيين متطلبات وزن تبلغ ‪ 70‬رطًال و ‪ 30‬رطًال للعنصرين األقل مستوى‪1[ .‬‬

‫‪ Hewlett-Packard .‬المطورة في ‪ FURPS + ،‬و ‪ FURPS‬تتضمن نماذج تصنيف المتطلبات المعروفة‬

‫قضايا تحليل المتطلبات‬

‫قضايا أصحاب المصلحة‬
 ‫‪:‬عدًد ا من الطرق التي يمكن للمستخدمين من خاللها منع جمع المتطلبات ‪ Rapid Development ،‬يوضح ستيف ماكونيل ‪ ،‬في كتابه‬
‫‪‬‬
‫ال يفهم المستخدمون ما يريدون أو ليس لدى المستخدمين فكرة واضحة عن متطلباتهم‬
‫لن يلتزم المستخدمون بمجموعة من المتطلبات المكتوبة‬
‫يصر المستخدمون على المتطلبات الجديدة بعد إصالح التكلفة والجدول الزمني‬
‫التواصل مع المستخدمين بطيء‬
‫غالًب ا ال يشارك المستخدمون في المراجعات أو يكونون غير قادرين على القيام بذلك‬
‫المستخدمون غير متطورين تقنًي ا‬
‫ال يفهم المستخدمون عملية التطوير‬
‫ال يعرف المستخدمون عن التكنولوجيا الحالية‬

‫‪.‬قد يؤدي هذا إلى الموقف الذي تتغير فيه متطلبات المستخدم باستمرار حتى عند بدء تطوير النظام أو المنتج‬

‫قضايا المهندس ‪ /‬المطور‬

‫‪:‬المشاكل المحتملة التي يسببها المهندسين والمطورين أثناء تحليل المتطلبات هي‬

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

‫محاولة الحلول‬
‫‪.‬كان أحد الحلول التي تم محاولة حلها لمشاكل االتصاالت هو توظيف متخصصين في تحليل األعمال أو النظام‬

‫وحاالت االستخدام ‪ ،‬وتطوير ‪ (UML) ،‬التقنيات التي تم تقديمها في التسعينيات مثل النماذج األولية ‪ ،‬ولغة النمذجة الموحدة‬
‫‪.‬البرمجيات الرشيقة تهدف أيًض ا إلى أن تكون حلواًل للمشكالت التي تمت مواجهتها مع األساليب السابقة‬

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

‫ألواح الكتابة اإللكترونية لرسم تدفقات التطبيق واختبار البدائل‬

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

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

‫مراجع‬
‫اقتناء الدفاع مطبعة جامعة ‪ Wayback. 2001 ،‬أساسيات هندسة النظم أرشفة ‪ 22-07-2011‬في آلة ‪1. ^ a b c d e f g h‬‬
 ‫كوتونيا ‪ ،‬جيرالد ؛ سومرفيل ‪ ،‬إيان (‪ .)1998‬هندسة المتطلبات‪ :‬العمليات والتقنيات ‪ .‬شيشستر ‪ ،‬المملكة المتحدة‪ :‬جون ^ ‪2.‬‬
‫‪‬‬ ‫‪ ISBN 9780471972082.‬وايلي وأوالده‪ .‬رقم‬
‫آالن أبران جيمس دبليو مور بيير بورك روبرت دوبوي ‪ ،‬محرران‪( .‬مارس ‪" .)2005‬الفصل ‪​:2‬متطلبات البرنامج" ‪ .‬دليل ^ ‪3.‬‬
‫‪ ISBN 0-‬رقم ‪ IEEE.‬لهندسة البرمجيات المعرفية (طبعة عام ‪ .)2004‬لوس أالميتوس ‪ ،‬كاليفورنيا‪ :‬مطبعة جمعية الكمبيوتر‬
‫تم االسترجاع ‪“ . 08-02-2007‬من المسلم به على نطاق واسع في صناعة البرمجيات أن مشاريع هندسة ‪7695-2330-7.‬‬
‫”‪.‬البرمجيات معرضة للخطر بشكل كبير عندما يتم تنفيذ هذه األنشطة بشكل سيئ‬

‫فهرس‬
‫بريان بيرينباخ دانيال بوليش يورجن كاتزمير أرنولد رودورفر (‪ .)2009‬هندسة متطلبات البرمجيات واألنظمة‪ :‬عملًي ا ‪.‬‬
‫‪ ISBN 978-0-07-160547-2.‬رقم ‪: McGraw-Hill Professional.‬نيويورك‬
‫هاي ‪ ،‬ديفيد سي (‪ .)2003‬تحليل المتطلبات‪ :‬من وجهات نظر األعمال إلى الهندسة المعمارية (الطبعة األولى)‪ .‬نهر السرج‬
‫‪ ISBN 0-13-028228-6.‬العلوي ‪ ،‬نيوجيرسي‪ :‬برنتيس هول‪ .‬رقم‬
‫رقم ‪ CRC.‬البالنت ‪ ،‬فيل (‪ .)2009‬هندسة المتطلبات للبرمجيات واألنظمة (الطبعة األولى)‪ .‬ريدموند ‪ ،‬واشنطن‪ :‬مطبعة‬
‫‪ISBN 978-1-4200-6467-4.‬‬
‫ماكونيل ‪ ،‬ستيف (‪ .)1996‬التطوير السريع‪ :‬ترويض جداول البرامج البرية (الطبعة األولى)‪ .‬ريدموند ‪ ،‬واشنطن‪ :‬مطبعة‬
‫‪ ISBN 1-55615-900-5.‬مايكروسوفت‪ .‬رقم‬
‫وقائع المؤتمر حول مستقبل ‪ (PDF) . ICSE '00.‬نسيبة ب‪ .‬إيستربروك ‪ ،‬س‪ .)2000( .‬هندسة المتطلبات‪ :‬خارطة طريق‬
‫‪ ISBN 1-‬هندسة البرمجيات ‪ .‬ص ‪ .46-35‬سيتسيركس ‪ . 10.1.1.131.3116 ‬دوى ‪ . 336512.336523 / 10.1145 :‬رقم‬
‫‪58113-253-0.‬‬
‫‪: O'Reilly Media.‬أندرو ستيلمان وجنيفر جرين (‪ .)2005‬إدارة مشاريع البرمجيات التطبيقية ‪ .‬كامبريدج ‪ ،‬ماساتشوستس‬
‫‪ ISBN 0-596-00948-8.‬رقم‬
‫كارل ويغرز وجوي بيتي (‪ .)2013‬متطلبات البرمجيات (الطبعة الثالثة)‪ .‬ريدموند ‪ ،‬واشنطن‪ :‬مطبعة مايكروسوفت‪ .‬رقم‬
‫‪ISBN 978-0-7356-7966-5.‬‬

‫روابط خارجية‬
‫مدخل موسوعة تمت مراجعته من قبل الزمالء حول هندسة المتطلبات والتحليل‬
‫عملية تعريف متطلبات أصحاب المصلحة بالجامعة الكتساب الدفاع‬
‫‪ MIL-HDBK 520‬دليل مستند متطلبات األنظمة‬