بناء متطلبات المستخدم

Microsoft Visual Studio Ultimate يساعدك في فهم و مناقشة والاتصال باحتياجات المستخدمين لديك بواسطة رسم رسومات تخطيطية حول الأنشطة الخاصة بهم و الجزء الذي يلعبه النظام الخاص بك في تحقيق الأهداف الخاصة بهم. طراز المتطلبات هو مجموعة من الرسومات التخطيطية هذه, كل منها تركز على جوانب مختلفة من احتياجات المستخدمين.

طراز المتطلبات يساعدك في:

• التركيز على السلوك الخارجي الخاص بالنظام, بشكل منفصل عن تصميمه الداخلي.

• وصف احتياجات المستخدمين و المساهمين مع غموض أقل بكثير من اللغة العادية.

• تعريف معجم متناسق المصطلحات يمكن استخدامه من قِبَل المستخدمين و المطورين و المختبرين.

• إنقاص التباعد و عدم التناسق في المتطلبات.

• تقليل العمل المطلوب للاستجابة للتغيّر في المتطلبات.

• تخطيط ترتيب تطوير الميزات.

• استخدام النماذج كأساس لاختبارات النظام, و وضع علاقات واضحة بين الاختبارات و المتطلبات. عند تغيير المتطلبات, تساعدك هذه العلاقة على تحديث الاختبارات بشكل صحيح. هذا يضمن أن يلبي النظام المتطلبات الجديدة.

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

ملاحظة

خلال هذه المواضيع, "النظام" يعني النظام أو التطبيق الذي يتم تطوير. قد يكون مجموعة كبيرة من مكونات البرامج والأجهزة; أو تطبيق واحد; أو أحد مكونات البرامج داخل نظام أكبر. في كل حالة, طراز المتطلبات يصف السلوك الذي يمكن رؤيته من خارج النظام الخاص بك, إما من خلال واجهة مستخدم أو API.

المهام الشائعة

يمكنك إنشاء عدة طرق عرض مختلفة من متطلبات المستخدمين. كل عرض يوفر نوع معين من المعلومات. عند إنشاء طرق العرض هذه, فمن الأفضل الانتقال بشكل متكرر من واحد إلى آخر. يمكنك البدء من أي طريقة عرض.

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

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

وصف كيفية استخدام النظام الخاص بك

أنشئ رسومات تخطيطية لحالات الاستخدام لوصف الذي يستخدم النظام و ما يستخدمه لأجله. حالة الاستخدام تمثّل هدف مستخدم النظام, و الإجراء الذي يقوم بتنفيذه لتحقيق الهدف.

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

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

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

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

مخطط حالة الاستخدام يوفر فقط ملخصًا عن حالات الاستخدام. لتوفير أوصاف أكثر تفصيلاً, يمكنك ربط حالات الاستخدام في الرسم التخطيطي لمستندات منفصلة، و رسومات تخطيطية أخرى. للتعرف على كيفية فعل ذلك، راجع كيفية القيام بما يلي: ربط حالة استخدام بمستندات و مخططات.

رسم مخطط حالة استخدام يساعد الفريق الخاص بك على:

• التركيز على ما يتوقع المستخدمون أن يتم فعله بالنظام، دون أن يتم تشويشهم بواسطة تفاصيل التطبيق.

• مناقشة نطاق النظام الخاص بك أو إصدارات معينة من النظام.

توفر المواضيع التالية مزيداً من المعلومات:

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

تعريف المصطلحات المستخدمة لوصف المتطلبات

يمكنك استخدام الرسومات التخطيطية للفئة UML لتساعدك في تطوير كلمات متناسقة من مفاهيم الأعمال المستخدمة للأغراض التالية:

• بواسطة المستخدمين أنفسهم لمناقشة العمل الذي يعمل فيه النظام.

• لوصف احتياجات المستخدمين, على سبيل المثال في أوصاف حالات الاستخدام وقواعد الأعمال و قصص المستخدمين.

• أنواع المعلومات المتبادلة في الـ API الخاص بالنظام أو من خلال واجهة المستخدم.

• أوصاف النظام أو اختبارات القبول.

عندما يتم استخدامها لهذا الغرض, محتوى مخطط فئة UML يسمى المخطط التصوري لفئة. (وهو يعرف أيضًا بـ طراز المجال أو طراز تحليل فئة .)

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

على سبيل المثال، يمكنك رسم هذه الفئات التصورية لنظام "العشاء الآن":

الرسم التخطيطي التصزري للفئة يوفر معجمًا بالمصطلحات التي تستخدمها خلال طراز المتطلبات. على سبيل المثال، في الوصف المفصّل لحالة الاستخدام "طلب وجبة" قد تكتب:

