Заметки бизнес-аналитика
Главная › Бизнес-анализ

Требования: виды и качество

На странице

Уровни требований

Классическая схема по Вигерсу — от «зачем» к «как именно»:

УровеньОтвечает на вопросПример
Бизнес-требованияЗачем бизнесу это нужноСократить время обработки заявки с 2 дней до 4 часов
Пользовательские требованияЧто пользователь хочет сделатьМенеджер хочет видеть все новые заявки в одном списке
Функциональные требованияЧто должна делать системаСистема должна отображать список заявок со статусом «Новая», отсортированный по дате создания

Рядом с ними живут:

  • Нефункциональные требования — атрибуты качества: скорость, надёжность, безопасность и т.д.
  • Бизнес-правила — правила предметной области, не зависящие от системы. Например: «скидка не может превышать 30%».
  • Ограничения — то, что сужает выбор решения. Например: «только PostgreSQL», «хранение данных в РФ», «срок — до 1 марта».

Схема Вигерса: где фиксируются и откуда берутся требования

Каждый уровень требований описывается в своём документе, и у каждого свои источники:

Тип требованияГде фиксируетсяИсточники
Бизнес-требованияДокумент концепции и границ (Vision & Scope)Спонсор и заказчик проекта, руководство, владелец продукта, маркетинг, бизнес-кейс и стратегия компании, анализ рынка и конкурентов
Пользовательские требованияДокумент пользовательских требований: варианты использования, user story, сценарииПредставители классов пользователей и «защитники продукта» (product champions), интервью и воркшопы, наблюдение за работой, анализ задач пользователей
Функциональные требованияСпецификация требований к ПО (SRS)Выводятся аналитиком из пользовательских требований, бизнес-правил и атрибутов качества; уточняются с разработчиками и архитектором
Бизнес-правилаКаталог бизнес-правилКорпоративные политики и регламенты, законы и постановления, отраслевые стандарты, вычислительные правила (формулы, тарифы)
Атрибуты качестваSRS, раздел нефункциональных требованийПользователи, эксплуатация и служба поддержки, безопасность, архитектор, SLA похожих систем, ожидаемая нагрузка от бизнеса
Внешние интерфейсыSRS, раздел интерфейсов; спецификации APIВладельцы смежных систем, документация внешних API, оборудование, протоколы обмена
ОграниченияSRS, раздел ограниченийКорпоративные ИТ-стандарты, архитектурная служба, бюджет и сроки, требования к платформе, регуляторы
Системные требованияСпецификация системных требованийДля систем из нескольких подсистем, в том числе с оборудованием: распределяются по подсистемам (ПО, железо, люди)

Типичные источники требований по Вигерсу

  • Интервью и обсуждения с пользователями — основной источник; важно охватить все классы пользователей.
  • Описания текущих бизнес-процессов и того, что в них не устраивает.
  • Документация существующей системы: руководства пользователя, старые ТЗ, отчёты, экранные формы. Помогает понять, что нужно сохранить, а что изменить.
  • Анализ рынка и конкурентов: какие функции есть у похожих продуктов.
  • Обращения в поддержку и отчёты о проблемах: реальные боли пользователей текущей системы.
  • Маркетинговые опросы и анкеты: когда пользователей много и нужно понять предпочтения большинства.
  • Наблюдение за работой пользователей: выявляет то, что люди делают по привычке и не упоминают на интервью.
  • Анализ сценариев задач пользователей: от задач пользователя к функциям системы.
  • События и реакции системы: какие внешние события (сигналы, сообщения, время) должна обрабатывать система и как на них реагировать.
  • Законы, регламенты и стандарты: обязательные требования, о которых стейкхолдеры могут не упомянуть (152-ФЗ, PCI DSS, ГОСТ).
На собеседовании полезно связать источник с уровнем: бизнес-требования приходят от спонсора и из стратегии, пользовательские — от представителей пользователей, функциональные аналитик выводит сам, а бизнес-правила и ограничения часто лежат в документах, а не в головах людей.

ФТ и НФТ

ФТ описывают, что делает система: функции, реакции на действия, обработку данных.
НФТ описывают, насколько хорошо и при каких условиях она это делает.

