Libri përshkruan një metodë për të shkruar një pjesë të një deklarate problemi, domethënë metodën e rastit të përdorimit.
Cfare eshte? Ky është një përshkrim i skenarit të ndërveprimit të përdoruesit me sistemin (ose me biznesin). Në këtë rast, sistemi vepron si një kuti e zezë (dhe kjo bën të mundur ndarjen e detyrës komplekse të projektimit në projektimin e ndërveprimit dhe sigurimin e këtij ndërveprimi). Në të njëjtën kohë, futen standardet e shënimeve, të cilat garantojnë lehtësinë e leximit, përfshirë edhe për jo-pjesëmarrësit, dhe lejon disa kontrolle për plotësinë dhe përputhshmërinë me qëllimet e palës së interesuar.
Përdorni shembullin e rastit
Si duket skenari, duke përdorur shembullin e autorizimit në sit me email:
(Sistemi) Hyni në faqen e internetit për të hyrë në llogarinë tuaj personale. ~~ (niveli i detit)
Kontekst: Një klient i paautorizuar hyn në sajt në mënyrë që faqja ta njohë atë dhe të shfaqë informacione personale për të: historikun e shfletimit, historinë e blerjeve, numrin aktual të pikëve të bonusit, etj., duke përdorur emailin si hyrje.
niveli: qëllimi i përdoruesit
Personazhi kryesor: klient (vizitor i dyqanit tonë online)
Fushëveprimi: Ndërveprimi i klientit me faqen e internetit të dyqanit online
Palët e interesit dhe interesat:
- tregtari dëshiron që të identifikohet numri maksimal i vizitorëve të faqes për mbulim më të madh të postimeve personale,
- specialisti i sigurisë dëshiron të sigurojë që nuk ka raste të aksesit të paautorizuar në të dhënat personale të vizitorit, duke përfshirë përpjekjet për të gjetur fjalëkalimin për një llogari ose për të kërkuar një llogari me një fjalëkalim të dobët,
- sulmuesi dëshiron të fitojë akses në bonuset e viktimës,
- konkurrentët duan të lënë komente negative për produktet,
- Botnet-i dëshiron të marrë bazën e klientëve të dyqanit dhe të përdorë një sulm për ta bërë sitin jofunksional.
Parakushtet: vizitori nuk duhet të jetë i autorizuar.
Garancitë minimale: vizitori do të dijë nëse përpjekja për autorizim ishte e suksesshme apo e pasuksesshme.
Garancitë e suksesit: vizitori është i autorizuar.
Skenari kryesor:
- Klienti fillon autorizimin.
- Sistemi konfirmon që klienti nuk është i autorizuar dhe nuk e kalon numrin e përpjekjeve të pasuksesshme të autorizimit nga një seancë e caktuar (kërkimi i një fjalëkalimi të dobët për shumë llogari) sipas "Rregullit të Sigurisë Nr. 23".
- Sistemi rrit numëruesin për numrin e përpjekjeve për autorizim.
- Sistemi i shfaq klientit një formular autorizimi.
- Klienti fut emailin dhe fjalëkalimin e tij.
- Sistemi konfirmon praninë e një klienti me një email të tillë në sistem dhe se fjalëkalimi përputhet dhe numri i përpjekjeve për hyrje në këtë llogari nuk është tejkaluar sipas "Rregullit të Sigurisë Nr. 24".
- Sistemi autorizon klientin, shton historikun e shfletimit dhe shportën e këtij sesioni me sesionin e fundit të kësaj llogarie klienti.
- Sistemi shfaq një mesazh suksesi të autorizimit dhe kalon në hapin e skriptit nga i cili klienti u ndërpre për autorizim. Në këtë rast, të dhënat në faqe ringarkohen duke marrë parasysh të dhënat e llogarisë personale.
Shtesat:
2.a. Klienti është tashmë i autorizuar:
2.a.1. Sistemi njofton klientin për faktin e autorizimit të kryer më parë dhe ofron të ndërpresë skriptin ose të shkojë në hapin 4, dhe nëse hapi 6 është përfunduar me sukses, atëherë hapi 7 kryhet me sqarim:
2.a.7. Sistemi deaktorizon klientin nën llogarinë e vjetër, autorizon klientin në llogarinë e re, ndërsa historiku i shfletimit dhe karroca e këtij sesioni ndërveprimi mbeten në llogarinë e vjetër dhe nuk transferohen në atë të re. Tjetra, shkoni në hapin 8.
2.b Numri i përpjekjeve për autorizim ka tejkaluar pragun sipas “Rregullit të Sigurisë Nr. 23”:
2.b.1 Shkoni te hapi 4, një captcha shfaqet gjithashtu në formularin e autorizimit
2.b.6 Sistemi konfirmon hyrjen e saktë të captcha
2.b.6.1 Captcha është futur gabimisht:
2.b.6.1.1. sistemi rrit numëruesin e përpjekjeve të pasuksesshme të autorizimit edhe për këtë llogari
2.b.6.1.2. sistemi shfaq një mesazh dështimi dhe kthehet në hapin 2
6.a. Nuk u gjet asnjë llogari me këtë email:
6.a.1 Sistemi shfaq një mesazh në lidhje me dështimin dhe ofron një zgjedhje për të shkuar në hapin 2 ose për të shkuar te skenari "Regjistrimi i përdoruesit" dhe për të ruajtur emailin e futur,
6.b. Fjalëkalimi për llogarinë me këtë email nuk përputhet me atë të futur:
6.b.1 Sistemi rrit numëruesin e përpjekjeve të pasuksesshme për hyrje në këtë llogari.
6.b.2 Sistemi shfaq një mesazh në lidhje me dështimin dhe ofron zgjedhjen për të shkuar te skenari i "Rikuperimit të fjalëkalimit" ose në hapin 2.
6.c: Numri i përpjekjeve për hyrje për këtë llogari ka tejkaluar pragun për "Rregullin e Sigurisë nr. 24".
6.c.1 Sistemi shfaq një mesazh në lidhje me bllokimin e hyrjes në llogari për X minuta dhe vazhdon në hapin 2.
Çfarë është e mrekullueshme
Kontrollet për plotësinë dhe pajtueshmërinë me qëllimet, domethënë, ju mund t'i jepni kërkesa një analisti tjetër për verifikim, duke bërë më pak gabime në fazën e formulimit të problemit.
Puna me një sistem kuti të zezë ju lejon të ndani zhvillimin dhe koordinimin me klientin e asaj që do të automatizohet nga metodat e zbatimit.
Është pjesë e rrugës së analistit, një nga pjesët kryesore të përdorshmërisë. Skenari i përdoruesit përcakton rrugët kryesore të lëvizjes së tij, gjë që redukton shumë lirinë e zgjedhjes për projektuesin dhe klientin dhe ndihmon në rritjen e shpejtësisë së zhvillimit të dizajnit.
Jam shumë i kënaqur me vendin në përshkrim ku identifikohen përjashtimet për çdo hap ndërveprimi. Një sistem i plotë IT duhet të sigurojë një lloj trajtimi përjashtimesh, disa manualisht, disa automatikisht (si në shembullin e mësipërm).
Përvoja tregon se trajtimi i papërshtatshëm i përjashtimeve mund ta kthejë lehtësisht një sistem në një sistem tmerrësisht të papërshtatshëm. Më kujtohet historia kur në kohët sovjetike, për të marrë një vendim, duhej të merrje disa miratime nga shërbime të ndryshme, dhe sa e dhimbshme është kur shërbimi i fundit thotë - por aplikimi juaj është me emrin e gabuar ose ndonjë gabim tjetër në shenjat e pikësimit, ribëni gjithçka dhe rikoordinoni gjithçka.
Shpesh ndeshem me situata ku logjika e funksionimit të një sistemi që nuk ishte menduar për përjashtime kërkonte një ripërpunim domethënës të sistemit. Për shkak të kësaj, pjesa më e madhe e punës së analistit shpenzohet për trajtimin e përjashtimeve.
Shënimi i tekstit, në krahasim me diagramet, lejon që të identifikohen dhe mbulohen më shumë përjashtime.
Shtesë në metodë nga praktika
Rasti i përdorimit nuk është një pjesë me prioritet të pavarur të deklaratës, ndryshe nga historia e përdoruesit.
Në skenarin e mësipërm, merrni parasysh përjashtimin “6.a. Nuk u gjet asnjë llogari me këtë email.” dhe hapi tjetër "6.a.1 Sistemi shfaq një mesazh dështimi dhe vazhdon në hapin 2." Cilat gjëra negative mbetën në prapaskenë? Për klientin, çdo kthim është i barabartë me faktin se e gjithë puna që ai ka bërë për futjen e të dhënave është hedhur në një vendgrumbullim. (Thjesht nuk është e dukshme në skenar!) Çfarë mund të bëhet? Rindërtoni skenarin në mënyrë që kjo të mos ndodhë. A është e mundur të bëhet kjo? Ju mund - si shembull, të shikoni skriptin e autorizimit të Google.
Optimizimi i skenarit
Libri flet për formalizimin, por thotë pak për metodat për optimizimin e skenarëve të tillë.
Por është e mundur të forcohet metoda duke optimizuar skenarët dhe metoda e formalizimit të rasteve të përdorimit e lejon këtë. Në mënyrë të veçantë, ju duhet të mendoni për çdo përjashtim që ndodh, të përcaktoni shkakun dhe të rindërtoni skenarin në mënyrë që të hiqni qafe përjashtimin ose të minimizoni udhëtimin e klientit.
Kur bëni një porosi nga një dyqan online, duhet të shkruani qytetin e dorëzimit. Mund të rezultojë që dyqani nuk mund të dorëzojë mallra në qytetin e zgjedhur nga klienti sepse nuk dërgon atje, për shkak të kufizimeve të madhësisë ose për shkak të mungesës së mallrave në magazinë përkatëse.
Nëse thjesht përshkruajmë skenarin e ndërveprimit në fazën e regjistrimit, mund të shkruajmë "të informojmë klientin se dorëzimi është i pamundur dhe të ofrojmë të ndryshojmë qytetin ose përmbajtjen e karrocës" (dhe shumë analistë fillestarë ndalen këtu). Por nëse ka shumë raste të tilla, atëherë skenari mund të optimizohet.
Gjëja e parë që duhet të bëni është t'ju lini të zgjidhni vetëm qytetin ku mund të dorëzojmë. Kur ta bëni këtë? Para se të zgjidhni një produkt në faqen e internetit (autodektifikimi i qytetit përmes IP me sqarim).
Së dyti, duhet të zgjedhim vetëm mallrat që mund t'i dorëzojmë klientit. Kur ta bëni këtë? Në momentin e përzgjedhjes - në pllakën e produktit dhe kartën e produktit.
Këto dy ndryshime shkojnë shumë drejt eliminimit të këtij përjashtimi.
Kërkesat për matje dhe metrikë
Kur shqyrtoni detyrën e minimizimit të trajtimit të përjashtimeve, mund të vendosni një detyrë raportimi (rasti i përdorimit nuk përshkruhet). Sa përjashtime ka pasur, në cilat raste kanë ndodhur, plus sa skenarë në hyrje kanë kaluar me sukses.
Por mjerisht. Përvoja ka treguar se kërkesat e raportimit për skenarët në këtë formë nuk janë të mjaftueshme; është e nevojshme të merren parasysh kërkesat e raportimit për proceset që përshkruhen kryesisht jo në formën e një rasti përdorimi.
Qasja në përdorshmëri
Në praktikën tonë, ne kemi zgjeruar formularin e përshkrimit të rastit të përdorimit me një përshkrim të atributeve specifike të subjekteve dhe të dhënave që klienti të marrë një vendim, gjë që rrit përdorshmërinë e mëvonshme.
Për dizajnin e përdorshmërisë, ne shtuam një seksion të hyrjes - të dhënat e shfaqjes.
Në një skenar me autorizim, ky është fakti që klienti është i autorizuar në sistem. Nëse klienti është i para-autorizuar, atëherë shfaqni një paralajmërim për kalimin e historisë së navigimit dhe karrocës në llogarinë e re pas autorizimit të suksesshëm.
Në përgjithësi, kjo është një shfaqje e informacionit të nevojshëm për klientin në mënyrë që ai të mund të marrë një vendim për veprimet e tij të mëtejshme sipas skenarit (mund të pyesni nëse këto të dhëna janë të mjaftueshme për klientin, çfarë tjetër nevojitet, çfarë informacioni bën klienti duhet të marrë vendime).
Gjithashtu vlen të ndahet informacioni i futur në fusha hyrëse nëse ato përpunohen veçmas dhe me formimin e përjashtimeve të ndryshme.
Në shembullin me autorizimin e klientit, nëse ndani informacionin e futur në hyrje dhe fjalëkalim, atëherë ia vlen të ndryshoni skriptin e autorizimit për të theksuar fazat e futjes së një hyrje të veçantë dhe një fjalëkalimi të veçantë (dhe kjo bëhet në Yandex, Google, por nuk bëhet në shumicën e dyqaneve online).
Arritja e transformimeve të kërkuara të të dhënave
Ju gjithashtu mund të nxirrni kërkesat për algoritmet e konvertimit të të dhënave nga skripti.
Shembuj:
- Për të marrë një vendim për të blerë një produkt në një dyqan online, klienti duhet të dijë në kartën e produktit mundësinë, koston, kohën e dorëzimit në qytetin e tij të këtij produkti (të cilat llogariten nga algoritmi bazuar në disponueshmërinë e produktit në magazinat dhe parametrat e zinxhirit të furnizimit).
- Kur futni një frazë në linjën e kërkimit, klientit i shfaqen sugjerimet e kërkimit sipas algoritmit (të cilat gjenerohen nga algoritmi...).
Në total
Në përgjithësi, pas leximit të librit, për fat të keq, nuk është e qartë se si të kalohet nga një analist në problemet e biznesit në një specifikim teknik të zyrtarizuar për një zhvillues. Libri tregon vetëm një pjesë të procesit, me hapat hyrës të paqartë dhe hapat e ardhshëm të paqartë. Vetë rasti i përdorimit më shpesh nuk është një deklaratë e plotë për zhvilluesin.
Megjithatë, kjo është një mënyrë shumë e mirë për të zyrtarizuar dhe përpunuar skenarë të ndërveprimit midis një objekti dhe një subjekti, kur ndërveprimi shkakton një ndryshim në diçka në subjekt. Është një nga metodat e pakta të shkrimit që lejon kërkesa të verifikueshme me pika kërkimi të qartë të përjashtimit.
Libri është një domosdoshmëri për t'u lexuar për analistët që të fillojnë të shkruajnë drama të testueshme.
Burimi: www.habr.com