11.2 Документування бізнес-правил

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

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

12Користувацькі інтерфейси і специфікація вимог до

Користувацькі інтерфейси

Включення елементів інтерфейсу користувача в специфікацію має як переваги, так і недоліки.

Переваги:

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

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

3. Підрахунок елементів графічного інтерфейсу користувача {graphical user interface, GUI) або числа функнальних точок * {function points), пов'язаних з кожним екраном, дозволяє оцінити розмір проекту і, отже, витрати на реалізацію.

Недоліки:

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

2. Включення елементів інтерфейсу користувача у вимоги може змістити пріоритети, і опис функціональності виявиться неповним. Макет екрану не замінить користувацьких і функціональних вимог.

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

Шаблон спецификации требований к ПЗ

Багато хто застосовують шаблони, створені на основі того, що описані в IEEE Standard 830-1998, «IEEE Recommended Practice for Software Requirements Specifications »(IEEE, 1998b). Він годиться для самих різних проектів, проте в ньому зустрічаються обмеження і неясні місця.

1. Введення 1.1 Призначення 1.2 Угоди, прийняті документах 1.3 Передбачувана аудиторія і рекомендації з читання 1.4 Межі проекту 1.5 Посилання 2. загальний опис 2.1 Загальний погляд на продукт 2.2 Особливості продукту 2.3 Класи і характеристики користувачів 2.4 Операційна середу 2.5 Обмеження дизайну і реалізації 2.6 Документація для користувачів 2.7 Припущення і залежно 3. функції системи 3.x Функція системи X 3.x. 1 Опис і пріоритети З.х.2 Послідовності «вплив - реакція» З.х.3 Функціональні вимоги 4. Вимоги до зовнішнього інтерфейсу 4.1 Інтерфейси користувача 4.2 Інтерфейси обладнання 4.3 Інтерфейси ПО 4.4 Інтерфейси передачі інформації 5. Інші нефункціональні вимоги 5.1 Вимоги до продуктивності 5.2 Вимоги до охорони праці 5.3 Вимоги до безпеки 5.4 Атрибути якості 6. інші вимоги Додаток А. Словник термінів Додаток Б. Моделі аналізу Додаток Г. Список питань

Рис. 11-1. Шаблон для специфікації вимог до ПЗ

На рис. 11-1 показаний шаблон специфікації вимог до ПЗ, створюванний на основі стандарту IEEE 830; в ньому пропонується безліч прикладів додаткових вимог до продукту, які ви можете включити в свою специфікацію. У додатку Г показаний приклад специфікаціі вимог до ПЗ, похідною від цього шаблону. змініть його відповідно до особливостей вашого проекту. Якщо якийсь розділ вашого шаблону не годиться для конкретного проекту, не видаляйте його заголовок, але вкажіть, що він непридатний. У цьому випадку у користувача не виникне підозри, що щось важливе було пропущено по неуважності. Якщо вам постійно доводиться пропускати одні й ті ж розділи, це означає, що шаблон слід настроїти. Створіть зміст і журнал змін специфікації вимог до ПЗ де вказані дата зміни, співробітник, який вніс зміну, і її причина. Іноді фрагмент інформації логічно підходить для декількох розділів шаблону. Набагато важливіше акуратно і послідовно фіксувати інформацію, ніж гаряче обговорювати, де слід зберігати кожен елемент.