Насколько этот пункт важен, настолько же часто им и пренебрегают. Еще раз о том, для чего нужно фиксировать требования:
Это касается как высокоуровневых требований, так и конкретных технических деталей. Если требование или пожелание к системе принято в процессе дискуссии, фиксируйте, кто принимал участие в дискуссии. Это позволит при необходимости выяснить детали, причины требований непосредственно с тем, кто данное требование высказал. Кроме того, вы сможете проанализировать, чьи требования учтены, а чьи - нет.
Определите тех лиц, кто должен утверждать требования. Не приступайте к разработке до того момента, пока требования не утверждены. Сделайте это правилом и не отступайте от этого никогда, иначе вы будете постоянно переделывать одну и ту же функциональность и убирать следы сделанных изменений
В самом простом варианте, я предлагаю следующий формат документа, содержащего утвержденные требования к системе
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 таблицы будет рассмотрено в следующих пунктах.
Направления улучшения данного процесса: