სისტემების ფუნქციური მოთხოვნების აღწერის თანამედროვე მეთოდები. ალისტერ კობერნი. წიგნის მიმოხილვა და დამატებები

წიგნში აღწერილია პრობლემის განცხადების ნაწილის ჩაწერის ერთი მეთოდი, კერძოდ გამოყენების შემთხვევის მეთოდი.

რა არის ეს? ეს არის მომხმარებლის ურთიერთქმედების სცენარის აღწერა სისტემასთან (ან ბიზნესთან). ამ შემთხვევაში, სისტემა მოქმედებს როგორც შავი ყუთი (და ეს შესაძლებელს ხდის რთული დიზაინის ამოცანის დაყოფას ურთიერთქმედების დიზაინზე და ამ ურთიერთქმედების უზრუნველყოფას). ამავდროულად, დანერგილია სანოტო სტანდარტები, რაც უზრუნველყოფს კითხვის სიმარტივეს, მათ შორის, არამონაწილეებისთვის და იძლევა გარკვეული შემოწმების შესაძლებლობას დაინტერესებული მხარის მიზნებთან სისრულისა და შესაბამისობის შესახებ.

გამოიყენეთ შემთხვევის მაგალითი

როგორ გამოიყურება სცენარი საიტზე ავტორიზაციის მაგალითის გამოყენებით ელექტრონული ფოსტით:

(სისტემა) შედით საიტზე თქვენს პირად ანგარიშზე წვდომისთვის. ~~ (ზღვის დონე)

კონტექსტი: არაავტორიზებული კლიენტი შედის საიტზე ისე, რომ საიტი ცნობს მას და აჩვენებს მის პერსონალურ ინფორმაციას: დათვალიერების ისტორიას, შესყიდვების ისტორიას, ბონუს ქულების ამჟამინდელ რაოდენობას და ა.შ. 
დონე: მომხმარებლის მიზანი
Მთავარი გმირი: კლიენტი (ჩვენი ონლაინ მაღაზიის სტუმარი)
ფარგლები: კლიენტის ურთიერთქმედება ონლაინ მაღაზიის ვებსაიტთან
დაინტერესებული მხარეები და ინტერესები:

• მარკეტერს სურს საიტის ვიზიტორთა მაქსიმალური რაოდენობის იდენტიფიცირება პირადი გზავნილების მეტი გაშუქებისთვის,
• უსაფრთხოების სპეციალისტს სურს უზრუნველყოს, რომ არ არსებობს ვიზიტორის პერსონალურ მონაცემებზე არასანქცირებული წვდომის შემთხვევები, მათ შორის ერთი ანგარიშის პაროლის გამოცნობის მცდელობები ან სუსტი პაროლით ანგარიშის ძებნა,
• თავდამსხმელს სურს მიიღოს წვდომა მსხვერპლის ბონუსებზე,
• კონკურენტებს სურთ დატოვონ უარყოფითი მიმოხილვები პროდუქტებზე,
• ბოტნეტს სურს მოიპოვოს მაღაზიის მომხმარებელთა ბაზა და გამოიყენოს თავდასხმა საიტის არაფუნქციონირებისთვის.

წინაპირობები: ვიზიტორი არ უნდა იყოს ავტორიზებული.
მინიმალური გარანტიები: ვიზიტორმა გაიგოს ავტორიზაციის მცდელობა წარმატებული იყო თუ წარუმატებელი.
წარმატების გარანტიები: ვიზიტორი უფლებამოსილია.

მთავარი სცენარი:

