Визначення та розробка вимог до ПЗ

Вхідні дані:

· Вимоги, що пред’являються для установки;

· Обмеження системи (системні обмеження)

· Функціональні вимоги до ПЗ системи.

Вихідні дані:

· Попередні (первинні) вимоги до ПЗ

· Вимоги, що пред’являються для установки

Призначення:

· Планування проекту

· Встановлення вимог

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

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

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

Попередні (первинні) вимог до ПЗ і вимоги. Що пред’являються для установки повинні включати розглянуті обмеження системи, такі як: термі, розмір, мова, маркетингові обмеження і технології.

Визначення вимог до інтерфейсу

Вхідні дані:

· Обмеження системи

· Функціональний опис системи

· Попередні (первинні) вимоги до ПЗ

· Функціональні вимоги до ПЗ системи

· Вимоги до інтерфейсу системи (якщо доступні, тобто вже визначені)

Вихідні дані:

· Вимоги до інтерфейсу системи

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

Інтерфейс користувача має вирішальне значення у визначенні зручності використання системи.

Вимоги до інтерфейсу включають:

1. Зручність роботи з графічними елементами

2. Види відповідної кольорової гамми

3. Розміщення інформації на екрані

4. Підбір шляхів символіки і кольорової композиції

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

· Мінімальність витрат ресурсів користувача при введенні, модифікації і перегляді даних;

· Максимальна взаємодія програми і користувача (продуктивність)

· Мінімальний об’єм оперативної памяті користувача

10. Процеси встановлення вимог – встановлення пріоритетів та інтеграція вимог до програмного забезпечення.

Встановлення пріоритетів та інтеграція вимог до ПЗ

Вхідні дані:

· Опис інформації стосовно ризиків

· Попередні (первинні) вимоги до ПЗ

· Вимоги до інтерфейсу ПЗ

Вихідні дані:

· Вимоги до ПЗ

Призначення:

· Початок проекту

· Управління і моніторинг проекту

· Проектування

· Реалізація

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

Формування вимог до ПЗ, що зявляються повинні бути переглянуті і перевірені при необхідності.

11. Загальний зміст специфікації вимог до програмного забезпечення.

Специфікація вимог до ПЗ – закінчений опис поведінки системи, яку потрібно розробити.

В стандарті IEEE 830 містяться рекомендації до структури і методів опису вимог до ПЗ.

Специфікація вимог до ПЗ

SRS – специфікація для конкретного (визначеного) ПЗ, програми чи набору програм, які виконують визначені функції в конкретному середовищі.

SRS можуть бути складені одним або декількома представниками постачальника, одним або декількома представниками клієнта, або обома.

Специфікація вимог до ПЗ – документ, що представляє собою рекомендовану методику складання специфікації вимог до ПЗ. (Она сама не поняла что сказала)

Специфікація вимог до ПЗ (SRS)

Основні питання, що розглядаються SRS

· Функціональні можливості системи

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

· Робочі характеристики системи: швидкодія, доступність та інше

· Атрибути системи: зручність для користувачів різних груп, захищеність системи%

· Можливі проектні обмеження, що накладаються на систему: вимоги до ОС, до форматів даних, до СУБД.

Переваги використання SRS:

· Для замовника – точний опис того, що він хоче отримати;

· Для розробника – однозначне тлумачення і розуміння того, що хоче отримати замовник.

Характеристика правильно складеної SRS :

· Коректність

· Однозначність

· Повнота

· Несуперечливість

· Упорядкованість за значністю

· Перевіряємість

· Модифікуємість

· Відслідковуваність

12. Методи збору та виявлення вимог

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

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

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

Методи встановлення та виявлення вимог:

1. Інтерв’ю замовника та експертів прикладного домену.

2. Анкетування

3. Спостереження

4. Виявлення документів та аналогічних систем

5. Нарада

6. Мозковий штурм

7. Прототипування

13. Інтерв’ю замовника та експертів прикладного домену.