Простий спосіб почати збирати функціональні вимоги до проєкту

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

Проблема з розділенням вимог

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

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

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

Аналіз агентів (stakeholder analysis)

Будь-який збір вимог розпочинається з вивчення агентів (stakeholder’ів). Хто такі ці агенти? Це будь-хто, хто впливає на проєкт і, в першу чергу, це безпосередні замовники. Агентами також є розробники, т.з. “DevOps’и” інвестори, CEO, CIO, CTO, інші С-levels, яких стосується проєкт, спеціалісти з інформаційної безпеки, служба підтримки, звичайні користувачі системи, системні адміністратори, модератори та користувачі з іншими ролями, різноманітні регулятори.

Згідно принципу єдиної відповідальності (SRP – Single Responsibility Principle), має бути лише одна причина для змін і ця причина починається з того, для кого була створена певна функціональність. Можна сказати, що люди є причинами для змін. Таким чином, важливо замислитися над розробкою окремих рішень для кожної групи агентів.

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

Початок роботи над use-cases діаграмою для збору вимог
Початок роботи над use-cases діаграмою для збору вимог

Використання діаграм способів використання (use-cases diagrams)

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

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

Use-cases diagram with functional requirements.
Use-cases diagram with functional requirements.

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

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

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *