Насколько этот пункт важен, настолько же часто им и пренебрегают. Еще раз о том, для чего нужно фиксировать требования:
Чтобы формально утверждать
Чтобы планировать работу
Чтобы проверять работу
Чтобы аргументированно спорить с заказчиком
Чтобы обучать разработчиков и пользователей
Чтобы иметь возможность проверить правильность работы системы при модификациях
Чтобы иметь возможность заменить одну часть системы другой
Фиксируйте источники требований
Это касается как высокоуровневых требований, так и конкретных технических деталей. Если требование или пожелание к системе принято в процессе дискуссии, фиксируйте, кто принимал участие в дискуссии. Это позволит при необходимости выяснить детали, причины требований непосредственно с тем, кто данное требование высказал. Кроме того, вы сможете проанализировать, чьи требования учтены, а чьи - нет.
Утверждайте требования
Определите тех лиц, кто должен утверждать требования. Не приступайте к разработке до того момента, пока требования не утверждены. Сделайте это правилом и не отступайте от этого никогда, иначе вы будете постоянно переделывать одну и ту же функциональность и убирать следы сделанных изменений
В самом простом варианте, я предлагаю следующий формат документа, содержащего утвержденные требования к системе
1
2
3
4
5
6
7
8
#
User Story
Comments
Priority (1,2...)
Realize in iteration #
Realize in version #
Man-hours estimated
Man-hours used
До момента утверждения я обычно хранил все требования в оригинальном виде: в виде электронных писем, записей в блокноте и т.д. Более подробно о том, как заполнять пункты 4-8 таблицы будет рассмотрено в следующих пунктах.
Направления улучшения данного процесса:
Фиксировать все требования, а не только утвержденные
Forekc.ru
Рефераты, дипломы, курсовые, выпускные и квалификационные работы, диссертации, учебники, учебные пособия, лекции, методические пособия и рекомендации, программы и курсы обучения, публикации из профильных изданий