Выявление и документирование требований (BCS)

Главные идеи#

Начните с задания на проект: OSCAR#

Прежде чем что-либо выявлять, авторы книги BCS требуют чёткого задания на проект (terms of reference). Их мнемоника OSCAR охватывает Objectives — цели, Scope — границы, Constraints — ограничения (бюджет, сроки, стандарты), Authority — полномочия (кто разрешает конфликты между требованиями) и Resources — ресурсы. Без них требования уходят в сторону от того, чего бизнес пытается достичь.

Кто участвует#

Со стороны бизнеса — спонсор (согласует задание на проект, выделяет ресурсы, подписывает требования, разрешает конфликты), эксперты в предметной области и бизнес-пользователи. Внешний эксперт в предметной области приносит отраслевую практику, но может не знать культуры и внутренней политики компании, и его могут воспринимать как чужака. Со стороны проекта — руководитель проекта, бизнес-аналитик и разработчик, который проверяет техническую осуществимость и может создавать прототипы.

Неявное знание#

Книга опирается на наблюдение Майкла Полани: люди знают больше, чем могут рассказать. Формы неявного знания (tacit knowledge), на которые стоит обращать внимание:

• Навыки, отработанные до автоматизма и поэтому трудные для описания.
• Само собой разумеющиеся факты, о которых эксперт не упоминает, потому что они кажутся очевидными. Они всплывают на приёмочном тестировании или после запуска, когда их исправление обходится дорого.
• Парадная версия и закулисье (front story / back story): люди описывают приглаженную версию своей работы. Фраза «всё работает без сбоев» — сигнал проверить цифры.
• Представить новое трудно, если нет прототипа, на который можно отреагировать.
• Разные нормы: в книге рассказывается об исследователе, который указал на гору, чтобы спросить её название, и записал местное слово, означавшее «твой палец».
• Интуиция эксперта и организационная культура, включая сообщества практики со своими неписаными правилами.

Чтобы вывести такое знание на поверхность, BCS предлагает четыре подхода: ученичество (apprentice: ходить за экспертом по пятам или проводить анализ протокола, когда эксперт работает и рассуждает вслух), наблюдение (observe), пересказ (recount: истории и сценарии) и разыгрывание (enact: прототипы и ролевое проигрывание сценариев).

От списка к каталогу#

Сырые требования сначала попадают в простой список требований: требование, источник, комментарий. Затем аналитик пропускает список через фильтры:

• Отнесите каждое требование к категории.
• Объедините дубликаты и разделите пересекающиеся требования.
• Разбейте составные требования так, чтобы каждое говорило об одном.
• Проверьте необходимость: требование должно поддерживать цели проекта и относиться к проблеме, а не к симптому.
• Проверьте техническую, деловую и финансовую осуществимость.
• Разрешите конфликты переговорами, при необходимости — с эскалацией к спонсору.
• Уберите замаскированные решения: требование говорит, что нужно бизнесу, а не как это обеспечить.

Каждое оставшееся требование должно быть ясным, кратким, непротиворечивым, относящимся к делу, однозначным, правильным, проверяемым и трассируемым. BCS рекомендует форму действующее лицо + глагольная группа + объект и итоговую проверку по SMART.

Четыре категории#

• Общие: деловые ограничения, политики, правовые требования, требования к фирменному стилю, культурные и языковые требования, требования к непрерывности бизнеса.
• Технические: оборудование, программное обеспечение, совместимость систем.
• Функциональные: ввод данных, ведение данных, процедуры, получение данных (отчёты и запросы).
• Нефункциональные: скорость, безопасность, доступ, резервное копирование и восстановление, архивирование, сопровождаемость, доступность, удобство использования и ёмкость системы. Авторы предупреждают, что эти требования часто откладывают или прорабатывают поверхностно и что это становится причиной многих реальных провалов.

Общие требования часто раскладываются на остальные: закон о защите данных превращается в уровни безопасности (нефункциональные требования) и правила доступа (функциональные).

Документирование, валидация, управление#

Документ требований по BCS состоит из шести частей: введение и предыстория, модели бизнес-процессов, функциональные модели (контекстная диаграмма и диаграмма вариантов использования), модель данных, каталог требований и глоссарий.

В валидации участвуют спонсор, владельцы требований, эксперт в предметной области, разработчики, тестировщики и проектный офис. По итогам каждое требование либо принимается как есть, либо принимается после небольших правок, либо отправляется на доработку и повторное рассмотрение.

Для приоритетов используется MoSCoW из DSDM Atern: Must have (в первом инкременте), Should have (может ненадолго отложиться), Could have (исключается первым, если не хватает времени) и Won’t have this time (в этот раз не делаем).

Управление требованиями — это трассировка каждого требования назад, к его источнику, и вперёд, к тому, что с ним стало, а также управление конфигурацией: версии 0.1, 0.2 для черновиков, 1.0 для проверенной базовой версии, 2.0 и далее после одобренных изменений.