Suvremene metode za opisivanje funkcionalnih zahtjeva za sustave. Alistair Coburn. Prikaz knjige i dopune

Knjiga opisuje jednu metodu za pisanje dijela izjave o problemu, naime metodu slučaja upotrebe.

Što je? Ovo je opis scenarija interakcije korisnika sa sustavom (ili s tvrtkom). U ovom slučaju, sustav djeluje kao crna kutija (što omogućuje podjelu složenog zadatka dizajna na projektiranje interakcije i osiguravanje te interakcije). Istodobno se uvode standardi notacije koji osiguravaju jednostavnost čitanja, uključujući i one koji nisu sudionici, te omogućuju neke provjere potpunosti i usklađenosti s ciljevima dionika.

Primjer upotrebe

Kako izgleda scenarij na primjeru autorizacije na stranici putem e-pošte:

(Sustav) Prijavite se na web stranicu za pristup svom osobnom računu. ~~ (razina mora)

Kontekst: Neovlašteni klijent se prijavljuje na stranicu kako bi ga stranica prepoznala i prikazala mu osobne podatke: povijest pregledavanja, povijest kupovine, trenutni broj bonus bodova itd., koristeći e-mail kao prijavu. 
razina: cilj korisnika
Glavni lik: klijent (posjetitelj naše online trgovine)
Opseg: Interakcija klijenta s web mjestom internetske trgovine
Dionici i interesi:

  • trgovac želi da se identificira maksimalan broj posjetitelja stranice radi veće pokrivenosti osobnim slanjem,
  • stručnjak za sigurnost želi osigurati da nema slučajeva neovlaštenog pristupa osobnim podacima posjetitelja, uključujući pokušaje pogađanja lozinke za jedan račun ili traženje računa sa slabom lozinkom,
  • napadač želi dobiti pristup žrtvinim bonusima,
  • konkurenti žele ostaviti negativne recenzije na proizvode,
  • Botnet želi dobiti bazu kupaca trgovine i upotrijebiti napad kako bi stranicu učinio neoperativnom.

Preduvjeti: posjetitelj ne smije biti ovlašten.
Minimalna jamstva: posjetitelj će znati je li pokušaj autorizacije bio uspješan ili neuspješan.
Jamstvo uspjeha: posjetitelj je ovlašten.

Glavni scenarij:

  1. Klijent pokreće autorizaciju.
  2. Sustav potvrđuje da klijent nije autoriziran i da ne premašuje broj neuspješnih pokušaja autorizacije iz dane sesije (traženje slabe lozinke za više računa) prema “Sigurnosnom pravilu br. 23”.
  3. Sustav povećava brojač za broj pokušaja autorizacije.
  4. Sustav klijentu prikazuje obrazac za autorizaciju.
  5. Klijent upisuje svoj email i lozinku.
  6. Sustav potvrđuje prisutnost klijenta s takvom e-poštom u sustavu i da lozinka odgovara i da broj pokušaja prijave na ovaj račun nije prekoračen prema “Sigurnosnom pravilu br. 24”.
  7. Sustav autorizira klijenta, dodaje povijest pregledavanja i košaricu ove sesije sa zadnjom sesijom ovog klijentskog računa.
  8. Sustav prikazuje poruku o uspješnoj autorizaciji i prelazi na korak skripte od kojeg je klijent prekinut radi autorizacije. U tom se slučaju podaci na stranici ponovno učitavaju uzimajući u obzir podatke o osobnom računu.

ekstenzije:
2.a. Klijent je već ovlašten:
 2.a.1. Sustav obavještava klijenta o činjenici prethodno provedene autorizacije i nudi ili prekid skripte ili prijelaz na korak 4, a ako je korak 6 uspješno dovršen, tada se korak 7 izvodi uz pojašnjenje:
 2.a.7. Sustav deaktorizira klijenta pod starim računom, autorizira klijenta pod novim računom, dok povijest pregledavanja i košarica ove sesije interakcije ostaju na starom računu i ne prenose se na novi. Zatim idite na korak 8.
2.b Broj pokušaja autorizacije premašio je prag prema “Sigurnosnom pravilu br. 23”:
 2.b.1 Idite na korak 4, captcha se dodatno prikazuje na obrascu za autorizaciju
 2.b.6 Sustav potvrđuje točan unos captcha
    2.b.6.1 Captcha unesena netočno:
      2.b.6.1.1. sustav povećava brojač neuspješnih pokušaja autorizacije i za ovaj račun
      2.b.6.1.2. sustav prikazuje poruku o pogrešci i vraća se na korak 2
