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

На початку фази проектування проектна група працює з проектними вимогами. Вони поділяються на:

• бізнес-вимоги;

• вимоги до експлуатації;

• системні вимоги;

• вимоги користувача.

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

• інструкцією команді розробників про те, що вони повинні будуть створити;

• основою для оцінювання об'єму роботи;

• чіткою угодою із замовником про те, що повинно бути зроблено;

• основою для синхронізації роботи усієї проектної команди.

Із шаблонами відповідних документів можна ознайомитися на сайті Microsoft.

Література до теми

1. ГОСТ 34.602-89 http://vsegost.com/Catalog/11/11254.shtml

2. ГОСТ 34.602-89 "Техническое задание на создание автоматизированной системы" (ТЗ на АС)

3. Маглинец Ю. Анализ требований к автоматизированным информационным системам БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий – Intuit.ru, 2008.

4. Вигерс К. Разработка требований к программному обеспечению. Пер, с англ. - М.:Издательско-торговый дом "Русская Редакция", 2004. – 576с.

10.3. Питання для самоконтролю

1. Стисло опишіть, як документуються вимоги у різних методологіях.

2. Знайдіть спільні риси та відмінності у шаблонах «Vision» RUP та SRS.

3. Які основні складові зовнішнього інтерфейсу?

4. Розкрийте основні характеристики інтерфейсу користувача, наведіть приклади.

Тема №11. Перевірка вимог

11.1. Методичні вказівки до вивчення теми

Верифікація і валідація

Термін «верифікація» (verification) у вітчизняній літературі зазвичай перекладають, як «перевірка». Термін «валідація», – як «перевірка правильності», «атестація», «твердження».

Згідно із стандартом IЕЕЕ 1012-1986, верифікація є процесом оцінювання системи або компоненту з метою визначити, чи задовольняють результати деякої фази умовам, накладеним на початку цієї фази. Валідація у цьому ж стандарті визначається, як процес оцінювання системи або компоненту під час або після закінчення процесу розробки з метою визначити, чи задовольняє вона вказаним вимогам.

Валідація пов'язана з експертизою продукту з метою визначення його відповідності потребам користувача. У цьому і полягає суть відмінності: якщо верифікація пов'язана із з'ясуванням того, чи задовольняє об'єкт, що розробляється, або процес його створення сформульованим вимогам, то валідація відповідає на питання, чи вірно розроблений цільовий об'єкт (продукт), чи задовольняє він потреби замовника. Інший аспект валідації полягає у тому, що вона, зазвичай, пов’язана з формальним прийманням (атестацією) системи.

Деякі стандарти, наприклад SWEBOK, IEEE 1059-93 "IEEE Guide for Software Verification and Validation Plans", вводять для цих двох процесів узагальнююче поняття V&V (Validation and Verification). Згідно IEEE 1059-93, верифікація і валідація програмного забезпечення – впорядкований підхід в оцінці програмних продуктів, що здійснюється упродовж усього життєвого циклу. Зусилля, що докладаються у межах робіт з верифікації і валідації, спрямовані на забезпечення якості як невід'ємної характеристики програмного забезпечення і задоволення вимог користувача.

З усього, зазначеного вище стає зрозумілим, як здійснити верифікацію і валідацію ПС та(або) процесу її створення: у першому випадку необхідно переконатися, що ПС (компонент, процес) відповідає сформульованим вимогам, у другому – що ПС дійсно працює. Але якщо критерієм перевірки ПС виступають вимоги, то що може бути критерієм перевірки самих вимог? Відповідь полягає у тому, що вимоги повинні задовольняти властивостям, сформульованим у темі№2 «Властивості вимог», додатково необхідно переконатися у тому, що:

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

• вимоги до ПЗ точно відбивають системні вимоги, бізнес-правила, тощо;

• вимоги забезпечують якісну основу для проектування і збору ПЗ. [1]

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