Съвременни методи за описание на функционалните изисквания към системите. Алистър Кобърн. Рецензия на книгата и допълнения

Книгата описва един метод за написване на част от изложение на проблем, а именно методът за използване на случай.

Какво е? Това е описание на сценария на взаимодействие на потребителя със системата (или с бизнеса). В този случай системата действа като черна кутия (и това прави възможно разделянето на сложната задача за проектиране на взаимодействие при проектиране и осигуряване на това взаимодействие). Същевременно се въвеждат стандарти за нотация, което гарантира лекота на четене, включително и за неучастници, и позволява някои проверки за пълнота и съответствие с целите на заинтересованата страна.

Пример за използване

Как изглежда сценарият, използвайки примера за оторизация на сайта чрез имейл:

(Система) Влезте в уебсайта, за да получите достъп до личния си акаунт. ~~ (морско ниво)

Контекст: Неоторизиран клиент влиза в сайта, така че сайтът да го разпознае и да покаже лична информация за него: хронология на сърфиране, хронология на покупките, текущ брой бонус точки и т.н., като използва имейл като вход. 
ниво: потребителска цел
Главен герой: клиент (посетител на нашия онлайн магазин)
Обхват: Взаимодействие на клиента с уебсайта на онлайн магазина
Заинтересовани страни и интереси:

• маркетологът иска максималния брой посетители на сайта да бъдат идентифицирани за по-голямо покритие на личните съобщения,
• специалистът по сигурността иска да гарантира, че няма случаи на неоторизиран достъп до личните данни на посетителя, включително опити за отгатване на паролата за един акаунт или търсене на акаунт със слаба парола,
• нападателят иска да получи достъп до бонусите на жертвата,
• конкурентите искат да оставят отрицателни отзиви за продуктите,
• Ботнетът иска да получи клиентската база на магазина и да използва атака, за да направи сайта неработещ.

Предпоставки: посетителят не трябва да бъде упълномощен.
Минимални гаранции: посетителят ще разбере дали опитът за авторизация е бил успешен или неуспешен.
Гаранции за успех: посетителят е упълномощен.

Основен сценарий:

1. Клиентът инициира оторизация.
2. Системата потвърждава, че клиентът не е авторизиран и не надвишава броя на неуспешните опити за авторизация от дадена сесия (търсене на слаба парола за множество акаунти) съгласно „Правило за сигурност № 23“.
3. Системата увеличава брояча на броя опити за авторизация.
4. Системата показва формуляр за оторизация на клиента.
5. Клиентът въвежда своя имейл и парола.
6. Системата потвърждава присъствието на клиент с такъв имейл в системата и че паролата съвпада и броят на опитите за влизане в този акаунт не е надвишен съгласно „Правило за сигурност № 24“.
7. Системата оторизира клиента, добавя историята на сърфиране и кошницата на тази сесия с последната сесия на този клиентски акаунт.
8. Системата показва съобщение за успешно оторизиране и преминава към стъпката на скрипта, от която клиентът е прекъснат за оторизация. В този случай данните на страницата се презареждат, като се вземат предвид данните от личния акаунт.

Разширения:
2.а. Клиентът вече е оторизиран:
 2.а.1. Системата уведомява клиента за факта на извършеното по-рано разрешение и предлага или да прекъсне скрипта, или да премине към стъпка 4, а ако стъпка 6 е завършена успешно, тогава стъпка 7 се изпълнява с пояснение:
 2.а.7. Системата деактивира клиента под стария акаунт, оторизира клиента под новия акаунт, докато хронологията на сърфирането и количката от тази сесия на взаимодействие остават в стария акаунт и не се прехвърлят към новия. След това отидете на стъпка 8.
2.b Броят на опитите за авторизация е надвишил прага съгласно „Правило за сигурност № 23“:
 2.b.1 Отидете на стъпка 4, captcha се показва допълнително във формуляра за оторизация
 2.b.6 Системата потвърждава правилното въвеждане на captcha
    2.b.6.1 Captcha е въведена неправилно:
      2.б.6.1.1. системата увеличава брояча на неуспешни опити за авторизация и за този акаунт
      2.б.6.1.2. системата показва съобщение за грешка и се връща към стъпка 2
6.а. Не е намерен акаунт с този имейл:
 6.a.1 Системата показва съобщение за грешка и предлага избор между преминаване към стъпка 2 или преминаване към сценария „Регистриране на потребител“ и запазване на въведения имейл,
6.б. Паролата за акаунта с този имейл не съвпада с въведената:
 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