1. კლიენტი იწყებს ავტორიზაციას.
2. სისტემა ადასტურებს, რომ კლიენტი არ არის ავტორიზებული და არ აღემატება წარუმატებელი ავტორიზაციის მცდელობების რაოდენობას მოცემული სესიიდან (სუსტი პაროლის ძიება მრავალი ანგარიშისთვის) „უსაფრთხოების წესი No23“ შესაბამისად.
3. სისტემა ზრდის ავტორიზაციის მცდელობების მრიცხველს.
4. სისტემა კლიენტს უჩვენებს ავტორიზაციის ფორმას.
5. კლიენტი შეაქვს მის ელფოსტას და პაროლს.
6. სისტემა ადასტურებს კლიენტის არსებობას ასეთი ელექტრონული ფოსტით სისტემაში და რომ პაროლი ემთხვევა და ამ ანგარიშზე შესვლის მცდელობების რაოდენობა არ არის გადაჭარბებული „უსაფრთხოების წესი No24“-ის მიხედვით.
7. სისტემა აძლევს კლიენტს ავტორიზაციას, ამატებს დათვალიერების ისტორიას და ამ სესიის კალათს ამ კლიენტის ანგარიშის ბოლო სესიასთან.
8. სისტემა აჩვენებს ავტორიზაციის წარმატების შეტყობინებას და გადადის სკრიპტის საფეხურზე, საიდანაც კლიენტი შეწყდა ავტორიზაციისთვის. ამ შემთხვევაში, გვერდის მონაცემები ხელახლა იტვირთება პირადი ანგარიშის მონაცემების გათვალისწინებით.

გაფართოებები:
2.ა. კლიენტი უკვე ავტორიზებულია:
 2.a.1. სისტემა აცნობებს კლიენტს ადრე შესრულებული ავტორიზაციის ფაქტს და სთავაზობს ან შეწყვიტოს სკრიპტი ან გადავიდეს მე-4 საფეხურზე, ხოლო თუ ნაბიჯი 6 წარმატებით დასრულდა, მაშინ ნაბიჯი 7 შესრულებულია განმარტებით:
 2.a.7. სისტემა ახდენს კლიენტის დეაქტორიზაციას ძველი ანგარიშით, ავტორიზაციას აძლევს კლიენტს ახალი ანგარიშით, ხოლო ამ ინტერაქციის სესიის დათვალიერების ისტორია და კალათა რჩება ძველ ანგარიშში და არ გადადის ახალზე. შემდეგი, გადადით მე-8 საფეხურზე.
2.ბ ავტორიზაციის მცდელობების რაოდენობამ გადააჭარბა ზღვარს „უსაფრთხოების წესი No23“-ის მიხედვით:
 2.b.1 გადადით მე-4 საფეხურზე, captcha დამატებით გამოჩნდება ავტორიზაციის ფორმაზე
 2.b.6 სისტემა ადასტურებს კაპჩას სწორ შეყვანას
    2.b.6.1 არასწორად შეყვანილი Captcha:
      2.ბ.6.1.1. სისტემა ზრდის ავტორიზაციის წარუმატებელი მცდელობების მრიცხველს ამ ანგარიშისთვისაც
      2.ბ.6.1.2. სისტემა აჩვენებს წარუმატებლობის შეტყობინებას და უბრუნდება მე-2 საფეხურს
6.ა. ამ ელფოსტით ანგარიში ვერ მოიძებნა:
 6.a.1 სისტემა აჩვენებს შეტყობინებას წარუმატებლობის შესახებ და გთავაზობთ არჩევანს, გადახვიდეთ მე-2 საფეხურზე ან გადახვიდეთ „მომხმარებლის რეგისტრაციის“ სცენარზე და შეინახოთ შეყვანილი ელ.წერილი,
6.ბ. ამ ელფოსტის ანგარიშის პაროლი არ ემთხვევა შეყვანილს:
 6.ბ.1 სისტემა ზრდის ამ ანგარიშზე შესვლის წარუმატებელი მცდელობების მრიცხველს.
 6.ბ.2 სისტემა აჩვენებს შეტყობინებას წარუმატებლობის შესახებ და გთავაზობთ არჩევანს, გადახვიდეთ „პაროლის აღდგენის“ სცენარზე ან გადახვიდეთ მე-2 საფეხურზე.
6.c: ამ ანგარიშისთვის შესვლის მცდელობის მრიცხველმა გადააჭარბა „უსაფრთხოების წესი No. 24“-ის ზღვარს.
 6.c.1 სისტემა აჩვენებს შეტყობინებას ანგარიშის შესვლის X წუთის განმავლობაში დაბლოკვის შესახებ და გადადის მე-2 საფეხურზე.

