Bókin lýsir einni aðferð til að skrifa hluta af vandamálayfirlýsingu, nefnilega use case method.
Hvað það er? Þetta er lýsing á atburðarás notendasamskipta við kerfið (eða við fyrirtækið). Í þessu tilviki virkar kerfið sem svartur kassi (og þetta gerir það mögulegt að skipta flóknu hönnunarverkefninu í að hanna samspil og tryggja þetta samspil). Jafnframt eru innleiddir staðlar fyrir nótnaskrift sem tryggja auðvelda lestur, einnig fyrir þá sem ekki eru þátttakendur, og gera ráð fyrir nokkrum athugunum á heilleika og samræmi við markmið hagsmunaaðila.
Notaðu dæmi
Hvernig atburðarásin lítur út, með því að nota dæmi um heimild á síðunni með tölvupósti:
(Kerfi) Skráðu þig inn á vefsíðuna til að fá aðgang að persónulega reikningnum þínum. ~~ (sjávarborð)
Samhengi: Óviðkomandi viðskiptavinur skráir sig inn á síðuna þannig að síðan þekki hann og sýni persónulegar upplýsingar fyrir hann: vafraferil, kaupferil, núverandi fjölda bónuspunkta o.s.frv., með tölvupósti sem innskráningu.
Stig: markmið notenda
Aðalpersóna: viðskiptavinur (gestur netverslunar okkar)
Umfang: Samskipti viðskiptavina við vefsíðu netverslunarinnar
Hagsmunaaðilar og hagsmunir:
- markaðsaðilinn vill að hámarksfjöldi gesta sé auðkenndur til að fá meiri umfjöllun um persónulega pósta,
- öryggissérfræðingurinn vill tryggja að engin tilvik séu um óviðkomandi aðgang að persónuupplýsingum gestsins, þar með talið tilraunir til að giska á lykilorð fyrir einn reikning eða leita að reikningi með veikt lykilorð,
- árásarmaðurinn vill fá aðgang að bónusum fórnarlambsins,
- samkeppnisaðilar vilja skilja eftir neikvæðar umsagnir um vörur,
- Botnetið vill ná í viðskiptavinahóp verslunarinnar og nota árás til að gera síðuna óstarfhæfa.
Forsendur: gesturinn má ekki fá leyfi.
Lágmarkstryggingar: gesturinn mun vita hvort heimildartilraunin heppnaðist eða misheppnaðist.
Ábyrgð á árangri: gesturinn hefur heimild.
Aðal atburðarás:
- Viðskiptavinur hefur frumkvæði að heimild.
- Kerfið staðfestir að viðskiptavinurinn hefur ekki heimild og fer ekki yfir fjölda misheppnaðra heimildatilrauna frá tiltekinni lotu (leit að veiktu lykilorði fyrir marga reikninga) samkvæmt "Öryggisreglu nr. 23".
- Kerfið eykur teljara fyrir fjölda heimildatilrauna.
- Kerfið sýnir viðskiptavinum heimildareyðublað.
- Viðskiptavinurinn slær inn netfangið sitt og lykilorð.
- Kerfið staðfestir tilvist viðskiptavinar með slíkan tölvupóst í kerfinu og að lykilorðið passi og ekki sé farið yfir fjölda innskráningartilrauna á þennan reikning samkvæmt „Öryggisreglu nr. 24“.
- Kerfið heimilar viðskiptavininn, bætir vafrasögunni og körfu þessarar lotu við síðustu lotu þessa viðskiptavinarreiknings.
- Kerfið birtir skilaboð um árangur af heimild og færist yfir í skriftuþrepið sem biðlarinn var trufluður frá vegna heimildar. Í þessu tilviki eru gögnin á síðunni endurhlaðin með hliðsjón af persónulegum reikningsgögnum.
Viðbætur:
2.a. Viðskiptavinurinn hefur þegar heimild:
2.a.1. Kerfið lætur viðskiptavininn vita um áður framkvæmda heimild og býður annaðhvort að trufla handritið eða fara í skref 4, og ef skrefi 6 er lokið, þá er skref 7 framkvæmt með skýringu:
2.a.7. Kerfið afvirkjar viðskiptavininn undir gamla reikningnum, heimilar viðskiptavininn undir nýja reikningnum, á meðan vafraferill og körfu þessarar samskiptalotu eru áfram á gamla reikningnum og flytjast ekki yfir á þann nýja. Næst skaltu fara í skref 8.
2.b Fjöldi heimildatilrauna hefur farið yfir viðmiðunarmörk samkvæmt „Öryggisreglu nr. 23“:
2.b.1 Farðu í skref 4, captcha birtist til viðbótar á heimildareyðublaðinu
2.b.6 Kerfið staðfestir rétta captcha-færslu
2.b.6.1 Captcha rangt slegið inn:
2.b.6.1.1. kerfið eykur teljara misheppnaðar heimildatilrauna fyrir þennan reikning líka
2.b.6.1.2. kerfið birtir bilunarskilaboð og fer aftur í skref 2
6.a. Enginn reikningur með þessum tölvupósti fannst:
6.a.1 Kerfið birtir skilaboð um bilun og býður upp á val um annað hvort að fara í skref 2 eða fara í „User Registration“ atburðarás og vista innsláttan tölvupóst,
6.b. Lykilorðið fyrir reikninginn með þessum tölvupósti passar ekki við það sem slegið var inn:
6.b.1 Kerfið eykur teljara misheppnaðar innskráningartilrauna á þennan reikning.
6.b.2 Kerfið birtir skilaboð um bilun og býður upp á val um annað hvort að fara í „Endurheimt lykilorðs“ eða fara í skref 2.
6.c: Innskráningartilraunateljarinn fyrir þennan reikning hefur farið yfir þröskuldinn fyrir „Öryggisreglu nr. 24“.
6.c.1 Kerfið birtir skilaboð um lokun á innskráningu reiknings í X mínútur og heldur áfram í skref 2.
Hvað er frábært
Athuganir á heilleika og samræmi við markmið, það er, þú getur sett kröfur til annars sérfræðings til sannprófunar, gerir færri mistök á stigi vandamálamótunar.
Að vinna með svart kassakerfi gerir þér kleift að aðskilja þróun og samhæfingu við viðskiptavininn á því sem verður sjálfvirkt frá innleiðingaraðferðum.
Það er hluti af leið sérfræðingsins, einn af meginþáttum nothæfis. Atburðarás notandans skilgreinir helstu leiðir hreyfingar hans, sem dregur mjög úr valfrelsi hönnuðarins og viðskiptavinarins og hjálpar til við að auka hraða hönnunarþróunar.
Ég er mjög ánægður með staðinn í lýsingunni þar sem undantekningar frá hverju samskiptaþrepi eru auðkenndar. Fullkomið upplýsingatæknikerfi verður að gera ráð fyrir einhvers konar undanþágumeðferð, sumum handvirkt, annað sjálfkrafa (eins og í dæminu hér að ofan).
Reynslan sýnir að vanhugsuð undantekningameðferð getur auðveldlega breytt kerfi í hræðilega óþægilegt kerfi. Ég man eftir sögunni þegar á Sovéttímanum, til þess að fá ákvörðun, þurftir þú að fá nokkur samþykki frá mismunandi þjónustum og hversu sársaukafullt það er þegar síðasta þjónustan segir - en umsókn þín er á röngu nafni eða einhver önnur mistök í greinarmerki, endurtaka allt og samræma allt aftur.
Ég rekst oft á aðstæður þar sem rekstrarrökfræði kerfis sem ekki var úthugsað fyrir undantekningar krafðist verulegrar endurvinnslu á kerfinu. Vegna þessa fer bróðurpartinn af vinnu greiningaraðilans í meðhöndlun undantekninga.
Textaskrift, öfugt við skýringarmyndir, gerir kleift að bera kennsl á og ná yfir fleiri undantekningar.
Viðbót við aðferðina frá æfingu
Notkunartilvikið er ekki sjálfstætt forgangsraðaður hluti yfirlýsingarinnar, ólíkt notendasögunni.
Í ofangreindri atburðarás skaltu íhuga undantekningu „6.a. Enginn reikningur með þessum tölvupósti fannst." og næsta skref "6.a.1 Kerfið birtir bilunarskilaboð og heldur áfram í skref 2." Hvaða neikvæðu hlutir voru skildir eftir á bak við tjöldin? Fyrir viðskiptavininn jafngildir hver ávöxtun því að allri vinnu sem hann vann við að slá inn gögn er hent á urðunarstaðinn. (Það sést bara ekki í handritinu!) Hvað er hægt að gera? Endurbyggðu handritið þannig að þetta gerist ekki. Er hægt að gera þetta? Þú getur - sem dæmi, skoðað Google heimildarforskriftina.
Hagræðing atburðarásar
Í bókinni er talað um formfestingu en lítið um aðferðir til að hagræða slíkum atburðarásum.
En það er hægt að styrkja aðferðina með því að hagræða sviðsmyndir og notkunartilviksformunaraðferðin gerir það kleift. Sérstaklega þarftu að hugsa um hverja undantekningu sem á sér stað, ákvarða orsökina og endurbyggja handritið til að losna við undantekninguna eða lágmarka ferðalag viðskiptavina.
Þegar pantað er í netverslun þarf að slá inn afhendingarborgina. Það getur komið í ljós að verslunin getur ekki afhent vörur til þeirrar borgar sem viðskiptavinur velur vegna þess að hún afhendir ekki þangað, vegna stærðartakmarkana eða vegna skorts á vöru í samsvarandi vöruhúsi.
Ef við lýsum einfaldlega atburðarás samskipta á skráningarstigi, getum við skrifað "upplýsa viðskiptavininn um að afhending sé ómöguleg og boðið að breyta borginni eða innihaldi körfunnar" (og margir nýliðir sérfræðingar hætta þar). En ef það eru mörg slík tilvik, þá er hægt að fínstilla atburðarásina.
Það fyrsta sem þú þarft að gera er að leyfa þér að velja aðeins borgina þar sem við getum afhent. Hvenær á að gera þetta? Áður en þú velur vöru á vefsíðunni (sjálfvirk uppgötvun borgarinnar í gegnum IP með skýringu).
Í öðru lagi þurfum við að velja aðeins þær vörur sem við getum afhent viðskiptavininum. Hvenær á að gera þetta? Á því augnabliki sem valið er - á vöruflísum og vöruspjaldi.
Þessar tvær breytingar fara langt í að útrýma þessari undantekningu.
Kröfur um mælingar og mælikvarða
Þegar þú skoðar það verkefni að lágmarka meðhöndlun undantekninga geturðu stillt tilkynningarverkefni (notatilviki er ekki lýst). Hversu margar undantekningar voru, í hvaða tilfellum þær áttu sér stað, auk þess hversu margar komandi aðstæður stóðust.
En því miður. Reynslan hefur sýnt að tilkynningarkröfur um sviðsmyndir á þessu formi duga ekki heldur þarf að huga að skýrslukröfum vegna ferla sem lýst er aðallega ekki í formi notkunartilviks.
Aðgangur að notagildi
Í starfi okkar höfum við stækkað eyðublaðið fyrir notkunartilvik með lýsingu á sérstökum eiginleikum eininga og gögnum fyrir viðskiptavininn til að taka ákvörðun, sem eykur síðari notagildi.
Fyrir nothæfishönnun bættum við við innsláttarhluta - sýna gögn.
Í atburðarás með heimild er þetta sú staðreynd að viðskiptavinurinn hefur heimild í kerfinu. Ef viðskiptavinurinn hefur forheimild, birtu þá viðvörun um að skipta um leiðsöguferil og körfu yfir á nýja reikninginn eftir að heimild hefur verið veitt.
Almennt séð er þetta sýning á nauðsynlegum upplýsingum fyrir viðskiptavininn svo að hann geti tekið ákvörðun um frekari aðgerðir í samræmi við atburðarásina (þú getur spurt hvort þessi gögn dugi fyrir viðskiptavininn, hvað þarf annað, hvaða upplýsingar gera viðskiptavinurinn þarf að taka ákvarðanir).
Einnig er þess virði að skipta innslögðum upplýsingum í innsláttarreiti ef þær eru unnar sérstaklega og með mismunandi undantekningum.
Í dæminu með heimild viðskiptavinar, ef þú aðskilur innsláttar upplýsingar í notandanafn og lykilorð, þá er það þess virði að breyta heimildarforskriftinni til að auðkenna stigin við að slá inn sérstakt notandanafn og sérstakt lykilorð (og þetta er gert í Yandex, Google, en ekki gert í flestum netverslunum).
Að ná nauðsynlegum gagnabreytingum
Þú getur líka dregið út kröfur um reiknirit fyrir umbreytingu gagna úr handritinu.
Dæmi:
- Til að taka ákvörðun um að kaupa vöru í netverslun þarf viðskiptavinurinn að vita á vörukortinu möguleika, kostnað, afhendingartíma til borgar sinnar á þessari vöru (sem eru reiknaðir með reikniritinu byggt á framboði vörunnar í vöruhús og færibreytur aðfangakeðju).
- Þegar setning er slegin inn í leitarlínuna eru viðskiptavinum sýndar leitartillögur samkvæmt reikniritinu (sem eru búnar til af reikniritinu...).
Alls
Almennt, eftir að hafa lesið bókina, því miður, er ekki ljóst hvernig á að fara alla leið frá sérfræðingur til viðskiptavandamála til formlegrar tækniforskriftar fyrir þróunaraðila. Bókin segir aðeins frá hluta ferlisins, inntaksþrepin eru óljós og næstu skref óljós. Notkunartilvikið sjálft er oftast ekki tæmandi yfirlýsing fyrir framkvæmdaraðilann.
Engu að síður er þetta mjög góð leið til að formfesta og vinna úr atburðarás um samspil hlutar og viðfangs, þegar samspilið veldur breytingu á einhverju í viðfangsefninu. Það er ein af fáum ritunaraðferðum sem gerir kleift að sannreyna kröfur með skýrum undantekningaleitarstöðum.
Bókin er skyldulesning fyrir greinendur til að byrja að skrifa prófanleg leikrit.
Heimild: www.habr.com