ProHoster > Blogs > interneta ziņas > MÅ«sdienu metodes funkcionālo prasÄ«bu aprakstÄ«Å”anai sistēmām. Alisters Kobērns. Grāmatas apskats un papildinājumi

MÅ«sdienu metodes funkcionālo prasÄ«bu aprakstÄ«Å”anai sistēmām. Alisters Kobērns. Grāmatas apskats un papildinājumi

Grāmatā ir aprakstÄ«ta viena metode problēmas izklāsta daļas rakstÄ«Å”anai, proti, lietoÅ”anas gadÄ«juma metode.

Kas tas ir? Å is ir lietotāja mijiedarbÄ«bas scenārija apraksts ar sistēmu (vai uzņēmumu). Å ajā gadÄ«jumā sistēma darbojas kā melnā kaste (un tas ļauj sadalÄ«t sarežģīto projektÄ“Å”anas uzdevumu mijiedarbÄ«bas projektÄ“Å”anā un Ŕīs mijiedarbÄ«bas nodroÅ”ināŔanā). Vienlaikus tiek ieviesti apzÄ«mējumu standarti, kas nodroÅ”ina lasÄ«Å”anas ērtumu, arÄ« tiem, kas nepiedalās, un ļauj nedaudz pārbaudÄ«t pilnÄ«gumu un atbilstÄ«bu ieinteresētās puses mērÄ·iem.

Izmantojiet gadījuma piemēru

Kā izskatās scenārijs, izmantojot vietnes autorizācijas piemēru pa e-pastu:

(Sistēma) Piesakieties vietnē, lai piekļūtu savam personīgajam kontam. ~~ (jūras līmenis)

Konteksts: Neautorizēts klients piesakās vietnē, lai vietne viņu atpazÄ«tu un parādÄ«tu viņam personisko informāciju: pārlÅ«koÅ”anas vēsturi, pirkumu vēsturi, paÅ”reizējo bonusa punktu skaitu utt., izmantojot e-pastu kā pieteikÅ”anos. 
Līmenis: lietotāja mērķis
Galvenais varonis: klients (mūsu interneta veikala apmeklētājs)
Darbības joma: Klientu mijiedarbība ar interneta veikala vietni
Ieinteresētās personas un intereses:

  • mārketinga speciālists vēlas, lai tiktu identificēts maksimālais vietnes apmeklētāju skaits, lai nodroÅ”inātu lielāku personisko sÅ«tÄ«jumu pārklājumu,
  • droŔības speciālists vēlas nodroÅ”ināt, lai nenotiktu nesankcionētas piekļuves gadÄ«jumi apmeklētāja personas datiem, tajā skaitā mēģinājumi uzminēt viena konta paroli vai meklēt kontu ar vāju paroli;
  • uzbrucējs vēlas piekļūt upura prēmijām,
  • konkurenti vēlas atstāt negatÄ«vas atsauksmes par produktiem,
  • RobottÄ«kls vēlas iegÅ«t veikala klientu bāzi un izmantot uzbrukumu, lai padarÄ«tu vietni nederÄ«gu.

PriekÅ”nosacÄ«jumi: apmeklētājs nedrÄ«kst bÅ«t autorizēts.
Minimālās garantijas: apmeklētājs zinās, vai autorizācijas mēģinājums bija veiksmīgs vai neveiksmīgs.
Panākumu garantijas: apmeklētājs ir autorizēts.

Galvenais scenārijs:

  1. Klients uzsāk autorizāciju.
  2. Sistēma apstiprina, ka klients nav autorizēts un nepārsniedz neveiksmÄ«go autorizācijas mēģinājumu skaitu noteiktā sesijā (vājas paroles meklÄ“Å”ana vairākiem kontiem) saskaņā ar ā€œDroŔības noteikumu Nr. 23ā€.
  3. Sistēma palielina autorizācijas mēģinājumu skaitītāju.
  4. Sistēma klientam parāda autorizācijas veidlapu.
  5. Klients ievada savu e-pastu un paroli.
  6. Sistēma apstiprina klienta ar Ŕādu e-pastu klātbÅ«tni sistēmā un paroles sakritÄ«bu un pieteikÅ”anās mēģinājumu skaitu Å”ajā kontā nav pārsniegts saskaņā ar ā€œDroŔības noteikumu Nr.24ā€.
  7. Sistēma autorizē klientu, pievieno pārlÅ«koÅ”anas vēsturi un Ŕīs sesijas grozu ar Ŕī klienta konta pēdējo sesiju.
  8. Sistēma parāda veiksmīgas autorizācijas ziņojumu un pāriet uz skripta darbību, no kuras klienta autorizācija tika pārtraukta. Šajā gadījumā dati lapā tiek atkārtoti ielādēti, ņemot vērā personas konta datus.

