Требования: сердце работы аналитика
Как превратить «хочу вот такое» в то, что можно построить и проверить.
Что такое требование
Требование — это описание того, что система должна делать или какой должна быть. Пишется в форме «Система должна…». Из требований потом рождается всё остальное: схемы, ТЗ — техническое задание, код и тесты.
Урок 1. Актор ≠ стейкхолдер
Аналитик всегда разделяет тех, кто жмёт кнопки, и тех, кому важен результат.
flowchart LR
M(("Менеджер")):::actor -->|пользуется| S["Калькулятор
доходности"]:::hl
S -. выгода .-> BANK["Банк"]:::sh
S -. выгода .-> CL["Клиент"]:::sh
classDef actor fill:#2f6f8f,stroke:#2f6f8f,color:#fff;
classDef hl fill:#b1121f,stroke:#b1121f,color:#fff;
classDef sh fill:#eef4f7,stroke:#2f6f8f,color:#20323b;
- Актор — actor, «действующее лицо» — тот, кто руками работает с системой. Здесь: менеджер.
- Стейкхолдеры — stakeholders, «держатели интереса» — кому важен результат, но кнопки не жмут. Здесь: банк (продать маржинальные продукты) и клиент (не потерять на инфляции).
Урок 2. Требование должно быть проверяемым
| Формулировка | Проверяемо? | Почему |
|---|---|---|
| Показывать реальную доходность вклада | ✅ да | видно на экране — либо есть, либо нет |
| Помочь менеджеру продать инвестиции | ✕ нет | это бизнес-цель, не требование — не ткнёшь и не проверишь |
| Посчитать прибыль по инвестпродукту | ✅ да | ввёл данные → получил число |
| ⚠ почти | слово «правильно» неизмеримо — убрать |
Бизнес-цель не выбрасываем, а переводим в проверяемое требование:
Урок 3. Функциональные vs нефункциональные
| Тип | Отвечает на вопрос | Пример |
|---|---|---|
| Функциональные functional | что система делает? | считает, показывает, сравнивает |
| Нефункциональные non-functional | какой она должна быть? | скорость, надёжность, безопасность, язык интерфейса |
Пример нефункционального требования к калькулятору: «пересчёт мгновенный при изменении любого поля» и «на экране дисклеймер, что это не индивидуальная рекомендация». Второе ты в реальном калькуляторе уже сделал, только не знал термина.
Данные: контракт «вход → система → выход»
Любую систему полезно представить как «чёрный ящик»: что в неё входит и что выходит.
flowchart LR in1["Сумма"] --> SYS in2["Ставка, %"] --> SYS in3["Инфляция, %"] --> SYS SYS["Расчёт по формуле
Фишера"]:::hl SYS --> o1["Реальная сумма"] SYS --> o2["Разница с вкладом"] classDef hl fill:#b1121f,stroke:#b1121f,color:#fff;
Эталон: как звучит готовое описание
Актор: менеджер банка.
Стейкхолдеры: банк (рост продаж), клиент (сохранность средств).
Проблема: клиент видит номинальную ставку и не замечает, что инфляция съедает доходность; менеджеру нечем это наглядно показать.
Функциональные требования:
- Система должна рассчитывать реальную доходность вклада с учётом инфляции.
- Система должна рассчитывать доходность инвестпродукта за тот же срок.
- Система должна показывать сравнение вклада и инвестпродукта на одном экране.
Нефункциональные требования:
- Пересчёт мгновенный при изменении любого поля.
- На экране — дисклеймер о том, что это не индивидуальная рекомендация.