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

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

При работе над Agile проектами часто возникает вопрос, как организовать процесс сбора требований к разрабатываемой системе.

Общепринятым шаблоном сбора требований в Agile проектах является их проработка на одну итерацию раньше, чем девелопмент.

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

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