PaplaŔinājumi:
2.a. Klients jau ir autorizēts:
 2.a.1. Sistēma informē klientu par iepriekÅ” veiktās autorizācijas faktu un piedāvā vai nu pārtraukt skriptu, vai arÄ« pāriet uz 4. soli, un, ja 6. darbÄ«ba ir veiksmÄ«gi pabeigta, tad tiek veikta 7. darbÄ«ba ar precizējumu:
 2.a.7. Sistēma deaktivizē klientu vecajā kontā, autorizē klientu jaunajā kontā, savukārt Ŕīs mijiedarbÄ«bas sesijas pārlÅ«koÅ”anas vēsture un grozs paliek vecajā kontā un netiek pārsÅ«tÄ«ts uz jauno. Pēc tam pārejiet uz 8. darbÄ«bu.
2.b Autorizācijas mēģinājumu skaits ir pārsniedzis slieksni saskaņā ar ā€œDroŔības noteikumu Nr. 23ā€:
 2.b.1. Pārejiet uz 4. darbÄ«bu, pilnvarojuma veidlapā papildus tiek parādÄ«ta captcha
 2.b.6. Sistēma apstiprina pareizu captcha ievadi
    2.b.6.1. Captcha ievadÄ«ts nepareizi:
      2.b.6.1.1. sistēma palielina neveiksmÄ«go autorizācijas mēģinājumu skaitÄ«tāju arÄ« Å”im kontam
      2.b.6.1.2. sistēma parāda kļūmes ziņojumu un atgriežas pie 2. darbÄ«bas
6.a. Netika atrasts neviens konts ar Ŕo e-pasta adresi:
 6.a.1 Sistēma parāda ziņojumu par kļūmi un piedāvā izvēlēties vai nu pāriet uz 2. darbÄ«bu, vai arÄ« pāriet uz scenāriju ā€œLietotāja reÄ£istrācijaā€ un saglabāt ievadÄ«to e-pastu,
6.b. Parole kontam ar Ŕo e-pastu neatbilst ievadītajai:
 6.b.1 Sistēma palielina neveiksmÄ«go pieteikÅ”anās mēģinājumu skaitu Å”ajā kontā.
 6.b.2. Sistēma parāda ziņojumu par kļūmi un piedāvā izvēlēties: pāriet uz scenāriju ā€œParoles atkopÅ”anaā€ vai pāriet uz 2. darbÄ«bu.
6.c: Ŕī konta pieteikÅ”anās mēģinājumu skaitÄ«tājs ir pārsniedzis ā€œDroŔības noteikuma Nr. 24ā€ slieksni.
 6.c.1 Sistēma parāda ziņojumu par konta pieteikÅ”anās bloÄ·Ä“Å”anu uz X minÅ«tēm un pāriet uz 2. darbÄ«bu.

Kas ir lieliski

Pārbauda pilnÄ«gumu un atbilstÄ«bu mērÄ·iem, tas ir, jÅ«s varat izvirzÄ«t prasÄ«bas citam analÄ«tiÄ·im pārbaudei, pieļaujot mazāk kļūdu problēmas formulÄ“Å”anas stadijā.

Darbs ar melnās kastes sistēmu ļauj nodalÄ«t automatizējamā izstrādi un saskaņoÅ”anu ar klientu no ievieÅ”anas metodēm.

Tā ir daļa no analītiķa ceļa, viena no galvenajām lietojamības daļām. Lietotāja scenārijs nosaka galvenos viņa kustības ceļus, kas ievērojami samazina dizainera un pasūtītāja izvēles brīvību un palīdz palielināt dizaina izstrādes ātrumu.

Esmu ļoti apmierināts ar vietu aprakstā, kur ir noteikti izņēmumi katram mijiedarbÄ«bas posmam. PilnÄ«gai IT sistēmai ir jānodroÅ”ina kāda veida izņēmumu apstrāde, daži manuāli, daži automātiski (kā iepriekÅ” minētajā piemērā).

Pieredze rāda, ka nepārdomāta izņēmumu apstrāde var viegli pārvērst sistēmu par Å”ausmÄ«gi neērtu sistēmu. Atceros stāstu, kad padomju laikos, lai pieņemtu lēmumu, bija jāsaņem vairāki saskaņojumi no dažādiem dienestiem, un cik sāpÄ«gi ir, kad pēdējā servisā saka - bet tavā iesniegumā ir nepareizs nosaukums vai kāda cita kļūda iekŔā. pieturzÄ«mes, visu pārtaisi un visu vēlreiz saskaņo.

Bieži nākas saskarties ar situācijām, kad sistēmas darbības loģika, kas nebija pārdomāta par izņēmumiem, prasīja būtisku sistēmas pārstrādi. Šī iemesla dēļ lauvas tiesa analītiķa darba tiek tērēta izņēmumu apstrādei.

Teksta apzÄ«mējumi, atŔķirÄ«bā no diagrammām, ļauj identificēt un aptvert vairāk izņēmumu.

Papildinājums metodei no prakses

AtŔķirÄ«bā no lietotāja stāsta lietoÅ”anas gadÄ«jums nav atseviŔķi prioritāra paziņojuma daļa.

IepriekÅ” minētajā scenārijā apsveriet izņēmumu ā€œ6.a. Konts ar Å”o e-pasta adresi netika atrasts. un nākamo darbÄ«bu ā€œ6.a.1. Sistēma parāda kļūmes ziņojumu un pāriet uz 2. darbÄ«buā€. Kādas negatÄ«vās lietas palika aizkulisēs? Klientam jebkura atdeve ir lÄ«dzvērtÄ«ga tam, ka viss darbs, ko viņŔ veica, ievadot datus, tiek izmests poligonā. (Tas vienkārÅ”i nav redzams skriptā!) Ko var darÄ«t? PārbÅ«vējiet skriptu, lai tas nenotiktu. Vai ir iespējams to izdarÄ«t? Piemēram, varat apskatÄ«t Google autorizācijas skriptu.

Scenārija optimizācija

Grāmatā ir runāts par formalizāciju, bet maz teikts par metodēm Ŕādu scenāriju optimizÄ“Å”anai.

Bet metodi ir iespējams stiprināt, optimizējot scenārijus, un lietoÅ”anas gadÄ«jumu formalizācijas metode ļauj to izdarÄ«t. Konkrēti, jums ir jādomā par katru izņēmumu, jānosaka cēlonis un jāpārveido skripts, lai atbrÄ«votos no izņēmuma vai samazinātu klienta ceļu.

Veicot pasūtījumu no interneta veikala, jāievada piegādes pilsēta. Var izrādīties, ka veikals nevar piegādāt preces uz klienta izvēlēto pilsētu, jo tur nepiegādā, izmēru ierobežojumu dēļ, vai preču trūkuma dēļ attiecīgajā noliktavā.

Ja mēs vienkārÅ”i aprakstam mijiedarbÄ«bas scenāriju reÄ£istrācijas posmā, mēs varam rakstÄ«t ā€œinformējiet klientu, ka piegāde nav iespējama, un piedāvājam mainÄ«t pilsētu vai groza saturuā€ (un daudzi iesācēju analÄ«tiÄ·i apstājas pie tā). Bet, ja Ŕādu gadÄ«jumu ir daudz, tad scenāriju var optimizēt.

Pirmā lieta, kas jums jādara, ir ļaut jums izvēlēties tikai pilsētu, kurā mēs varam piegādāt. Kad tas jādara? Pirms preces izvēles vietnē (pilsētas automātiska noteikÅ”ana caur IP ar precizējumu).

Otrkārt, mums ir jādod iespēja izvēlēties tikai tās preces, kuras varam piegādāt klientam. Kad tas jādara? Izvēles brīdī - uz preces flīzes un preču kartes.

Å Ä«s divas izmaiņas ievērojami palÄ«dz novērst Å”o izņēmumu.

Prasības mērījumiem un metrikām

