Ang aklat ay naglalarawan ng isang paraan para sa pagsulat ng bahagi ng isang pahayag ng problema, katulad ng paraan ng kaso ng paggamit.
Ano ito? Isa itong paglalarawan ng senaryo ng pakikipag-ugnayan ng user sa system (o sa negosyo). Sa kasong ito, gumaganap ang system bilang isang itim na kahon (at ginagawa nitong posible na hatiin ang kumplikadong gawain sa disenyo sa pagdidisenyo ng pakikipag-ugnayan at pagtiyak ng pakikipag-ugnayan na ito). Kasabay nito, ang mga pamantayan ng notasyon ay ipinakilala, na nagsisiguro sa kadalian ng pagbabasa, kabilang ang para sa mga hindi kalahok, at nagbibigay-daan para sa ilang mga pagsusuri para sa pagkakumpleto at pagsunod sa mga layunin ng stakeholder.
Halimbawa ng use case
Ano ang hitsura ng senaryo, gamit ang halimbawa ng awtorisasyon sa site sa pamamagitan ng email:
(System) Mag-log in sa website upang ma-access ang iyong personal na account. ~~ (level ng dagat)
Konteksto: Ang isang hindi awtorisadong kliyente ay nag-log in sa site upang makilala siya ng site at magpakita ng personal na impormasyon para sa kanya: kasaysayan ng pagba-browse, kasaysayan ng pagbili, kasalukuyang bilang ng mga puntos ng bonus, atbp., gamit ang email bilang isang pag-login.
Antas: layunin ng gumagamit
Bida: kliyente (bisita ng aming online na tindahan)
Saklaw: Pakikipag-ugnayan ng kliyente sa website ng online na tindahan
Mga stakeholder at interes:
- gusto ng marketer na matukoy ang maximum na bilang ng mga bisita sa site para sa mas malawak na saklaw ng mga personal na pagpapadala,
- gustong tiyakin ng espesyalista sa seguridad na walang mga kaso ng hindi awtorisadong pag-access sa personal na data ng bisita, kabilang ang mga pagtatangka na hulaan ang password para sa isang account o maghanap ng account na may mahinang password,
- gusto ng umaatake na makakuha ng access sa mga bonus ng biktima,
- nais ng mga kakumpitensya na mag-iwan ng mga negatibong pagsusuri sa mga produkto,
- Nais ng botnet na makuha ang customer base ng tindahan at gumamit ng isang pag-atake upang hindi magamit ang site.
Mga Precondition: hindi dapat awtorisado ang bisita.
Mga minimum na garantiya: malalaman ng bisita kung matagumpay o hindi matagumpay ang pagtatangka ng pahintulot.
Mga garantiya ng tagumpay: awtorisado ang bisita.
Pangunahing senaryo:
- Pinasimulan ng kliyente ang pahintulot.
- Kinukumpirma ng system na ang kliyente ay hindi awtorisado at hindi lalampas sa bilang ng hindi matagumpay na mga pagtatangka sa pagpapahintulot mula sa isang partikular na session (naghahanap ng mahinang password para sa maraming account) ayon sa "Security Rule No. 23".
- Pinapataas ng system ang counter para sa bilang ng mga pagtatangka sa pahintulot.
- Nagpapakita ang system ng form ng pahintulot sa kliyente.
- Ipinasok ng kliyente ang kanyang email at password.
- Kinukumpirma ng system ang pagkakaroon ng isang kliyente na may ganoong email sa system at na ang password ay tumutugma at ang bilang ng mga pagtatangka sa pag-login sa account na ito ay hindi lalampas ayon sa "Security Rule No. 24".
- Pinapahintulutan ng system ang kliyente, idinaragdag ang kasaysayan ng pagba-browse at ang basket ng session na ito kasama ang huling session ng account ng kliyente na ito.
- Nagpapakita ang system ng mensahe ng tagumpay ng awtorisasyon at lumilipat sa hakbang ng script kung saan naantala ang kliyente para sa awtorisasyon. Sa kasong ito, nire-reload ang data sa page na isinasaalang-alang ang data ng personal na account.
Mga Extension:
2.a. Ang kliyente ay awtorisado na:
2.a.1. Inaabisuhan ng system ang kliyente tungkol sa katotohanan ng dati nang ginawang awtorisasyon at nag-aalok na matakpan ang script o pumunta sa hakbang 4, at kung matagumpay na nakumpleto ang hakbang 6, isasagawa ang hakbang 7 nang may paglilinaw:
2.a.7. Ide-deactorize ng system ang kliyente sa ilalim ng lumang account, pinahihintulutan ang kliyente sa ilalim ng bagong account, habang ang kasaysayan ng pagba-browse at cart ng session ng pakikipag-ugnayan na ito ay nananatili sa lumang account at hindi inililipat sa bago. Susunod, pumunta sa hakbang 8.
2.b Ang bilang ng mga pagtatangka sa awtorisasyon ay lumampas sa threshold ayon sa βSecurity Rule No. 23β:
2.b.1 Pumunta sa hakbang 4, ang isang captcha ay karagdagang ipinapakita sa form ng pahintulot
2.b.6 Kinukumpirma ng system ang tamang captcha entry
2.b.6.1 Maling naipasok ang Captcha:
2.b.6.1.1. pinapataas din ng system ang counter ng hindi matagumpay na mga pagtatangka sa pagpapahintulot para sa account na ito
2.b.6.1.2. ang system ay nagpapakita ng isang mensahe ng pagkabigo at bumalik sa hakbang 2
6.a. Walang nakitang account na may ganitong email:
6.a.1 Ang system ay nagpapakita ng isang mensahe tungkol sa pagkabigo at nag-aalok ng isang pagpipilian ng alinman sa pagpunta sa hakbang 2 o pagpunta sa "Pagpaparehistro ng User" na senaryo at pag-save ng ipinasok na email,
6.b. Ang password para sa account na may ganitong email ay hindi tumutugma sa ipinasok:
6.b.1 Pinapataas ng system ang counter ng mga hindi matagumpay na pagsubok sa pag-log in sa account na ito.
6.b.2 Nagpapakita ang system ng mensahe tungkol sa kabiguan at nag-aalok ng pagpipiliang pumunta sa senaryo ng βPagbawi ng Passwordβ o sa hakbang 2.
6.c: Ang counter ng pagsubok sa pag-log in para sa account na ito ay lumampas sa threshold para sa "Panuntunan ng Seguridad Blg. 24."
6.c.1 Nagpapakita ang system ng mensahe tungkol sa pagharang sa pag-log in sa account sa loob ng X minuto at nagpapatuloy sa hakbang 2.
Ang galing
Sinusuri ang pagkakumpleto at pagsunod sa mga layunin, iyon ay, maaari kang magbigay ng mga kinakailangan sa isa pang analyst para sa pag-verify, na gumagawa ng mas kaunting mga pagkakamali sa yugto ng pagbabalangkas ng problema.
Ang pagtatrabaho sa isang black box system ay nagbibigay-daan sa iyo upang paghiwalayin ang pagbuo at koordinasyon sa customer ng kung ano ang magiging awtomatiko mula sa mga pamamaraan ng pagpapatupad.
Ito ay bahagi ng landas ng analyst, isa sa mga pangunahing bahagi ng kakayahang magamit. Tinutukoy ng senaryo ng gumagamit ang mga pangunahing landas ng kanyang paggalaw, na lubos na binabawasan ang kalayaan sa pagpili para sa taga-disenyo at sa customer at nakakatulong upang mapataas ang bilis ng pagbuo ng disenyo.
Lubos akong nalulugod sa lugar sa paglalarawan kung saan natukoy ang mga pagbubukod sa bawat hakbang sa pakikipag-ugnayan. Ang isang kumpletong IT system ay dapat magbigay ng ilang uri ng exception handling, ang ilan ay manu-mano, ang ilan ay awtomatiko (tulad ng sa halimbawa sa itaas).
Ipinakikita ng karanasan na ang hindi pinag-isipang paghawak ng exception ay madaling gawing isang system na lubhang hindi maginhawa. Naaalala ko ang kuwento noong panahon ng Sobyet, upang makakuha ng desisyon, kailangan mong kumuha ng ilang mga pag-apruba mula sa iba't ibang mga serbisyo, at kung gaano kasakit kapag sinabi ng huling serbisyo - ngunit ang iyong aplikasyon ay nasa maling pangalan o iba pang pagkakamali sa bantas, gawing muli ang lahat at muling i-coordinate ang lahat.
Madalas akong nakakatagpo ng mga sitwasyon kung saan ang operating logic ng isang system na hindi pinag-isipan para sa mga exception ay nangangailangan ng makabuluhang reworking ng system. Dahil dito, ang malaking bahagi ng gawain ng analyst ay ginugugol sa paghawak ng exception.
Ang notasyon ng teksto, bilang kabaligtaran sa mga diagram, ay nagbibigay-daan sa higit pang mga pagbubukod na matukoy at masakop.
Dagdag sa pamamaraan mula sa pagsasanay
Ang kaso ng paggamit ay hindi isang independiyenteng priyoridad na bahagi ng pahayag, hindi katulad ng kwento ng user.
Sa senaryo sa itaas, isaalang-alang ang pagbubukod "6.a. Walang nakitang account na may ganitong email.β at ang susunod na hakbang "6.a.1 Ang system ay nagpapakita ng isang mensahe ng pagkabigo at nagpapatuloy sa hakbang 2." Anong mga negatibong bagay ang naiwan sa mga eksena? Para sa kliyente, ang anumang pagbabalik ay katumbas ng katotohanan na ang lahat ng gawaing ginawa niya sa pagpasok ng data ay itinapon sa isang landfill. (Hindi lang ito nakikita sa script!) Ano ang maaaring gawin? Buuin muli ang script upang hindi ito mangyari. Posible bang gawin ito? Maaari mong - bilang isang halimbawa, tingnan ang script ng awtorisasyon ng Google.
Pag-optimize ng senaryo
Ang aklat ay nagsasalita tungkol sa pormalisasyon, ngunit kakaunti ang sinasabi tungkol sa mga pamamaraan para sa pag-optimize ng mga ganitong sitwasyon.
Ngunit posible na palakasin ang pamamaraan sa pamamagitan ng pag-optimize ng mga sitwasyon, at pinapayagan ito ng paraan ng pormalisasyon ng use case na magawa ito. Sa partikular, kailangan mong pag-isipan ang bawat pagbubukod na nangyayari, tukuyin ang dahilan, at muling buuin ang script upang maalis ang pagbubukod o mabawasan ang paglalakbay ng customer.
Kapag naglalagay ng isang order mula sa isang online na tindahan, dapat kang pumasok sa lungsod ng paghahatid. Maaaring lumabas na ang tindahan ay hindi makapaghatid ng mga kalakal sa lungsod na pinili ng kliyente dahil hindi ito naghahatid doon, dahil sa mga paghihigpit sa laki, o dahil sa kakulangan ng mga kalakal sa kaukulang bodega.
Kung ilalarawan lang namin ang senaryo ng pakikipag-ugnayan sa yugto ng pagpaparehistro, maaari naming isulat ang "ipaalam sa kliyente na imposible ang paghahatid at mag-alok na baguhin ang lungsod o ang mga nilalaman ng cart" (at maraming mga baguhang analyst ang huminto doon). Ngunit kung mayroong maraming mga ganitong kaso, kung gayon ang senaryo ay maaaring ma-optimize.
Ang unang bagay na kailangan mong gawin ay hayaan kang pumili lamang ng lungsod kung saan kami makakapaghatid. Kailan ito gagawin? Bago pumili ng isang produkto sa website (autodetection ng lungsod sa pamamagitan ng IP na may paglilinaw).
Pangalawa, kailangan nating magbigay ng pagpipilian lamang ng mga kalakal na maaari nating ihatid sa kliyente. Kailan ito gagawin? Sa sandali ng pagpili - sa tile ng produkto at card ng produkto.
Malaki ang naitutulong ng dalawang pagbabagong ito para maalis ang pagbubukod na ito.
Mga kinakailangan para sa mga sukat at sukatan
Kapag isinasaalang-alang ang gawain ng pagliit ng paghawak ng exception, maaari kang magtakda ng gawain sa pag-uulat (hindi inilarawan ang kaso ng paggamit). Gaano karaming mga pagbubukod ang nagkaroon, sa anong mga kaso naganap ang mga ito, at kung gaano karaming mga papasok na sitwasyon ang matagumpay na naipasa.
Pero sayang. Ipinakita ng karanasan na hindi sapat ang pag-uulat ng mga kinakailangan para sa mga senaryo sa form na ito; kinakailangang isaalang-alang ang pag-uulat ng mga kinakailangan para sa mga proseso na higit na inilalarawan ay hindi sa anyo ng isang kaso ng paggamit.
Access sa Usability
Sa aming pagsasanay, pinalawak namin ang form para sa paglalarawan ng use case na may paglalarawan ng mga partikular na katangian ng mga entity at data para makapagdesisyon ang kliyente, na nagpapahusay sa kasunod na kakayahang magamit.
Para sa disenyo ng kakayahang magamit, nagdagdag kami ng seksyon ng input - ipakita ang data.
Sa isang senaryo na may awtorisasyon, ito ang katotohanan na ang kliyente ay awtorisado sa system. Kung ang kliyente ay paunang pinahintulutan, pagkatapos ay magpakita ng babala tungkol sa paglipat ng kasaysayan ng nabigasyon at cart sa bagong account pagkatapos ng matagumpay na pagpapahintulot.
Sa pangkalahatan, ito ay isang pagpapakita ng kinakailangang impormasyon para sa kliyente upang makagawa siya ng desisyon tungkol sa kanyang mga karagdagang aksyon ayon sa senaryo (maaari mong tanungin kung ang data na ito ay sapat para sa kliyente, ano pa ang kailangan, anong impormasyon ang ginagawa kailangang gumawa ng mga desisyon ang kliyente).
Ito ay nagkakahalaga din na hatiin ang ipinasok na impormasyon sa mga patlang ng input kung sila ay pinoproseso nang hiwalay at may pagbuo ng iba't ibang mga pagbubukod.
Sa halimbawa ng awtorisasyon ng kliyente, kung ihihiwalay mo ang ipinasok na impormasyon sa pag-login at password, sulit na baguhin ang script ng awtorisasyon upang i-highlight ang mga yugto ng pagpasok ng isang hiwalay na pag-login at isang hiwalay na password (at ginawa ito sa Yandex, Google, ngunit hindi ginawa sa karamihan ng mga online na tindahan).
Pag-abot sa kinakailangang pagbabago ng data
Maaari mo ring kunin ang mga kinakailangan para sa mga algorithm ng conversion ng data mula sa script.
ΠΡΠΈΠΌΠ΅ΡΡ:
- Upang makagawa ng desisyon na bumili ng produkto sa isang online na tindahan, kailangang malaman ng kliyente sa card ng produkto ang posibilidad, gastos, oras ng paghahatid sa kanyang lungsod ng produktong ito (na kinakalkula ng algorithm batay sa pagkakaroon ng produkto sa mga bodega at mga parameter ng supply chain).
- Kapag naglalagay ng parirala sa linya ng paghahanap, ipinapakita ang kliyente ng mga mungkahi sa paghahanap ayon sa algorithm (na nabuo ng algorithm...).
Sa kabuuan
Sa pangkalahatan, pagkatapos basahin ang libro, sa kasamaang-palad, hindi malinaw kung paano pumunta mula sa isang analyst hanggang sa mga problema sa negosyo hanggang sa isang pormal na teknikal na detalye para sa isang developer. Ang aklat ay nagsasabi lamang ng bahagi ng proseso, na ang mga hakbang sa pag-input ay hindi malinaw at ang mga susunod na hakbang ay hindi malinaw. Ang use case mismo ay kadalasang hindi kumpletong pahayag para sa developer.
Gayunpaman, ito ay isang napakahusay na paraan upang gawing pormal at iproseso ang mga senaryo ng pakikipag-ugnayan sa pagitan ng isang bagay at isang paksa, kapag ang pakikipag-ugnayan ay nagdudulot ng pagbabago sa isang bagay sa paksa. Isa ito sa ilang paraan ng pagsulat na nagbibigay-daan sa mga nabe-verify na kinakailangan na may tahasang mga punto sa paghahanap ng exception.
Ang aklat ay dapat basahin para sa mga analyst upang magsimulang magsulat ng mga masusubok na dula.
Pinagmulan: www.habr.com