Тема: Специфікація вимог до пз (модуль 2) Способи представлення вимог

• Документація, в якій використовується чітко структурована і акуратно використовувана природна мова

• Графічні моделі, що ілюструють процеси трансформації, стану системи і їх зміни, взаємодію даних, а також логічні потоки, класи об’єктів і відношення між ними

• Формальні специфікації, де вимоги визначені за допомогою математично точних, формальних логічних мов.

Результат розробки вимог – задокументована угода між клієнтами і розробниками про створюваний продукт.

Детальні функціональні і не функціональні вимоги до продукту записуються в специфікаціях до ПЗ.

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

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

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

1. Клієнтам – відділ маркетингу і спеціалісти з продажу хочуть мати уявлення про кінцевий продукт

2. Менеджерам проекту – за даними спеки розраховуються графіки, витрати і необхідні ресурси

3. Команді розробників ПЗ – отримує представлення про створюваний продукт

4. Групі тестування – складає плати тестування, варіанти використання і процедури.

5. Спеціалістам по обслуговуванню і підтримки – отримують представлення про функціональності кожної складової частини продукту

6. Укладачам документації – створюють керівництва для користувачів і вікна довідки на основі специфікації вимог до ПЗ і дизайну користувацького інтерфейсу

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

8. Персоналу, що займається юридичною стороною продукту – перевіряє, чи відповідають вимоги до продукту існуючим законам і постановам.

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

1. Функціональні можливості. Які передбачувані функції ПЗ?

2. Зовнішні інтерфейси. Як ПЗ взаємодії з користувачем, апаратними засобами системи, іншими апаратними засобами і іншим ПЗ?

3. Продуктивність (робочі характеристики). Яка швидкодія, досяжність, час відгуку, час відновлення різних функцій ПЗ?

4. Атрибути. Яка мобільність, правильність, зручність супроводження, захищеність ПЗ і інші критерії?

5. Можливі проектні обмеження, що накладаються на реалізацію. Чи існують необхідні стандарти на ефективні мові реалізації, політика по збереженню цілісності БД, обмеження ресурсів, операційне середовище (ща) і т.д.?

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

Документ SRS – однозначний і повний результат процесу специфікації інформаційної системи. Грамотно складений документ SRS надає наступні основні можливості:

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

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

Мета розробки – надати замовнику, розробнику іншим учасникам проекту ряд переваг:

• Створити основу для угоди між замовником і розробником про набір функцій, які повинна виконувати інформаційна система. Повний опис функцій ПЗ, наведений в SRS, допоможе потенційним користувачам визначити, чи відповідає ПЗ їхнім потребам або як необхідно змінити ПЗ, щоб задовольнити ці потреби.

• Оптимізувати обсяг робіт з розробки. Змушує учасників проекту суворо розглянути всі вимоги перед тим, як приступати до виконання проекту, і скорочує витрати на повторні проектування, кодування і тестування. Ретельний аналіз вимог, зазначених у СРС може розкрити недогляди, неправильне розуміння і суперечності, допущені на стадії розробки СРС, коли їх значно простіше виправити, ніж у процесі розробки.

• Забезпечити основу для оцінки витрат та планів. Опис програм, що розробляється відповідно до СРС, є практичною основою для оцінки витрат на проект і може використовуватись для затвердження проекту на підставі цих оцінок.

• Забезпечити основу для контролю якості розроблюваного продукту. Учасники проекту при використанні СРС можуть складати плани контролю якості, тестування і прийому більш ефективно.

• Полегшити розгортання та тиражування системи. СРС робить більш просту передачу ІС новим користувачам або її установку

• Служить в якості основи для розширення. Оскільки в СРС обговорюється сама ІС, а не проект, за яким вона розроблена, СРС служить основою для подальшого розширення готової системи.