ФТНФТ к той же функции
Система позволяет найти товар по названиюПоиск возвращает результат не дольше 1 с для 95% запросов при 500 одновременных пользователях
Пользователь может оплатить заказ картойПлатёжные данные передаются только по TLS 1.2+, номер карты не хранится в системе
Система формирует отчёт о продажахОтчёт за год строится не дольше 30 с
Типичная ошибка: считать функциональными требованиями требования к интерфейсу («кнопка зелёная») или писать НФТ без метрики («система должна быстро работать»). НФТ без числа нельзя проверить, а значит, это не требование.

Классификации НФТ

FURPS+

  • Functionality — функциональность. Сюда же часто относят безопасность.
  • Usability — удобство использования.
  • Reliability — надёжность: доступность, восстановление после сбоев.
  • Performance — производительность: время отклика, пропускная способность.
  • Supportability — сопровождаемость: тестируемость, расширяемость, локализация.
  • + — ограничения: проектные, реализационные, интерфейсные, физические, юридические.

ISO/IEC 25010

Подробнее — в подразделах «FURPS+ и ISO/IEC 25010» и «Чек-лист НФТ».

Стандартная модель качества продукта. Характеристики: функциональная пригодность, производительность, совместимость, удобство использования, надёжность, безопасность, сопровождаемость, переносимость. В редакции 2023 года к ним добавили взаимодействие (interaction capability) и защищённость от вреда (safety).

Примеры измеримых НФТ

  • Производительность: время отклика API каталога не больше 300 мс для 95-го перцентиля при 200 RPS.
  • Доступность: 99,9% в месяц, то есть не больше 43 минут простоя.
  • Восстановление: RTO — 1 час, RPO — 15 минут.
  • Безопасность: пароли хранятся только в виде хеша (bcrypt/argon2), после 5 неудачных попыток вход блокируется на 15 минут.
  • Удобство: новый оператор оформляет заказ без обучения быстрее чем за 3 минуты.
  • Масштабируемость: система выдерживает рост числа заказов в 3 раза без изменения архитектуры.

Свойства хорошего требования

  • Однозначное — все понимают его одинаково. Слова-маркеры проблемы: «быстро», «удобно», «и т.д.», «при необходимости».
  • Проверяемое — можно написать тест и получить «да» или «нет».
  • Полное — описаны входы, выходы, ошибки и граничные случаи.
  • Согласованное — не противоречит другим требованиям.
  • Атомарное — одно требование описывает одну вещь.
  • Трассируемое — понятно, откуда оно пришло (цель, стейкхолдер) и где реализовано и проверено.
  • Реализуемое — укладывается в технические и бюджетные рамки.

Вопросы для самопроверки

Чем ФТ отличаются от НФТ? Приведите пример к одной функции.

ФТ говорит, что система делает; НФТ — насколько хорошо или при каких условиях. Пример: «система отправляет SMS с кодом подтверждения» — это ФТ. «SMS доставляется не позже 30 с в 99% случаев» — это НФТ.

Откуда брать НФТ, если заказчик о них не говорит?

Из чек-листа категорий (FURPS+ / ISO 25010), законодательства (152-ФЗ, PCI DSS), требований эксплуатации и безопасности, текущих метрик и SLA похожих систем, ожидаемой нагрузки от бизнеса. Удобный формат — воркшоп с архитектором и эксплуатацией по сценариям атрибутов качества.

Что такое бизнес-правило и чем оно отличается от требования?

Бизнес-правило существует независимо от системы, это политика или закон предметной области. Требование описывает, как система будет это правило поддерживать. Правило: «возврат товара — в течение 14 дней». Требование: «система блокирует кнопку возврата, если с даты доставки прошло больше 14 дней».

Как сделать требование «система должна быть надёжной» проверяемым?

Разложить его на метрики: доступность (99,9%), время восстановления (RTO), допустимая потеря данных (RPO), поведение при отказе внешней системы. Для каждой метрики указать способ измерения.

Конспекты статей по теме

Подробные конспекты полезных статей. В конце каждого есть ссылка на оригинал и автора.

← Подготовка к собеседованию аналитикаFURPS+ и ISO/IEC 25010 →