روش های مدرن برای توصیف الزامات عملکردی برای سیستم ها. آلیستر کابرن. بررسی کتاب و اضافات

این کتاب یک روش برای نوشتن بخشی از یک بیانیه مشکل، یعنی روش مورد استفاده را توضیح می‌دهد.

آن چیست؟ این شرحی از سناریوی تعامل کاربر با سیستم (یا با کسب و کار) است. در این مورد، سیستم به عنوان یک جعبه سیاه عمل می کند (و این امر باعث می شود که وظیفه طراحی پیچیده را به طراحی تعامل و اطمینان از این تعامل تقسیم کنیم). در همان زمان، استانداردهای نشانه گذاری معرفی می شوند که سهولت خواندن را از جمله برای افراد غیرشرکت کننده تضمین می کند و اجازه می دهد برخی از بررسی ها برای کامل بودن و انطباق با اهداف ذینفعان انجام شود.

از مثال مورد استفاده کنید

با استفاده از مثال مجوز در سایت از طریق ایمیل، سناریو چگونه به نظر می رسد:

(سیستم) برای دسترسی به حساب شخصی خود وارد وبسایت شوید. ~~ (سطح دریا)

متن نوشته: یک مشتری غیرمجاز به سایت وارد می شود تا سایت او را بشناسد و اطلاعات شخصی را برای او نشان دهد: سابقه مرور، سابقه خرید، تعداد فعلی امتیازات جایزه و غیره با استفاده از ایمیل به عنوان ورود. 
مرحله: هدف کاربر
شخصیت اصلی: مشتری (بازدید کننده فروشگاه آنلاین ما)
محدوده: تعامل مشتری با وب سایت فروشگاه اینترنتی
ذینفعان و منافع:

  • بازاریاب می خواهد حداکثر تعداد بازدیدکنندگان سایت برای پوشش بیشتر نامه های شخصی شناسایی شود،
  • متخصص امنیتی می‌خواهد اطمینان حاصل کند که هیچ موردی از دسترسی غیرمجاز به داده‌های شخصی بازدیدکننده وجود ندارد، از جمله تلاش برای حدس زدن رمز عبور برای یک حساب یا جستجو برای حسابی با رمز عبور ضعیف،
  • مهاجم می خواهد به پاداش های قربانی دسترسی پیدا کند،
  • رقبا می خواهند نظرات منفی را روی محصولات بگذارند،
  • بات نت می خواهد پایگاه مشتریان فروشگاه را به دست آورد و از یک حمله برای غیرفعال کردن سایت استفاده کند.

پیش شرط ها: بازدید کننده نباید مجاز باشد.
حداقل تضمین ها: بازدید کننده می داند که آیا تلاش برای مجوز موفقیت آمیز بوده است یا ناموفق.
ضمانت های موفقیت: بازدید کننده مجاز است

سناریوی اصلی:

  1. مشتری مجوز را آغاز می کند.
  2. این سیستم تأیید می‌کند که مشتری مجاز نیست و از تعداد تلاش‌های ناموفق برای مجوز از یک جلسه معین (جستجوی رمز عبور ضعیف برای چندین حساب) طبق «قانون امنیتی شماره 23» تجاوز نمی‌کند.
  3. سیستم شمارنده تعداد تلاش‌های مجوز را افزایش می‌دهد.
  4. سیستم یک فرم مجوز را به مشتری نمایش می دهد.
  5. مشتری ایمیل و رمز عبور خود را وارد می کند.
  6. این سیستم وجود مشتری با چنین ایمیلی را در سیستم تأیید می کند و مطابق "قانون امنیتی شماره 24" گذرواژه مطابقت دارد و تعداد تلاش برای ورود به این حساب بیشتر نشده است.
  7. سیستم به مشتری مجوز می دهد، تاریخچه مرور و سبد این جلسه را با آخرین جلسه این حساب مشتری اضافه می کند.
  8. سیستم یک پیام موفقیت آمیز مجوز را نمایش می دهد و به مرحله اسکریپت می رود که از آنجا مشتری برای مجوز قطع شده است. در این حالت، داده های صفحه با در نظر گرفتن داده های حساب شخصی دوباره بارگذاری می شوند.

