Өтініш анализі үрдісінің схемасы

1. «Тапсырыс берушіні» идентификациялау. Қызығушылық танынатын тұлғаларды анықтау, яғни, қортындылаушы өнімде өзіне тиесілі бөлігі бар тұлғалар;

2. Тапсырыс беруші өкілдерімен сұхбат ұйымдастыру. Яғни олардың:

   • талғамы мен қажеттілігін анықтау;

   • Қолдау құралдарын пайдалану;

   • Пайдаланушының графикалық интерфейсін нобайын жасау;

   • Жабдықтың конструкциясын анықтау;

3. С-талабын стандартты құжат формасында жазу.

4. С-талабын тексеру;

5. В-талабын құру;

Барлық этаптар үшін келесі куәліктерді қадағалау керек:

• Жұмсалған уақыт;

• С-талабының беттер саны;

• Тапсырыс берушімен сөйлесуге кеткен уақыт мөлшері;

• Сапасын өзіндік бағалау;

• Тексеру жайында кемшіліктерді бағалау;

SPS-ті ұйымдастырудың бірнеше тәсілдері бар. IEEE830-1993 стандартының тарауы берілген:

1. Кіріспе

   0. Мақсаты

   1. Қолдану аймағы

   2. Анықталуы, терминдер мен қысқартулар

   3. Сілтеме

   4. Шолу

2. Жалпы сипатталуы

   0. Өнімнің перспективасы

      0. Жүйелік интерфейстер

      1. Пайдаланушы интерфейстер

      2. Аппараттық интерфейтер

      3. Программалық интерфейстер

      4. Коммуникациялық интерфейтер

      5. Жады бойынша шектеулер

      6. Операциялар

      7. Бейімделу бойынша өтініш

   1. Өнім функциясы

   2. Пайдаланушы сипаттамалары

   3. Шектеулер

   4. Болжамдар мен тәуелділіктер

   5. Өтініштердің бөлінуі

3. Толық қанды өтініштер

4. Ақпаратты сүйемелдеу

IEEЕ стандартының артықшылығы, ол әртүрлі жағдайларда қолдануға болатын мәселелерді шеше алады.

Өтініш анализін контекстте қарау керек. Себебі:

• Өтініш туындауының себепшісі адамдар екені даусыз

• өтініш беруде әр тапсырыс берушінің талабы дара сипатталады

• жасаушылар өтініштерге түбегейлі ықпал ететін кәсіби жауапкершілікті арқалайды;

• тапсырыс берушінің қалауынан гөрі мұқтаждығын анықтау қиынырақ;

• өтініш анализінің басым бөлігі анағұрлым жақты нәтижеге қол жеткізу мақсатында мұқият ұйымдастырылған коммуникативтік қызмет атқарады.

Өтініш анализі кезінде коммуникативтік қызметті қалай ұйымдастыру керектігі [5] тарауда толық айтылған. Кітап өтініш білдірудің прецедент әдісі және өзге де дәстүрлі үлгілері арқылы өтінішті барынша қолайлы етіп құрудың жолын көрсетеді. Кітапта жүзеге асыру, өтініштердің дәлдігін тексеру, салыстыруды анықтау әдістері, сондай-ақ жобаны жүзеге асыру барысында оған қатысы бар команда мүшелері жақсы білуге тиісті өңдеудің басты алты процесі сипатталған.

Тапсырыс беруші өтініштерінің сипаттамасы (с-талаптар)

Тапсырыс беруші қосымшаның қалай жұмыс істейтіндігінің тұжырымын жасайды. Бұл тұжырымды кейде қосымшаның моделі немесе жұмыс тұжырымы деп атайды. Әдетте, тапсырыс берушілер тұжырымды жүзеге асыру технологиясын білмейтіндіктен, инженерлер тұтыну варианттары, мәліммет легі немесе жағдайлардың алмаусы секілді қажет технологияны ұсынуы мүмкін. Көрсетілген техникаларды жобалауда да қолдануға болады.

