Требования не меняются, это мы их недовыявили

Конспект статьи. Автор оригинала: Юрий Куприянов (systems.education)

Автор спорит с тезисом, что требования постоянно меняются: чаще они просто не выявлены полностью на старте. По его опыту, после применения всех техник объём требований вырастает в полтора-два раза.

Почему требования «меняются»

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

Инструменты проверки полноты

• User Story Map — шаги процесса слева направо, акторы, карточки требований по приоритету. Выявляет пропущенные этапы.
• Модель данных — выделение сущностей из текстов интервью и регламентов, затем концептуальная ER-модель. Кратности связей порождают новые вопросы.
• Диаграммы состояний — для каждого перехода нужны сценарий и бизнес-правила.
• CRUD + LSHAX (List, Search, History, Archive, eXecute) — для каждого объекта и операции: кто вправе, при каких состояниях, кого уведомить, нужно ли подтверждение, можно ли отменить, что журналировать.

Что ещё часто забывают

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