Переклад статті, опублікованої у Community-Z
Якість специфікації багато в чому визначає якість кінцевого продукту. Неточна, непослідовна, неповна або навіть неправильна функціональна специфікація додатково призводить до дефектів у програмі через прогалини в аналізі, непорозуміння, надмірну інтерпретацію тощо. Більшості з цих проблем можна уникнути, якщо прийняти деякі передові методи створення специфікацій та усунути найбільш поширені помилки.
Специфікація функціональних вимог є основним обов’язком бізнес-аналітика та одним із факторів успіху ІТ-проекту. Якість цієї специфікації багато в чому визначає якість кінцевого продукту. Неточна, непослідовна, неповна або навіть неправильна функціональна специфікація додатково призводить до дефектів у програмі через прогалини в аналізі, непорозуміння, надмірну інтерпретацію тощо. Більшості з цих проблем можна уникнути, якщо прийняти деякі передові методи створення специфікацій та усунути найбільш поширені помилки.
Незалежно від того, за якою методологією ви працюєте, описуючи вимоги:
- Визначте шаблони для опису вимог. Детальний опис вимог має бути створений за допомогою стандартного шаблону з місцем для всієї відповідної інформації. Вимоги легше читати та отримувати. Це дозволяє уникати можливості пропуску важливої інформації. Приклад такого шаблону наведено нижче з використанням техніки «5Ws 1H».
- Використовуйте відповідні схеми та прототипи. Діаграми, що входять до опису вимог, виражають перебіг процесу, систематизують зміст і показують кореляції. Прототипи — це найпростіший спосіб описати вимоги до інтерфейсу користувача, оскільки зображення коштує тисячі слів.
- Підкріпіть текстовий опис іншими описами. Деякі вимоги доречні для опису за допомогою математичних рівнянь, таблиць, логічних умов або навіть мов програмування. Однак такий опис не повинен замінювати, а лише підтримувати текстовий опис.
- Наведіть приклади. У багатьох випадках приклади є більш зрозумілими, ніж докладний опис. На прикладах часто можна зловити конкретні крайні випадки.
- Використовуйте просту і строгу мову. Вимога/історія користувача має бути викладена простою та строгою мовою без складних речень та витонченого словникового запасу ?. Це полегшує швидке читання та розуміння вимог. Кожен читач буде вдячний вам за це.
Буде корисно: Гайд по User Stories для Junior BA
Техніка «5Ws 1H»
Типова історія користувача складається з певної фрази:
As a [type of user]
I want to [perform some task]
so that I can [reach some goal]
У багатьох випадках такий опис недостатньо точний. Щоб знати, як задовольнити такі вимоги, необхідні додаткові специфікації. Ось чому я застосував до свого User Storis техніку «5Ws 1H», яку використовують менеджери проектів для вирішення проблем. 5Ws означає Що, Хто, Чому, Коли, Де, а 1H означає Як. Для детального опису концепції див.: https://en.wikipedia.org/wiki/Five_W.
Хоча стандартна історія користувача охоплює лише відповіді на запитання: хто, що і чому, відповідь на решту запитань дозволяє мені бути більш точним із вимогою.
- Що – загальний опис функціональності
- Хто – користувач з певною роллю
- Чому – бізнес-ціль
- Коли – ситуація, коли ця історія користувача застосовна/ будь-які передумови, які мають бути виконані
- Де – конкретне місце в програмі або базі даних
- Як – графічний опис вимоги (схема процесу, прототип UI тощо) та список критеріїв приймання
Приклад використання техніки «5Ws 1H» в User Story:
What: Permissions management
Who: User with administrator role
Why: To allow the administrator to set permissions for individual roles in the system
When: User is logged in as an administrator. The system has set at least one role.
Where: Application -> Main Menu -> Admin panel -> User management
How:
Цікавий кейс: Як схрестити слона з бегемотом, або Чи можна поєднати User Stories та Use Cases в одному проєкті
Acceptance criteria:
- Admin should be able to indicate access rights for each area on 4 levels of access:
- Create
- Read
- Update
- Delete
2. Changes on access rights should be saved by clicking ‘Save’ button.
3. User is able to abort changes by clicking ‘Cancel’ button.
INVEST – оцінка якості історії користувача
Варто звернути особливу увагу на якість історії користувача. Щоб полегшити це, було створено корисну абревіатуру, яка утворює легко запам’ятовується англійське слово INVEST:
- Independent – історії користувачів повинні забезпечувати цінність незалежно один від одного. Це не означає відсутність будь-яких зв’язків. Вони можуть вказувати на те, що дана історія користувача має бути реалізована раніше іншої або що впровадження однієї значно зменшить зусилля щодо впровадження іншої. Річ у тому, що історія користувача має становити певне, окреме й логічне ціле.
- Negotiable – історія користувача повинна бути предметом обговорення. Це означає, що має бути простір для обговорення та переговорів щодо того, як має виглядати рішення. Не створюйте занадто «технічну» історію користувача, яка нав’язує командам розробників точний спосіб створення рішення. Це піддає ризику не помітити потенційно краще рішення.
- Valuable – кожна історія користувача повинна приносити певну цінність для користувача. Якщо реалізація історії користувача не дає ніякої цінності, навіщо про це турбуватися?
- Estimable – правильно визначена історія користувача має бути можливою для «оцінки», тобто визначення зусиль, необхідних для її реалізації. Звичайно, мова йде не про точні оцінки в днях чи годинах, а про відносні оцінки з використанням відносних одиниць (наприклад, балів історії). Оцінку значно полегшує визначення чітких і недвозначних критеріїв приймання.
- Small – занадто велику історію користувача важко точно оцінити, спланувати, розбити на завдання та перевірити.
- Testable – історія користувача повинна бути такою, що можна перевірити (відтестувати), щоб остаточно позначити її як DONE.
Після створення історії користувача проконсультуйтеся з командою і переконайтеся, що немає питань і відкритих трактувань. Отримайте підтвердження від членів команди, що все достатньо зрозуміло.
До теми: User Story та Acceptance Criteria: пишемо чіткі та зрозумілі вимоги
Хоча нині ми працюємо переважно в Agile-проектах, де слід вітати зміни, ми заощадимо багато часу та зусиль, якщо заздалегідь точно визначимо вимоги. Однак, пам’ятайте про маніфест Agile, який цінує «робоче програмне забезпечення над вичерпною документацією».
Автор: Magdalena Gluska (EPAM, Senior Business Analyst)
Стаття опублікована 6 грудня 2021