რა კარგია

ამოწმებს სისრულესა და მიზნებთან შესაბამისობას, ანუ თქვენ შეგიძლიათ სხვა ანალიტიკოსს მიაწოდოთ მოთხოვნები გადამოწმებისთვის, პრობლემის ფორმულირების ეტაპზე ნაკლები შეცდომის დაშვებით.

შავი ყუთის სისტემასთან მუშაობა საშუალებას გაძლევთ განასხვავოთ შემუშავება და მომხმარებელთან კოორდინაცია, თუ რა იქნება ავტომატიზირებული განხორციელების მეთოდებისგან.

ეს არის ანალიტიკოსის გზის ნაწილი, გამოყენებადობის ერთ-ერთი მთავარი ნაწილი. მომხმარებლის სცენარი განსაზღვრავს მისი მოძრაობის ძირითად გზებს, რაც მნიშვნელოვნად ამცირებს არჩევანის თავისუფლებას დიზაინერისა და მომხმარებლისთვის და ხელს უწყობს დიზაინის განვითარების სიჩქარის გაზრდას.

მე ძალიან კმაყოფილი ვარ აღწერილობის ადგილით, სადაც გამონაკლისებია გამოვლენილი თითოეული ურთიერთქმედების საფეხურიდან. სრულმა IT სისტემამ უნდა უზრუნველყოს რაიმე სახის გამონაკლისების მართვა, ზოგი ხელით, ზოგი ავტომატურად (როგორც ზემოთ მოცემულ მაგალითში).

გამოცდილება გვიჩვენებს, რომ არასწორად მოფიქრებულმა გამონაკლისმა შეიძლება ადვილად გადააქციოს სისტემა საშინლად მოუხერხებელ სისტემად. მახსოვს ისტორია, როცა საბჭოთა დროს, გადაწყვეტილების მისაღებად, სხვადასხვა სერვისებიდან რამდენიმე მოწონება მოგიწია და რა მტკივნეულია, როცა ბოლო სამსახურში წერია - მაგრამ შენი განცხადება არასწორი სახელია ან სხვა შეცდომა. პუნქტუაცია, ყველაფერი ხელახლა გააკეთე და ყველაფერი ხელახლა კოორდინაცია.

ხშირად ვხვდები სიტუაციებს, როდესაც სისტემის მუშაობის ლოგიკა, რომელიც არ იყო გააზრებული გამონაკლისებისთვის, მოითხოვდა სისტემის მნიშვნელოვან გადამუშავებას. ამის გამო, ანალიტიკოსის მუშაობის ლომის წილი იხარჯება გამონაკლისების დამუშავებაზე.

ტექსტის აღნიშვნა, დიაგრამებისგან განსხვავებით, იძლევა მეტი გამონაკლისის იდენტიფიცირებისა და დაფარვის საშუალებას.

მეთოდის დამატება პრაქტიკიდან

გამოყენების შემთხვევა არ არის განცხადების დამოუკიდებლად პრიორიტეტული ნაწილი, მომხმარებლის ამბავისგან განსხვავებით.

ზემოაღნიშნულ სცენარში განიხილეთ გამონაკლისი „6.a. ამ ელფოსტით ანგარიში არ მოიძებნა.” და შემდეგი ნაბიჯი „6.a.1 სისტემა აჩვენებს წარუმატებლობის შეტყობინებას და გადადის მე-2 საფეხურზე“. რა უარყოფითი რამ დარჩა კულისებში? კლიენტისთვის, ნებისმიერი დაბრუნება უდრის იმ ფაქტს, რომ ყველა სამუშაო, რომელიც მან გააკეთა მონაცემების შეყვანისას, გადაყრილია ნაგავსაყრელზე. (ეს უბრალოდ სკრიპტში არ ჩანს!) რა შეიძლება გაკეთდეს? აღადგინეთ სკრიპტი ისე, რომ ეს არ მოხდეს. შესაძლებელია თუ არა ამის გაკეთება? შეგიძლიათ - მაგალითად, გადახედოთ Google-ის ავტორიზაციის სკრიპტს.

