大连一方队员眼中的舒斯特尔“挺和气”

百度 她表示，营队特别之处在于救灾实际的演练，跟以往她参加过的活动性质不同，可以透过实际演练当面临灾害发生时，要如何去做准备及应对，透过现场实际模拟，将伤害降到最低。

Ана?л?з вимо?г поляга? в визначенн? потреб та умов, як? висуваються щодо нового, чи зм?неного продукту, враховуючи можливо конфл?ктн? вимоги р?зних замовник?в, таких як користувач? чи бенеф?ц?ари.

Анал?з вимог ? критичним для усп?шно? розробки проекту. Вимоги мають бути задокументованими, вим?рними, тестовними, пов'язаними з б?знес-потребами, ? описаними з р?внем детал?зац?? достатн?м для конструювання системи. Вимоги можуть бути арх?тектурними, структурними, повед?нковими, функц?ональними, та не функц?ональними.

У мов? моделювання SysML вимоги моделюють за допомогою д?аграми вимог, а в UML для цього ?нколи пристосовують д?аграму прецедент?в.

Огляд

Анал?з вимог включа? три види д?яльност?:

• Виявлення вимог: задача комун?кац?? з користувачами для визначення ?х вимог. Також це називають збором вимог.
• Анал?з вимог: виявлення недол?к?в вимог (неточностей, неповноти, неоднозначностей чи суперечностей) ? ?х виправлення.
• Запис вимог: Вимоги можуть документуватись в р?зних формах, таких як опис звичайною мовою, прецедентами, користувацькими ?стор?ями, чи специф?кац?ями процесу.

Анал?з вимог може бути довгим та важким процесом що вимага? використання тонких психолог?чних навичок. Нов? системи зм?нюють середовище ? в?дношення м?ж людьми, тому важливо розп?знати вс? зац?кавлен? сторони, взяти до уваги вс? ?хн? потреби, ? переконатись що вони розум?ють насл?дки як? приносить нова система. Анал?тики можуть використати к?лька метод?в щоб отримати в?д споживача вимоги. ?сторично це включа? проведення ?нтерв'ю, чи фокус-груп (яку в цьому контекст? част?ше називають як майстерня вимог) ? створення списк?в вимог. До сучасн?ших п?дход?в в?дносять прототипування, та прецеденти. За потреби анал?тик використа? комб?нац?ю цих метод?в щоб встановити точн? вимоги зац?кавлених стор?н, так щоб система в?дпов?дала б?знес-потребам.

?нженер?я вимог

Систематичний анал?з вимог також в?домий як ?нженер?я вимог. Часом б?льш неформально ?? називають збором вимог, чи специф?кац??ю вимог. Терм?н анал?з вимог також може застосовуватись до в?дпов?дного анал?зу, в протилежн?сть до, наприклад, збору чи документування вимог. ?нженер?я вимог може бути под?лена на дискретн? хронолог?чн? кроки:

• Зб?р (виявлення) вимог
• Анал?з вимог та ?х узгодження
• Специф?кац?я вимог
• Моделювання системи
• Перев?рка (вал?дац?я) вимог
• Управл?ння вимогами

?нженер?я вимог зг?дно з Лапланте (2007) ? ?п?ддисципл?ною системно? ?нженер?? та програмно? ?нженер?? яка причетна до визначення ц?лей, функц?й та обмежень апаратних та програмних систем?. В деяких моделях житт?вих цикл?в, процес ?нженер?? вимог почина?ться з д?яльност? по вивченню зд?йсненност?, результатом яко? ? зв?т про зд?йсненн?сть. Якщо зв?т припуска? що продукт може бути створеним, то почина?ться анал?з вимог. Якщо анал?з вимог переду? досл?дженням зд?йсненност?, що може сприяти нестандартному мисленню, тод? зд?йсненн?сть ма? визначитись перед завершенням анал?зу вимог.

Розд?ли анал?зу вимог

Визначення зац?кавлених стор?н

