Лекція №5. Вимоги до програмного забезпечення

Вимога - це умова, якій повинно задовольняти ПЗ, або властивість, якою воно повинне володіти, щоб:

Ø задовольнити потребу користувача в рішенні деякої задачі;

Ø задовольнити вимоги контракту, специфікації або стандарту.

Визначення вимог до ПЗ є складовою частиною процесу управління вимогами. Специфікація вимог до ПЗ є основним документом, який визначає план розробки ПЗ. Всі вимоги, визначені в специфікації, діляться на функціональні і нефункціональні. Функціональні вимоги визначають дії, які повинна виконувати система, без урахування обмежень, пов'язаних з її реалізацією, тобто вони відповідають на питання «що повинна робити система?». Тим самим функціональні вимоги визначають поведінку системи в процесі обробки інформації. Нефункціональні вимоги описують атрибути самої системи або атрибути системного оточення, тобто відповідають на питання: «як система робить те, що повинна робити?». Можна виділити наступні типи нефункціональних вимог:

Ø вимоги до застосування визначають якість інтерфейсу користувача, документації і учбових курсів;

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

Ø вимоги до реалізації наказують використовувати певні стандарти, мови програмування, операційне середовище та ін.;

Ø вимоги до надійності визначають допустиму частоту і дію збоїв, а також можливості відновлення;

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

Методи виявлення вимог:

Ø співбесіда (інтерв'ювання);

Ø анкетування;

Ø проведення нарад;

Ø сесії по виявленню вимог (мозковий штурм);

Ø розкадровування (storyboard);

Ø опис і аналіз бізнес-процесів;

Ø ролеві ігри;

Ø створення і демонстрація працюючих прототипів.

Етапи роботи з вимогами:

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

Будь-яка вимога в базі проекту має наступні атрибути:

1. Пріоритет (високий, середній, низький) - високопріоритетні вимоги реалізуються в першу чергу.
2. Статус (запропоновано, схвалено, реалізовано, верифіковано) - використовується для управління вимогою.
3. Вартість реалізації (висока, середня, низька - або числове значення) - використовується для планування витрат у ході проекту.
4. Складність реалізації (висока, середня, низька) - для планування розподілу робіт між розробниками.
5. Стабільність (висока, середня, низька) - ступінь змінюваності даної вимоги.
6. Відповідальний виконавець - розробник, який відповідає за цю вимогу.

Хороший набір вимог задовольняє наступним показникам якості (згідно стандарту IEEE 830-1998 Recommended Practice for Software Requirements Specifications):

Ø Коректність або адекватність (відповідність реальним потребам).

Ø Недвозначність (однозначність розуміння).

Ø Повнота (віддзеркалення всіх виділених потреб і всіх можливих ситуацій, в яких доведеться працювати системі).

Ø Несуперечність (узгодженість між різними елементами).

Ø Впорядкованість за пріоритетом і стабільністю.

Ø Потреба перевірки (виконання кожної вимоги повинне перевірятися достатньо ефективним способом - вимоги, які не перевіряють, повинні бути видалені з розгляду або зведені до варіантів, які перевіряються).

Ø Модифікованість (оформлення в зручних для внесення змін структурі і стилях).

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

Виявлені вимоги до ПЗ оформляються у вигляді низки документів і моделей. До основних документів, які регламентуються технологією Rational Unified Process, відносяться:

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

Ø Словник предметної області (глосарій) - визначає спільну термінологію для всіх моделей і описів вимог до системи. Глосарій призначений для опису термінології предметної області і може бути використаний як словник даних системи.

Ø Додаткова специфікація (технічні вимоги) - містить опис нефункціональних вимог до системи, таких, як надійність, зручність використання, продуктивність, супроводжуваність та ін.

Функціональні вимоги до системи моделюються і документуються за допомогою варіантів використання (use case). Варіант використання (use case) - зв'язний елемент функціональності, який надається системою при взаємодії з дійовими особами. Дійова особа (actor) - роль, узагальнення елементів зовнішнього оточення системи, які ведуть себе по відношенню до системи однаковим чином.

У контексті процесу управління вимогами варіанти використання трактуються таким чином (згідно Коберну):

Ø варіант використання фіксує угоду між учасниками проекту щодо поведінки системи;

Ø варіант використання описує поведінку системи за різних умов, коли система відповідає на запит одного із учасників, який називається основною дійовою особою;

Ø основну дійову особу ініціює взаємодія з системою, щоб досягти деякої мети. Система відповідає, враховуючи інтереси всіх учасників.

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

Стиль їх написання залежить від масштабу, кількості учасників і критичності проекту. У загальному випадку, рекомендується дотримуватися наступних правил:

Назви варіантів використання повинні бути діловими (нетехнічними) термінами, які мають значення для замовника.

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

Добре написаний варіант використання легко читається і складається з речень, написаних в єдиній граматичній формі. На навчання читання варіанта використання не повинно йти більше декількох хвилин.

Формат опису варіанту використання (за Коберном):

1. Ім'я - мета у вигляді короткої активної дієслівної фрази.
2. Контекст використання - довший опис мети.
3. Область дії.
4. Рівень точності.
5. Основна дійова особа.
6. Інші учасники і їх інтереси.
7. Передумова (визначає, виконання якої умови гарантує система перед тим, як дозволити запуск варіанта використання).
8. Мінімальні гарантії (найменші обіцянки системи учасникам, зокрема, коли мета основної дійової особи не може бути досягнута).
9. Гарантії успіху (або післяумова - postcondition - встановлює, що інтереси учасників задовольняються після успішного завершення варіанта використання в кінці основного сценарію).
10. Трігер (подія, яка запускає варіант використання).
11. Основний сценарій або потік (простий для розуміння типовий сценарій, в якому досягається мета основної дійової особи і задовольняються інтереси всіх учасників). Кожен крок основного сценарію описує: взаємодію двох дійових осіб ("Клієнт вводить адресу"); крок підтвердження для захисту інтересу учасника ("Система підтверджує PIN-код"); внутрішня зміна для задоволення інтересу учасника ("Система виводить суму з балансу").
12. Розширення (запускаються при виникненні певної умови, містять послідовність кроків, які описують, що відбувається за цієї умови, і закінчується досягненням мети або відмовою від неї).
13. Список змін у технології і даних.
14. Допоміжна інформація.

Існують чотири рівні точності (при описі варіантів використання, розташовані за ступенями підвищення точності):

Ø Дійові особи і цілі (перераховуються дійові особи і всі їх цілі, які забезпечуватиме система).

Ø Короткий виклад варіанта використання (в один абзац) або основний потік подій (без аналізу можливих помилок).

Ø Умови відмови (аналіз місць виникнення можливих помилок в основному потоці подій).

Ø Обробка відмови (написання альтернативних потоків подій).

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

Ø істотний вплив на архітектуру системи;

Ø ризиковані, складні для реалізації або термінові функції;

Ø застосування нової, не провіреної технології;

Ø значущість в економічних процесах.

Правила написання сценаріїв:

1. Використовуйте прості речення: Підмет...присудок...пряме доповнення... прийменниковий оборот (Система...утримує...суму...із залишку на рахунку).
2. Зрозуміло вкажіть, хто «володіє м'ячем». На кожному кроці одна з дійових осіб "володіє м'ячем" - повідомленням і даними, які одна дійова особа передає іншій.
3. Пишіть, дивлячись на варіант використання з погляду користувача, а не системи.
4. Не показуйте дуже незначні, дрібні дії.
5. Не показуйте детальні дії користувача в процесі роботи з інтерфейсом користувача. Опис деталей інтерфейсу погіршує якість документа, роблячи його довшим, нестійким і переобтяженим зв'язками.
6. Включайте «раціональний» набір дій:

o Основна дійова особа посилає системі запит і дані.

o Система підтверджує запит і дані.

o Система змінює внутрішній стан.

o Система видає дійовій особі результат.

1. Використовуйте дію «Підтвердити», а не «Перевірити».

Розширеннями варіанту використання є альтернативні сценарії (потоки подій), які описують дії системи в наступних ситуаціях:

Ø Некоректна дія дійової особи (введення невірного пароля).

Ø Бездіяльність основної дійової особи (закінчення часу очікування введення пароля).

Ø Речення "система підтверджує" пов'язане з обробкою непідтвердження (невірний обліковий номер).

Ø Невідповідна реакція другорядної дійової особи або її відсутність (закінчення часу очікування відповіді).

Ø Внутрішня помилка в розроблюваній системі, яка повинна бути виявлена і оброблена в звичайному порядку (заблокований автомат для видачі готівки).

Ø Несподівана і незвичайна помилка, яку необхідно обробити (виявлено пошкодження журналу транзакцій).

Ø Критично важливі недоліки у продуктивності системи (час реакції перевищує 5 секунд).

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

Приклад опису сценаріїв для варіанта використання «Зняти гроші з рахунку» в системі Банкомат:

Дата добавления: 2014-01-07