სცენარის ოპტიმიზაცია

წიგნში საუბარია ფორმალიზაციაზე, მაგრამ ცოტა რამ არის ნათქვამი ასეთი სცენარის ოპტიმიზაციის მეთოდებზე.

მაგრამ მეთოდის გაძლიერება შესაძლებელია სცენარების ოპტიმიზაციის გზით და გამოყენების შემთხვევების ფორმალიზაციის მეთოდი ამის საშუალებას იძლევა. კონკრეტულად, თქვენ უნდა იფიქროთ თითოეულ გამონაკლისზე, რაც ხდება, დაადგინოთ მიზეზი და აღადგინოთ სკრიპტი ისე, რომ თავიდან აიცილოთ გამონაკლისი ან მინიმუმამდე დაიყვანოთ მომხმარებლის მოგზაურობა.

ონლაინ მაღაზიიდან შეკვეთის განთავსებისას უნდა შეიყვანოთ მიწოდების ქალაქი. შეიძლება აღმოჩნდეს, რომ მაღაზიას არ შეუძლია საქონლის მიწოდება კლიენტის მიერ არჩეულ ქალაქში, რადგან არ აწვდის იქ, ზომების შეზღუდვის გამო, ან შესაბამის საწყობში საქონლის ნაკლებობის გამო.

თუ უბრალოდ აღვწერთ ურთიერთქმედების სცენარს რეგისტრაციის ეტაპზე, შეგვიძლია დავწეროთ „აცნობეთ კლიენტს, რომ მიწოდება შეუძლებელია და შევთავაზოთ ქალაქის ან კალათის შიგთავსის შეცვლა“ (და ბევრი დამწყები ანალიტიკოსი აქ ჩერდება). მაგრამ თუ ასეთი შემთხვევები ბევრია, მაშინ შესაძლებელია სცენარის ოპტიმიზაცია.

პირველი, რაც უნდა გააკეთოთ, არის უფლება აირჩიოთ მხოლოდ ქალაქი, სადაც ჩვენ შეგვიძლია მიწოდება. როდის უნდა გავაკეთოთ ეს? პროდუქტის არჩევამდე ვებგვერდზე (ქალაქის ავტომატური აღმოჩენა IP-ის საშუალებით დაზუსტებით).

მეორეც, ჩვენ უნდა მივცეთ არჩევანი მხოლოდ იმ საქონელზე, რომელიც შეგვიძლია მივაწოდოთ კლიენტს. როდის უნდა გავაკეთოთ ეს? შერჩევის მომენტში - პროდუქტის ფილაზე და პროდუქტის ბარათზე.

ეს ორი ცვლილება დიდ გზას ადგას ამ გამონაკლისის აღმოფხვრისკენ.

მოთხოვნები გაზომვებისა და მეტრიკის მიმართ

გამონაკლისების დამუშავების მინიმიზაციის ამოცანის განხილვისას, შეგიძლიათ დააყენოთ საანგარიშო დავალება (გამოყენების შემთხვევა არ არის აღწერილი). რამდენი გამონაკლისი იყო, რა შემთხვევებში მოხდა, პლუს რამდენი შემომავალი სცენარი წარმატებით ჩაიარა.

მაგრამ ვაი. გამოცდილებამ აჩვენა, რომ ამ ფორმით სცენარების მოხსენების მოთხოვნები არ არის საკმარისი; აუცილებელია განიხილოს მოხსენების მოთხოვნები იმ პროცესებზე, რომლებიც ძირითადად აღწერილია არა გამოყენების შემთხვევის სახით.

გამოყენებადობაზე წვდომა

ჩვენს პრაქტიკაში, ჩვენ გავაფართოვეთ გამოყენების შემთხვევის აღწერის ფორმა ერთეულების სპეციფიკური ატრიბუტებისა და მონაცემების აღწერით, რათა კლიენტმა მიიღო გადაწყვეტილება, რაც აძლიერებს შემდგომ გამოყენებადობას.

გამოყენებადობის დიზაინისთვის, ჩვენ დავამატეთ შეყვანის განყოფილება - მონაცემების ჩვენება.

