Розробка вимог — це процес, який включає заходи, необхідні для створення та затвердження документа, що містить специфікацію системних вимог. Розрізняють чотири основні етапи цього процесу — аналіз технічної здійснюваності створення системи, формування (добування) й аналіз вимог, специфікація вимог і створення відповідної документації, атестація (перевірка) вимог.
Для формування та аналізу вимог зазвичай застосовують кілька підходів. Серед найпоширеніших методів слід назвати анкетування, інтерв’ю, спостереження, вивчення ділових документів та наявних систем, рольові ігри, етнографічний метод, метод мозкового штурму, метод, оснований на множині опорних точок зору, сценарії, методи структурного аналізу, використання програмних прототипів, JAD (Joint Application Development, сумісна розробка додатків), RAD (Rapid Application Development, швидка розробка додатків).
Для подання та документування вимог застосовують офісні додатки.
Методи прототипування та RAD передбачають застосування CASEсистем для швидкого генерування прототипу — робочої моделі програмного додатку, що подає користувацький інтерфейс і поведінку системи при настанні певних подій або дій користувача (див. тему). Одноразовий прототип використовується лише під час формування вимог, а еволюційний — ще й для створення кінцевого програмного продукту. Застосування CASEзасобів є ключовим аспектом методу RAD. Зокрема, існує потреба в CASEсистемах із можливостями циклічної розробки з переходом від проектних моделей до програми і назад (див. тему 5).
На основі підходу з використанням різних опорних точок зору, що відповідають різним кінцевим користувачам, які висловлюють у вимогах до системи власні інтереси, розроблено метод VORD (ViewpointOriented Requirements Definition, визначення вимог на підставі точок зору). Основними його етапами є такі:
— ідентифікація точок зору, що отримують системні сервіси, та ідентифікація сервісів, що відповідають кожній точці зору. Один із застосовуваних підходів полягає у проведенні мозкової атаки, в якій задіяні всі особи, що беруть участь у формуванні вимог;
— структурування точок зору — створення ієрархії згрупованих точок зору. Загальносистемні сервіси подаються як вищі рівні ієрархії і наслідуються точками зору нижчого рівня. Якщо виявлено сервіси, для яких не визначено відповідних точок зору, це означає, що деякі точки зору не було ідентифіковано. Один і той самий сервіс може бути співвіднесений з кількома точками зору. Точки зору також визначають вхідні дані та керівну інформацію для сервісів. На рис. 3.2 подано частину ієрархії точок зору для системи банкоматів. Для спрощення показано лише сервіси, пов’язані з двома точками зору;
— документування опорних точок зору — точний опис ідентифікованих точок зору і сервісів за допомогою стандартних форм (відповідних шаблонів) і сценаріїв подій. На сценаріях базується методика формування вимог як варіантів використання (див. тему 5);
— відображення системи точок зору, що подає системні об’єкти, визначені на основі інформації з опорних точок зору.
Оскільки метод VORD передбачає оброблення великих обсягів інформації, для його застосування потрібні CASEзасоби, зокрема VORDtool. Робота із системою передбачає такі кроки:
— ідентифікація точок зору — виконується за допомогою дерева абстрактних точок зору (рис. 3.3). У дереві представлено безпосередні точки зору, що визначають основну частину системи, та непрямі, необхідні для моделювання організаційних вимог. Визначені точки зору переносяться у вікно додатка, де визначаються підкласи точок зору (рис. 3.4) та вводяться їхні атрибути;
— ідентифікація вимог — для обраної точки зору відкривається форма опису вимоги (рис. 3.5), в яку вводиться опис вимоги, джерело (а), обґрунтування;
— аналіз обмежень;
— опис сценаріїв;
— аналіз вимог — здійснюється обмежений аналіз конфліктів між вимогами;
— узгодження вимог — користувачеві надається можливість переглянути рекомендовані зміни у вимогах і прийняти рішення щодо їх здійснення, що автоматично заноситься у звіт про виявлені конфлікти;
— формування звітів;
— перевірка вимог — користувачеві пропонується контрольний перелік питань, що автоматично асоціюються з певними компонентами (точками зору, вимогами, сценаріями подій) і відображають стан роботи у певний момент.
Завершує процес розроблення вимог їх атестація. Атестація має засвідчити, що вимоги справді визначають ту систему, яку воліє мати замовник. З цією метою виконуються перевірки правильності вимог, їх несуперечливості, повноти та виконуваності. Для атестації вимог застосовують кілька методів — огляд (аналіз) вимог рецензентами, прототипування, генерування тестових сценаріїв. Якщо вимоги подано у формі структурних або формальних моделей, для перевірки їх несуперечливості можна використовувати інструментальні CASEзасоби. Цей процес унаочнює рис. 3.6. Перевіряються всі вимоги, знесені в базу даних, аналізатор вимог готує звіт про всі виявлені суперечності.
.jpg)
