Разработка требований - часть 2

Насколько этот пункт важен, настолько же часто им и пренебрегают. Еще раз о том, для чего нужно фиксировать требования:

1. Чтобы формально утверждать
2. Чтобы планировать работу
3. Чтобы проверять работу
4. Чтобы аргументированно спорить с заказчиком
5. Чтобы обучать разработчиков и пользователей
6. Чтобы иметь возможность проверить правильность работы системы при модификациях
7. Чтобы иметь возможность заменить одну часть системы другой

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

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

В самом простом варианте, я предлагаю следующий формат документа, содержащего утвержденные требования к системе

До момента утверждения я обычно хранил все требования в оригинальном виде: в виде электронных писем, записей в блокноте и т.д. Более подробно о том, как заполнять пункты 4-8 таблицы будет рассмотрено в следующих пунктах.

Направления улучшения данного процесса:

1. Фиксировать все требования, а не только утвержденные
2. Хранить версии требований и историю изменений