ავტორიზაციის სცენარში, ეს არის ის ფაქტი, რომ კლიენტი ავტორიზებულია სისტემაში. თუ კლიენტი წინასწარ არის ავტორიზებული, მაშინ აჩვენეთ გაფრთხილება ნავიგაციის ისტორიისა და კალათის ახალ ანგარიშზე გადართვის შესახებ წარმატებული ავტორიზაციის შემდეგ.

ზოგადად, ეს არის კლიენტისთვის საჭირო ინფორმაციის ჩვენება, რათა მან შეძლოს გადაწყვეტილების მიღება მისი შემდგომი ქმედებების შესახებ სცენარის მიხედვით (შეგიძლიათ იკითხოთ, საკმარისია თუ არა ეს მონაცემები კლიენტისთვის, კიდევ რა არის საჭირო, რა ინფორმაციას აკეთებს კლიენტმა უნდა მიიღოს გადაწყვეტილებები).  
ასევე ღირს შეყვანილი ინფორმაციის დაყოფა შეყვანის ველებად, თუ ისინი დამუშავდება ცალკე და სხვადასხვა გამონაკლისების ფორმირებით.

კლიენტის ავტორიზაციის მაგალითში, თუ შეყვანილ ინფორმაციას გამოყოფთ ლოგინში და პაროლში, მაშინ ღირს ავტორიზაციის სკრიპტის შეცვლა, რათა ხაზი გავუსვა ცალკე შესვლისა და ცალკე პაროლის შეყვანის ეტაპებს (და ეს გაკეთდა Yandex-ში, Google-ში, მაგრამ არ კეთდება უმეტეს ონლაინ მაღაზიებში).

მონაცემთა საჭირო ტრანსფორმაციების მიღწევა

თქვენ ასევე შეგიძლიათ ამოიღოთ მოთხოვნები მონაცემთა კონვერტაციის ალგორითმებისთვის სკრიპტიდან.

მაგალითები:

• ონლაინ მაღაზიაში პროდუქტის შეძენის გადაწყვეტილების მისაღებად, კლიენტმა უნდა იცოდეს პროდუქტის ბარათზე ამ პროდუქტის შესაძლებლობა, ღირებულება, მიწოდების დრო თავის ქალაქში (რომლებიც გამოითვლება ალგორითმის მიხედვით, პროდუქტის ხელმისაწვდომობაზე საწყობები და მიწოდების ჯაჭვის პარამეტრები).
• საძიებო ხაზში ფრაზის შეყვანისას კლიენტს ეჩვენება საძიებო წინადადებები ალგორითმის მიხედვით (რომლებიც გენერირებულია ალგორითმის მიერ...).

საერთო ჯამში

ზოგადად, წიგნის წაკითხვის შემდეგ, სამწუხაროდ, გაუგებარია, თუ როგორ უნდა გაიაროს მთელი გზა ანალიტიკოსიდან ბიზნეს პრობლემებამდე, დეველოპერის ოფიციალურ ტექნიკურ სპეციფიკაციამდე. წიგნში აღწერილია პროცესის მხოლოდ ნაწილი, შეყვანის საფეხურები გაურკვეველია და შემდეგი ნაბიჯები გაურკვეველი. თავად გამოყენების შემთხვევა ხშირად არ არის სრული განცხადება დეველოპერისთვის.

მიუხედავად ამისა, ეს არის ძალიან კარგი გზა ობიექტსა და სუბიექტს შორის ურთიერთქმედების სცენარების ფორმალიზებისა და დამუშავებისთვის, როდესაც ურთიერთქმედება იწვევს საგნის რაღაცის ცვლილებას. ეს არის წერის ერთ-ერთი იმ რამდენიმე მეთოდიდან, რომელიც საშუალებას იძლევა გადამოწმებადი მოთხოვნების გამონაკლისის ძებნის პუნქტები.

წიგნი აუცილებლად წასაკითხია ანალიტიკოსებისთვის, რათა დაიწყონ ტესტირებადი პიესების წერა.

წყარო: www.habr.com