PROFILPELAJAR.COM

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

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

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

Огляд

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

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

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

Інженерія вимог

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

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

Інженерія вимог згідно з Лапланте (2007) є «піддисципліною системної інженерії та програмної інженерії яка причетна до визначення цілей, функцій та обмежень апаратних та програмних систем».^[4] В деяких моделях життєвих циклів, процес інженерії вимог починається з діяльності по вивченню здійсненності, результатом якої є звіт про здійсненність. Якщо звіт припускає що продукт може бути створеним, то починається аналіз вимог. Якщо аналіз вимог передує дослідженням здійсненності, що може сприяти нестандартному мисленню, тоді здійсненність має визначитись перед завершенням аналізу вимог.

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

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

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

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

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

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

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

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

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

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

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

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

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

Переваги

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

Недоліки

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

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

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

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

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

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

Докладніше: Моделювання цілей

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

Прототипи

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

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

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

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

Прецеденти

Докладніше: Прецедент (програмування)

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

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

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

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

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

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

Типи вимог

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

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

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

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

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

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

Функціональні вимоги: Функціональні вимоги пояснюють що має бути зроблено ідентифікацією необхідної задачі, дії, чи діяльності які мають виконуватись. Аналіз функціональних вимог буде використаний в функціях верхніх рівнів для функціонального аналізу.^[5]

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

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

Вимоги дизайну: Вимоги «будувати до», «кодувати до», і «купувати до» для продуктів, і «як виконати» для процесів виражених в технічних пакетах даних та інструкціях.^[5]

Успадковані вимоги: Вимоги які маються на увазі вимогами вищого рівня, чи перетворені з них. Наприклад вимога великої дальності, чи високої швидкості може спричинити вимогу дизайну малої ваги.^[5]

Розподілені вимоги: Вимоги які визначені поділом, чи іншим перерозміщенням високорівневих вимог в кілька низькорівневих вимог. Наприклад стокілограмовий пристрій що складається з двох підсистем може спричинити вимоги ваги не більше 70 та 30 кілограм для конкретних систем нижчого рівня.^[5]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проте залишається основна проблема: обмеженість інформації та знань учасниками процесу формулювання вимог, можливі конфлікти інтересів між ними та нездатність вірно виставити пріоритети^[6].

Див. також

Примітки

↑ Executive editors: Alain Abran, James W. Moore; editors Pierre Bourque, Robert Dupuis, ред. (March 2005). Chapter 2: Software Requirements. Guide to the software engineering body of knowledge (вид. 2004). Los Alamitos, CA: IEEE Computer Society Press. ISBN 0-7695-2330-7. Архів оригіналу за 23 березня 2009. Процитовано 8 лютого 2007. It is widely acknowledged within the software industry that software engineering projects are critically vulnerable when these activities are performed poorly.
↑ Jon Holt, Simon Perry (2008). 4.9 Requirement diagrams (structural). SysML for Systems Engineering. The Institution of Engineering and Technology. ISBN 978-0-86341-825-9.
↑ Wiegers, Karl E. (2003). Software Requirements (вид. 2nd). Redmond, WA: Microsoft Press. ISBN 0-7356-1879-8. Архів оригіналу за 5 травня 2021. Процитовано 28 жовтня 2010.
↑ Phillip A. Laplante (2007) What Every Engineer Should Know about Software Engineering. Page 44.
↑ ^а ^б ^в ^г ^д ^е ^ж Systems Engineering Fundamentals. [Архівовано 22 липня 2011 у Wayback Machine.] Defense Acquisition University Press, 2001
↑ ^а ^б Albert Endres, Dieter Rombach (2003). 2.3.1 Glass’ law. A Handbook of Software and Systems Engineering. Pearson. ISBN 0-321-15420-7.
↑ (Enders, Rombach; розділ 2.3.2 Boehm's first law)

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

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.