Вимога
У інженерії вимога — це умова, яка має бути виконана, щоб результат певної роботи вважався прийнятним. Це явний, об’єктивний, чіткий і часто кількісний опис умови, якій має відповідати матеріал, проєкт, продукт або послуга.[1]
Специфікація — це сукупність вимог, яку зазвичай використовують розробники на етапі проєктування під час розробки нового продукту, а також тестувальники під час перевірки.
У разі ітеративної та інкрементальної розробки вимоги розробляються паралельно з проєктуванням і реалізацією. У водоспадній моделі вимоги завершуються до початку проєктування або реалізації.
Вимоги використовуються в багатьох інженерних галузях, зокрема у проєктуванні, системній інженерії, інженерії програмного забезпечення, інженерії підприємств, розробці продуктів та оптимізації процесів.
Вимога — це досить широке поняття, яке може описувати будь-яку необхідну або бажану функцію, атрибут, здатність, характеристику чи якість системи, що забезпечує її цінність і корисність для замовника, організації, користувача або іншої зацікавленої сторони.
Термін вимога використовується у спільноті інженерів програмного забезпечення щонайменше з 1960-х років.[2]
Відповідно до Guide to the Business Analysis Body of Knowledge® (BABOK) версії 2 від International Institute of Business Analysis,[3] вимога — це:
- Умова або здатність, необхідна зацікавленій стороні для розв’язання проблеми чи досягнення мети.
- Умова або здатність, які має задовольняти або якими має володіти рішення чи його компонент, щоб відповідати контракту, стандарту, специфікації або іншому формально встановленому документу.
- Документоване представлення умови або здатності, як у пунктах (1) або (2).
Це визначення базується на стандарті IEEE 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology.[4]
Вимоги можна умовно поділити на дві категорії:
- Вимоги до продукту — визначають властивості системи або продукту.
- Вимоги до процесу — визначають діяльність, яку має виконувати організація-розробник. Наприклад, такі вимоги можуть задавати методології, яких слід дотримуватися, а також обмеження, яких організація повинна дотримуватися.
Характеристики якісних вимог по-різному формулюються різними авторами; зазвичай кожен підкреслює ті риси, які найбільш доречні для його тематики або конкретної технологічної області. Однак наведені нижче характеристики загалом визнаються.[5] [6]
| Властивість | Пояснення |
|---|---|
| Єдиність (когерентність) | Вимога стосується одного і лише одного аспекту. |
| Повнота | Вимога повністю сформульована в одному місці без пропущеної інформації. |
| Несуперечність | Вимога не суперечить жодній іншій вимозі та повністю узгоджується з усією авторитетною зовнішньою документацією. |
| Атомарність | Вимога є атомарною, тобто не містить сполучників. Наприклад, «Поле поштового індексу має перевіряти американські та канадські індекси» слід записати як дві окремі вимоги: (1) «Поле поштового індексу має перевіряти американські індекси» і (2) «Поле поштового індексу має перевіряти канадські індекси». |
| Відстежуваність | Вимога відповідає повністю або частково бізнес-потребі, визначеній зацікавленими сторонами та належним чином задокументованій. |
| Актуальність | Вимога не втратила чинності з плином часу. |
| Однозначність | Вимога сформульована стисло, без використання технічного жаргону, акронімів (якщо вони не визначені в іншому місці документа вимог) або іншої спеціалізованої лексики. Вона описує об’єктивні факти, а не суб’єктивні думки, і допускає лише одне тлумачення. Уникаються нечіткі іменники, прикметники, прийменники, дієслова та суб’єктивні формулювання. Також уникаються заперечні та складені речення. |
| Важливість | Багато вимог відображають характеристики, відсутність яких призведе до серйозних або навіть критичних недоліків. Інші ж описують функції, які можуть бути реалізовані за наявності часу та бюджету. Вимога має містити рівень важливості. |
| Верифіковність | Реалізацію вимоги можна визначити за допомогою базових методів: інспекції, демонстрації, тестування (з інструментуванням) або аналізу (включно з перевіреним моделюванням і симуляцією). |
- Архітектурні вимоги
- Бізнес вимоги
- Користувацькі вимоги
- Функціональні вимоги
- Вимоги до якості (нефункціональні)
- Вимоги до реалізації
- Правові вимоги
- ↑ [[1](https://web.archive.org/web/20151106210652/http://www.astm.org/COMMIT/Blue_Book.pdf) Form and Style of Standards, ASTM Blue Book]. ASTM International. 2012. Архів [[2](http://www.astm.org/COMMIT/Blue_Book.pdf) оригіналу] за 6 листопада 2015. Процитовано 5 січня 2013.
{{cite book}}: Перевірте значення|archive-url=(довідка); Перевірте значення|url=(довідка) - ↑ Boehm, Barry (2006). [[3](http://dl.acm.org/citation.cfm?id=1134288) A view of 20th and 21st century software engineering]. ICSE '06 Proceedings of the 28th international conference on Software engineering. University of Southern California, University Park Campus, Los Angeles, CA: Association for Computing Machinery, ACM New York, NY, USA. с. 12—29. ISBN 1-59593-375-1. Процитовано 2 січня 2013.
{{cite conference}}: Перевірте значення|url=(довідка) - ↑ [1.3) Key Concepts - IIBA | International Institute of Business Analysis. [www.iiba.org. Процитовано 2016–09–25).
{{cite web}}: Перевірте значення|url=(довідка)Обслуговування CS1: Сторінки з неправильним форматом в діапазонах дат (посилання) - ↑ [[4](https://web.archive.org/web/20110110043912/http://standards.ieee.org/findstds/standard/610.12-1990.html) IEEE SA - 610.12-1990 - IEEE Standard Glossary of Software Engineering Terminology]. Архів [[5](http://standards.ieee.org/findstds/standard/610.12-1990.html) оригіналу] за 10 січня 2011.
{{cite web}}: Перевірте значення|archive-url=(довідка); Перевірте значення|url=(довідка) - ↑ Davis, Alan M. (1993). Software Requirements: Objects, Functions, and States, Second Edition. Prentice Hall. ISBN 978-0-13-805763-3.
- ↑ IEEE Computer Society (1998). IEEE Recommended Practice for Software Requirements Specifications. Institute of Electrical and Electronics Engineers, Inc. ISBN 978-0-7381-0332-7.