მობილური აპლიკაციის მოთხოვნების ჩეკლისტი ბიზნესისთვის

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

რა არის მობილური აპლიკაციის მოთხოვნების ჩეკლისტი?

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

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

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

რომელი მოთხოვნები უნდა შევიდეს დოკუმენტში?

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

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

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

როდის სჭირდება ბიზნესს დეტალური მოთხოვნების დოკუმენტი?

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

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

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

როგორ ცვლის ჩეკლისტი რეალურ aiAPP-ის მოცულობას?

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

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

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

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

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

როგორ შევადგინოთ მობილური აპლიკაციის მოთხოვნების ჩეკლისტი?

1. ესაუბრეთ პროცესის მფლობელს. ჩაიწერეთ მიმდინარე მოქმედება, შეფერხება, გამონაკლისი და პასუხისმგებელი პირი.
2. აირჩიეთ პირველი სასარგებლო გზა. ერთი მომხმარებლის მიზანი შესვლიდან დადასტურებულ შედეგამდე სრულად მიიყვანეთ.
3. დახაზეთ ეკრანებისა და მდგომარეობების მოძრაობა. შეიტანეთ ცარიელი, ჩატვირთვის, ინტერნეტის გათიშვის, ნებართვის უარყოფისა და წარუმატებელი კავშირის შემთხვევები.
4. აღწერეთ მონაცემები და უფლებები. მიუთითეთ დანიშნულება, წვდომა, შენახვა, წაშლა და გარე მხარის მიერ დამუშავება.
5. განსაზღვრეთ კავშირების პირობები. დაწერეთ მიმართულება, ავტორიზაციის მფლობელი, ლოდინის ზღვარი, განმეორებითი ცდა, დუბლირების მართვა და ხელით შესასრულებელი სათადარიგო ნაბიჯი.
6. ჩამოაყალიბეთ მიღების მტკიცებულება. თითოეულ მნიშვნელოვან მოთხოვნას დაუკავშირეთ ტესტი, მოსალოდნელი პასუხი, შესანახი მასალა და დამტკიცებაზე პასუხისმგებელი პირი.
7. დააფიქსირეთ გადაცემის მფლობელობა. ჩამოწერეთ ყველა ანგარიში, კოდის საცავი, საბუთი და საოპერაციო როლი, რომელიც ბიზნესს გადაეცემა.

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

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

რომელი შეცდომები ასუსტებს მოთხოვნების დოკუმენტს?

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

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

რა შეზღუდვები აქვს მოთხოვნების ჩეკლისტს?

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

დოკუმენტი App Store-ის ან Google Play-ის თანხმობას ვერ უზრუნველყოფს. განხილვის პროცესებს Apple-ი და Google-ი მართავენ. კომპანიებს წესის შეცვლა ან დამატებითი მტკიცებულების მოთხოვნა შეუძლიათ. ზუსტი ჩაბარების თარიღიც ვერ დამტკიცდება, თუ გარე მომწოდებლის პასუხი, ავტორიზაციის მონაცემები ან შესაბამისობის გადაწყვეტილება ჯერ უცნობია.

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

დაკავშირებული გზამკვლევები

• aiAPP-ის სამუშაო ფორმატი და ფასები
• მობილური აპლიკაციის კავშირები
• უსაფრთხოების მიდგომა
• კონფიდენციალურობის პირობები
• პროექტის განხილვა aiAPP-ის გუნდთან

ხშირად დასმული კითხვები

უნდა დაწეროს თუ არა ბიზნესმა ტექნიკური დავალება პროგრამისტთან საუბრამდე?

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

საკმარისია თუ არა პროტოტიპი მობილური აპლიკაციის აწყობის დასამტკიცებლად?

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

ვინ უნდა დაამტკიცოს მოთხოვნების დოკუმენტი?

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

რა უნდა მიიღოს ბიზნესმა პროექტის გადაცემისას?

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