Нужно ли писать спецификацию требований?
Сергей Мартыненко предлагает задуматься об очевидных вещах. Например, зачем писать спецификации требований. Какие варианты использования полезны, а какие не очень.


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

Кажется, автор пропустил важный вопрос: нужна ли нам документация, описывающая состояние системы AS IS после завершения проекта? А через 2-3 года? Если да, то что заменит нам спеку?
С другой стороны, написание таких доков можно отдать техническому писателю. Не исключено, что получится лучше и дешевле.

Спецификация как контракт
Использовать спеку как контракт между разработкой и заказчиком бессмысленно из-за постоянного изменения требований. Согласно некоторым исследованиям, за 2 года требования на проекте изменяются минимум на 25%, в итоге получаем никому не нужный продукт.

Здесь многое зависит от того, кто у нас заказчик. Нередко подрядчики живут за счет того, что требования на длительных проектах регулярно меняются. Так возникают многочисленные Change Requests, стоящие денег. Если один хочет сделать нужный продукт/систему, это совсем не значит, что у его партнера та же цель. Просто бизнес.

Избыточные требования
Лучше набрать заведомо больше требований, чем мы можем или планируем реализовать. Таким образом мы стремимся достичь полноты требований. Чем больше требований собрали, тем выше вероятность, что не пропустили важное/необходимое.

Без ошибок грустно
Если в требованиях не выявили проблемы, то что-то пошло не так. Либо мы не увидели ошибки, и скоро будем из-за этого страдать, либо аналитик идеально создал концепцию системы. Но зачем тогда он ее описывал в документе? Согласно тезису о распространении идей, лучше бы он презентовал все устно.

Управление требованиями
Мы можем заранее набирать требования и компилировать их в задачи/релизы. В целом, реестр требований и процедуры управления намного важнее, чем разработка самих требований.

Выявление конфликтов
И докину вариант от себя.
Cпецификацию можно использовать как способ выявить противоречия между стейкхолдерами. Либо, если уже знаю о существовании противоречий, столкнуть их напрямую.
Сценарий прост:
1. Фиксируем версию одного из оппонентов
2. Выкладываем на общее ревью с просьбой прокомментировать.
3. Запасаемся попкорном

Это на случай, если нет возможности собрать их в одной комнате и не выпускать до получения необходимого результата

https://youtu.be/zVtTrXcHH2M