1.4 Способи представлення вимог до програмного проекту

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

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

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

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

Способи подання вимог можуть бути різні:

– просте текстовий опис;

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

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

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

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

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

Приклад:

Варіант використання «Збереження проекту» для системи управління вимогами

Передумови Проект відкритий у програмі керування вимогами Результат Створений файл XML з описом проекту Основний потік 1 Користувач запускає збереження файлу з новим ім’ям. 2 Система запитує шлях і ім'я файлу, в який необхідно зберегти проект. 3 Користувач задає шлях та ім'я файлу. 4 Система видає повідомлення "Проект збережений". Альтернативний потік 3.1 Якщо файл із заданим ім'ям вже існує 3.2 Система видає повідомлення "Файл [шлях і ім'я файлу] вже існує. Замінити його?" 3.3 Користувач підтверджує збереження проекту 3.4 Виконання варіанту використання триває з кроку 4 3.3.а) Якщо користувач відмовляється від збереження файлу, то система видає повідомлення "Проект не збережений" та виконання варіанту використання припиняється 3.3.б) Якщо користувач задає інші шлях і ім'я файлу, то виконання варіанту використання триває з кроку 3. Винятки Можлива помилка операційної системи при збереженні файлу. В цьому випад система видає повідомлення "Помилка при збереженні проекту в файл [шлях і ім'я файлу]" і видає повідомлення про причини помилки.

Як бачимо, варіант використання включає інформацію про:

– умовах, які повинні бути виконані до початку його здійснення;

– результати виконання;

– основному потоці взаємодії користувача і програми;

– можливі відхилення від основного потоку;

– можливі помилки і способи реакції на них програми.

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

Різні розробники можуть використовувати різні шаблони варіантів використання. Також різні шаблони варіантів використання можуть застосовуватися в різних проектах одного і того ж розробника. Більш докладно про варіанти використання наведено в книзі Алістера Коберна «Сучасні методи опису функціональних вимог до систем».

Крім опису функціонування системи, вимоги можуть включати такі очікування користувачів, як зручність інтерфейсу, надійність, швидкодія. Такі вимоги називають атрибутами якості [2]. Атрибути якості повинні враховуватися при виборі архітектури і засобів реалізації проекту.

Комп'ютерні програми і створювані ними документи часто повинні відповідати корпоративній політиці, промисловим стандартам або урядовим постановам. Ці вимоги називають бізнес-правилами. Їх текст не слід повністю переносити в опис вимог проекту, досить включити посилання на відповідні документи, щоб розробники могли врахувати їх при створенні програми.

При розробці вимог не слід намагатися відразу сформулювати їх в остаточному вигляді. Швидше за все в ході роботи над проектом вимоги будуть змінюватися – з'являтися нові, змінюватися існуючі. Не слід до нескінченності намагатися поліпшити використовуються у вимогах формулювання. Головне, щоб вони були достатньо повними і не допускали неоднозначного розуміння.