العميل يختار القائمة التي منها ينشئ طلب ومن ثم يقوم بإنشاء عناصر الطلب في الـ طلب عن طريق تحديد عناصر القائمة من الـ قائمة.

لاحظ كيف أن المصطلحات المستخدمة في ذلك الوصف هي أسماء الفئات في الطراز. الرسم التخطيطي يزيل الغموض من العلاقات بين تلك الفئات. على سبيل المثال, فإنه يُظهر بوضوح أن كل "طلب" يقترن بـ"قائمة" واحدة فقط.

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

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

على سبيل المثال، قد يتم تمثيل الطلبات في XML و SQL و HTML و C# في أجزاء مختلفة من النظام في واجهات مختلفة بين الأجزاء. الاقتران بين "طلب" و "قائمة" قد يتم تمثيله بعدة طرق مختلفة, مثل المراجع داخل التعليمات البرمجية في C# ، أو العلاقات في قاعدة البيانات, أو الـIDs المتداخلة المرجعية في XML. ولكن بالرغم من هذه الاختلافات, الطراز التصوري يوفر معلومات هامة صحيحة في كل جزء من البرنامج. الرسم التخطيطي للفئة في المثال يوضح لنا أن في كل تطبيق سيكون هناك "قائمة" واحدة فقط مقترنة بكل "طلب".

رسم مخطط فئة للمتطلبات يساعد الفريق الخاص بك على:

• تعريف و معايرة المصطلحات الأساسية المستخدمة في مناقشات احتياجات المستخدمين.

• توضيح العلاقات بين تلك المصطلحات.

توفر المواضيع التالية مزيداً من المعلومات:

التعرف على	قراءة
معلومات أكثر تفصيلا حول البحث عن فئات المتطلبات	مخططات فئات UML: إرشادات
العناصر في مخطط تصوّري لفئة	مخططات فئات UML: المرجع
كيفية تطوير التعليمات البرمجية من الفئات التصورية	بناء نمذجة لبنية نظام البرامج.

إظهار قواعد العمل

قاعدة عمل هي أحد المتطلبات الغير مقترنة بحالة استخدام محددة, و يجب أن تكون ملاحظة من خلال النظام.

العديد من قواعد العمل تكون قيود على العلاقات بين الفئات التصورية. يمكنك كتابة قواعد العمل الثابتة هذه كتعليقات مقترنة بالفئات ذات الصلة في الرسم تخطيطي التصوري لفئة. فعلى سبيل المثال:

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

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

لاحظ أن الاختيار هنا هو حول كيفية تعريفك للمتطلبات, و أن هذا مستقل عن كيفية تنفيذ المتطلبات في التعليمات البرمجية للبرنامج.

توفر المواضيع التالية مزيداً من المعلومات:

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

وصف متطلبات جودة الخدمة

توجد عدة فئات من متطلبات جودة الخدمة. وتتضمن ما يلي:

• الأداء

• الأمان

• قابلية الاستخدام

• الاعتمادية

• الشدة

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

إذا قام "مطعم" بحذف "عنصر قائمة" أثناء قيام "عميل" بـ "طلب وجبة" ، سيتم عرض أي "عنصر مطلوب" مرتبط بـ"عنصر القائمة" هذا سيتم عرضه باللون الأحمر.

توفر المواضيع التالية مزيداً من المعلومات:

التعرف على	قراءة
معلومات أكثر تفصيلا حول تسجيل جودة متطلبات جودة الخدمة	Guidelines for Defining Quality of Service Requirements
إرفاق مستندات إضافية بحالات الاستخدام	كيفية القيام بما يلي: ربط حالة استخدام بمستندات و مخططات
كيفية تطوير التعليمات البرمجية التي تلتزم بمتطلبات جودة الخدمة	بناء نمذجة لبنية نظام البرامج.

إظهار تدفق العمل بين المستخدمين و النظام الخاص بك

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

فعلى سبيل المثال:

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

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

توفر المواضيع التالية مزيداً من المعلومات:

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

إظهار التفاعلات بين المستخدمين و النظام الخاص بك

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

فعلى سبيل المثال:

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

توفر المواضيع التالية مزيداً من المعلومات:

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

استخدام طراز لتقليل حالات عدم التناسق

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

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

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

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

• اسأل عن القيود الموجودة على السمات و الاقترانات, و خاصة القيود المتعلقة بأكثر من سمة أو اقتران.

• اسأل عن التسلسلات الصالحة و الغير صالحة من حالات الاستخدام, و ارسم رسومات تخطيطية تسلسلية أو رسومات تخطيطية للأنشطة لتوضيحها.

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

راجع أيضًا:

المبادئ

كيفية القيام بما يلي: تحرير مخططات و طراز UML

تطوير اختبارات من طراز

استخدام الطرازات داخل عملية التطوير

بناء نمذجة لبنية نظام البرامج.