13Моделювання вимог до пз

Досвід розробників ПЗ показав, що моделі аналізу повинні доповнювати, а не замінювати специфікації вимог на природній мові¹⁶.

Таблиця 1. Прив'язка побажань клієнта до компонентів моделі аналізу

Тип слова	Приклади	Компоненти моделі аналізу
Іменники	Люди, організації, системи ПО, елементи даних або існуючі об'єкти	– Кінцеві об'єкти або сховища даних (діаграми потоків даних) – Дійові особи (діаграми варіантів використання) – Об'єкти або їх атрибути (діаграми «сутність - зв'язок») – Класи або їх атрибути (діаграми класів)
Дієслова	Дії, завдання, які користувач може виконати, або події, які можуть відбутися	– Процеси (діаграми потоків даних) – Варіанти використання (діаграми варіантів використання) – Взаємозв'язку (діаграми «Сутність - зв'язок») – Перетворення (діаграми переходу станів) – Процеси (діаграми процесів)

13.1 Моделі візуального представлення

До моделей візуального представлення відносяться:

1 діаграми потоків даних (data flow diagrams, DFD);

2 діаграми «сутність - зв'язок» (entity-relationship diagrams, ERD);

3 діаграми переходу станів (state-transition diagrams, STD);

4 карти діалогів (dialog maps);

5 діаграми варіантів використання;

6 діаграми класів;

7 діаграми взаємодії.

1 Діаграма потоків даних (data flow diagram, DFD) - основний інструмент структурного аналізу. Вона дозволяє визначати трансформаційні процеси системи, сукупність (зберігання) даних або матеріалів, якими система управляє, і потоки даних або матеріалів між процесами, сховищами і зовнішнім світом.

2 Діаграма «сутність - зв'язок» представляє логічні групи інформації предметної області та їх взаємозв'язок. Діаграма допомагає зрозуміти і пов'язати компоненти даних компанії або системи, не маючи на увазі, що в продукт буде обов'язково включена база даних.

3 Діаграма переходу станів (state-transition diagram) дозволяє отримати точне, повне і ясне уявлення про механізм з кінцевим числом станів. Діаграма переходу станів містить три типи елементів:

3.1 прямокутників - можливі стани системи – показані у вигляді;

3.1 транзакції (transitions) – у вигляді стрілок, що з'єднують прямокутники;

3.1 події які викликають транзакцію – у вигляді текстових пояснень для кожної стрілки переходу.

4 Карта діалогів – являє дизайн користувальницького інтерфейсу на високому рівні абстракції. На ній показані елементи діалогу в системі і навігація між ними, але не показаний докладний вигляд екрану. Карта діалогів дозволяє розглянути можливі концепції користувальницького інтерфейсу з урахуванням розуміння вимог. Карта діалогів – це прекрасний спосіб представити взаємодії діючої особи і системи, описувані варіантом використання.

5 Діаграма варіантів¹⁷ Цей вид діаграм дозволяють створювати список операцій, які виконує система. Як правило цей вид діаграм називають діаграмами функцій так як набір таких діаграм створює список вимог до системи і визначається з множиною функцій, що виконує система. Кожна діаграма - це опис послідовності дій та взаємодій між акторами та іншими компонентами системи.

6 Діаграма класів (class diagram) - це графічний спосіб відобразити класи, ідентифіковані в ході об'єктно-орієнтованого аналізу, і взаємин між ними.

7 Діаграма взаємодії – складається з двох діаграм, послідовності дій та співробітництва

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

7.1 Діаграма послідовності дій взаємодія об’єктів прийняття та передачі повідомлення об’єктами-клієнтами та обробки цих повідомлень об’єктами-серверами. Цей тип діаграм не акцентує увагу на конкретній взаємодії головний акцент приділяється послідовності прийому/передачі повідомлень.

7.2 Діаграма співробітництва - даний тип діаграм дозволяє описати взаємодію об’єктів, абстрагуючись від послідовності передачі повідомлень. На цій діаграмі в компактному вигляді відображаються всі повідомлення, що приймаються та відправляються для кожного об’єкта, а також типи цих повідомлень.

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

Прийоми моделювання аналізу, підтримуються різними комерційними інструментами автоматизованого проектування ПЗ (computer-aided software engineering, CASE). Використання цих інструментів забезпечує деяку перевагу перед звичайними засобами малювання. По-перше, вони легко дозволяють поліпшити якість діаграм при повторних переглядах вимог. Крім того, інструменти автоматизованого проектування ПЗ «знають» правила для кожного методу моделювання, який вони підтримують. Вони здатні визначити синтаксичні помилки і невідповідності, які фахівцям, перевіряючи діаграми, не завжди вдається виявить! Ці інструменти пов'язують різні діаграми один з одним і з їх загальними визначеннями даних в словнику даних, а також дозволяють підтримувати моделі в узгодженому стані та у відповідності з функціональним вимогам в специфікації вимог до ПЗ.

14Атрибути якості ПЗ. Атрибути, важливі для користувачів. Атрибути, важливі для розробників

15Прототипування як засіб зменшення ризику розробки ПЗ. Види прототипів

16Пріоритети вимог до ПЗ. Шкала пріоритетів. Оцінка прототипу

17Перегляд вимог до ПЗ. Проведення експертизи вимог. Тестування вимог

18Вплив вимог на планування проекту, дизайн, написання коду та тестування ПЗ. Розподіл витрат на вимоги для різних моделей ЖЦ ПЗ.

19Основні складові управління вимогами до ПЗ. Атрибути вимог

19.1 Основні складові управління вимогами до ПЗ

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

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

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

Управління вимогами передбачає спілкування між членами проектної групи і зацікавленими сторонами, і адаптацію до змін у вимогах протягом всього проекту. Щоб запобігти перетину поля одного класу вимог з іншим, постійні зв'язки між членами команди розробників є критичними. Наприклад, при розробці програмного забезпечення для внутрішнього використання у бізнесу можуть бути настільки сильні потреби, що він може проігнорувати вимоги користувачів, або вважати, що створені сценарії використання покриють також і користувальницькі вимоги.

Існує безліч програмних продуктів для автоматизації управління вимогами, що розрізняються ціною та функціональними можливостями. Є такі комерційні пакети: IBM Rational RequisitePro, Borland CaliberRM, Sybase PowerDesigner, так і безкоштовні (наприклад, OSRMT — Open Source Requirements Management Tool).