Важливо розуміти, на що саме бізнес-аналітик має звертати увагу під час підготовки. У цьому контексті питання збору та пріоритизації вимог не розглядаються — припустимо, що вони вже виконані.
Аспекти, на які варто звертати увагу під час підготовки вимог до розробки ПЗ
Розглянемо основні аспекти, які необхідно враховувати під час підготовки вимог до розробки програмного забезпечення (без урахування етапів збору та пріоритезації). Їх можна умовно поділити на кілька змістовних блоків:
- функціональність;
- адміністративні процеси;
- якість вимог;
- оформлення та стиль;
- інші аспекти.
Далі детальніше розглянемо кожен із цих блоків.
Функціональність
Почнемо із загальних принципів.
Під час опису вимог важливо забезпечити такий рівень деталізації, який гарантує однакове та однозначне розуміння вимоги як замовником, так і командою розробки. На практиці потрібна глибина опису часто визначається досвідом.
Якщо вимога передбачає розрахунок певних показників, обов’язково потрібно описати методологію розрахунку та додати наочні приклади. Бажано також показати розрахунки для складних або нетипових ситуацій, щоб продемонструвати всі можливі нюанси.
Необхідно описати поведінку системи в особливих ситуаціях — наприклад, у разі різних типів помилок або альтернативних сценаріїв роботи. Важливо не лише визначити, що саме повинна робити система, але й як саме це відбуватиметься. Для цього часто використовують, наприклад, Use Case-сценарії.
Розробники можуть реалізувати необхідний функціонал, але послідовність дій для досягнення результату може виявитися незручною для користувача. У такому випадку реалізацію доведеться переглядати.
Також важливо забезпечити відповідність інтерфейсу користувача та поведінки системи прийнятій дизайн-системі. Якщо такої системи немає, варто хоча б створити її базову версію та дотримуватися її. Інакше однакові елементи інтерфейсу можуть почати працювати по-різному в різних частинах системи.
Не слід забувати і про права доступу (permissions) для різних ролей у системі.
Окремо потрібно описати:
- стан елементів при відкритті сторінки;
- значення за замовчуванням;
- поведінку системи при зміні пов’язаних параметрів.
Наприклад, на сторінці можуть бути такі параметри:
- тип задачі (тип 1 — обраний за замовчуванням, доступні дві періодичності; тип 2 — доступна лише періодичність «щоденно»);
- періодичність (за замовчуванням «одноразово», альтернативний варіант — «щоденно»);
- час запуску (за замовчуванням 18:00).
Виникає питання: як повинна поводитися система, якщо користувач змінить час запуску на 19:00, а потім переключить тип задачі на тип 2?
- Чи зміниться періодичність автоматично на «щоденно»?
- Чи залишиться час запуску 19:00?
- Чи він повернеться до значення за замовчуванням 18:00?
- Якщо знову обрати тип 1, чи залишиться періодичність «щоденно»?
Такі нюанси також потрібно описувати у вимогах, оскільки рішення в кожному випадку може бути різним залежно від бізнес-логіки.
Корисно проводити сценарне моделювання роботи системи, щоб визначити:
- у яких ситуаціях можливі збої;
- до яких наслідків вони можуть призвести;
- як ці ситуації обробляти або запобігати їм.
Наприклад, якщо система отримує дані з групи пристроїв для розрахунку певних показників, потрібно передбачити ситуацію, коли частина пристроїв стає недоступною. У вимогах має бути описано, як у такому випадку повинні розраховуватися показники.
Бажано також мати прототипи або макети сторінок системи, особливо якщо їх створює сам бізнес-аналітик. У деяких випадках потрібно навіть узгодити кольорову палітру з замовником, щоб система була доступною для людей із особливостями сприйняття кольорів.
Для веб-застосунків корисно створити схему маршрутизації (routing) між сторінками. Вона дозволяє швидко зрозуміти, куди потрапляє користувач і як організована навігація в системі.
Також бажано фіксувати, яку саме бізнес-потребу закриває кожна вимога.
Адміністративний блок
Цей блок стосується дотримання процесів та регламентів організації під час роботи з вимогами.
Сюди можуть входити такі дії:
Реєстрація вимоги в системі.
Іноді через терміновість продакт-менеджери ставлять задачі розробникам напряму, без оновлення технічного завдання та без інформування аналітиків. У результаті виникає плутанина: незрозуміло, чи це баг, нова функція, чи просто зміни не були зафіксовані в документації.
Тому важливо підтримувати узгоджену комунікацію в команді та своєчасно оновлювати документацію. Інакше кількість неактуальних документів почне швидко зростати.
Узгодження вимоги із замовником.
Розробку варто починати лише після остаточного погодження вимоги та термінів її реалізації.
Рев’ю вимоги іншими аналітиками або розробниками перед відправкою замовнику.
Ведення версійності вимог.
Відстеження руху вимоги по процесу.
Декомпозиція задач на реалізацію вимоги.
Дотримання цих практик дозволяє у будь-який момент зрозуміти:
- на якому етапі знаходиться вимога;
- що відбувалося раніше;
- які зміни вносилися в документ.
Це особливо важливо, коли вимог багато.
Якість вимог
У цьому блоці вимоги перевіряються на відповідність критеріям якості.
До таких критеріїв зазвичай належать:
- повнота (вимога містить усю необхідну інформацію для розробки та розуміння, без пропущених деталей);
- узгодженість (вимога не суперечить іншим вимогам, правилам системи або бізнес-логіці);
- однозначність (вимога сформульована так, щоб її не можна було трактувати по-різному);
- здійсненність (вимогу реально реалізувати з урахуванням технічних можливостей, ресурсів і часу);
- перевірюваність (тестованість)(можна чітко перевірити, чи виконана вимога (наприклад, через тестування або критерії приймання);
- пріоритетність (вимога має визначений рівень важливості відносно інших вимог);
- атомарність (вимога описує одну конкретну функцію або поведінку, а не кілька різних речей одночасно);
- необхідність (вимога дійсно потрібна для досягнення бізнес-цілей або роботи системи);
- трасованість (можна простежити зв’язок вимоги з бізнес-потребою, задачами розробки та тестами);
- модифікованість (вимогу легко змінити або доповнити без порушення структури документа);
- зрозумілість (вимога написана простою і чіткою мовою, зрозумілою для всіх учасників проєкту).
Оскільки тема якості вимог досить широка і добре описана в літературі та інтернеті, детально зупинятися на ній немає потреби.
Оформлення та стиль
До цього блоку належать аспекти, що впливають на зручність читання та сприйняття документа.
Зокрема:
- відповідність прийнятому стандарту оформлення (наприклад внутрішні стандарти організації тощо);
- використання загальноприйнятої термінології (тут можливо створити Глосарій, або словник технічних термінів, що будуть використовуватись в подальшому);
- фіксація всіх термінів у спеціальному розділі (Глосарій — терміни конкретного проєкту або документа. Словник технічних термінів — загальний довідник термінів певної галузі);
- єдиний стиль тексту (відступи, вирівнювання, нумерація списків);
- використання дієслів у наказовому способі;
- уникнення слів, які можна трактувати неоднозначно;
- лаконічність тексту;
- мінімальна кількість довгих складних речень;
- відсутність орфографічних і пунктуаційних помилок.
Щодо графічних матеріалів:
- вони повинні бути читабельними;
- мати спокійну кольорову палітру;
- не містити спотворених пропорцій;
- мати адекватний розмір.
Таблиці також варто оформлювати за єдиним принципом: назва таблиці, заголовки колонок, зазначення одиниць виміру.
Не менш важливо дотримуватися коректної нумерації розділів і пунктів.
Інші аспекти
До цієї категорії можна віднести практики, які складно формально класифікувати, але вони допомагають покращити якість вимог.
Наприклад, корисно після написання вимоги зробити паузу на кілька днів, а потім перечитати її ще раз. Дуже часто під час повторного перегляду стають помітними неточності або моменти, які варто уточнити чи виправити.