Рецензирование существующих требований

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

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

Механизмы формального рецензирования требований:

1. Распространение документации, которая должна быть рассмотрена, каждому из заинтересованных лиц для проверки.

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

3. Используйте контрольные списки для проверки каждого документа на покрытие каждой точки зрения. Смотрите раздел руководства “Валидация требований“.

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

5. Результаты анализа должны быть отмечены в качестве рабочих элементов либо требования, либо запроса на изменение или задачи для дальнейшего анализа или утверждения.

Тема выявления в Agile

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

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

1. Создание журнала продукта – для гибких команд (Scrum), журнал продукта представляет собой все требования, которые должны быть разработаны командой разработчиков. Владелец продукта несет ответственность за создание этого списка. Он может использовать многие из описанных выше методов для руководства в формировании списка. Однако основное различие заключается в том, что он обычно не обеспечивает формальности для этого. Планирование рассчитывается на очень короткий период времени, и вся группа заинтересованных лиц рассматривается в качестве однородной группы источников для различных требований, которые поставляются в журнал продукта. Качество журнала не столь высокое, как в традиционных проектах. Это не является ни риском, ни недостатком, потому что гибкая команда вновь будет пересматривать его с владельцем продукта и другими заинтересованными сторонами, чтобы углубиться в детали, когда придет время. Журнал продукта должен храниться в TFS как рабочие элементы “Требование”, “Сценарий” или “Качество обслуживания”.

2. Анализ Журнала итераций – как только “кусок” журнала продукта утвержден в качестве цели для итерации, члены команды разработчиков будут использовать в основном техники интервью и неофициальных раскадровок для конкретизации деталей пользовательского описания функциональности, опираясь на владельца продукта или его делегата для предоставления детализации. Документация используется по минимуму. Этого достаточно, чтобы позволить членам команды разработать и сопоставить поведение требований к архитектуре предприятия/приложения, написать свои тесты и код и выполнить приемо-сдаточные испытания для них. Для хранения элемент журнала, как правило, представляется в виде рабочего элемента “Требование” в шаблоне процесса MSF для CMMI , или “Сценарий” шаблона процесса MSF для Agile.