По заданной бизнес-ситуации выявить требования и написать понятную постановку, проверив её по чек-листу качества требований.
От ситуации к постановке: как это работает
От ситуации к постановке: как это работает
Реальная работа аналитика начинается с «сырой» просьбы заказчика, в которой перемешаны проблема, желаемое решение и домыслы. Задача — распутать этот клубок и сформулировать требования чётко.
Первый шаг: отделить проблему от решения. Заказчик часто говорит «нам нужна кнопка X» (решение), а реальная проблема — «мы теряем клиентов, потому что они не могут найти нужный товар» (проблема). Хороший аналитик задаёт вопрос «Зачем?» до тех пор, пока не доберётся до бизнес-цели.
Второй шаг: разложить требования по уровням. Бизнес-требование — зачем это нужно предприятию. Функциональное — что система должна делать. Нефункциональное — каким качеством она должна обладать (скорость, безопасность, надёжность), с конкретными цифрами. User story — «Как <роль>, я хочу <действие>, чтобы <ценность>» — с критериями приёмки в формате Given-When-Then.
Третий шаг: проверить по чек-листу качества — характеристики BABOK плюс два правила из стандартов IEEE/ISO: прослеживаемость и отсутствие решения внутри требования.
• Однозначно? Нет слов «быстро», «удобно», «и т.п.».
• Проверяемо? Можно написать тест.
• Непротиворечиво? Не конфликтует с другими требованиями.
• Выполнимо? Реально технически и по срокам.
• Прослеживаемо? Есть источник и связь с реализацией.
• Нет подмены проблемы решением? Описано «что и зачем», а не «как именно реализовать».
От просьбы к постановке
- 11
Отделить проблему от решения: спрашивать «зачем?», пока не появится бизнес-цель
- 22
Разложить требования по уровням: бизнес → стейкхолдеры → ФТ и НФТ
- 33
Записать историю «Как… я хочу… чтобы…» и критерии Given-When-Then
- 44
Проверить по чек-листу: однозначно, проверяемо, прослеживаемо, без решения внутри
Конспект урока
От ситуации к постановке: как это работает
Реальная работа аналитика начинается с «сырой» просьбы заказчика, в которой перемешаны проблема, желаемое решение и домыслы. Задача — распутать этот клубок и сформулировать требования чётко.
Первый шаг: отделить проблему от решения. Заказчик часто говорит «нам нужна кнопка X» (решение), а реальная проблема — «мы теряем клиентов, потому что они не могут найти нужный товар» (проблема). Хороший аналитик задаёт вопрос «Зачем?» до тех пор, пока не доберётся до бизнес-цели.
Второй шаг: разложить требования по уровням. Бизнес-требование — зачем это нужно предприятию. Функциональное — что система должна делать. Нефункциональное — каким качеством она должна обладать (скорость, безопасность, надёжность), с конкретными цифрами. User story — «Как <роль>, я хочу <действие>, чтобы <ценность>» — с критериями приёмки в формате Given-When-Then.
Третий шаг: проверить по чек-листу качества — характеристики BABOK плюс два правила из стандартов IEEE/ISO: прослеживаемость и отсутствие решения внутри требования.
• Однозначно? Нет слов «быстро», «удобно», «и т.п.».
• Проверяемо? Можно написать тест.
• Непротиворечиво? Не конфликтует с другими требованиями.
• Выполнимо? Реально технически и по срокам.
• Прослеживаемо? Есть источник и связь с реализацией.
• Нет подмены проблемы решением? Описано «что и зачем», а не «как именно реализовать».