Как найти пропущенные требования

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

Когда остановить выявление (на время)#

Полной завершённости вы не достигнете никогда, особенно в гибкой разработке. Вигерс и Битти перечисляют практические сигналы того, что пора двигаться дальше:

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

Подразумеваемые и неявные требования#

• Подразумеваемые требования (assumed requirements) — то, чего люди ждут, не говоря об этом, потому что это кажется очевидным. Что очевидно заказчику, не всегда очевидно разработчику.
• Неявные требования (implied requirements) логически следуют из сформулированного требования, но нигде не записаны. Если пользователи могут сохранить наполовину заполненную веб-форму, им нужно и открыть этот черновик снова. В книге описан портал, где никто не определил навигацию по иерархии контента; разработчики сделали плоский список с постраничным выводом по 20 элементов, и некоторые материалы приходилось искать, пролистывая больше 50 страниц.

Чтобы вывести на поверхность и те и другие, спрашивайте: «Что вы считаете само собой разумеющимся?», задавайте открытые, не зависящие от контекста вопросы («Какая точность нужна продукту?») вместо вопросов «да или нет», проводите повторные интервью и привлекайте заинтересованные стороны, которые ещё не участвовали. Свежий взгляд находит пробелы, которые не находит перечитывание.

Восемь проверок на пропущенные требования#

1. Декомпозируйте высокоуровневые требования, пока они не станут простыми. Расплывчатые формулировки верхнего уровня оставляют место для расхождения между тем, что представляет себе заказчик, и тем, что делает разработчик.
2. Проверьте охват классов пользователей. Каждое пользовательское требование должно приносить пользу хотя бы одному классу пользователей, и каждый класс пользователей должен быть услышан.
3. Трассируйте функциональные требования к их источнику: пользовательскому требованию, системному требованию или бизнес-правилу. Так видно, описано ли на самом деле всё необходимое.
4. Проверьте граничные значения. Одно требование для сумм меньше 100 $ и другое для сумм больше 100 $ оставляют неопределённой ровно сумму 100 $. Пропущенные требования часто прячутся на краях диапазонов.
5. Представьте информацию по-другому. Текст скрывает пробелы; на диаграмме недостающая стрелка или переход видны сразу.
6. Проверьте сложную логику. Сочетания И, ИЛИ и НЕ почти всегда неполны, и чаще всего пропущена ветка «иначе». Разложите логику в таблицу или дерево решений: они заставляют перечислить все сочетания.
7. Используйте чек-лист стандартных функциональных областей, о которых легко забыть: журналирование ошибок, резервное копирование и восстановление, безопасность доступа, отчёты, печать, предварительный просмотр, пользовательские настройки.
8. Проведите CRUD-проверку по модели данных. Для каждой сущности данных убедитесь, что там, где это имеет смысл, есть способ её создать (Create), прочитать (Read), изменить (Update) и удалить (Delete). Отсутствующая операция над важной сущностью — типичный симптом пропущенного требования.

Ещё одна проверка — пройти по атрибутам качества один за другим; см. Атрибуты качества программного обеспечения.

Два предостережения#

• Избегайте аналитического паралича. Цель — приемлемый уровень риска, а не 100% полноты.
• Уравновешивайте голоса. Не позволяйте самому громкому заказчику доминировать. Вигерс и Битти советуют, чтобы за каждым сторонником продукта стояла группа пользователей того же класса.

Авторы также отмечают, что граница между «что» и «как» размыта. Ранние наброски проектных решений и прототипы помогают выявлению, если вы предупредите участников, что они иллюстрируют идею и не являются окончательным дизайном.