Кіріспе
Инженерлік процесс
Жүйелік және бағдарламалық инженерияда талаптарды талдау жаңа немесе өзгертілген өнім немесе жобаның қажеттіліктеріне немесе шарттарына жұмыс істейтін міндеттерге назар аударады, сонымен қатар әртүрлі мүдделі тараптардың қарама-қайшы талаптарын ескере отырып, бағдарламалық жасақтама немесе жүйе талаптарын талдау, құжаттау, тексеру және басқаруды қамтиды. Талаптарды талдау жүйелік немесе бағдарламалық жасақтама жобасының табысы немесе сәтсіздігі үшін маңызды. Талаптар құжатталған, іске асырылатын, өлшенетін, тестілеуге болатын, ізге түсірілетін, анықталған бизнес қажеттіліктеріне немесе мүмкіндіктеріне байланысты болуы керек және жүйе дизайны үшін жеткілікті деңгейде егжей-тегжейлі анықталған болуы тиіс.
Бірлескен талаптарды әзірлеу (БЖЖ) сессиялары
Талаптар көбінесе жеке мүдделі тараптарға белгісіз, функционалдық байланыстарға ие болады және мүдделі тараптармен жүргізілетін әңгімелерде жиі назардан тыс қалады немесе толыққанды анықталмайды. Бақыланатын ортада, тәжірибелі фасилитатор (бизнес-аналитик) жетекшілігімен JRD сессияларын өткізу арқылы осы функционалдық байланыстарды анықтауға болады, онда мүдделі тараптар талаптарды анықтау, олардың мәліметтерін талдау және функционалдық байланыстарды анықтау үшін талқылауға қатысады. Талқылауды жазу үшін арнайы хатшы болуы керек, бұл бизнес-аналитикке сессия мақсатына сай келетін тиісті талаптарды дамытатын бағытта талқылауды жүргізуге мүмкіндік береді. JRD сессиялары бірлескен қолданбаны жобалау сессияларымен ұқсас. Алғашқысы жобалауға бағыт беру үшін талаптарды анықтайды, ал екіншісі анықталған талаптарды қанағаттандыру үшін іске асырылатын нақты жобалау ерекшеліктерін анықтайды.
Келісім-шарт үлгісіндегі талап тізімдері
Қажеттіліктерді құжаттаудың дәстүрлі әдістерінің бірі – келісімшарт түріндегі талаптар тізімі. Күрделі жүйелерде мұндай тізімдер жүздеген бетке жете алады. Оны ұзын сонар сауда тізімімен салыстыруға болады. Мұндай тізімдер қазіргі заманғы талдауда жиі қолданылмайды, себебі олар өз мақсаттарына жетуде үлкен сәтсіздікке ұшырады. Дегенмен, олар әлі де кездеседі.
Жақсы жақтары
Қажеттіліктердің тізімін ұсынады. Жоба демеушілері мен әзірлеушілер арасында шарт жасау керек. Үлкен жүйе үшін, төменгі деңгейдегі талаптарды туындатуға болатын жоғары деңгейдегі сипаттама беруге болады.
Кемшіліктері
Мұндай тізімдер жүздеген беттерге созылуы мүмкін. Олар оқырманға қажетті қолданбаны түсінікті етіп сипаттауға арналмаған. Мұндай талаптар тізімі барлық талаптарды абстракциялайды, сондықтан контекст өте аз болады. Бизнес-аналитик талаптарға қатысты ақпаратты қоса берілген жобалау құжаттамасында келтіре алады. Бұл абстракция талаптардың қалай байланысқа түсетінін немесе бірлесе жұмыс істейтінін сипаттауға бағытталмаған. Тізім талаптар арасындағы қарым-қатынастар мен тәуелділіктерді көрсетпеуі мүмкін. Тізім әрбір тармақты басымдыққа ие етуді жеңілдеткенімен, бір тармақты контекстен шығарып тастау бүкіл пайдалану сценарийін немесе бизнес-талапты қажетсіз ете алады. Тізім қажетті жүйе/қолданбаның жобалауына тигізетін әсерін жақсырақ түсіну үшін мүдделі тараптармен талаптарды мұқият қарап шығу қажеттігін жоймайды. Тізімді жасау оның толықтығына кепілдік бермейді. Бизнес-аналитик толыққанды тізімді табуға және жинауға адал күш жұмсау керек, ал жетіспейтін талаптарды көрсету үшін мүдделі тараптарға сүйенуі керек. Бұл тізімдер мүдделі тараптар мен әзірлеушілер арасында өзара түсіністік туралы жаңылысқан ой тудыруы мүмкін; Бизнес-аналитиктер аударма процесінде маңызды рөл атқарады. Даму және сынақ процесі басталмас бұрын барлық функционалдық талаптарды анықтау дерлік мүмкін емес. Егер бұл тізімдер өзгермейтін келісімшарт ретінде қарастырылса, онда даму процесінде туындаған талаптар дау тудыруы мүмкін өзгеріс сұранысын қалыптастыруы мүмкін.
Талаптар тізімдеріне балама
Талаптар тізіміне орнына, Ұтымды бағдарламалық жасақтаманы әзірлеу күнделікті тілде талаптарды беру үшін Пайдаланушы әңгімелерін қолданады.
Өлшеуге болатын мақсаттар
Ең жақсы тәжірибелер талаптардың жинақталған тізімін тек меңзеу ретінде ғана қарастырып, нақты бизнес мақсаттары анықталғанша, қайта-қайта "неге?" деп сұрайды. Мүдделі тараптар мен әзірлеушілер содан кейін әрбір мақсаттың қандай деңгейде орындалғанын өлшеу үшін тесттер құрастыра алады. Мұндай мақсаттар, нақты бірақ өлшенбеген талаптардың ұзақ тізіміне қарағанда, әлдеқайда баяу өзгеріп отырады. Шағын, өлшенетін мақсаттар жиынтығы белгіленгеннен кейін, жобаның жартысы аяқталмас бұрын мүдделі тараптарға нақты құндылық жеткізу үшін жылдам прототиптеу және қысқа итеративтік даму кезеңдеріне көшуге болады.
Үлгілер
Прототип – басқа компьютерлік бағдарламаның қасиеттерінің бір бөлігін көрсететін компьютерлік бағдарлама, ол пайдаланушыларға әлі құрылмаған қолданбаны көруге мүмкіндік береді. Прототиптің кең таралған түрі – макет, ол болашақ пайдаланушылар мен өзге де мүдделі тараптарға жүйенің қалай болады деген ойға келуге көмектеседі. Прототиптер жобалау шешімдерін қабылдауды оңайлатуға септігін тигізеді, себебі қолданбаның элементтерін қолданба құрылатын алдында көруге және бөлісуге болады. Прототиптерді енгізу арқасында пайдаланушылар мен әзірлеушілер арасындағы байланыс әлдеқайда жақсарған. Қолданбалардың бастапқы нұсқаларын қарау кейінірек өзгерістердің азаюына, демек, жалпы құнның айтарлықтай төмендеуіне әкелді. Прототиптер жазық сызбалар (көбінесе wireframe деп аталады) немесе синтезделген функционалдылықты қолданатын жұмыс істейтін қолданбалар болуы мүмкін. Wireframe-дер әртүрлі графикалық дизайн құжаттарында жасалады және әдетте, түстердің барлығын алып тастайды (яғни, сұр түсті палитраны қолданады), егер соңғы бағдарламалық жасақтамаға графикалық дизайн қолданылуы күтілсе. Бұл прототиптің қолданбаның соңғы визуальдық бейнесін көрсететіні туралы жаңылысудың алдын алуға көмектеседі.
Пайдалану жағдайлары
Пайдалану жағдайы – жүйеге қойылатын функционалдық талаптарды құжаттауға арналған құрылым, әдетте бағдарламалық жасақтамамен байланысты, ол жаңа немесе өзгертіліп жатқан болсын. Әрбір пайдалану жағдайы, белгілі бір бизнес мақсатына жету үшін жүйенің адам-пайдаланушымен немесе басқа жүйемен қалай өзара әрекеттесу керектігін көрсететін сценарийлер жиынтығын ұсынады. Пайдалану жағдайлары көбінесе техникалық терминологиядан аулақ болып, оның орнына соңғы пайдаланушының немесе салалық сарапшының тілін пайдаланады. Пайдалану жағдайларын көбінесе талаптар инженерлері мен мүдделі тараптар бірлесіп жасайды. Пайдалану жағдайлары – бағдарламалық қамтамасыз етудің немесе жүйелердің мінез-құлқын сипаттауға арналған сырттай қарағанда қарапайым құралдар. Пайдалану жағдайы пайдаланушылардың бағдарламалық қамтамасыз етумен немесе жүйемен қалай жұмыс істейтінін сипаттайтын мәтіндік құжаттан тұрады. Пайдалану жағдайлары жүйенің ішкі жұмысын сипаттамауы керек, сондай-ақ жүйенің қалай іске асырылатынын түсіндірмеуі керек. Олардың орнына, олар тізбектелген болжамдарсыз тапсырманы орындау үшін қажетті қадамдарды көрсетеді.
Талаптардың ерекшеліктері
Талаптарды айқындау – қазіргі бизнес қажеттіліктері туралы ашылу нәтижелерін жинақтау және осы қажеттіліктерді бағалау арқылы шешімнің көлеміндегі қажеттіліктерді қанағаттандыру үшін не қажеттігін анықтау және нақтылау. Ашылу, талдау және айқындау түсінікті қазіргі күйден болашақ күйге жылжытады. Талаптарды айқындау болашақта іске асырылатын жағдайдың толық көлемін және тереңдігін қамтуы мүмкін, немесе басымдыққа ие бағдарламалық жүйедегі қателерді жою және жақсарту сияқты нақты кемшіліктерді толтыруға бағытталуы мүмкін. Кез келген ірі бизнес процесінде бағдарламалық қамтамасыз ету, деректер жүйелері мен технологиялар қолданылатынын ескере отырып, талаптарды айқындау көбінесе бағдарламалық жүйелерді құрумен, сатып алумен, бұлттық есептеу стратегияларымен, өнімдер мен құрылғылардағы енгізілген бағдарламалық қамтамасыз етумен немесе басқа технологиялармен байланысты. Талаптарды айқындаудың кең анықтамасы кез келген шешім стратегиясын немесе компонентін қамтиды немесе оларға назар аударады, мысалы, оқыту, құжаттамалық нұсқаулар, персонал, маркетингтік стратегиялар, жабдықтар, керек-жарақтар және т.б.
Талаптардың түрлері
Талаптар бірнеше түрге бөлінеді. Техникалық басқаруға қатысты талаптардың ең көп кездесетін жіктелулері: