Савремене методе за описивање функционалних захтева за системе. Алистаир Цобурн. Приказ књиге и допуне

Књига описује један метод за писање дела исказа проблема, односно метод случаја употребе.

Шта је то? Ово је опис сценарија интеракције корисника са системом (или са пословањем). У овом случају, систем делује као црна кутија (и то омогућава да се сложен задатак дизајна подели на пројектовање интеракције и обезбеђивање ове интеракције). Истовремено се уводе стандарди за нотацију, што обезбеђује лакоћу читања, укључујући и неучеснике, и омогућава одређене провере комплетности и усклађености са циљевима заинтересоване стране.

Пример употребе

Како изгледа сценарио, користећи пример ауторизације на сајту путем е-поште:

(Систем) Пријавите се на веб локацију да бисте приступили свом личном налогу. ~~ (ниво мора)

Контекст: Неовлашћени клијент се пријављује на сајт тако да га сајт препознаје и приказује личне податке за њега: историју прегледања, историју куповине, тренутни број бонус поена итд., користећи е-пошту као пријаву. 
Ниво: циљ корисника
Главни лик: клијент (посетилац наше онлајн продавнице)
Обим: Интеракција клијента са веб-сајтом онлине продавнице
Заинтересоване стране и интереси:

• продавац жели да се идентификује максималан број посетилаца сајта ради веће покривености личних порука,
• стручњак за безбедност жели да осигура да нема случајева неовлашћеног приступа личним подацима посетиоца, укључујући покушаје да се погоди лозинка за један налог или тражење налога са слабом лозинком,
• нападач жели да добије приступ жртвиним бонусима,
• конкуренти желе да оставе негативне критике о производима,
• Ботнет жели да добије базу купаца продавнице и искористи напад да учини сајт нефункционалним.

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

Главни сценарио:

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.ц.1 Систем приказује поруку о блокирању пријаве на налог током Кс минута и прелази на корак 2.

Шта је супер

Проверава комплетност и усклађеност са циљевима, односно можете дати захтеве другом аналитичару за верификацију, правећи мање грешака у фази формулације проблема.

Рад са системом црне кутије омогућава вам да одвојите развој и координацију са клијентом онога што ће бити аутоматизовано од метода имплементације.

То је део пута аналитичара, један од главних делова употребљивости. Сценарио корисника дефинише главне путеве његовог кретања, што у великој мери смањује слободу избора за дизајнера и купца и помаже да се повећа брзина развоја дизајна.

Веома сам задовољан местом у опису где су идентификовани изузеци у сваком кораку интеракције. Комплетан ИТ систем мора да обезбеди неку врсту обраде изузетака, неке ручно, неке аутоматски (као у примеру изнад).

Искуство показује да лоше промишљено руковање изузетцима може лако претворити систем у ужасно незгодан систем. Сећам се приче када сте у совјетско време, да бисте добили одлуку, морали да добијете неколико одобрења од различитих служби, и како је болно када последња служба каже – али ваша пријава је у погрешном називу или нека друга грешка у интерпункције, понови све и поново усклади све.

Често се сусрећем са ситуацијама када је логика рада система који није осмишљен за изузетке захтевала значајну прераду система. Због тога се лавовски део посла аналитичара троши на руковање изузетцима.

Означавање текста, за разлику од дијаграма, омогућава да се идентификује и покрије више изузетака.

Додатак методи из праксе

Случај употребе није независни приоритетни део изјаве, за разлику од корисничке приче.

У горњем сценарију, размотрите изузетак „6.а. Није пронађен ниједан налог са овом е-поштом.” и следећи корак „6.а.1 Систем приказује поруку о грешци и прелази на корак 2.“ Које негативне ствари су остале иза сцене? За клијента је сваки повратак раван томе да сав посао који је урадио уносећи податке баци на депонију. (То се једноставно не види у сценарију!) Шта се може учинити? Поново направите скрипту да се то не догоди. Да ли је то могуће урадити? Можете - као пример, погледати скрипту Гоогле ауторизације.

Оптимизација сценарија

Књига говори о формализацији, али мало говори о методама за оптимизацију таквих сценарија.