Якобсон жасап шыққан тұтыну варианттары тұжырымы тапсырыс берушінің тұтынушымен өзара байланыс формасында көрсетудің ұтымды әдісі ретінде танымал.

USE CASE тұтыну варианты – тұтынушы үшін қандай да бір ұтымдылығы бар қызметтердің толыққанды жиынтығы іспетті.

Тұтынудың варианттарын тұтынушыға қатысты міндеттерді идентификациялау нәтижесінде алуға болады. Ол үшін «Тұтынушының жүйеге қатысты міндеттері қандай және ол жүйеден не күтеді?» деген сауалға жауап беру керек. Тұтыну вариаттарын функционалды өтініштерді тікелей сараптау нәтижесінде анықтауға болады. Көбіне функционалды өтініштер тікелей тұтыну вариантында көрініс табады.

Лешека Мацяшек [4] бойынша өтініш анализі тұтыну мен пәндік сала объектілерін кесте арқылы анықтау вариантының спецификасымен сәйкес болуы мүмкін:

• тұтыну варианты мен субъекті бойынша тармақтау;

• тұтыну варинаты спецификасының сипаттамасы;

• функционалды өтініштер мен кластардың – мәндердің сәйкестігі. Пәндік саланың барлық кластары өтініш анализі нәтижесінде алынуы мүмкін. Соңғысы жағдайларды басқару қосымшасы үшін өндіруш мен тапсырыс берушілердің келісімге келу жетістігінің қолайлы тәсілі болып табылады.

Пайдаланушы интерфейсінің дизайны ПО-ның жобалау кезеңіне кіреді, алайда оны да өтініш анализінің бөлігі ретінде қарастыруға болады. Тапсырыс берушілер GUI нобайын жасауды, көбіне, қосымшаны пайдаланушының графикалық интерфейсі (GUI) және бағдарламаны сипаттауға жәрдемдесудің оңтайлы әдісі түрінде қабылдайды.

Тұтынушыға бейімделген интерфейсті жобалаудың принциптері басты бастамашы принциптері [4, 7 тарауда] көрсетілген.

Тұтынушы интерфейстерін жасаудағы басты қадамдарын көрсетейік:

1. Өз тұтыеушыңызды анықтаңыз (с) (С-өтініштерді өңдеу);

2. Жобаланған жүйенің бағытын түсініңіз (С, D);

3. Жақсы экрандық дизаинның принциптерінің қолданылуы (С,D).

4. Терезелердің тиісті типін таңдаңыз (С, D);

5. Меню жүйесін жасап шығыңыз (С,D);

6. Қажетінше басқарудың аппараттық құрлымын таңдаңыз (С);

7. Қажетінше басқарудың экрандық элементтерін таңдаңыз (С);

8. Терезелерді реттемесін ұйымдастырып, жасап шығыңыз (С, D);

9. Қажетті түстерді таңдаңыз (D);

10. Сарапталған белгілерді құрыңыздар (С,D);

11. Нәтижелі хабарламалар, кері байланыс және басшылықты табыңыздар (D).

Тапсырыс беруші талаптарын жүйелеудің төрт әдісі:

1. Қарапайым және өзімен-өзі тұратын талаптар бар, оны қысқа да нұсқа сөйлемдермен беріңіз;

2. Егер де талаптар тұтынушы мен қосымшаның өзара байланысын бейнелейтін болса, оны тұтынушы варианты арқылы көрсетіңіз;

3. Егер де талаптар әрбірі мәліметтерді алатын және беретін өңдеу элементтеріне қатысы болса, мәлімметтер легінің диаграммасын пайдаланыңыз;

4. Егер талаптар бағдарлама (немесе бағдарлама бөліктері) орнығатын күйге қатысы болса, келесі әрекеттерді орындаңыз:

• бағдарламаның барлық күйін анықтаңыз;

• бастапқы күйді көрсетіңіз;

• күйлердің алмасуын қамтитын жағдайларды анықтаңыз;

• енгізілген күйлерді анықтаңыз.