2. Користувацькі вимоги

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

Разом з тим при описі вимог природньою мовою можуть виникнути різні проблеми.

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

2. Змішання вимог. У користувацьких вимогах відсутній чіткий поділ на функціональні і нефункціональні вимоги, на системні цілі і проектну інформацію.

3. Об'єднання вимог. Кілька різних вимог до системи можуть описуватися як єдина користувацька вимога.

У якості ілюстрації до описаних проблем розглянемо вимогу до середовища програмування мовою ADA, представлену в прикладі 3.4. Ця вимога містить опис як загального плану, так і деталізований. З інформації, що втримується в описі загального плану, випливає, що засоби керування конфігурацією є складовою частиною інтерфейсу APSE, у той час як з більш деталізованого опису випливає, що засоби керування конфігурацією повинні надавати доступ до об'єктів, що входять до складу груп, без вказівки їх повних імен. Цю інформацію краще помістити в специфікацію системних вимог.

Приклад 3.4. Вимога до бази даних для середовища програмування Ada

4.А.5. База даних повинна підтримувати генерацію і керування конфігурацією об'єктів; у базі даних згруповані об'єкти можуть виступати у вигляді окремих об'єктів. Засіб керування конфігурацією повинен надати можливість доступу до об'єктів, що входять до складу груп, за допомогою їх неповних імен.

У документі, що містить вимоги до системи, бажано відокремлювати користувацькі вимоги від більш деталізованих системних вимог. Інакше непідготовлений читач користувацьких вимог може “потонути” у технічних подробицях, розуміння яких вимагає певних професійних знань. Приклад змішання різних вимог демонструє приклад 3.5. Він представляє вимогу до САSЕ-засобів для редагування схем структур програмних систем. У цій вимозі мова йде про можливість відображення або приховання сітки, що допомагає користувачеві точно позиціонувати структурні елементи схеми.

Приклад 3.5. Приклад користувацької вимоги

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

У цій вимозі переплітається не менш трьох різних вимог.

1. Концептуальна функціональна вимога: система редагування повинна мати у своєму розпорядженні можливість відображення сітки. Це основна причина появи даного вимоги.

2. Нефункціональна вимога, що дає докладну інформацію про те, у яких одиницях буде вимірятися крок сітки (сантиметри або дюйми).

3. Нефункціональна користувацька вимога, що відноситься до інтерфейсу: як користувач може відобразити або сховати сітку.

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

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

Приклад 3.6. Опис засобу відображення сітки

Засіб відображення сітки

Редактор повинен мати засіб виводу на екран сітки, яка складається з паралельних горизонтальних і вертикальних ліній і повинна відображатися у вигляді фону на екрані редактора. Сітка ‒ пасивний елемент, що полегшує вирівнювання користувачем структурних елементів схем.

Обґрунтування. Сітка повинна допомогти користувачеві створити акуратну схему із правильно розміщеними елементами. Хоча активна сітка (така, у якій елементи “прив'язуються" до вузлів сітки) також може бути корисною, вона не забезпечує точного позиціонування елементів. Користувач визначить положення елементів схеми краще, чим це зробить автоматизований засіб.

Специфікація: Екліпс/АРМ/Засоби/DE/FS.

Зверніть увагу на обґрунтування вимоги. Воно допомагає розробникам зрозуміти, чому ця вимога включена в специфікацію і у якому ступені воно може змінитися в майбутньому. Наприклад, в обґрунтуванні вимоги на засіб відображення сітки сказано, що також може бути корисною активна сітка, де елементи схеми автоматично "прив'язуються" до вузлів сітки. Однак тут перевага свідомо віддана пасивній сітці. Якщо надалі виникне необхідність внести зміни в дану вимогу, то із цього обґрунтування буде видно, що варіант пасивної сітки обраний навмисно, а не з'явився на етапі реалізації системи.

Наступний приклад вимоги, що також відноситься до системи редагування схеми структури ПЗ, показаний в прикладі 3.7. Це деталізована специфікація системної функції. У цьому випадку вимога включає список дій, які повинен виконати користувач для реалізації даної функції; іноді необхідно записати подібну послідовність дій, оскільки деякі функції повинні виконуватися тільки строго визначеним способом. Інформація про те, як реалізується дана функція, у цій вимозі відсутня.

Приклад 3.7. Користувацька вимога по створенню структурних елементів схеми

1. Додавання структурних елементів у схему

2. Редактор повинен мати засіб, що надає користувачеві можливість додавати в схему нові структурні елементи обраного типу

3. Послідовність дій користувача для додавання в схему нового структурного елемента.

• Користувач вибирає тип елемента, що додається.

• Користувач поміщає курсор у потрібну позицію на схемі і указує, яким символом буде відображатися новий елемент.

• Користувач переміщає символ елемента в кінцеву позицію.

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

Специфікація: Екліпс/АРМ/Засоби/DE/FS.

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

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

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

3. Використовуйте різні накреслення шрифту (напівжирне і курсив) для виділення ключових частин вимоги.

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