Вимоги до програмного забезпечення

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до навігації Перейти до пошуку
Технологія розробки програмного забезпечення
Цикл розробки програмного забезпечення
Програміст за роботою
Діяльність і кроки
Допоміжні дисципліни
Практики
Інструменти
Стандарти та галузі знань

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

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

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

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

[ред. | ред. код]

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

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

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

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

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

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

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

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


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

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

[ред. | ред. код]

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

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

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

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

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

[ред. | ред. код]

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

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

Див. також

[ред. | ред. код]

Примітки

[ред. | ред. код]
  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.
Отримано з https://uk.wikipedia.org/wiki/Вимоги_до_програмного_забезпечення