الأساليب الحديثة لوصف المتطلبات الوظيفية للأنظمة. أليستير كوبيرن. مراجعة الكتاب والإضافات

يصف الكتاب طريقة واحدة لكتابة جزء من بيان المشكلة، وهي طريقة حالة الاستخدام.

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

استخدم مثال الحالة

كيف يبدو السيناريو باستخدام مثال التفويض الموجود على الموقع عبر البريد الإلكتروني:

(النظام) قم بتسجيل الدخول إلى الموقع للوصول إلى حسابك الشخصي. ~~ (مستوى سطح البحر)

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

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

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

السيناريو الرئيسي:

1. يبدأ العميل التفويض.
2. يؤكد النظام أن العميل غير مخول ولا يتجاوز عدد محاولات التفويض غير الناجحة من جلسة معينة (البحث عن كلمة مرور ضعيفة لحسابات متعددة) وفق "القاعدة الأمنية رقم 23".
3. يقوم النظام بزيادة العداد لعدد محاولات التفويض.
4. يقوم النظام بعرض نموذج التفويض للعميل.
5. يقوم العميل بإدخال البريد الإلكتروني وكلمة المرور الخاصة به.
6. يقوم النظام بالتأكد من وجود عميل لديه مثل هذا البريد الإلكتروني في النظام وأن كلمة المرور متطابقة وعدم تجاوز عدد محاولات الدخول لهذا الحساب حسب "القاعدة الأمنية رقم 24".
7. يقوم النظام بتفويض العميل وإضافة سجل التصفح وسلة هذه الجلسة مع الجلسة الأخيرة لحساب العميل هذا.
8. يعرض النظام رسالة نجاح التفويض وينتقل إلى خطوة البرنامج النصي التي تمت مقاطعة العميل منها للحصول على التفويض. وفي هذه الحالة يتم إعادة تحميل البيانات الموجودة على الصفحة مع مراعاة بيانات الحساب الشخصي.

ملحقات:
2.أ. العميل مخول بالفعل:
 2.أ.1. يقوم النظام بإعلام العميل بحقيقة التفويض الذي تم إجراؤه مسبقًا ويعرض عليه إما مقاطعة البرنامج النصي أو الانتقال إلى الخطوة 4، وإذا تم إكمال الخطوة 6 بنجاح، فسيتم تنفيذ الخطوة 7 مع التوضيح:
 2.أ.7. يقوم النظام بإلغاء تنشيط العميل ضمن الحساب القديم، وتفويض العميل ضمن الحساب الجديد، بينما يظل سجل التصفح وعربة جلسة التفاعل هذه في الحساب القديم ولا يتم نقلهما إلى الحساب الجديد. بعد ذلك، انتقل إلى الخطوة 8.
2.ب تجاوز عدد محاولات التفويض الحد الأدنى وفقًا لـ "القاعدة الأمنية رقم 23":
 2.ب.1 انتقل إلى الخطوة 4، بالإضافة إلى ذلك يتم عرض كلمة التحقق في نموذج التفويض
 2.ب.6 يؤكد النظام إدخال كلمة التحقق الصحيح
    2.ب.6.1 تم إدخال كلمة التحقق بشكل غير صحيح:
      2.ب.6.1.1. ويقوم النظام بزيادة عدد محاولات التفويض غير الناجحة لهذا الحساب أيضًا
      2.ب.6.1.2. يعرض النظام رسالة فشل ويعود إلى الخطوة 2
6.أ. لم يتم العثور على حساب بهذا البريد الإلكتروني:
 6.أ.1 يعرض النظام رسالة حول الفشل ويعرض خيار إما الانتقال إلى الخطوة 2 أو الانتقال إلى سيناريو "تسجيل المستخدم" وحفظ البريد الإلكتروني الذي تم إدخاله،
6.ب. كلمة المرور الخاصة بالحساب الذي يحتوي على هذا البريد الإلكتروني لا تتطابق مع كلمة المرور التي تم إدخالها:
 6.ب.1 يقوم النظام بزيادة عدد محاولات الدخول غير الناجحة إلى هذا الحساب.
 6.ب.2 يعرض النظام رسالة حول الفشل ويقدم خيار إما الانتقال إلى سيناريو "استرداد كلمة المرور" أو الانتقال إلى الخطوة 2.
6.ج: تجاوز عداد محاولات تسجيل الدخول لهذا الحساب الحد الأقصى لـ "قاعدة الأمان رقم 24".
 6.c.1 يعرض النظام رسالة حول حظر تسجيل الدخول إلى الحساب لمدة X دقيقة وينتقل إلى الخطوة 2.

ما هو عظيم

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

يتيح لك العمل بنظام الصندوق الأسود فصل التطوير والتنسيق مع العميل لما سيتم أتمتته عن طرق التنفيذ.

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

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

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

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

يتيح التدوين النصي، على عكس المخططات، تحديد المزيد من الاستثناءات وتغطيتها.

بالإضافة إلى الطريقة من الممارسة

حالة الاستخدام ليست جزءًا ذو أولوية مستقلة من البيان، على عكس قصة المستخدم.

في السيناريو أعلاه، خذ بعين الاعتبار الاستثناء "6.a. لم يتم العثور على حساب بهذا البريد الإلكتروني." والخطوة التالية "6.أ.1 يعرض النظام رسالة فشل وينتقل إلى الخطوة 2." ما هي الأمور السلبية التي تركت خلف الكواليس؟ بالنسبة للعميل، فإن أي عائد هو بمثابة حقيقة أن كل العمل الذي قام به في إدخال البيانات يتم إلقاؤه في مكب النفايات. (إنه غير مرئي في البرنامج النصي!) ما الذي يمكن فعله؟ أعد بناء البرنامج النصي حتى لا يحدث هذا. هل من الممكن أن تفعل هذا؟ يمكنك - على سبيل المثال، إلقاء نظرة على البرنامج النصي لتفويض Google.

تحسين السيناريو

ويتحدث الكتاب عن إضفاء الطابع الرسمي، لكنه لا يذكر إلا القليل عن أساليب تحسين مثل هذه السيناريوهات.

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

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

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

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

ثانيًا، نحتاج إلى إعطاء خيار فقط للسلع التي يمكننا تسليمها إلى العميل. متى تفعل هذا؟ في لحظة الاختيار - على بلاط المنتج وبطاقة المنتج.

يقطع هذان التغييران شوطًا طويلاً نحو إزالة هذا الاستثناء.

متطلبات القياسات والمقاييس

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

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

الوصول إلى سهولة الاستخدام

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

لتصميم قابلية الاستخدام، أضفنا قسم الإدخال - عرض البيانات.

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

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

في مثال ترخيص العميل، إذا قمت بفصل المعلومات المدخلة إلى تسجيل الدخول وكلمة المرور، فمن المفيد تغيير البرنامج النصي للتفويض لتسليط الضوء على مراحل إدخال تسجيل دخول منفصل وكلمة مرور منفصلة (وقد تم ذلك في Yandex، Google، ولكن لا يتم ذلك في معظم المتاجر عبر الإنترنت).

الوصول إلى تحويلات البيانات المطلوبة

يمكنك أيضًا استخراج متطلبات خوارزميات تحويل البيانات من البرنامج النصي.

الأمثلة على ذلك:

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

في المجموع

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

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

الكتاب يجب قراءته للمحللين لبدء كتابة مسرحيات قابلة للاختبار.

المصدر: www.habr.com