Kirjassa kuvataan yksi tapa kirjoittaa osa ongelmalauseesta, eli käyttötapausmenetelmä.
Mikä se on? Tämä on kuvaus käyttäjän vuorovaikutusskenaariosta järjestelmän (tai yrityksen) kanssa. Tässä tapauksessa järjestelmä toimii mustana laatikkona (ja tämä mahdollistaa monimutkaisen suunnittelutehtävän jakamisen vuorovaikutuksen suunnitteluun ja tämän vuorovaikutuksen varmistamiseen). Samalla otetaan käyttöön merkintästandardeja, jotka takaavat lukemisen helppouden myös ei-osanottajille ja mahdollistavat jonkin verran täydellisyyden ja sidosryhmän tavoitteiden mukaisuuden tarkistamisen.
Käytä tapausesimerkkiä
Miltä skenaario näyttää käyttämällä esimerkkiä sivuston valtuuksista sähköpostitse:
(Järjestelmä) Kirjaudu sisään verkkosivustolle päästäksesi henkilökohtaiseen tiliisi. ~~ (merenpinta)
Konteksti: Luvaton asiakas kirjautuu sivustolle siten, että sivusto tunnistaa hänet ja näyttää hänen henkilökohtaisia tietojaan: selaushistorian, ostohistorian, tämänhetkisen bonuspistemäärän jne. käyttämällä sähköpostia sisäänkirjautumisena.
taso: käyttäjän tavoite
Päähenkilö: asiakas (verkkokauppamme vierailija)
Laajuus: Asiakkaan vuorovaikutus verkkokaupan verkkosivuston kanssa
Sidosryhmät ja intressit:
- markkinoija haluaa, että sivuston kävijöiden enimmäismäärä tunnistetaan, jotta henkilökohtaisten postitusten kattavuus kasvaisi,
- tietoturva-asiantuntija haluaa varmistaa, ettei vierailijan henkilötietoihin pääse luvatta käsiksi, mukaan lukien yritetään arvata yhden tilin salasanaa tai etsiä tiliä heikolla salasanalla,
- hyökkääjä haluaa päästä käsiksi uhrin bonuksiin,
- kilpailijat haluavat jättää negatiivisia arvosteluja tuotteista,
- Bottiverkko haluaa saada liikkeen asiakaskunnan ja tehdä sivustosta hyökkäyksen käyttökelvottoman.
Edellytykset: vierailija ei saa olla valtuutettu.
Vähimmäistakuut: Vierailija tietää, oliko valtuutusyritys onnistunut vai epäonnistunut.
Menestyksen takuut: vierailija on valtuutettu.
Pääskenaario:
- Asiakas aloittaa valtuutuksen.
- Järjestelmä vahvistaa, että asiakasta ei ole valtuutettu, eikä se ylitä tietyn istunnon epäonnistuneiden valtuutusyritysten määrää (heikon salasanan etsiminen useille tileille) "Turvallisuussäännön nro 23" mukaisesti.
- Järjestelmä lisää valtuutusyritysten lukumäärää.
- Järjestelmä näyttää asiakkaalle valtuutuslomakkeen.
- Asiakas syöttää sähköpostiosoitteensa ja salasanansa.
- Järjestelmä vahvistaa, että järjestelmässä on asiakas, jolla on tällainen sähköposti, ja että salasana täsmää ja että tälle tilille kirjautumisyritysten määrä ei ylity "Turvallisuussäännön nro 24" mukaisesti.
- Järjestelmä valtuuttaa asiakkaan, lisää tämän istunnon selaushistorian ja korin tämän asiakastilin viimeiseen istuntoon.
- Järjestelmä näyttää valtuutuksen onnistumisviestin ja siirtyy komentosarjavaiheeseen, josta asiakas keskeytettiin valtuutuksen vuoksi. Tässä tapauksessa sivun tiedot ladataan uudelleen ottaen huomioon henkilökohtaiset tilitiedot.
Laajennukset:
2.a. Asiakas on jo valtuutettu:
2.a.1. Järjestelmä ilmoittaa asiakkaalle aiemmin tehdyn valtuutuksen tosiasiasta ja tarjoaa joko keskeyttää komentosarjan tai siirtyä vaiheeseen 4, ja jos vaihe 6 on suoritettu onnistuneesti, suoritetaan vaihe 7 selvennyksellä:
2.a.7. Järjestelmä deaktivoi asiakkaan vanhan tilin alle, valtuuttaa asiakkaan uudelle tilille, kun taas tämän vuorovaikutusistunnon selaushistoria ja ostoskori säilyvät vanhassa tilissä eivätkä siirry uudelle tilille. Siirry seuraavaksi vaiheeseen 8.
2.b Valtuutusyritysten määrä on ylittänyt "Turvallisuussäännön nro 23" mukaisen kynnyksen:
2.b.1 Siirry vaiheeseen 4, valtuutuslomakkeessa näkyy lisäksi captcha
2.b.6 Järjestelmä vahvistaa oikean captcha-merkinnän
2.b.6.1 Captcha syötetty väärin:
2.b.6.1.1. järjestelmä lisää myös tämän tilin epäonnistuneiden valtuutusyritysten laskuria
2.b.6.1.2. järjestelmä näyttää virheviestin ja palaa vaiheeseen 2
6.a. Tällä sähköpostilla ei löytynyt tiliä:
6.a.1 Järjestelmä näyttää virheilmoituksen ja tarjoaa mahdollisuuden joko siirtyä vaiheeseen 2 tai siirtyä "Käyttäjän rekisteröinti" -skenaarioon ja tallentaa syötetty sähköposti,
6.b. Tämän sähköpostin tilin salasana ei vastaa syötettyä salasanaa:
6.b.1 Järjestelmä lisää epäonnistuneiden kirjautumisyritysten laskuria tälle tilille.
6.b.2 Järjestelmä näyttää virheilmoituksen ja tarjoaa mahdollisuuden valita joko "Salasanan palautus" -skenaarioon tai vaiheeseen 2.
6.c: Tämän tilin kirjautumisyrityslaskuri on ylittänyt "Turvallisuussäännön nro 24" kynnyksen.
6.c.1 Järjestelmä näyttää X minuutin ajan viestin tilin kirjautumisen estämisestä ja jatkaa vaiheeseen 2.
Mikä on hienoa
Tarkistaa täydellisyyden ja tavoitteiden noudattamisen, eli voit antaa vaatimuksia toiselle analyytikolle todentamista varten, mikä tekee vähemmän virheitä ongelman muotoiluvaiheessa.
Työskentely black box -tyyppisellä järjestelmällä mahdollistaa automatisoitavan kehittämisen ja koordinoinnin erottamisen toteutustavoista.
Se on osa analyytikon polkua, yksi käytettävyyden pääosista. Käyttäjän skenaario määrittelee hänen liikkeensä pääpolut, mikä vähentää suuresti suunnittelijan ja asiakkaan valinnanvapautta ja nopeuttaa suunnittelun kehitystä.
Olen erittäin tyytyväinen kuvauksen kohtaan, jossa jokaiseen vuorovaikutusvaiheeseen on merkitty poikkeuksia. Täydellisen IT-järjestelmän tulee tarjota jonkinlainen poikkeuskäsittely, osa manuaalisesti, osa automaattisesti (kuten yllä olevassa esimerkissä).
Kokemus osoittaa, että huonosti harkittu poikkeusten käsittely voi helposti muuttaa järjestelmän hirveän hankalaksi järjestelmäksi. Muistan tarinan, kun neuvostoaikana päätöksen saamiseksi piti saada useita hyväksyntöjä eri palveluilta, ja kuinka kipeää on, kun viimeinen palvelu sanoo - mutta hakemuksesi on väärällä nimellä tai muussa virheessä. välimerkit, tee kaikki uudelleen ja koordinoi kaikki uudelleen.
Olen usein törmännyt tilanteisiin, joissa poikkeuksille harkitsemattoman järjestelmän toimintalogiikka vaati järjestelmän merkittävää uudistamista. Tästä johtuen leijonanosa analyytikon työstä kuluu poikkeusten käsittelyyn.
Tekstin merkitseminen kaavioiden sijaan mahdollistaa useampien poikkeuksien tunnistamisen ja kattamisen.
Lisäys menetelmään käytännössä
Käyttötapaus ei ole lausunnon itsenäisesti priorisoitu osa, toisin kuin käyttäjätarina.
Harkitse yllä olevassa skenaariossa poikkeusta ”6.a. Tällä sähköpostilla ei löytynyt tiliä." ja seuraava vaihe "6.a.1 Järjestelmä näyttää virheviestin ja jatkaa vaiheeseen 2." Mitä negatiivista jäi kulissien taakse? Asiakkaalle mikä tahansa palautus merkitsee sitä, että kaikki hänen tietojen syöttämisensä tekemä työ heitetään kaatopaikalle. (Se ei vain näy käsikirjoituksessa!) Mitä voidaan tehdä? Rakenna käsikirjoitus uudelleen, jotta näin ei tapahdu. Onko mahdollista tehdä tämä? Voit - esimerkiksi katsoa Googlen valtuutuskoodia.
Skenaarion optimointi
Kirjassa puhutaan formalisoinnista, mutta kerrotaan vähän menetelmistä tällaisten skenaarioiden optimoimiseksi.
Mutta menetelmää on mahdollista vahvistaa skenaarioita optimoimalla, ja käyttötapausten formalisointimenetelmä mahdollistaa tämän. Tarkemmin sanottuna sinun on mietittävä jokaista esiintyvää poikkeusta, määritettävä syy ja rakennettava komentosarja uudelleen, jotta voit päästä eroon poikkeuksesta tai minimoida asiakaspolun.
Kun teet tilauksen verkkokaupasta, sinun on syötettävä toimituskaupunki. Saattaa käydä niin, että kauppa ei pysty toimittamaan tavaraa asiakkaan valitsemaan kaupunkiin, koska se ei toimita sinne, kokorajoitusten vuoksi tai tavaran puutteen vuoksi vastaavassa varastossa.
Jos kuvailemme yksinkertaisesti vuorovaikutuksen skenaariota rekisteröintivaiheessa, voimme kirjoittaa "ilmoita asiakkaalle, että toimitus on mahdotonta ja tarjoamme kaupungin tai ostoskorin sisällön vaihtamista" (ja monet aloittelevat analyytikot pysähtyvät siihen). Mutta jos tällaisia tapauksia on paljon, skenaario voidaan optimoida.
Ensimmäinen asia, joka sinun on tehtävä, on antaa sinun valita vain kaupunki, johon voimme toimittaa. Milloin tämä tehdään? Ennen tuotteen valitsemista verkkosivustolta (kaupungin automaattinen tunnistus IP:n kautta selvennyksellä).
Toiseksi meidän on annettava valita vain tuotteet, jotka voimme toimittaa asiakkaalle. Milloin tämä tehdään? Valintahetkellä - tuoteruudussa ja tuotekortissa.
Nämä kaksi muutosta edistävät pitkälle tämän poikkeuksen poistamisessa.
Mittaus- ja mittausvaatimukset
Kun harkitset poikkeuskäsittelyn minimoimista, voit asettaa raportointitehtävän (käyttötapausta ei kuvata). Kuinka monta poikkeusta oli, missä tapauksissa niitä esiintyi ja kuinka monta saapuvaa skenaariota onnistui.
Mutta valitettavasti. Kokemus on osoittanut, että tässä muodossa olevien skenaarioiden raportointivaatimukset eivät riitä, vaan on huomioitava raportointivaatimukset prosesseille, joita kuvataan pääosin ei käyttötapauksen muodossa.
Pääsy käytettävyyteen
Käytännössämme olemme laajentaneet käyttötapauskuvauslomaketta entiteettien ja datan tiettyjen attribuuttien kuvauksella, jotta asiakas voi tehdä päätöksen, mikä parantaa myöhempää käytettävyyttä.
Käytettävyyssuunnittelua varten lisäsimme syöttöosion - näyttötiedot.
Valtuutetussa skenaariossa tämä on tosiasia, että asiakas on valtuutettu järjestelmässä. Jos asiakas on valtuutettu etukäteen, näytä varoitus navigointihistorian ja ostoskorin vaihtamisesta uudelle tilille onnistuneen valtuutuksen jälkeen.
Yleensä tämä on asiakkaalle tarvittavien tietojen näyttöä, jotta hän voi tehdä päätöksen jatkotoimistaan skenaarion mukaan (voit kysyä, riittävätkö nämä tiedot asiakkaalle, mitä muuta tarvitaan, mitä tietoja asiakkaan täytyy tehdä päätöksiä).
Myös syötetyt tiedot kannattaa jakaa syöttökenttiin, jos niitä käsitellään erikseen ja eri poikkeuksia muodostaen.
Esimerkissä asiakkaan valtuutus, jos erotat syötetyt tiedot kirjautumistunnukseksi ja salasanaksi, kannattaa muuttaa valtuutusskriptiä korostaaksesi erillisen kirjautumisen ja erillisen salasanan syöttämisen vaiheita (ja tämä tehdään Yandexissä, Googlessa, mutta ei tehdä useimmissa verkkokaupoissa).
Vaadittujen datamuunnosten saavuttaminen
Voit myös poimia skriptistä tiedon muunnosalgoritmien vaatimukset.
Esimerkkejä:
- Päättääkseen ostaa tuotteen verkkokaupasta asiakkaan tulee tietää tuotekortista tämän tuotteen mahdollisuus, hinta, toimitusaika kaupunkiinsa (jotka lasketaan algoritmilla tuotteen saatavuuden perusteella varastot ja toimitusketjun parametrit).
- Kun hakuriville syötetään lause, asiakkaalle näytetään algoritmin mukaisia hakuehdotuksia (jotka algoritmi generoi...).
Yhteensä
Yleisesti ottaen kirjan lukemisen jälkeen ei valitettavasti ole selvää, kuinka edetä analyytikosta liiketoimintaongelmiin aina kehittäjän viralliseen tekniseen spesifikaatioon. Kirja kertoo vain osan prosessista, syöttövaiheet ovat epäselviä ja seuraavat vaiheet epäselvät. Itse käyttötapaus ei useimmiten ole täydellinen lausunto kehittäjälle.
Tämä on kuitenkin erittäin hyvä tapa formalisoida ja prosessoida kohteen ja subjektin välisiä vuorovaikutusskenaarioita, kun vuorovaikutus saa aikaan muutoksen jossakin subjektissa. Se on yksi harvoista kirjoitusmenetelmistä, joka mahdollistaa todennettavissa olevat vaatimukset eksplisiittisillä poikkeushakupisteillä.
Kirja on pakollinen luku analyytikoille, jotta he voivat alkaa kirjoittaa testattavia näytelmiä.
Lähde: will.com