Savremene metode za opisivanje funkcionalnih zahtjeva za sisteme. Alistair Coburn. Recenzija knjige i dodaci

Knjiga opisuje jednu metodu za pisanje dijela iskaza problema, odnosno metodu slučaja upotrebe.

Šta je to? Ovo je opis scenarija interakcije korisnika sa sistemom (ili sa poslovanjem). U ovom slučaju, sistem djeluje kao crna kutija (i to omogućava da se složen zadatak dizajna podijeli na projektiranje interakcije i osiguranje ove interakcije). Istovremeno se uvode standardi za notaciju, što osigurava lakoću čitanja, uključujući i neučesnike, i omogućava određene provjere kompletnosti i usklađenosti sa ciljevima dionika.

Primjer slučaja upotrebe

Kako izgleda scenario, koristeći primjer autorizacije na web stranici putem e-pošte:

(Sistem) Prijavite se na web stranicu da biste pristupili svom ličnom računu. ~~ (nivo mora)

Kontekst: Neovlašteni klijent se prijavljuje na stranicu tako da ga stranica prepoznaje i prikazuje lične podatke za njega: historiju pregledavanja, historiju kupovine, trenutni broj bonus poena itd., koristeći e-poštu kao prijavu. 
Nivo: korisnički cilj
glavni lik: klijent (posjetilac naše online trgovine)
Opseg: Interakcija klijenta sa web stranicom online trgovine
Zainteresovane strane i interesi:

  • marketer želi da se identifikuje maksimalni broj posetilaca sajta radi veće pokrivenosti lične pošte,
  • stručnjak za sigurnost želi osigurati da nema slučajeva neovlaštenog pristupa ličnim podacima posjetitelja, uključujući pokušaje pogađanja lozinke za jedan račun ili traženja računa sa slabom lozinkom,
  • napadač želi pristupiti žrtvinim bonusima,
  • konkurenti žele ostaviti negativne kritike o proizvodima,
  • Botnet želi pridobiti bazu kupaca trgovine i iskoristiti napad kako bi web lokaciju učinio nefunkcionalnom.

Preduslovi: posjetitelj ne smije biti ovlašten.
Minimalne garancije: posjetitelj će znati da li je pokušaj autorizacije bio uspješan ili neuspješan.
Garancije uspeha: posjetitelj je ovlašten.

Glavni scenario:

  1. Klijent pokreće autorizaciju.
  2. Sistem potvrđuje da klijent nije autorizovan i da ne prelazi broj neuspešnih pokušaja autorizacije iz date sesije (traženje slabe lozinke za više naloga) u skladu sa „Sigurnosnim pravilom br. 23“.
  3. Sistem povećava brojač za broj pokušaja autorizacije.
  4. Sistem klijentu prikazuje obrazac autorizacije.
  5. Klijent unosi svoj email i lozinku.
  6. Sistem potvrđuje prisustvo klijenta sa takvom e-poštom u sistemu i da se lozinka poklapa i da broj pokušaja prijave na ovaj nalog nije prekoračen prema „Sigurnosnom pravilu br. 24“.
  7. Sistem ovlašćuje klijenta, dodaje istoriju pregledanja i korpu ove sesije sa poslednjom sesijom ovog klijentskog naloga.
  8. Sistem prikazuje poruku o uspjehu autorizacije i prelazi na korak skripte iz kojeg je klijent prekinut radi autorizacije. U tom slučaju, podaci na stranici se ponovo učitavaju uzimajući u obzir podatke ličnog računa.

Ekstenzije:
2.a. Klijent je već ovlašten:
 2.a.1. Sistem obavještava klijenta o činjenici da je prethodno izvršena autorizacija i nudi da prekine skriptu ili da pređe na korak 4, a ako je korak 6 uspješno završen, onda se korak 7 izvodi uz pojašnjenje:
 2.a.7. Sistem deaktorira klijenta pod starim nalogom, ovlašćuje klijenta pod novim nalogom, dok istorija pregledanja i korpa ove interakcijske sesije ostaju na starom nalogu i ne prenose se na novi. Zatim idite na korak 8.
2.b Broj pokušaja autorizacije je premašio prag prema “Sigurnosnom pravilu br. 23”:
 2.b.1 Idite na korak 4, captcha se dodatno prikazuje na obrascu za autorizaciju
 2.b.6 Sistem potvrđuje ispravan unos captcha
    2.b.6.1 Captcha unesena pogrešno:
      2.b.6.1.1. sistem povećava brojač neuspješnih pokušaja autorizacije i za ovaj račun
      2.b.6.1.2. sistem prikazuje poruku o grešci i vraća se na korak 2
6.a. Nije pronađen nijedan račun s ovom e-poštom:
 6.a.1 Sistem prikazuje poruku o neuspjehu i nudi izbor ili odlazak na korak 2 ili odlazak na scenario “Registracija korisnika” i spremanje unesene e-pošte,
6.b. Lozinka za račun sa ovom e-poštom ne odgovara unesenoj:
 6.b.1 Sistem povećava brojač neuspješnih pokušaja prijave na ovaj račun.
 6.b.2 Sistem prikazuje poruku o neuspjehu i nudi izbor između odlaska na scenario „Oporavak lozinke“ ili odlaska na korak 2.
6.c: Brojač pokušaja prijave za ovaj nalog je premašio prag za „Sigurnosno pravilo br. 24.“
 6.c.1 Sistem prikazuje poruku o blokiranju prijave na nalog na X minuta i prelazi na korak 2.