برنامه های افزودنی:
2.a. مشتری قبلاً مجاز است:
 2.a.1. سیستم مشتری را در مورد مجوز قبلی که قبلاً انجام شده است مطلع می کند و پیشنهاد می دهد که اسکریپت را قطع کند یا به مرحله 4 برود و اگر مرحله 6 با موفقیت انجام شود ، مرحله 7 با شفاف سازی انجام می شود:
 2.a.7. سیستم مشتری را تحت حساب قدیمی غیرفعال می کند، مشتری را تحت حساب جدید مجوز می دهد، در حالی که سابقه مرور و سبد خرید این جلسه تعامل در حساب قدیمی باقی می ماند و به حساب جدید منتقل نمی شود. سپس به مرحله 8 بروید.
2.b تعداد تلاش‌های مجوز طبق «قانون امنیتی شماره 23» از آستانه فراتر رفته است:
 2.b.1 به مرحله 4 بروید، یک کپچا علاوه بر این در فرم مجوز نمایش داده می شود
 2.b.6 سیستم ورود صحیح کپچا را تأیید می کند
    2.b.6.1 کپچا اشتباه وارد شده است:
      2.b.6.1.1. سیستم شمارنده تلاش های ناموفق مجوز برای این حساب را نیز افزایش می دهد
      2.b.6.1.2. سیستم یک پیام خرابی نمایش می دهد و به مرحله 2 باز می گردد
6.a. هیچ حسابی با این ایمیل پیدا نشد:
 6.a.1 سیستم پیامی در مورد خرابی نمایش می‌دهد و گزینه رفتن به مرحله 2 یا رفتن به سناریوی «ثبت کاربر» و ذخیره ایمیل وارد شده را ارائه می‌دهد.
6.b. رمز عبور حساب دارای این ایمیل با رمز وارد شده مطابقت ندارد:
 6.b.1 سیستم شمارنده تلاش های ناموفق برای ورود به این حساب را افزایش می دهد.
 6.b.2 سیستم پیامی در مورد خرابی نمایش می‌دهد و گزینه رفتن به سناریوی «بازیابی رمز عبور» یا رفتن به مرحله 2 را ارائه می‌دهد.
6.c: شمارنده تلاش برای ورود به سیستم برای این حساب از آستانه "قانون امنیتی شماره 24" فراتر رفته است.
 6.c.1 سیستم پیامی در مورد مسدود شدن ورود به حساب برای X دقیقه نمایش می دهد و به مرحله 2 می رود.

چه عالی

بررسی کامل بودن و انطباق با اهداف، یعنی می توانید الزاماتی را برای تأیید به تحلیلگر دیگری بدهید و در مرحله فرمول بندی مشکل اشتباهات کمتری انجام دهید.

کار با سیستم نوع جعبه سیاه به شما امکان می دهد توسعه و هماهنگی با مشتری را از روش های پیاده سازی خودکار جدا کنید.

این بخشی از مسیر تحلیلگر، یکی از بخش های اصلی قابلیت استفاده است. سناریوی کاربر مسیرهای اصلی حرکت او را مشخص می کند که آزادی انتخاب را برای طراح و مشتری بسیار کاهش می دهد و به افزایش سرعت توسعه طراحی کمک می کند.

من از مکانی در توضیحات که در آن استثناهایی برای هر مرحله تعامل مشخص شده است بسیار خوشحالم. یک سیستم فناوری اطلاعات کامل باید نوعی رسیدگی به استثناء را فراهم کند، برخی به صورت دستی، برخی به صورت خودکار (مانند مثال بالا).

