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

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

Технологія розробки програмного забезпечення
Цикл розробки програмного забезпечення
Програміст за роботою
Діяльність і кроки
Допоміжні дисципліни
Практики
Інструменти
Стандарти та галузі знань

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Див. також

Примітки
  1. Вигерс К. Разработка требований к программному обеспечению. — 2004.
  2. Ларман К. Применение UML 2.0 и шаблонов проектирования. – 2007.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.