Зац?кавлен? сторони (ЗС) це особи чи орган?зац??, як? мають д?йсний ?нтерес до системи. Вона може впливати на них прямо чи опосередковано.

Визна?ться, що зац?кавлен? сторони не обмежуються орган?зац??ю що найняла анал?тик?в. До зац?кавлених стор?н також в?дносять:

• кожного хто керуватиме системою (звичайн? та обслуговуюч? оператори)
• будь-кого хто отрима? вигоди в?д системи (функц?ональн?, пол?тичн?, ф?нансов? та соц?альн? бенеф?ц?ари).
• кожен хто бере участь в придбанн? чи закупц? системи. В розробц? продукт?в для масового ринку, в?дд?л менеджменту продукту, маркетингу, ? ?нод? продаж д?ють як сурогатн? споживач? щоб направляти розробку продукту.
• орган?зац?? що регулюють аспекти системи (ф?нансов?, безпеки, та ?нш? регулятори)
• люди та орган?зац?? що протистоять систем? (негативн? зац?кавлен? сторони (див. також Негативний прецедент)
• орган?зац?? в?дпов?дальн? за системи як? будуть вза?мод?яти з системою що розробля?ться
• т? орган?зац?? як? горизонтально ?нтегруються з орган?зац??ю для яко? анал?тики конструюють систему

?нтерв'ю з зац?кавленими сторонами

?нтерв'ю з ЗС ? рядовим п?дходом що використову?ться в анал?з? вимог. Ця техн?ка може служити як шлях отримання висококонцентрованого знання яке часто не виявля?ться в сп?льних сес?ях розробки вимог, де увага зац?кавлено? сторони п?дпорядкована забезпеченню б?льш крос-функц?онального контексту. Б?льш того, особистий характер ?нтерв'ю нада? б?льш розслаблююче середовище де х?д думок може бути детальн?ше пояснений.

Сп?льн? сес?? розробки вимог

Вимоги часто мають крос-функц?ональн? насл?дки, як? нев?дом? окремим зац?кавленим сторонам ? часто пропускаються чи неправильно описуються протягом ?нтерв'ю з ЗС. Ц? крос-функц?ональн? насл?дки можуть бути виявленими проведенням сес?й СРР в контрольованому середовищ?, стимульованому квал?ф?кованим посередником, де ЗС беруть участь в дискус?? з метою виявлення вимог, анал?зують ?х детал? ? розкривають крос-функц?ональн? насл?дки. Мають бути присутн? спец?ально призначен? секретар, та б?знес-анал?тик для документування дискус??. Використання навичок навченого посередника для управл?ння дискус??ю зв?льня? б?знес-анал?тика, дозволяючи йому сфокусуватись на процес? визначення вимог.

Сес?? СРР под?бн? до сес?й сп?льного проектування ПЗ. Спершу сес?? виявляють вимоги як? направляють дизайн, а пот?м виявляють властивост? як? мають бути реал?зован? щоб задовольнити отриман? вимоги.

Списки вимог в стил? контракту

Також традиц?йним способом документування вимог ? список вимог в стил? контракту. В складн?й систем? такий список вимог може розтягуватись на сотн? стор?нок.

В?дпов?дною метафорою може бути надзвичайно довгий список покупок. Так? списки не дуже ц?нуються в сучасному анал?з?, так як вони показали малу усп?шн?сть в досягненн? сво?х ц?лей. Тим не менш, ?х ?нод? можна побачити ? сьогодн?.

Переваги

• Нада? ч?ткий попунктовий список вимог.
• Нада? контракт м?ж спонсорами проекту, та розробниками.
• Для велико? системи може надати опис високого р?вня.

Недол?ки

• Так? списки розтягуються на сотн? стор?нок. Так? документи майже неможливо прочитати ц?лком, ? отримати повне розум?ння системи.
• Так? списки абстрагують вс? вимоги, тому ? мало контексту

• ?х абстракц?я робить неможливим побачити як вимоги сполучаються чи працюють разом.
• Така абстракц?я заважа? правильно розставляти пр?оритети м?ж вимогами.
• Така абстракц?я зб?льшу? под?бн?сть та ймов?рн?сть неправильно? ?нтерпретац?? вимог, чим б?льше людей ?? прочитають тим б?льша к?льк?сть р?зних ?нтерпретац?й з'явиться.
• Така абстракц?я означа? що надзвичайно важко впевнитись що ви ма?те б?льш?сть вимог.

• Так? списки створюють фальшиве в?дчуття вза?много розум?ння м?ж зац?кавленими сторонами та розробниками.
• Списки в стил? контракту дають ЗС фальшиве в?дчуття безпеки, що розробники мусять досягти певних речей. Тем не менш, через природу таких списк?в вони упускають критичн? вимоги, як? виявляються п?зн?ше в процес?. Розробники можуть використати ц? в?дкрит? вимоги щоб переглянути умови договору на свою користь.
• Так? списки вимог не допомагають в проектуванн? системи

Альтернативи до списк?в вимог

Як альтернатива до великих, попередньо-описаних списк?в вимог гнучка розробка програмного забезпечення використову? ?стор?? користувач?в щоб описати вимогу в повсякденних терм?нах.

Вим?рюван? ц?л?

Найкращ? практики беруть складений список вимог як п?дказку, ? пост?йно запитують ?Чому??, поки не стане зрозум?лою справжня б?знес ц?ль. Зац?кавлен? сторони ? розробники можуть скласти тести що вим?рюють р?вень досягнення ц?лей. Так? ц?л? зм?нюються пов?льн?ше н?ж довгий список конкретних але невим?рних вимог. Як т?льки невеликий наб?р критичних, вим?рних ц?лей буде встановлений, швидке прототипування та коротк? ?теративн? фази розробки можуть продовжити приносити справжн? ц?нност? для зац?кавлено? сторони, задовго до середини проекту.

Прототипи

В середин? 1980-тих прототипування розглядалось як найкраще р?шення до проблеми анал?зу вимог. Прототипи — це макети програмного забезпечення. Макети дозволяють користувачам в?зуал?зувати ще не створений додаток . Прототипи допомагають користувачам уявити як буде виглядати система, ? спростити для користувач?в прийняття конструкторських р?шень. П?сля введення прототип?в спостер?гаються значн? покращення в комун?кац?? м?ж користувачами й розробниками. Ранн? бачення програмного забезпечення приводить до меншо? к?лькост? зм?н у майбутньому ? тому зменшу? загальну варт?сть проекту.

Тим не менш, протягом останнього десятил?ття, прототипування хоча й зарекомендувало себе як корисна техн?ка, але не розв'язало проблему вимог:

• Як т?льки менеджери бачать прототип, вони перестають розум?ти що проект ще не буде завершений протягом деякого часу.
• Дизайнери часто думають що змушен? використовувати скле?ний докупи код прототипу в реальн?й систем?, бо вони бояться ?втратити час? починаючи заново.
• Прототипи загалом допомагають в конструкторських р?шеннях, та проектуванн? ?нтерфейсу користувача. Та вони не можуть сказати як? вимоги були спочатку.
• Дизайнери ? к?нцев? користувач? можуть занадто сфокусуватись на конструюванн? ?нтерфейсу користувача, ? занадто мало на створенн? системи що викону? б?знес процес.
• Прототипи добре працюють для ?нтерфейс?в користувача, та под?й на екран?, але не дуже корисн? для пакетних чи асинхронних процес?в як? можуть включати складн? розрахунки чи запити до даних.

Прототипи можуть бути плоскими д?аграмами (як? часто називаються каркасними моделями), чи робочими додатками що використовують синтезовану функц?ональн?сть. Каркасн? модел? створюються в р?зноман?тних граф?чних дизайн-документах, ? часто видаляють увесь кол?р з дизайну (використовують чорно-б?лу пал?тру) в випадках кол?р з дизайну (використовують чорно-б?лу пал?тру) в випадках коли к?нцеве ПЗ буде мати в?дпов?дний граф?чний дизайн. Це допомага? уникнути плутанини м?ж концептом програми в дизайн-документ?, та ?? к?нцевим виглядом.

Прецеденти

Прецеденти це технолог?я документування потенц?йних вимог до ново?, чи зм?нено? програмно? системи. Кожен прецедент нада? один чи б?льше сценар??в як? виражають те, як система вза?мод?? з користувачем чи ?ншою системою щоб досягти конкретно? б?знес ц?л?. Прецеденти зазвичай уникають техн?чного жаргону, в?ддаючи перевагу мов? к?нцевого користувача чи експерта в предметн?й област?. ?нженери вимог та ЗС часто виступають сп?вавторами прецедент?в.

Прецеденти ? оманливо простими ?нструментами для опису повед?нки системи. Прецедент м?стить текстовий опис вс?х способ?в якими користувач? можуть працювати з програмним забезпеченням. Прецеденти не описують жодних внутр?шн?х процес?в у систем?, ? не пояснюють як система ма? реал?зовуватись. Вони просто показують кроки як? користувач ма? зд?йснити щоб виконати свою задачу. Так можна описати вс? способи вза?мод?? з системою.

Специф?кац?я вимог до програмного забезпечення

Специф?кац?я вимог до програмного забезпечення (SRS) — це повний опис повед?нки системи що розробля?ться. В?н включа? наб?р прецедент?в, що описують вс? вза?мод?? користувача з системою. Прецеденти також в?дом? як функц?ональн? вимоги. На додачу до прецедент?в, SRS також м?стить нефункц?ональн? (чи додатков? вимоги). Нефункц?ональн? вимоги ? вимогами як? накладають обмеження на проект, чи реал?зац?ю (так? як вимоги ?нженер?? продуктивност?, стандарти якост?, чи обмеження проектування).

Рекомендован? п?дходи до специф?кац?? вимог до ПЗ описан? в стандарт? IEEE 830–1998. Цей стандарт опису? можлив? структури, бажаний вм?ст ? якост? специф?кац?? вимог.

Типи вимог

Вимоги категоризуються к?лькома способами. Нижче подана звичайна категоризац?я вимог яка стосу?ться техн?чного менеджменту:

Вимоги споживача

вирази факт?в та припущень як? описують оч?кування до системи в терм?нах ц?лей, середовища, обмежень, та м?ри ефективност? й придатност?. Споживач? це т?, хто виконують в?с?м первинних функц?й системно? ?нженер??, з особливим наголосом на оператор?, як на ключовому споживач?. Операц?йн? вимоги опишуть базову необх?дн?сть, ? як м?н?мум дадуть в?дпов?дь на запитання, з даного списку:

• Операц?йне поширення ? розгортання: Де використають систему?
• Проф?ль чи сценар?й м?с??: Як система буде виконувати сво? завдання?
• Продуктивн?сть та пов'язан? параметри: Як? параметри критичн? для виконання м?с???
• Використання середовища: Як будуть використовуватись р?зноман?тн? компоненти системи?
• Вимоги ефективност?: Якою ефективною ма? бути система для виконання сво?? м?с???
• Операц?йний житт?вий цикл: Як довго система буде використовуватись споживачем?
• Середовище: Яких середовищ система оч?ку? щоб працювати ефективно?

Арх?тектурн? вимоги

Арх?тектурн? вимоги пояснюють що ма? бути зроблено ?дентиф?кац??ю необх?дно? системно? арх?тектури.

Структурн? вимоги

Структурн? вимоги пояснюють що ма? бути зроблено ?дентиф?кац??ю необх?дно? структури системи.

Повед?нков? вимоги

Повед?нков? вимоги пояснюють що ма? бути зроблено ?дентиф?кац??ю необх?дно? повед?нки системи.

Функц?ональн? вимоги

Функц?ональн? вимоги пояснюють що ма? бути зроблено ?дентиф?кац??ю необх?дно? задач?, д??, чи д?яльност? як? мають виконуватись. Анал?з функц?ональних вимог буде використаний в функц?ях верхн?х р?вн?в для функц?онального анал?зу.

Нефункц?ональн? вимоги

Нефункц?ональн? вимоги — це вимоги що задають критер?й для оц?нки операц?й системи, зам?сть ?? повед?нки.

Вимоги продуктивност?

До яко? м?ри м?с?? чи функц?? повинн? бути виконан?; зазвичай вим?рю?ться в терм?нах к?лькост?, якост?, охопленн?, сво?часност? чи готовност?. Протягом анал?зу вимог, вимоги продуктивност? (як добре воно ма? бути зроблено) будуть ?нтерактнивно розроблятись вздовж вс?х виявлених функц?? що базуються на факторах житт?вого циклу системи, ? характеризуються в терм?нах ступеня визначеност? в ?х оц?нках, ступеня критичност? усп?ху системи, ? ?х в?дношення до ?нших вимог.

Вимоги дизайну

Вимоги ?будувати до?, ?кодувати до?, ? ?купувати до? для продукт?в, ? ?як виконати? для процес?в виражених в техн?чних пакетах даних та ?нструкц?ях.

Успадкован? вимоги

Вимоги як? маються на уваз? вимогами вищого р?вня, чи перетворен? з них. Наприклад вимога велико? дальност?, чи високо? швидкост? може спричинити вимогу дизайну мало? ваги.

Розпод?лен? вимоги

Вимоги як? визначен? под?лом, чи ?ншим перерозм?щенням високор?вневих вимог в к?лька низькор?вневих вимог. Наприклад сток?лограмовий пристр?й що склада?ться з двох п?дсистем може спричинити вимоги ваги не б?льше 70 та 30 к?лограм для конкретних систем нижчого р?вня.

До в?домих моделей категоризац?? вимог належать FURPS та FURPS+, розроблен? в Hewlett-Packard.

Проблеми анал?зу вимог

Правильно визначен? вимоги до програмного про?кту ма? надзвичайно велике значення для його усп?ху. Досл?дження Роберта Гласа (англ. Robert Glass) дек?лькох провалених про?кт?в св?дчать, що нев?рно визначен? вимоги ? чи не головною причиною ?х невдач. Чим дал? просува?ться робота над про?ктом, тим важче ? дорожче виправити помилки, допущен? при визначен? вимог до про?кту.

Проблеми з зац?кавленою стороною

Ст?в МакКоннел, в сво?й книжц? Швидка розробка, детал?зу? способи, якими користувач? можуть перешкоджати збору вимог:

• Користувач? не розум?ють чого ?м треба, чи не мають ч?ткого уявлення про сво? вимоги
• Користувач? не вкладуть н?чого в наб?р письмових вимог
• Користувач? наполягають на нових вимогах п?сля ф?ксац?? ц?ни та граф?ку розробки
• Сп?лкування з користувачами в?дбува?ться пов?льно
• Користувач? часто не беруть участ? у оглядах чи не мають змоги брати участь
• Користувач? неграмотн? техн?чно
• Користувач? не розум?ють процес розробки
• Користувач? не знають про сучасн? технолог??

Це може привести до ситуац?? в як?й вимоги користувача продовжують зм?нюватись нав?ть коли почалась розробка.

Проблеми з ?нженерами/розробниками

Можлив? проблеми як? можуть спричинити розробники та ?нженери протягом анал?зу вимог:

• Техн?чний персонал та к?нцев? користувач? можуть говорити р?зними мовами. Вони можуть помилково в?рити в те, що вони перебувають в ?деальн?й згод?, поки не буде наданий зак?нчений продукт.
• ?нженери та розробники можуть спробувати зробити вимоги як? п?дходять до ?снуючо? системи чи модел?, зам?сть того щоб розробляти систему спец?ально п?д потреби кл??нта.
• Анал?з часто може проводитись ?нженерами чи програм?стами, а не персоналом з навичками комун?кац?? та знанням предменно? област? для правильного розум?ння потреб кл??нта.

Можлив? р?шення

Одне з можливих р?шень в проблем? комун?кац?? — найняти спец?ал?ста з б?знес-анал?зу чи системного анал?зу.

Технолог?? представлен? в 1990-тих так? як прототипування, Unified Modeling Language (UML), прецеденти, та Гнучка розробка програмного забезпечення також вважаються р?шеннями проблем пов'язаних з попередн?ми методами.

Також, на ринок вийшов новий клас ?нструмент?в симуляц?? програмного забезпечення чи ?нструмент?в опису ПЗ. Ц? ?нструменти створен? як м?ст через комун?кац?йний розрив м?ж користувачами та IT — ф?рмами, ? дозволяють додаткам(ПЗ) бути ?випробуваними ринком? перед тим як з'явиться перший код. Найкращ? з цих ?нструмент?в надають:

• електронн? дошки для малювання еск?з?в процес?в додатку та тестових альтернатив
• здатн?сть ф?ксувати б?знес лог?ку та потреби даних
• здатн?сть генерувати високояк?сн? прототипи як? близько ?м?тують к?нцевий продукт
• здатн?сть додавати контекстуальн? вимоги та ?нш? коментар?
• здатн?сть для в?ддалених та розпод?лених користувач?в запускати та вза?мод?яти з симуляц??ю

Проте залиша?ться основна проблема: обмежен?сть ?нформац?? та знань учасниками процесу формулювання вимог, можлив? конфл?кти ?нтерес?в м?ж ними та нездатн?сть в?рно виставити пр?оритети.

Див. також

• Вимоги до програмного забезпечення
• Д?аграма вимог
• Функц?ональн? вимоги
• Нефункц?ональн? вимоги
• Прототипування програмного забезпечення
• Специф?кац?я вимог до програмного забезпечення

Л?тература для подальшого читання

• Laplante, Phil (2009). Requirements Engineering for Software and Systems (вид. 1st). Redmond, WA: CRC Press. ISBN 1-42006-467-3. Арх?в ориг?налу за 8 липня 2011. Процитовано 28 жовтня 2010.
• McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules (вид. 1st). Redmond, WA: Microsoft Press. ISBN 1-55615-900-5.
• Wiegers, Karl E. (2003). Software Requirements (вид. 2nd). Redmond, WA: Microsoft Press. ISBN 0-7356-1879-8. Арх?в ориг?налу за 5 травня 2021. Процитовано 28 жовтня 2010.
• Andrew Stellman and Jennifer Greene (2005). Applied Software Project Management. Cambridge, MA: O'Reilly Media. ISBN 0-596-00948-8. Арх?в ориг?налу за 25 травня 2021. Процитовано 23 травня 2022.
• Brian Berenbach, Daniel Paulish, Juergen Katzmeier, Arnold Rudorfer (2009). Software & Systems Requirements Engineering: In Practice. New York: McGraw-Hill Professional. ISBN 0-07-1605479. Арх?в ориг?налу за 9 травня 2021. Процитовано 23 травня 2022.
• Walter Sobkiw (2008). Sustainable Development Possible with Creative System Engineering. New Jersey: CassBeth. ISBN 0615216307. Арх?в ориг?налу за 23 с?чня 2020. Процитовано 28 жовтня 2010.

Посилання

• Requirements Engineering Process ?Goodies? [Арх?вовано 23 листопада 2008 у Wayback Machine.]
• Requirements Engineering: A Roadmap [Арх?вовано 7 червня 2011 у Wayback Machine.] (PDF) article by Bashar Nuseibeh and Steve Easterbrook, 2000.