Kitab problem bəyanatının bir hissəsini yazmaq üçün bir üsul, yəni istifadə nümunəsi metodunu təsvir edir.
Bu nədir? Bu, istifadəçinin sistemlə (və ya bizneslə) qarşılıqlı əlaqəsi ssenarisinin təsviridir. Bu halda sistem qara qutu kimi çıxış edir (və bu, mürəkkəb dizayn tapşırığını qarşılıqlı əlaqənin layihələndirilməsinə və bu qarşılıqlı əlaqənin təmin edilməsinə bölməyə imkan verir). Eyni zamanda, qeyri-iştirakçılar üçün də daxil olmaqla, oxumağın asanlığını təmin edən və maraqlı tərəfin məqsədlərinə tamlıq və uyğunluq üçün bəzi yoxlamalara imkan verən qeyd standartları tətbiq olunur.
İstifadə nümunəsi
E-poçt vasitəsilə saytda avtorizasiya nümunəsindən istifadə edərək, ssenari necə görünür:
(Sistem) Şəxsi hesabınıza daxil olmaq üçün vebsayta daxil olun. ~~ (dəniz səviyyəsi)
Kontekst: İcazəsiz müştəri sayta daxil olur ki, sayt onu tanısın və onun üçün şəxsi məlumatı göstərsin: giriş kimi e-poçtdan istifadə edərək baxış tarixçəsi, alış tarixçəsi, bonus xallarının cari sayı və s.
Səviyyə: istifadəçi məqsədi
Əsas xarakter: müştəri (onlayn mağazamızın ziyarətçisi)
Əhatə dairəsi: Müştərilərin onlayn mağaza veb saytı ilə qarşılıqlı əlaqəsi
Maraqlı tərəflər və maraqlar:
- marketoloq şəxsi göndərişləri daha çox əhatə etmək üçün sayt ziyarətçilərinin maksimum sayının müəyyən edilməsini istəyir,
- təhlükəsizlik mütəxəssisi ziyarətçinin şəxsi məlumatlarına icazəsiz giriş hallarının, o cümlədən bir hesabın parolunu təxmin etmək və ya zəif parolu olan hesabı axtarmaq cəhdlərinin olmamasını təmin etmək istəyir;
- təcavüzkar qurbanın bonuslarına giriş əldə etmək istəyir,
- rəqiblər məhsullar haqqında mənfi rəylər buraxmaq istəyirlər,
- Botnet mağazanın müştəri bazasını əldə etmək və saytı işlək etmək üçün hücumdan istifadə etmək istəyir.
İlkin şərtlər: ziyarətçiyə icazə verilməməlidir.
Minimum zəmanətlər: ziyarətçi avtorizasiya cəhdinin uğurlu və ya uğursuz olduğunu biləcək.
Uğur zəmanətləri: ziyarətçiyə icazə verilir.
Əsas ssenari:
- Müştəri avtorizasiyaya başlayır.
- Sistem müştərinin avtorizasiya olunmadığını təsdiq edir və “Təhlükəsizlik Qaydası №23”ə uyğun olaraq verilmiş seansdan (birdən çox hesab üçün zəif parolun axtarışı) uğursuz avtorizasiya cəhdlərinin sayını aşmır.
- Sistem avtorizasiya cəhdlərinin sayı üçün sayğacı artırır.
- Sistem müştəriyə icazə formasını göstərir.
- Müştəri e-poçtunu və şifrəsini daxil edir.
- Sistem sistemdə belə bir e-poçtu olan müştərinin olmasını və parolun uyğun olduğunu və bu hesaba giriş cəhdlərinin sayının “24 nömrəli Təhlükəsizlik Qaydası”na uyğun olaraq keçmədiyini təsdiqləyir.
- Sistem müştəriyə icazə verir, baxış tarixçəsini və bu sessiyanın səbətini bu müştəri hesabının son sessiyasına əlavə edir.
- Sistem avtorizasiya müvəffəqiyyəti mesajını göstərir və müştərinin avtorizasiya üçün dayandırıldığı skript addımına keçir. Bu halda, səhifədəki məlumatlar şəxsi hesab məlumatları nəzərə alınmaqla yenidən yüklənir.
Genişləndiricilər:
2.a. Müştəri artıq səlahiyyətlidir:
2.a.1. Sistem müştərini əvvəllər yerinə yetirilmiş avtorizasiya faktı barədə məlumatlandırır və ya skripti dayandırmağı, ya da 4-cü addıma keçməyi təklif edir və 6-cı addım uğurla tamamlanarsa, 7-ci addım aydınlaşdırma ilə yerinə yetirilir:
2.a.7. Sistem köhnə hesab üzrə müştərini deaktorasiya edir, yeni hesab üzrə müştəriyə avtorizasiya edir, eyni zamanda bu qarşılıqlı əlaqə sessiyasının baxış tarixçəsi və səbəti köhnə hesabda qalır və yeni hesaba köçürmür. Sonra 8-ci addıma keçin.
2.b “Təhlükəsizlik Qaydası № 23”ə uyğun olaraq icazə cəhdlərinin sayı həddi keçib:
2.b.1 4-cü addıma keçin, icazə formasında captcha əlavə olaraq göstərilir
2.b.6 Sistem düzgün captcha girişini təsdiq edir
2.b.6.1 Captcha səhv daxil edilib:
2.b.6.1.1. sistem bu hesab üçün də uğursuz avtorizasiya cəhdlərinin sayğacını artırır
2.b.6.1.2. sistem uğursuzluq mesajı göstərir və 2-ci addıma qayıdır
6.a. Bu e-poçtla heç bir hesab tapılmadı:
6.a.1 Sistem uğursuzluq barədə mesaj göstərir və ya 2-ci addıma keçmək, ya da “İstifadəçi Qeydiyyatı” ssenarisinə keçmək və daxil edilmiş e-poçtu saxlamaq seçimi təklif edir,
6.b. Bu e-poçtla hesab üçün parol daxil edilmiş parolla uyğun gəlmir:
6.b.1 Sistem bu hesaba uğursuz giriş cəhdlərinin sayğacını artırır.
6.b.2 Sistem uğursuzluq haqqında mesaj göstərir və ya “Parolun Bərpası” ssenarisinə keçmək, ya da 2-ci addıma keçmək seçimi təklif edir.
6.c: Bu hesab üçün giriş cəhdi sayğacı “Təhlükəsizlik Qaydası №24” həddi keçib.
6.c.1 Sistem X dəqiqə ərzində hesaba girişin bloklanması haqqında mesaj göstərir və 2-ci addıma keçir.
Nə gözəl
Tamlığı və məqsədlərə uyğunluğu yoxlayır, yəni problemin formalaşdırılması mərhələsində daha az səhv edərək yoxlama üçün başqa bir analitikə tələblər verə bilərsiniz.
Qara qutu sistemi ilə işləmək avtomatlaşdırılacaq işlərin müştəri ilə işlənməsini və əlaqələndirilməsini həyata keçirmə üsullarından ayırmağa imkan verir.
Bu, analitik yolunun bir hissəsidir, istifadənin əsas hissələrindən biridir. İstifadəçinin ssenarisi onun hərəkətinin əsas yollarını müəyyən edir ki, bu da dizayner və müştəri üçün seçim azadlığını xeyli azaldır və dizaynın işlənib hazırlanması sürətini artırmağa kömək edir.
Təsvirdə hər bir qarşılıqlı əlaqə addımı üçün istisnaların müəyyən edildiyi yerdən çox məmnunam. Tam İT sistemi bəzi istisnaların idarə edilməsini təmin etməlidir, bəziləri əl ilə, bəziləri avtomatik (yuxarıdakı nümunədə olduğu kimi).
Təcrübə göstərir ki, düzgün düşünülməmiş istisnaların idarə edilməsi sistemi asanlıqla olduqca əlverişsiz bir sistemə çevirə bilər. Hekayəni xatırlayıram ki, sovet dövründə qərar qəbul etmək üçün müxtəlif xidmətlərdən bir neçə razılıq almalı idin və sonuncu xidmətin deməsi nə qədər ağrılı olur - amma ərizənin adı səhvdir və ya başqa bir səhvdir. durğu işarələri, hər şeyi yenidən düzəldin və hər şeyi yenidən əlaqələndirin.
İstisnalar üçün düşünülməmiş sistemin işləmə məntiqinin sistemin əhəmiyyətli dərəcədə yenidən işlənməsini tələb etdiyi vəziyyətlərlə tez-tez rastlaşıram. Buna görə də, analitik işinin aslan payı istisnaların idarə edilməsinə sərf olunur.
Diaqramlardan fərqli olaraq mətn notasiyası daha çox istisnaları müəyyən etməyə və əhatə etməyə imkan verir.
Təcrübədən metoda əlavə
İstifadə nümunəsi, istifadəçi hekayəsindən fərqli olaraq, bəyanatın müstəqil olaraq prioritetləşdirilmiş hissəsi deyil.
Yuxarıdakı ssenaridə “6.a. Bu e-poçtla heç bir hesab tapılmadı.” və növbəti addım “6.a.1 Sistem uğursuzluq mesajı göstərir və 2-ci addıma keçir.” Pərdə arxasında hansı mənfi şeylər qaldı? Müştəri üçün hər hansı bir qayıdış onun məlumat daxil etməklə gördüyü bütün işlərin poliqona atılmasına bərabərdir. (Bu, sadəcə skriptdə görünmür!) Nə etmək olar? Bunun baş verməməsi üçün skripti yenidən qurun. Bunu etmək mümkündürmü? Məsələn, Google avtorizasiya skriptinə baxa bilərsiniz.
Ssenari optimallaşdırılması
Kitab rəsmiləşdirmədən bəhs edir, lakin bu cür ssenarilərin optimallaşdırılması üsulları haqqında az danışır.
Amma ssenariləri optimallaşdırmaqla metodu gücləndirmək mümkündür və istifadə halının rəsmiləşdirilməsi üsulu bunu etməyə imkan verir. Xüsusilə, istisnadan xilas olmaq və ya müştəri səyahətini minimuma endirmək üçün baş verən hər bir istisna haqqında düşünməli, səbəbini müəyyənləşdirməli və skripti yenidən qurmalısınız.
Onlayn mağazadan sifariş verərkən çatdırılma şəhərini daxil etməlisiniz. Belə çıxa bilər ki, mağaza müştərinin seçdiyi şəhərə mal çatdıra bilmir, çünki oraya çatdırmır, ölçü məhdudiyyəti səbəbindən və ya müvafiq anbarda mal yoxdur.
Qeydiyyat mərhələsində qarşılıqlı əlaqə ssenarisini sadəcə təsvir etsək, “müştəriyə çatdırılmanın qeyri-mümkün olduğunu bildirin və şəhəri və ya arabanın məzmununu dəyişdirməyi təklif edin” (və bir çox təcrübəsiz analitiklər orada dayanır) yaza bilərik. Ancaq belə hallar çox olarsa, o zaman ssenari optimallaşdırıla bilər.
Etməyiniz lazım olan ilk şey yalnız çatdıra biləcəyimiz şəhəri seçməyinizə icazə verməkdir. Bunu nə vaxt etməli? Veb saytında məhsul seçməzdən əvvəl (aydınlaşdırma ilə IP vasitəsilə şəhərin avtomatik aşkarlanması).
İkincisi, biz yalnız müştəriyə çatdıra biləcəyimiz mallardan seçim verməliyik. Bunu nə vaxt etməli? Seçim anında - məhsulun kafelində və məhsul kartında.
Bu iki dəyişiklik bu istisnanın aradan qaldırılması istiqamətində uzun bir yol qət edir.
Ölçmə və ölçülərə dair tələblər
İstisna hallarını minimuma endirmək tapşırığını nəzərdən keçirərkən, hesabat tapşırığı təyin edə bilərsiniz (istifadə halı təsvir edilmir). Nə qədər istisnalar var idi, hansı hallarda baş verdi, üstəlik neçə gələn ssenari uğurla keçdi.
Amma heyif. Təcrübə göstərir ki, bu formada ssenarilər üçün hesabat tələbləri kifayət deyil, əsasən istifadə halı şəklində olmayan proseslər üçün hesabat tələblərini nəzərə almaq lazımdır.
İstifadəyə giriş
Təcrübəmizdə biz müştərinin qərar qəbul etməsi üçün obyektlərin xüsusi atributlarının və məlumatların təsviri ilə istifadə halının təsviri formasını genişləndirmişik ki, bu da sonrakı istifadə imkanlarını artırır.
İstifadəyə uyğun dizayn üçün biz bir giriş bölməsi əlavə etdik - məlumatları göstərin.
Səlahiyyətli bir ssenaridə bu, müştərinin sistemdə səlahiyyətli olması faktıdır. Müştəri əvvəlcədən icazə alıbsa, uğurlu avtorizasiyadan sonra naviqasiya tarixçəsini və səbəti yeni hesaba köçürmək barədə xəbərdarlıq göstərin.
Ümumiyyətlə, bu, müştəri üçün lazım olan məlumatların nümayişidir ki, o, ssenariyə uyğun olaraq sonrakı hərəkətləri barədə qərar qəbul edə bilsin (bu məlumatların müştəri üçün kifayət olub-olmadığını soruşa bilərsiniz, başqa nə lazımdır, nə məlumat verir? müştəri qərar qəbul etməlidir).
Daxil edilmiş məlumatları ayrı-ayrılıqda və müxtəlif istisnaların formalaşması ilə işlənirsə, giriş sahələrinə bölməyə dəyər.
Müştəri icazəsi ilə nümunədə, daxil edilmiş məlumatları giriş və şifrə ilə ayırsanız, ayrıca giriş və ayrıca parol daxil etmə mərhələlərini vurğulamaq üçün avtorizasiya skriptini dəyişdirməyə dəyər (və bu Yandex, Google-da edilir, lakin əksər onlayn mağazalarda edilmir).
Lazımi məlumat çevrilmələrinə çatmaq
Siz həmçinin verilənlərin çevrilməsi alqoritmləri üçün tələbləri skriptdən çıxara bilərsiniz.
Nümunələr:
- Onlayn mağazada məhsul almaq qərarına gəlmək üçün müştəri məhsul kartında bu məhsulun mümkünlüyünü, dəyərini, onun şəhərinə çatdırılma müddətini bilməlidir (bunlar məhsulun mövcudluğu əsasında alqoritmlə hesablanır). anbarlar və təchizat zəncirinin parametrləri).
- Axtarış xəttinə söz daxil edilərkən müştəriyə alqoritmə uyğun axtarış təklifləri göstərilir (onlar alqoritm tərəfindən yaradılır...).
Ümumi
Ümumiyyətlə, kitabı oxuduqdan sonra, təəssüf ki, bir analitikdən biznes problemlərinə, bir tərtibatçı üçün rəsmiləşdirilmiş texniki spesifikasiyaya qədər bütün yolu necə keçmək aydın deyil. Kitab prosesin yalnız bir hissəsini izah edir, giriş addımları aydın deyil və sonrakı addımlar aydın deyil. İstifadə halının özü çox vaxt tərtibatçı üçün tam ifadə deyil.
Buna baxmayaraq, bu, qarşılıqlı əlaqə subyektdə bir şeyin dəyişməsinə səbəb olduqda, obyekt və subyekt arasında qarşılıqlı əlaqə ssenarilərini rəsmiləşdirmək və emal etmək üçün çox yaxşı bir yoldur. Bu, açıq istisna axtarış nöqtələri ilə yoxlanıla bilən tələblərə imkan verən bir neçə yazı metodundan biridir.
Kitab analitiklərin sınaqdan keçirilə bilən pyeslər yazmağa başlaması üçün mütləq oxunmalıdır.
Mənbə: www.habr.com