У кнізе апісаны адзін метад напісання часткі пастаноўкі задачы, а менавіта метад use case.
Што гэта такое? Гэта апісанне сцэнара ўзаемадзеяння карыстальніка з сістэмай (ці з бізнесам). Сістэма пры гэтым выступае як чорная скрыня (і гэта дае магчымасць падзяліць складаную задачу праектавання на праектаванне ўзаемадзеяння і забеспячэнне гэтага ўзаемадзеяння). Пры гэтым уводзяцца стандарты натацыі, што забяспечвае прастату чытання ў тым ліку не ўдзельнікам, і дазваляе рабіць некаторыя праверкі на паўнату і адпаведнасць мэтам стэйкхолдэра.
Прыклад use case
Як выглядае сцэнар, на прыкладзе аўтарызацыі на сайце праз email:
(Сістэмны) Аўтарызавацца на сайце для доступу ў асабісты кабінет. ~~ (узровень мора)
Кантэкст: Не аўтарызаваны кліент аўтарызуецца на сайце, каб сайт яго даведаўся і паказваў персанальную для яго інфармацыю: гісторыю праглядаў, пакупак, бягучую колькасць бонусных балаў і інш, выкарыстоўваючы email як лагін.
узровень: мэта карыстальніка
Асноўная дзеючая асоба: кліент (наведвальнік нашай інтэрнэт-крамы)
Вобласць дзеяння: Узаемадзеянне кліента з сайтам інтэрнэт-крамы
Зацікаўленыя асобы і інтарэсы:
- маркетолаг хоча, каб максімальная колькасць наведвальнікаў сайта была ідэнтыфікавана для большага ахопу персанальных рассылак,
- спецыяліст бяспекі хоча, каб не было выпадкаў несанкцыянаванага доступу да персанальных дадзеных наведвальніка, уключаючы спробы падбору пароля для аднаго акаўнта або пошуку акаўнта са слабым паролем,
- зламыснік хоча атрымаць доступ да бонусаў ахвяры,
- канкурэнты хочуць пакінуць негатыўныя водгукі на тавары,
- ботнет хоча атрымаць базу кліентаў крамы і з дапамогай нападу дамагчыся непрацаздольнасці сайта.
Прадмовы: наведвальнік павінен быць не аўтарызаваны.
Мінімальныя гарантыі: наведвальнік даведаецца факт паспяховай ці няўдалай спробы аўтарызацыі.
Гарантыі поспеху: наведвальнік аўтарызаваны.
Асноўны сцэнар:
- Кліент запускае аўтарызацыю.
- Сістэма пацвярджае, што кліент не аўтарызаваны і не перавышэнне колькасці няўдалых спроб аўтарызацыі з дадзенай сесіі (пошук слабога пароля ў мноства акаўнтаў) па "Правіле бяспекі №23".
- Сістэма павялічвае лічыльнік колькасці спробаў аўтарызацыі.
- Сістэма адлюстроўвае кліенту форму аўтарызацыі.
- Кліент уводзіць email і пароль.
- Сістэма пацвярджае наяўнасць кліента з такім email у сістэме і супадзенне пароля і не перавышэнне колькасці спроб уваходу ў дадзены рахунак па «Правіле бяспекі №24».
- Сістэма аўтарызуе кліента, дадае гісторыю прагляду і кошык дадзенага сеанса з апошнім сеансам гэтага акаўнта кліента.
- Сістэма адлюстроўвае паведамленне паспяховасці аўтарызацыі і пераходзіць на крок сцэнара, з якога кліент спыніўся на аўтарызацыю. Пры гэтым дадзеныя на старонцы перагружаюцца з улікам персанальных дадзеных акаўнта.
Пашырэння:
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.а. Акаўнта з дадзеным email не выяўлена:
6.а.1 Сістэма паказвае паведамленне аб няўдалага і прапануе на выбар, альбо пераход да кроку 2, альбо пераход да сцэнара «Рэгістрацыя карыстальніка» з захаваннем уведзенага email,
6.б. Пароль ад акаўнта з дадзеным email не супадае з уведзеным:
6.б.1 Сістэма павялічвае лічыльнік няўдалых спроб уваходу ў дадзены акаўнт.
6.б.2 Сістэма адлюстроўвае паведамленне аб няўдалага і прапануе на выбар, або пераход да сцэнара «Аднаўленне пароля» або пераход да кроку 2.
6.у: Лічыльнік спроб уваходу ў дадзены рахунак перавысіла парог па «Правіле бяспекі №24».
6.в.1 Сістэма адлюстроўвае паведамленне аб блакаванні ўваходу ў рахунак на працягу X хвілін і пераходзіць да кроку 2.
Што выдатна
Праверкі на паўнату і адпаведнасць мэтам, гэта значыць можна аддаваць патрабаванні на праверку іншаму аналітыку, дапушчаючы менш памылак на стадыі пастаноўкі задачы.
Праца з сістэмай тыпу чорная скрыня дазваляе падзяліць выпрацоўку і ўзгадненне з замоўцам таго, а што ж будзе аўтаматызавана ад спосабаў рэалізацыі.
З'яўляецца часткай шляху аналітыка, адной з асноўных частак па юзабіліці. Сцэнар карыстальніка задае асноўныя шляхі яго руху, што моцна памяншае свабоду выбару для дызайнера і заказчыка і спрыяе павелічэння хуткасці выпрацоўкі дызайну.
Вельмі цешыць у апісанні месца, дзе выяўляюцца выключэнні кожнага кроку ўзаемадзеяння. Цэласная ІТ сістэма павінна прадугледжваць тую ці іншую апрацоўку выключэнняў, частка ў ручным рэжыме, частка ў аўтаматычным (як у прыкладзе вышэй).
Досвед паказвае, што не прадуманая апрацоўка выключэнняў можа лёгка ператварыць сістэму ў жудасна няёмкую сістэму. Успамінаецца гісторыя, калі ў саўковыя часы для атрымання рашэння патрабавалася атрымаць некалькі ўзгадненняў розных службаў і як жа балюча, калі апошняя служба кажа - а ў вас заява не на тое імя ці яшчэ якая памылка ў прыпыненні, перарабляйце ўсё і пераўзгодніце ўсё.
Часта сутыкаюся з сітуацыямі, калі не прадуманая для выключэнняў логіка працы сістэма патрабавала значнай пераробкі гэтай сістэмы. З-за гэтага львіная доля работ аналітыка траціцца на апрацоўку выключэнняў.
Натацыя ў выглядзе тэксту, у адрозненні ад дыяграм, дазваляе выявіць і ахапіць больш выключэнняў.
Дадатак да метаду з практыкі
Use case не з'яўляецца незалежна якая прыярытызуецца часткай пастаноўкі, у адрозненні ад user story.
У паказаным сцэнары, разгледзім выключэнне “6.а. Акаўнта з дадзеным email не знойдзена.” і наступны крок "6.а.1 Сістэма паказвае паведамленне аб няўдалага і пераходзіць да кроку 2". Што з негатыўнага засталося за кадрам? Для кліента любы зварот раўнасільна таму, што ўся праца які ён прарабіў уводзячы дадзеных выкідваецца на звалку. (У сцэнары гэтага проста так не відаць!) Што можна зрабіць? Перабудаваць сцэнар так, каб гэтага не ўзнікала. Ці можна так зрабіць? Можна - як прыклад, паглядзіце на сцэнар аўтарызацыі ў Google.
Аптымізацыя сцэнара
Кніга расказвае пра фармалізацыю, але мала расказвае пра метады аптымізацыі такіх сцэнарыяў.
Але магчыма ўзмацніць метад з дапамогай аптымізацыі сцэнараў і спосаб фармалізацыі use case дазваляе гэта зрабіць. Канкрэтна, над кожным выключэннем трэба падумаць, вызначыць прычыну і перабудаваць сцэнар так, каб пазбавіцца ад выключэння або мінімізаваць шлях кліента.
У афармленні замовы інтэрнэт-крамы трэба ўвесці горад дастаўкі. Можа так аказацца, што для абранага кліентам горада крама не можа даставіць тавар таму, што не робіць туды дастаўку, з-за габарытных абмежаванняў або з-за адсутнасці тавару на адпаведным складзе.
Калі проста апісваць сцэнар узаемадзеяння на стадыі афармлення, то можна запісаць "паведаміць кліенту аб немагчымасці дастаўкі і прапанаваць змяніць горад або склад кошыка" (і многія пачаткоўцы аналітыкі на гэтым спыняюцца). Але калі такіх выпадкаў дастаткова шмат, то можна аптымізаваць сцэнарый.
Першае што трэба зрабіць - трэба даваць абраць толькі той горад, куды мы можам зрабіць дастаўку. Калі гэта рабіць? Перад момантам выбару тавара на сайце (аўтавызначэнне горада праз ip з удакладненнем).
Другое - трэба даваць выбар толькі таго тавару, які мы можам даставіць кліенту. Калі гэта рабіць? У момант выбару - на плітцы тавараў і картцы тавару.
Гэтыя дзве змены значна практычна пазбаўляюць ад гэтага выключэння.
Патрабаванні на вымярэнні і метрыкі
Разглядаючы задачу мінімізацыі апрацоўкі выключэнняў можна паставіць задачу на справаздачнасць (не апісваецца use case). Як шмат было выключэнняў, у якіх выпадках яны ўзнікалі, плюс як шмат сцэнарыяў прайшло паспяхова ад уваходных.
Але нажаль. Досвед паказаў, што патрабаванняў на справаздачнасць да сцэнароў у такім выглядзе недастаткова, трэба разглядаць патрабаванні ў справаздачнасці на працэсы, якія апісваюцца ў асноўным не ў выглядзе use case.
Вынахад на Usability
У нашай практыцы мы пашырылі форму апісання use case апісаннем канкрэтных атрыбутаў сутнасцяў і дадзеных для прыняцця рашэння кліентам, што ўзмацняе наступнае юзабіліці.
Для праектавання юзабіліці мы дадалі ўваходны раздзел - якія адлюстроўваюцца дадзеныя.
У сцэнары з аўтарызацыяй - гэта факт аўтарызацыі кліента ў сістэме. Калі кліент папярэдне аўтарызаваны, то адлюстроўваць папярэджанне аб пераключэнні гісторыі навігацыі і кошыка на новы рахунак пасля паспяховасці аўтарызацыі.
У агульным выпадку гэта адлюстраванне патрэбнай інфармацыі для кліента, каб ён мог прымаць рашэнне аб сваіх далейшых дзеяннях па сцэнары (можна спытаць - а ці дастаткова кліенту гэтых дадзеных, што яшчэ трэба, якая інфармацыя патрэбна для прыняцця рашэнняў кліенту).
Гэтак жа варта падзяляць уводную інфармацыю на палі ўводу, калі іх апрацоўка адбываецца паасобна і з фармаваннем розных выключэнняў.
У прыкладзе з аўтарызацыяй кліента, калі вылучыць уводную інфармацыю на лагін і пароль, тое варта змяніць сцэнара аўтарызацыі з вылучэннем этапаў уводу асобна лагіна і асобна пароля (і гэта зроблена ў Yandex, Google, але не зроблена ў большасці інтэрнэт-крам).
Выхад на патрабаваныя пераўтварэнні дадзеных
З сцэнара гэтак жа можна выцягнуць патрабаванні да алгарытмаў пераўтварэння дадзеных.
Прыклады:
- Кліенту для прыняцця рашэння аб куплі тавару ў інтэрнэт-краме на картцы тавару трэба ведаць магчымасць, кошт, тэрміны дастаўкі ў яго горад дадзенага тавара (якія вылічаюцца алгарытмам па факце наяўнасці тавара на складах і параметраў ланцужкоў паставак).
- Пры ўводзе фразы ў пошукавы радок кліенту па алгарытме паказваюцца пошукавыя падказкі (якія фармуюцца алгарытмам …).
Разам
У цэлым, пасля прачытання кнігі, на жаль, не зразумела як прайсці ўвесь шлях аналітыка ад бізнес-праблем да фармалізаванага ТЗ для распрацоўшчыка. У кнізе распавядаецца толькі частка працэсу з незразумела сфармуляванымі ўваходнымі і незразумела паказанымі далейшымі крокамі. Сам па сабе use case поўнай пастаноўкай для распрацоўніка часцей за ўсё не з'яўляецца.
Тым не менш, гэта вельмі добры спосаб фармалізацыі і апрацоўкі сцэнараў узаемадзеяння аб'екта і суб'екта, калі пры ўзаемадзеянні ўзнікае змену чаго-небудзь у суб'екце. З'яўляецца адным з нямногіх спосабаў запісу, якія дапускаюць правяраныя патрабаванні з відавочнымі кропкамі пошуку выключэнняў.
Кніга абавязковая для прачытання аналітыкамі, каб яны пачалі пісаць правяраныя пастаноўкі.
Крыніца: habr.com