Разработка требований

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

Определите источники требований

В качестве таких источников могут выступать:
- Начальники любого уровня
- Сами разработчики
- Инженеры других отделов
- Сотрудники коммерческого отдела, менеджеры
- Представители сотрудничающей организации
- Отдел клиентской поддержки (Customer service)
- Конечные клиенты (Retail customers)
Определите, кто, как и когда может вносить на рассмотрение требования к ПО

При этом не следует ограничивать всех вышеперечисленных действующих лиц какими-либо форматами или средствами. Будьте готовы, что при необходимости требования будут озвучены устно или по телефону, будут отправляться письмом или по ICQ, при чем в том виде, в котором удобно тому, кто данное требование высказывает. В разработке требований будут участвовать самые нетехнические специалисты или даже не специалисты. Главное здесь добиться следующего:
1. Чтобы разработчик мог работать, не отвлекаясь (см. общие требования по организации процесса разработки).
2. Дать понять всем участникам процесса, что тот факт, что требование зафиксировано, не означает того, что оно будет выполнено.
Участвуйте в разработке требований

Может случиться так, что по разным причинам, вы окажетесь не вовлеченными в процесс обсуждения разрабатываемой системы, и не будете иметь информации о проводимых совещаниях и их результатах. Вместо этого вы будете иметь дело с уже написанными документами. Такое вполне может произойти, если ваша основная позиция - разработчик и считается, что ваша задача - исполнять требования, а не тратить время на их обсуждение. Такое может случиться, если компания имеет несколько территориально удаленных филиалов. В любом случае, постарайтесь убедить руководство в том, что вам, как лицу, осуществляющему планирование и управление процессом разработки, необходимо участвовать в таких обсуждениях
Фиксируйте требования!

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

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

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

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

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 таблицы будет рассмотрено в следующих пунктах.

Направления улучшения данного процесса:
1. Фиксировать все требования, а не только утвержденные
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