تجربه نشان می‌دهد که مدیریت استثنایی نادرست می‌تواند به راحتی یک سیستم را به یک سیستم بسیار ناخوشایند تبدیل کند. داستانی را به خاطر دارم که در زمان شوروی برای تصمیم گیری باید چندین تأییدیه از سرویس های مختلف می گرفتید و چقدر دردناک است که آخرین سرویس می گوید - اما درخواست شما به نام اشتباه است یا اشتباه دیگری در نقطه گذاری، همه چیز را دوباره انجام دهید و همه چیز را دوباره هماهنگ کنید.

من اغلب با موقعیت‌هایی برخورد می‌کنم که منطق عملیاتی سیستمی که برای استثنا در نظر گرفته نشده بود، نیازمند بازنگری قابل توجهی در سیستم است. به همین دلیل، سهم عمده کار تحلیلگر صرف رسیدگی به استثنا می شود.

نماد متن، بر خلاف نمودارها، اجازه می دهد تا استثناهای بیشتری شناسایی و پوشش داده شوند.

اضافه شدن به روش از عمل

مورد استفاده، برخلاف داستان کاربر، بخش اولویت‌بندی مستقل بیانیه نیست.

در سناریوی فوق استثناء «6.a.» را در نظر بگیرید. هیچ حسابی با این ایمیل پیدا نشد.» و مرحله بعدی "6.a.1 سیستم پیام خرابی را نمایش می دهد و به مرحله 2 می رود." چه چیزهای منفی در پشت پرده باقی ماند؟ برای مشتری، هر بازگشتی معادل این واقعیت است که تمام کارهایی که او برای وارد کردن داده‌ها انجام داده است در محل دفن زباله پرتاب می‌شود. (این فقط در فیلمنامه قابل مشاهده نیست!) چه کاری می توان انجام داد؟ اسکریپت را دوباره بسازید تا این اتفاق نیفتد. آیا انجام این کار ممکن است؟ شما می توانید - به عنوان مثال، به اسکریپت مجوز Google نگاه کنید.

بهینه سازی سناریو

کتاب در مورد رسمی سازی صحبت می کند، اما در مورد روش هایی برای بهینه سازی چنین سناریوهایی صحبت می کند.

اما می توان با بهینه سازی سناریوها روش را تقویت کرد و روش رسمی سازی استفاده از این امکان را می دهد. به طور خاص، شما باید در مورد هر استثنایی که رخ می دهد فکر کنید، علت را تعیین کنید و اسکریپت را بازسازی کنید تا از شر استثنا خلاص شوید یا سفر مشتری را به حداقل برسانید.

هنگام ثبت سفارش از فروشگاه اینترنتی، باید شهر تحویل را وارد کنید. ممکن است مشخص شود که فروشگاه به دلیل عدم تحویل در آنجا، به دلیل محدودیت سایز یا به دلیل نبود کالا در انبار مربوطه، نمی تواند کالا را به شهر انتخابی مشتری تحویل دهد.

اگر به سادگی سناریوی تعامل در مرحله ثبت نام را توصیف کنیم، می‌توانیم بنویسیم: «به مشتری اطلاع دهید که تحویل غیرممکن است و پیشنهاد تغییر شهر یا محتویات سبد خرید را بدهید» (و بسیاری از تحلیلگران تازه کار در اینجا متوقف می‌شوند). اما اگر چنین مواردی زیاد باشد، می توان سناریو را بهینه کرد.

اولین کاری که باید انجام دهید این است که به شما اجازه دهید فقط شهری را انتخاب کنید که ما می توانیم تحویل دهیم. چه زمانی این کار را انجام دهیم؟ قبل از انتخاب محصول در وب سایت (تشخیص خودکار شهر از طریق IP با شفاف سازی).

ثانیاً، ما باید فقط کالاهایی را انتخاب کنیم که می توانیم به مشتری تحویل دهیم. چه زمانی این کار را انجام دهیم؟ در لحظه انتخاب - روی کاشی محصول و کارت محصول.

این دو تغییر تا حد زیادی به حذف این استثنا کمک می کند.

الزامات برای اندازه گیری ها و متریک ها