Apsverot uzdevumu samazināt izņēmumu apstrādi, varat iestatÄ«t ziņoÅ”anas uzdevumu (lietoÅ”anas gadÄ«jums nav aprakstÄ«ts). Cik bija izņēmumu, kādos gadÄ«jumos tie notika, kā arÄ« cik daudz ienākoÅ”o scenāriju veiksmÄ«gi izturēja.

Bet diemžēl. Pieredze rāda, ka ar ziņoÅ”anas prasÄ«bām par scenārijiem Å”ajā formā nepietiek, ir jāņem vērā ziņoÅ”anas prasÄ«bas procesiem, kas aprakstÄ«ti galvenokārt nevis lietoÅ”anas gadÄ«juma veidā.

Piekļuve lietojamībai

Savā praksē esam paplaÅ”inājuÅ”i lietoÅ”anas gadÄ«jumu apraksta formu ar konkrētu entÄ«tiju atribÅ«tu un datu aprakstu, lai klients varētu pieņemt lēmumu, kas uzlabo turpmāko lietojamÄ«bu.

Lietojamības dizainam pievienojām ievades sadaļu - displeja dati.

Scenārijā ar autorizāciju tas ir fakts, ka klients ir autorizēts sistēmā. Ja klients ir iepriekÅ” autorizēts, pēc veiksmÄ«gas autorizācijas parādiet brÄ«dinājumu par navigācijas vēstures un groza pārslēgÅ”anu uz jauno kontu.

Kopumā tas ir klientam nepiecieÅ”amās informācijas attēlojums, lai viņŔ varētu pieņemt lēmumu par savu tālāko rÄ«cÄ«bu pēc scenārija (var jautāt, vai klientam ar Å”iem datiem pietiek, kas vēl vajadzÄ«gs, kāda informācija klientam ir jāpieņem lēmumi).  
IevadÄ«to informāciju ir vērts sadalÄ«t arÄ« ievades laukos, ja tie tiek apstrādāti atseviŔķi un veidojot dažādus izņēmumus.

Piemērā ar klienta autorizāciju, ja ievadÄ«to informāciju sadalāt pieteikumvārdā un parolē, ir vērts mainÄ«t autorizācijas skriptu, lai izceltu atseviŔķa pieteikumvārda un atseviŔķas paroles ievadÄ«Å”anas posmus (un tas tiek darÄ«ts Yandex, Google, bet tas netiek darÄ«ts lielākajā daļā tieÅ”saistes veikalu).

NepiecieŔamo datu transformāciju sasniegŔana

No skripta varat arī iegūt prasības datu konvertēŔanas algoritmiem.

Piemēri:

  • Lai pieņemtu lēmumu par preces iegādi interneta veikalā, klientam preces kartē ir jāzina Ŕīs preces iespēja, cena, piegādes laiks uz savu pilsētu (kas tiek aprēķināti pēc algoritma, pamatojoties uz preces pieejamÄ«bu noliktavas un piegādes ķēdes parametri).
  • Ievadot frāzi meklÄ“Å”anas rindā, klientam tiek parādÄ«ti meklÄ“Å”anas ieteikumi atbilstoÅ”i algoritmam (kurus Ä£enerē algoritms...).

Kopā

Kopumā pēc grāmatas izlasÄ«Å”anas diemžēl nav skaidrs, kā no analÄ«tiÄ·a lÄ«dz biznesa problēmām nonākt lÄ«dz formalizētai izstrādātāja tehniskajai specifikācijai. Grāmatā ir aprakstÄ«ta tikai daļa no procesa, ievades soļi ir neskaidri un nākamie soļi nav skaidri. Pats lietoÅ”anas gadÄ«jums izstrādātājam visbiežāk nav pilnÄ«gs paziņojums.

Tomēr tas ir ļoti labs veids, kā formalizēt un apstrādāt mijiedarbÄ«bas scenārijus starp objektu un subjektu, kad mijiedarbÄ«ba izraisa izmaiņas subjektā. Tā ir viena no nedaudzajām rakstÄ«Å”anas metodēm, kas ļauj pārbaudÄ«t prasÄ«bas ar skaidriem izņēmuma meklÄ“Å”anas punktiem.

Grāmata ir obligāti jāizlasa analītiķiem, lai sāktu rakstīt pārbaudāmas lugas.

Avots: www.habr.com

Pievieno komentāru