6.a. Nije pronađen nijedan račun s ovom e-poštom:
 6.a.1 Sustav prikazuje poruku o neuspjehu i nudi izbor odlaska na korak 2 ili odlaska na scenarij "Registracija korisnika" i spremanja unesene e-pošte,
6.b. Lozinka za račun s ovom e-poštom ne odgovara unesenoj:
 6.b.1 Sustav povećava broj neuspješnih pokušaja prijave na ovaj račun.
 6.b.2 Sustav prikazuje poruku o neuspjehu i nudi izbor odlaska na scenarij "Oporavak lozinke" ili odlaska na korak 2.
6.c: Brojač pokušaja prijave za ovaj račun premašio je prag za “Sigurnosno pravilo br. 24.”
 6.c.1 Sustav prikazuje poruku o blokiranju prijave na račun na X minuta i nastavlja na korak 2.

Što je super

Provjerava cjelovitost i usklađenost s ciljevima, odnosno možete dati zahtjeve drugom analitičaru na provjeru, čineći manje pogrešaka u fazi formulacije problema.

Rad sa sustavom crne kutije omogućuje vam da odvojite razvoj i koordinaciju s kupcem onoga što će biti automatizirano od metoda implementacije.

To je dio puta analitičara, jedan od glavnih dijelova upotrebljivosti. Korisnikov scenarij definira glavne staze njegovog kretanja, što uvelike smanjuje slobodu izbora dizajnera i kupca te pomaže u povećanju brzine razvoja dizajna.

Vrlo sam zadovoljan mjestom u opisu gdje su identificirane iznimke za svaki korak interakcije. Kompletan IT sustav mora omogućiti neku vrstu rukovanja iznimkama, neke ručno, neke automatski (kao u gornjem primjeru).

Iskustvo pokazuje da nepromišljeno rukovanje iznimkama može lako pretvoriti sustav u užasno nezgodan sustav. Sjećam se priče kada ste u sovjetsko vrijeme, da biste dobili rješenje, morali dobiti nekoliko suglasnosti od različitih službi, i kako je bolno kada posljednja služba kaže - ali vaša prijava je na pogrešnom imenu ili neka druga greška u interpunkciju, ponovite sve i ponovno koordinirajte sve.

Često se susrećem sa situacijama u kojima je logika rada sustava koji nije bio promišljen za iznimke zahtijevala značajnu preradu sustava. Zbog toga lavovski dio rada analitičara odlazi na obradu izuzetaka.

Tekstualni zapis, za razliku od dijagrama, omogućuje da se identificira i pokrije više iznimaka.

Dodatak metodi iz prakse

Slučaj upotrebe nije neovisno prioritetni dio izjave, za razliku od korisničke priče.

U gornjem scenariju, razmotrite izuzetak “6.a. Nije pronađen nijedan račun s ovom e-poštom.” i sljedeći korak "6.a.1 Sustav prikazuje poruku o pogrešci i nastavlja na korak 2." Koje su negativne stvari ostale iza kulisa? Za klijenta je svaki povrat ravan činjenici da sav posao koji je napravio oko unosa podataka baci na odlagalište. (Samo se ne vidi u skripti!) Što se može učiniti? Ponovno izgradite skriptu kako se to ne bi dogodilo. Je li moguće to učiniti? Možete - kao primjer, pogledati Google autorizacijsku skriptu.

Optimizacija scenarija

Knjiga govori o formalizaciji, ali govori malo o metodama za optimizaciju takvih scenarija.

Ali moguće je ojačati metodu optimiziranjem scenarija, a metoda formalizacije slučaja uporabe to omogućuje. Konkretno, trebate razmisliti o svakoj iznimci koja se dogodi, utvrditi uzrok i ponovno izgraditi skriptu kako biste se riješili iznimke ili minimizirali putovanje korisnika.

Prilikom narudžbe iz online trgovine morate unijeti grad dostave. Može se ispostaviti da trgovina ne može isporučiti robu u grad koji je odabrao klijent jer tamo ne dostavlja, zbog ograničenja veličine ili zbog nedostatka robe u odgovarajućem skladištu.

Ako jednostavno opišemo scenarij interakcije u fazi registracije, možemo napisati "obavijestiti klijenta da je isporuka nemoguća i ponuditi promjenu grada ili sadržaja košarice" (i mnogi analitičari početnici tu staju). Ali ako ima puno takvih slučajeva, onda se scenarij može optimizirati.

Prvo što trebate učiniti je dopustiti vam da odaberete samo grad u koji možemo isporučiti. Kada to učiniti? Prije odabira proizvoda na web mjestu (automatsko otkrivanje grada putem IP-a s pojašnjenjem).

Drugo, trebamo dati izbor samo robe koju možemo isporučiti klijentu. Kada to učiniti? U trenutku odabira - na pločici proizvoda i kartici proizvoda.

Ove dvije promjene uvelike doprinose uklanjanju ove iznimke.

Zahtjevi za mjerenja i metriku

Kada razmatrate zadatak minimiziranja rukovanja iznimkama, možete postaviti zadatak izvješćivanja (slučaj upotrebe nije opisan). Koliko je bilo iznimaka, u kojim slučajevima su se dogodile, plus koliko je dolaznih scenarija uspješno prošlo.

Ali jao. Iskustvo je pokazalo da zahtjevi za izvješćivanje za scenarije u ovom obliku nisu dovoljni, potrebno je razmotriti zahtjeve za izvješćivanje za procese koji su opisani uglavnom ne u obliku slučaja uporabe.

Pristup upotrebljivosti

U našoj praksi proširili smo obrazac za opis slučaja upotrebe opisom specifičnih atributa entiteta i podataka za donošenje odluke klijenta, što povećava kasniju upotrebljivost.

Za dizajn upotrebljivosti, dodali smo odjeljak za unos - prikaz podataka.

U scenariju s autorizacijom, to je činjenica da je klijent autoriziran u sustavu. Ako je klijent prethodno autoriziran, prikažite upozorenje o prebacivanju povijesti navigacije i košarice na novi račun nakon uspješne autorizacije.

Općenito, ovo je prikaz potrebnih informacija za klijenta kako bi mogao donijeti odluku o svojim daljnjim radnjama prema scenariju (možete pitati jesu li ti podaci dovoljni za klijenta, što je još potrebno, koje informacije služe klijent mora donositi odluke).  
Također je vrijedno podijeliti unesene podatke u polja za unos ako se obrađuju odvojeno i uz formiranje različitih iznimaka.

U primjeru s autorizacijom klijenta, ako razdvojite unesene podatke na prijavu i lozinku, tada vrijedi promijeniti skriptu za autorizaciju kako biste istaknuli faze unosa zasebne prijave i zasebne lozinke (a to se radi u Yandexu, Googleu, ali ne radi se u većini online trgovina).

Postizanje potrebnih transformacija podataka

Također možete izdvojiti zahtjeve za algoritme za pretvorbu podataka iz skripte.

Primjeri:

  • Kako bi donio odluku o kupnji proizvoda u online trgovini, klijent mora na kartici proizvoda znati mogućnost, cijenu, vrijeme isporuke u svoj grad ovog proizvoda (koji se izračunavaju algoritmom na temelju dostupnosti proizvoda u skladišta i parametri opskrbnog lanca).
  • Prilikom unosa izraza u redak za pretraživanje klijentu se prikazuju prijedlozi za pretraživanje prema algoritmu (koje generira algoritam...).

Ukupno

Općenito, nakon čitanja knjige, nažalost, nije jasno kako prijeći cijeli put od analitičara preko poslovnih problema do formalizirane tehničke specifikacije za programera. Knjiga govori samo o dijelu procesa, s nejasnim ulaznim koracima i nejasnim sljedećim koracima. Sam slučaj korištenja najčešće nije potpuna izjava za programera.

Ipak, ovo je vrlo dobar način za formaliziranje i obradu scenarija interakcije između objekta i subjekta, kada interakcija uzrokuje promjenu nečega u subjektu. To je jedna od rijetkih metoda pisanja koja dopušta provjerljive zahtjeve s eksplicitnim točkama pretraživanja izuzetaka.

Knjiga je nezaobilazno štivo za analitičare kako bi počeli pisati provjerljive drame.

Izvor: www.habr.com

Dodajte komentar