هنگامی که وظیفه به حداقل رساندن رسیدگی به استثنا را در نظر می گیرید، می توانید یک کار گزارش دهی تنظیم کنید (مورد استفاده توضیح داده نشده است). چند استثنا وجود داشت، در چه مواردی اتفاق افتاد، به علاوه چند سناریوی ورودی با موفقیت پشت سر گذاشتند.

اما افسوس. تجربه نشان داده است که الزامات گزارش‌دهی برای سناریوها در این فرم کافی نیست، لازم است الزامات گزارش‌دهی برای فرآیندهایی که عمدتاً در قالب یک مورد استفاده توصیف نمی‌شوند در نظر گرفته شود.

دسترسی به قابلیت استفاده

در عمل ما، فرم توصیف مورد استفاده را با توصیف ویژگی‌های خاص موجودیت‌ها و داده‌ها برای تصمیم‌گیری مشتری گسترش داده‌ایم که قابلیت استفاده بعدی را افزایش می‌دهد.

برای طراحی قابلیت استفاده، یک بخش ورودی - نمایش داده ها را اضافه کردیم.

در یک سناریوی با مجوز، این واقعیتی است که مشتری در سیستم مجاز است. اگر مشتری از قبل مجاز است، پس از تأیید موفقیت آمیز، هشداری در مورد تغییر سابقه پیمایش و سبد خرید به حساب جدید نمایش دهید.

به طور کلی، این نمایش اطلاعات لازم برای مشتری است تا بتواند طبق سناریو در مورد اقدامات بعدی خود تصمیم گیری کند (شما می توانید بپرسید که آیا این داده ها برای مشتری کافی است، چه چیز دیگری لازم است، چه اطلاعاتی انجام می دهد. مشتری باید تصمیم بگیرد).  
همچنین در صورت پردازش جداگانه و با تشکیل استثناهای مختلف، ارزش آن را دارد که اطلاعات وارد شده به فیلدهای ورودی تقسیم شود.

در مثال با مجوز مشتری، اگر اطلاعات وارد شده را به ورود و رمز عبور جدا کنید، ارزش آن را دارد که اسکریپت مجوز را تغییر دهید تا مراحل وارد کردن یک ورود به سیستم و یک رمز عبور جداگانه را برجسته کنید (و این در Yandex، Google انجام می شود، اما در اکثر فروشگاه های آنلاین انجام نمی شود).

دستیابی به تبدیل داده های مورد نیاز

همچنین می توانید الزامات الگوریتم های تبدیل داده را از اسکریپت استخراج کنید.

مثال:

  • برای تصمیم گیری برای خرید یک محصول در فروشگاه اینترنتی، مشتری باید روی کارت محصول، امکان، هزینه، زمان تحویل این محصول به شهر خود را بداند (که توسط الگوریتم بر اساس در دسترس بودن محصول محاسبه می شود. انبارها و پارامترهای زنجیره تامین).
  • هنگام وارد کردن یک عبارت در خط جستجو، به مشتری پیشنهادات جستجو مطابق با الگوریتم (که توسط الگوریتم تولید می شود ...) نشان داده می شود.

در کل

به طور کلی، پس از مطالعه کتاب، متأسفانه، مشخص نیست که چگونه می توان از یک تحلیلگر تا مشکلات تجاری تا یک مشخصات فنی رسمی برای یک توسعه دهنده را طی کرد. این کتاب تنها بخشی از فرآیند را بیان می‌کند، با مراحل ورودی نامشخص و مراحل بعدی نامشخص. خود مورد استفاده اغلب یک بیانیه کامل برای توسعه دهنده نیست.

با این وجود، این روش بسیار خوبی برای رسمی کردن و پردازش سناریوهای تعامل بین یک شی و یک موضوع است، زمانی که این تعامل باعث تغییر در چیزی در موضوع می شود. این یکی از معدود روش‌های نوشتن است که به الزامات قابل تأیید با نقاط جستجوی استثنایی صریح اجازه می‌دهد.

خواندن این کتاب برای تحلیل گران برای شروع نوشتن نمایشنامه های قابل آزمایش ضروری است.

منبع: www.habr.com

اضافه کردن نظر