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

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

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

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

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

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

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

Інженерія вимог згідно з Лапланте (2007) є «піддисципліною системної інженерії та програмної інженерії яка причетна до визначення цілей, функцій та обмежень апаратних та програмних систем».Phillip A. Laplante (2007) What Every Engineer Should Know about Software Engineering. Page 44. В деяких моделях життєвих циклів, процес інженерії вимог починається з діяльності по вивченню здійсненності, результатом якої є звіт про здійсненність. Якщо звіт припускає що продукт може бути створеним, то починається аналіз вимог. Якщо аналіз вимог передує дослідженням здійсненності, що може сприяти нестандартному мисленню, тоді здійсненність має визначитись перед завершенням аналізу вимог.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Прецеденти

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

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

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

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

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

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