في كتاب "الأساليب الحديثة لوصف المتطلبات الوظيفية للأنظمة" ، وصف أليستير كوبورن طريقة واحدة لكتابة جزء من بيان المشكلة ، وهي طريقة حالة الاستخدام.
ما هذا هذا وصف لسيناريو تفاعل المستخدم مع نظام (أو عمل). يعمل النظام في نفس الوقت كصندوق أسود (وهذا يجعل من الممكن تقسيم مهمة التصميم المعقدة إلى تصميم التفاعل وضمان هذا التفاعل). في الوقت نفسه ، يتم تقديم معايير الترميز ، والتي تضمن سهولة القراءة ، بما في ذلك لغير المشاركين ، وتتيح لك إجراء بعض الاختبارات للتأكد من اكتمالها والامتثال لأهداف صاحب المصلحة.
استخدام مثال الحالة
كيف يبدو السيناريو ، باستخدام مثال التفويض على الموقع عبر البريد الإلكتروني:
(النظام) قم بتسجيل الدخول إلى الموقع للوصول إلى حسابك الشخصي. ~~ (مستوى سطح البحر)
السياق: يتم تخويل العميل غير المصرح به على الموقع حتى يتعرف عليه الموقع ويعرض معلوماته الشخصية: محفوظات الاستعراض والمشتريات والعدد الحالي لنقاط المكافآت وما إلى ذلك ، باستخدام البريد الإلكتروني لتسجيل الدخول.
المستوى: هدف المستخدم
الممثل الرئيسي: العميل (زائر إلى متجرنا على الإنترنت)
النطاق: تفاعل العملاء مع موقع المتجر الإلكتروني
الأطراف والمصالح المهتمة:
- يريد المسوق تحديد أكبر عدد ممكن من زوار الموقع للوصول إلى النشرات الإخبارية الشخصية بشكل أفضل ،
- يريد أحد متخصصي الأمن منع الوصول غير المصرح به إلى البيانات الشخصية للزائر ، بما في ذلك محاولات تحديد كلمة مرور لحساب واحد أو البحث عن حساب بكلمة مرور ضعيفة ،
- يريد المهاجم الوصول إلى مكافآت الضحية ،
- المنافسون يريدون ترك ردود فعل سلبية على المنتجات ،
- يريد الروبوتات الحصول على قاعدة عملاء المتجر واستخدام الهجوم لجعل الموقع غير صالح.
الشروط المسبقة: يجب ألا يتم تسجيل دخول الزائر.
الحد الأدنى من الضمانات: سوف يكتشف الزائر حقيقة محاولة تسجيل دخول ناجحة أو غير ناجحة.
ضمانات النجاح: الزائر مخول.
السيناريو الرئيسي:
- يبدأ العميل إذن.
- يؤكد النظام أن العميل غير مصرح له ولا يتجاوز عدد محاولات تسجيل الدخول غير الناجحة من هذه الجلسة (البحث عن كلمة مرور ضعيفة للعديد من الحسابات) بموجب القاعدة الأمنية رقم 23.
- يزيد النظام من عدد محاولات التفويض.
- يعرض النظام نموذج تفويض للعميل.
- العميل يدخل البريد الإلكتروني وكلمة المرور.
- يؤكد النظام وجود عميل لديه مثل هذا البريد الإلكتروني في النظام وكلمة المرور مطابقة ولا يتجاوز عدد محاولات الدخول إلى هذا الحساب وفقًا لقاعدة الأمان رقم 24.
- يأذن النظام للعميل ، ويضيف سجل التصفح وسلة هذه الجلسة مع الجلسة الأخيرة من حساب العميل هذا.
- يعرض النظام رسالة نجاح التخويل ويستمر في خطوة البرنامج النصي التي قاطع منها العميل التخويل. في هذه الحالة ، يتم تحميل البيانات الموجودة على الصفحة بشكل زائد مع مراعاة البيانات الشخصية للحساب.
ملحقات:
2.أ. العميل مفوض بالفعل:
2.A.1. يخطر النظام العميل بحقيقة التفويض الذي تم تقديمه مسبقًا ويقترح إما إحباط البرنامج النصي أو المتابعة إلى الخطوة 4 ، بينما إذا تم إكمال الخطوة 6 بنجاح ، فسيتم تنفيذ الخطوة 7 مع التوضيح:
2.a.7. يقوم النظام بإلغاء تنشيط العميل بموجب الحساب القديم ، ويخوّل العميل بموجب الحساب الجديد ، بينما يظل سجل التصفح وسلة جلسة التفاعل هذه في الحساب القديم ، ولا يدخل في الحساب الجديد. بعد ذلك ، انتقل إلى الخطوة 8.
2.b تجاوز عدد محاولات التفويض الحد الأدنى بموجب "القاعدة الأمنية رقم 23":
2.b.1 انتقل إلى الخطوة 4 ، يتم عرض كلمة التحقق بشكل إضافي على نموذج التفويض
2.b.6 يؤكد النظام الإدخال الصحيح لبرنامج captcha
2.b.6.1 كلمة التحقق التي تم إدخالها بطريقة غير صحيحة:
2.b.6.1.1. يزيد النظام من محاولات تسجيل الدخول الفاشلة لهذا الحساب أيضًا
2.b.6.1.2. يعرض النظام رسالة فشل ويعود إلى الخطوة 2
6.أ. لم يتم العثور على حساب بهذه الرسالة الإلكترونية:
6.a.1 يعرض النظام رسالة حول الفشل ويقدم خيار إما الانتقال إلى الخطوة 2 أو الانتقال إلى البرنامج النصي "تسجيل المستخدم" مع حفظ البريد الإلكتروني الذي تم إدخاله ،
6.b. كلمة المرور من الحساب مع هذا البريد الإلكتروني لا تتطابق مع المدخلات:
6.b.1 يزيد النظام من محاولات فاشلة لإدخال هذا الحساب.
6.b.2 يعرض النظام رسالة فشل ويقدم اختيار إما الانتقال إلى سيناريو "استعادة كلمة المرور" أو الانتقال إلى الخطوة 2.
6.ج: تجاوز عدد محاولات الدخول إلى هذا الحساب الحد الأدنى بموجب "القاعدة الأمنية رقم 24".
6.v.1 يعرض النظام رسالة حول حظر مدخل الحساب لمدة X دقيقة ويستمر إلى الخطوة 2.
ما هو عظيم
يتحقق من اكتمال الأهداف والامتثال لها ، أي أنه يمكنك إعطاء متطلبات التحقق إلى محلل آخر ، مما يسمح بوجود أخطاء أقل في مرحلة تعيين المهمة.
يتيح لك العمل مع نظام مثل الصندوق الأسود مشاركة التطوير والتنسيق مع العميل حول ما سيتم تشغيله تلقائيًا من أساليب التنفيذ.
إنه جزء من مسار المحلل ، وهو أحد الأجزاء الرئيسية لقابلية الاستخدام. يحدد البرنامج النصي للمستخدم المسارات الرئيسية لحركته ، مما يقلل بدرجة كبيرة من حرية اختيار المصمم والعميل ويساعد على زيادة سرعة تطوير التصميم.
إنه لأمر ممتع للغاية في وصف المكان الذي يتم فيه الكشف عن استثناءات كل خطوة تفاعل. يجب أن يوفر نظام تكنولوجيا المعلومات الشامل معالجة استثناء أو أخرى ، وجزء في الوضع اليدوي ، وجزء تلقائي (كما في المثال أعلاه).
لقد أظهرت التجربة أن التعامل مع الاستثناءات بشكل سيء يمكن أن يحول النظام بسهولة إلى نظام غير مريح بشكل فظيع. أتذكر قصة عندما كان مطلوبًا في الأوقات السوفيتية الحصول على العديد من الموافقات من الخدمات المختلفة من أجل الحصول على حل ، وهو مؤلم عندما تقول الخدمة الأخيرة - ولديك اسم خاطئ أو خطأ آخر في علامات الترقيم ، وإعادة كل شيء والتوفيق بين كل شيء.
غالبًا ما أواجه مواقف تتطلب فيها منطق النظام الذي لم يتم التفكير فيه للاستثناءات تغييرًا كبيرًا في هذا النظام. ولهذا السبب ، يتم إنفاق نصيب الأسد من عمل المحلل على معالجة الاستثناءات.
تدوين النص ، على عكس المخططات ، يسمح لك بتحديد وتغطية المزيد من الاستثناءات.
بالإضافة إلى طريقة الممارسة
حالة الاستخدام ليست جزءًا من أولويات الإنتاج بشكل مستقل ، على عكس قصة المستخدم.
في هذا السيناريو ، خذ بعين الاعتبار الاستثناء "6.a. لم يتم العثور على حساب مع هذا البريد الإلكتروني. " والخطوة التالية "6.a.1. يعرض النظام رسالة فشل وينتقل إلى الخطوة 2". ماذا عن البقايا السلبية وراء الكواليس؟ بالنسبة للعميل ، فإن أي عائد يعادل حقيقة أن كل العمل الذي قام به بإدخال البيانات يتم طرحه في المكب. (هذا ببساطة غير مرئي في البرنامج النصي!) ما الذي يمكن عمله؟ إعادة إنشاء البرنامج النصي بحيث لا يحدث هذا. هل يمكن القيام بذلك؟ يمكنك - على سبيل المثال ، إلقاء نظرة على البرنامج النصي للترخيص في Google.
تحسين السيناريو
يتحدث الكتاب عن إضفاء الطابع الرسمي ، ولكن لا يتحدث إلا قليلاً عن أساليب التحسين لمثل هذه السيناريوهات.
ولكن من الممكن تقوية الطريقة من خلال تحسين النصوص ، وطريقة إضفاء الطابع الرسمي على حالة الاستخدام تسمح بذلك. على وجه التحديد ، في كل استثناء يحدث ، تحتاج إلى التفكير فيه وتحديد السبب وإعادة إنشاء البرنامج النصي للتخلص من الاستثناء أو تقليل مسار العميل.
عند طلب المتجر عبر الإنترنت ، يجب أن تدخل مدينة التسليم. قد يتضح أنه بالنسبة للمدينة التي اختارها العميل ، لا يستطيع المتجر تسليم البضائع لأنه لا يتم تسليمها هناك ، بسبب القيود الكلية أو بسبب نقص البضائع في المستودع المقابل.
إذا قمت ببساطة بوصف سيناريو التفاعل في مرحلة التصميم ، فيمكنك كتابة "إبلاغ العميل باستحالة التسليم وعرض تغيير المدينة أو تركيبة السلة" (ويتوقف العديد من المحللين المبتدئين عند هذا). ولكن إذا كان هناك الكثير من هذه الحالات ، فيمكنك تحسين السيناريو.
أول شيء فعله هو إعطاء المدينة فقط حيث يمكننا القيام بالتسليم. متى تفعل ذلك؟ قبل لحظة اختيار المنتج على الموقع (اكتشاف المدينة التلقائي عبر بروتوكول الإنترنت مع المواصفات).
ثانياً - تحتاج إلى إعطاء خيار للبضائع التي يمكننا توصيلها إلى العميل فقط. متى تفعل ذلك؟ في وقت الاختيار - على البلاط البضائع وبطاقة المنتج.
هذه التغييرات جهازي القضاء بشكل كبير هذا الاستثناء.
متطلبات القياس والمتري
بالنظر إلى مهمة تقليل معالجة الاستثناءات إلى الحد الأدنى ، يمكنك وضع المهمة على إعداد التقارير (لم يتم وصف حالة الاستخدام). كم عدد الاستثناءات ، في الحالات التي حدثت فيها ، بالإضافة إلى عدد السيناريوهات التي نجحت من تلك الواردة.
لكن للأسف. لقد أظهرت التجربة أن متطلبات إعداد التقارير للسيناريوهات في هذا النموذج ليست كافية ، تحتاج إلى النظر في متطلبات إعداد التقارير للعمليات الموضحة بشكل رئيسي وليس في شكل حالة استخدام.
سهولة الاستخدام
في ممارستنا ، قمنا بتوسيع وصف وصف حالة الاستخدام مع وصف السمات المحددة للكيانات والبيانات لاتخاذ القرارات من قبل العميل ، مما يعزز قابليتها للاستخدام اللاحقة.
لتصميم قابليتها للاستخدام ، أضفنا قسم الإدخال - البيانات المعروضة.
في سيناريو التخويل ، هذه حقيقة تفويض العميل في النظام. إذا كان العميل مفوضًا مسبقًا ، فقم بعرض تحذير حول تبديل محفوظات التنقل والسلة إلى الحساب الجديد بعد التفويض الناجح.
في الحالة العامة ، يعد هذا تعيينًا للمعلومات الضرورية للعميل حتى يتسنى له اتخاذ قرار بشأن تصرفاته الإضافية وفقًا للسيناريو (قد يسأل المرء عما إذا كان لدى العميل ما يكفي من هذه البيانات ، وما هو المطلوب ، وما هي المعلومات المطلوبة للعميل لاتخاذ القرارات).
يجدر أيضًا تقسيم معلومات الإدخال في حقول الإدخال في حالة حدوث معالجتها بشكل منفصل ومع تشكيل استثناءات مختلفة.
في المثال الخاص بتفويض العميل ، إذا قمت بتمييز المعلومات التي تم إدخالها باستخدام اسم مستخدم وكلمة مرور ، فيجب عليك تغيير البرنامج النصي للتخويل من خلال الخطوات المنفصلة لإدخال تسجيل دخول وكلمة مرور منفصلين (ويتم ذلك في Yandex ، Google ، ولكن ليس في معظم المتاجر عبر الإنترنت).
الوصول إلى تحويلات البيانات المطلوبة
يمكن أيضًا سحب متطلبات خوارزميات تحويل البيانات من البرنامج النصي.
الأمثلة على ذلك:
- لاتخاذ قرار بشأن شراء منتج في متجر على الإنترنت ، يحتاج العميل إلى أن يعرف على بطاقة المنتج إمكانية وتكلفة وشروط تسليم هذا المنتج لمدينته (والتي يتم حسابها بواسطة الخوارزمية على حقيقة توفر السلع في المستودعات ومعايير سلسلة التوريد).
- عند إدخال عبارة في سلسلة البحث ، يظهر العميل تلميحات البحث بواسطة الخوارزمية (التي يتم تكوينها بواسطة الخوارزمية ...).
في المجموع
بشكل عام ، بعد قراءة الكتاب ، لسوء الحظ ، ليس من الواضح كيفية الانتقال إلى الأمام من المحلل إلى مشاكل العمل إلى المعارف التقليدية الرسمية للمطور. يروي الكتاب جزءًا فقط من العملية بخطوات غير واضحة واردة ويظهر بشكل غير واضح الخطوات التالية. في الغالب ، حالة الاستخدام ليست في الغالب بيانًا كاملاً للمطور.
ومع ذلك ، فهذه طريقة جيدة جدًا لإضفاء الطابع الرسمي على سيناريوهات تفاعل الكائن وموضوعه ومعالجتهما ، عندما يتسبب التفاعل في تغيير شيء ما في الموضوع. إنه أحد أساليب الكتابة القليلة التي تسمح بمتطلبات قابلة للتحقق مع وجود نقاط بحث استثناء صريحة.
مطلوب قراءة الكتاب من قبل المحللين حتى يبدأوا في كتابة منتجات يمكن التحقق منها.