uk %D0%92%D0%B8%D0%BC%D0%BE%D0%B3%D0%B8 %D0%B4%D0%BE %D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE %D0%B7%D0%B0%D0%B1%D0%B5%D0%B7%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%BD%D1%8F

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

Розробка вимог до програмної системи може бути розділена на декілька етапів:

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

Види вимог за рівнями

Карл Вігерс визначає три рівні вимог до програмного забезпечення ^[1]

Бізнес-вимоги — визначають призначення ПЗ, можуть описуватися в документі про бачення (англ. vision) та документі про межі проекту (англ. scope).

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

Види вимог за характером

Функціональний характер — вимоги до поведінки системи
- Бізнес-вимоги
- Вимоги користувача
- Функціональні вимоги
Нефункціональний характер — вимоги до характеру поведінки системи
- Бізнес-правила — визначають обмеження, що витікають з предметної області.
- Системні вимоги — вимоги до програмних інтерфейсів, надійності, обладнанню.
- Атрибути якості
- Зовнішні системи та інтерфейси
- Обмеження

Джерела вимог

Законодавство
Вимоги стандартів
Бізнес-процеси
Очікування та бачення користувачів системи

Методи знаходження вимог

Спілкування з майбутнім користувачем: інтерв'ю, анкетування.
Мозковий штурм, семінар.
Аналіз нормативної документації та законодавства.
Аналіз бізнес-процесів.
Аналіз інтерфейсів.
Прототипування.
Аналіз бізнес-правил.
Спостереження.
Реєстр/карта зацікавлених сторін.
Бенчмаркінг та аналіз ринку.
Дизайн-мислення.
Добування даних (Data mining).

В українському ІТ найчастіше використовуються: інтерв’ю, аналіз документів, аналіз інтерфейсів, мозковий штурм, прототипування та аналіз бізнес-процесів ^[2].

Документування вимог

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

Технічне завдання
Специфікація вимог до програмного забезпечення (англ. Software Requirements Specification, SRS)

В рамках Уніфікованого процесу розробки вимоги представляються у вигляді кількох необов'язкових документів^[3]:

Модель випадків використання (прецедентів) (англ. Use Case Model) – набір типових сценаріїв використання системи. Описує функціональні (поведінкові) вимоги.
Додаткова специфікація (англ. Supplementary Specification). Містить нефункціональні вимоги, такі як вимоги до надійності, продуктивності, документування, підтримки, ліцензування тощо.
Словник термінів (англ. Glossary). Визначає важливі терміни і визначення. Може включати концепцію словника даних, який фіксує вимоги, пов'язані з даними, такими як правила верифікації, прийнятні значення тощо.
Бачення (англ. Vision). Узагальнює найважливіші високорівневі ідеї та вимоги, покладені в основу розробки системи. Це короткий оглядовий документ для швидкого ознайомлення з проектом.
Бізнес-правила (англ. Business Rules). Бізнес-правила або правила предметної області описують вимоги або політики, які виходять за рамки одного проекту, наприклад, політика компанії, організація бухобліку, державні норми оподаткування, закони. Можуть бути представлені у додатковій специфікації або окремим артефактом.

Вимоги до ПЗ можуть документуватися в текстовому або графічному вигляді. Текстові вимоги - це стислий та розгорнутий описи якогось прецеденту. Для графічного представлення використовують наступні нотації: ER (IDEF1FX), IDEF0, IDEF3, DFD, UML, OCL, SysML, ARIS (eEPC, VAD).

Вимоги в процесах розробки

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

В ітеративних процесах розробки фаза аналізу та розробки вимог в різному об'ємі є на кожній ітерації.

Див. також

Примітки

↑ Вигерс, Карл (2014). Разработка требований к программному обеспечению (російською) . БХВ-Петербург. ISBN 978-5-9909805-3-2.
↑ Гобов, Денис (5 липня 2021). Стан бізнес-аналізу в Україні (2020). Частина друга: Виявлення та аналіз вимог. https://www.artofba.com/.
↑ Ларман, Крэг (2019). Применение UML 2.0 и шаблонов проектирования (російською) . Диалектика. ISBN 978-5-907144-36-1.

[1] Вигерс, Карл (2014). Разработка требований к программному обеспечению (російською) . БХВ-Петербург. ISBN 978-5-9909805-3-2.

[2] Гобов, Денис (5 липня 2021). Стан бізнес-аналізу в Україні (2020). Частина друга: Виявлення та аналіз вимог. https://www.artofba.com/.

[3] Ларман, Крэг (2019). Применение UML 2.0 и шаблонов проектирования (російською) . Диалектика. ISBN 978-5-907144-36-1.

[1]

[2]

[3]