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