Šta je super

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

Rad sa sistemom crne kutije omogućava vam da odvojite razvoj i koordinaciju sa klijentom onoga što će biti automatizovano od metoda implementacije.

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

Veoma sam zadovoljan mjestom u opisu gdje su identificirani izuzeci u svakom koraku interakcije. Kompletan IT sistem mora da obezbedi neku vrstu obrade izuzetaka, neke ručno, neke automatski (kao u primeru iznad).

Iskustvo pokazuje da loše promišljeno rukovanje izuzetcima može lako pretvoriti sistem u užasno nezgodan sistem. Sjećam se priče kada ste u sovjetsko vrijeme, da biste dobili odluku, morali dobiti nekoliko odobrenja od različitih službi, i kako je bolno kada zadnji servis kaže - ali vaša prijava je u pogrešnom nazivu ili neka druga greška u interpunkcije, ponovi sve i ponovo uskladi sve.

Često se susrećem sa situacijama u kojima je operativna logika sistema koji nije osmišljen za izuzetke zahtijevala značajnu preradu sistema. Zbog toga se lavovski dio posla analitičara troši na rješavanje izuzetaka.

Obilježavanje teksta, za razliku od dijagrama, omogućava da se identifikuje i pokrije više izuzetaka.

Dodatak metodi iz prakse

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

U gore navedenom scenariju, razmotrite izuzetak „6.a. Nije pronađen nijedan račun s ovom e-poštom.” i sljedeći korak "6.a.1 Sistem prikazuje poruku o grešci i prelazi na korak 2." Koje negativne stvari su ostale iza scene? Za klijenta je svaki povratak jednak činjenici da se sav posao koji je obavio unoseći podatke baci na deponiju. (To se jednostavno ne vidi u scenariju!) Šta se može učiniti? Ponovo napravite skriptu tako da se to ne dogodi. Da li je to moguće uraditi? Možete - kao primjer, pogledati skriptu Google autorizacije.

Optimizacija scenarija

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

Ali moguće je ojačati metodu optimizacijom scenarija, a metoda formalizacije slučaja upotrebe omogućava da se to učini. Konkretno, morate razmisliti o svakom izuzetku koji se dogodi, utvrditi uzrok i ponovo izgraditi skriptu kako biste se riješili izuzetka ili minimizirali put 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 klijent izabrao jer tamo ne isporučuje, zbog ograničenja veličine ili zbog nedostatka robe u odgovarajućem skladištu.

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

Prvo što treba da uradite je da izaberete samo grad u koji možemo da isporučimo. Kada ovo uraditi? Prije odabira proizvoda na web stranici (autodetekcija grada putem IP-a sa pojašnjenjem).

Drugo, trebamo dati na izbor samo robu koju možemo isporučiti klijentu. Kada ovo uraditi? U trenutku odabira - na pločici proizvoda i kartici proizvoda.

Ove dvije promjene uvelike idu u pravcu eliminacije ovog izuzetka.

Zahtjevi za mjerenje i metriku

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

Ali avaj. Iskustvo je pokazalo da zahtjevi za izvještavanje za scenarije u ovoj formi nisu dovoljni, već je potrebno razmotriti zahtjeve izvještavanja za procese koji su opisani uglavnom ne u obliku slučaja upotrebe.

Pristup upotrebljivosti

U našoj praksi smo proširili obrazac za opis slučaja upotrebe sa opisom specifičnih atributa entiteta i podataka kako bi klijent mogao donijeti odluku, što poboljšava kasniju upotrebljivost.

Za dizajn upotrebljivosti, dodali smo ulaznu sekciju – prikaz podataka.

U scenariju s autorizacijom, to je činjenica da je klijent ovlašten u sistemu. Ako je klijent prethodno autoriziran, tada se prikazuje 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 on mogao donijeti odluku o svojim daljnjim radnjama prema scenariju (možete pitati da li su ti podaci dovoljni za klijenta, šta je još potrebno, koje informacije klijent treba da donosi odluke).  
Također je vrijedno podijeliti unesene podatke u polja za unos ako se obrađuju odvojeno i uz formiranje različitih izuzetaka.

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

Postizanje potrebnih transformacija podataka

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

primjeri:

  • Da bi donio odluku o kupovini proizvoda u online prodavnici, klijent mora na kartici proizvoda znati mogućnost, cijenu, vrijeme isporuke ovog proizvoda u svoj grad (koji se izračunavaju algoritmom na osnovu dostupnosti proizvoda u skladišta i parametri lanca snabdijevanja).
  • Prilikom unosa fraze u liniju za pretragu, klijentu se prikazuju prijedlozi za pretragu prema algoritmu (koji algoritam generiše...).

Ukupno

Općenito, nakon čitanja knjige, nažalost, nije jasno kako ići cijeli put od analitičara do 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 upotrebe najčešće nije potpuna izjava za programera.

Ipak, ovo je vrlo dobar način da se formaliziraju i obrađuju scenariji interakcije između objekta i subjekta, kada interakcija uzrokuje promjenu nečega u subjektu. To je jedna od rijetkih metoda pisanja koja dozvoljava provjerljive zahtjeve s eksplicitnim tačkama pretraživanja izuzetaka.

Knjiga je obavezna za čitanje za analitičare da počnu pisati drame koje se mogu testirati.

izvor: www.habr.com

Dodajte komentar