Али могуће је ојачати метод оптимизацијом сценарија, а метода формализације случаја употребе омогућава да се то уради. Конкретно, потребно је да размислите о сваком изузетку који се догоди, да одредите узрок и поново направите скрипту како бисте се решили изузетка или минимизирали пут корисника.

Приликом наручивања из онлине продавнице, морате унети град испоруке. Може се испоставити да продавница не може да испоручи робу у град који је изабрао клијент јер тамо не испоручује, због ограничења величине или због недостатка робе у одговарајућем магацину.

Ако једноставно опишемо сценарио интеракције у фази регистрације, можемо написати „обавестити клијента да је испорука немогућа и понудити да промени град или садржај колица“ (и многи аналитичари почетници се ту заустављају). Али ако таквих случајева има пуно, онда се сценарио може оптимизовати.

Прво што треба да урадите је да изаберете само град у који можемо да испоручимо. Када ово урадити? Пре избора производа на веб страници (аутодетекција града преко ИП-а са појашњењем).

Друго, треба да дамо на избор само робу коју можемо да испоручимо клијенту. Када ово урадити? У тренутку одабира - на плочици производа и картици производа.

Ове две промене увелико иду у правцу елиминисања овог изузетка.

Захтеви за мерење и метрику

Када разматрате задатак минимизирања руковања изузетцима, можете поставити задатак извештавања (случај употребе није описан). Колико је изузетака било, у којим случајевима су се десили, плус колико је долазних сценарија успешно прошло.

Али авај. Искуство је показало да захтеви за извештавање за сценарије у овој форми нису довољни, већ је потребно размотрити захтеве извештавања за процесе који су описани углавном не у форми случаја употребе.

Приступ употребљивости

У нашој пракси смо проширили образац за опис случаја коришћења описом специфичних атрибута ентитета и података како би клијент могао да донесе одлуку, што побољшава каснију употребљивост.

За дизајн употребљивости, додали смо одељак за унос – приказ података.

У сценарију са ауторизацијом, то је чињеница да је клијент ауторизован у систему. Ако је клијент унапред овлашћен, онда прикажите упозорење о пребацивању историје навигације и корпе на нови налог након успешне ауторизације.

Генерално, ово је приказ неопходних информација за клијента како би он могао да донесе одлуку о својим даљим акцијама према сценарију (можете питати да ли су ови подаци довољни за клијента, шта је још потребно, које информације треба клијент треба да доноси одлуке).  
Такође је вредно поделити унете информације у поља за унос ако се обрађују одвојено и са формирањем различитих изузетака.

У примеру са ауторизацијом клијента, ако унете информације одвојите на податке за пријаву и лозинку, онда је вредно променити скрипту за ауторизацију да бисте истакли фазе уношења одвојене пријаве и посебне лозинке (а то се ради у Иандек-у, Гоогле-у, али не ради у већини онлајн продавница).

Постизање потребних трансформација података

Такође можете извући захтеве за алгоритме конверзије података из скрипте.

Примери:

• Да би донео одлуку о куповини производа у онлајн продавници, клијент треба да зна на картици производа могућност, цену, време испоруке овог производа у свој град (који се израчунавају алгоритмом на основу доступности производа у складишта и параметри ланца снабдевања).
• Приликом уношења фразе у линију за претрагу, клијенту се приказују предлози за претрагу према алгоритму (које генерише алгоритам...).

Укупно

Уопштено говорећи, након читања књиге, нажалост, није јасно како ићи све од аналитичара до пословних проблема до формализоване техничке спецификације за програмера. Књига говори само о делу процеса, са нејасним корацима уноса и нејасним следећим корацима. Сам случај употребе најчешће није потпуна изјава за програмера.

Ипак, ово је веома добар начин да се формализују и обрађују сценарији интеракције између објекта и субјекта, када интеракција изазива промену у нечему у субјекту. То је један од ретких метода писања који дозвољава проверљиве захтеве са експлицитним тачкама претраге изузетака.

Књига је обавезна за читање аналитичара да би почели да пишу драме које се могу тестирати.

Извор: ввв.хабр.цом