Уровень 1. Документация требований

Когда вы начали записывать и сохранять требования, то получаете сразу неоспоримые преимущества.

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

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

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

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

Уровень 2. Организация требований

Данный уровень модели зрелости для управления требованиями уже говорит о качестве требований – их формате, сохранности и версионности. Качественные требования понятны как заказчику, который их формирует, так и всем членам проектной команды, которые разрабатывают ПО, удовлетворяющее потребностям заказчика. Для этого требования должны быть не только читаемыми, но и однозначными и непротиворечивыми.

Требования должны быть хорошо отформатированы. Сквозная нумерация, постоянные схемы, заголовки, шрифты и хорошее оглавление делают ваши документы легкими для прочтения, понимания и дальнейшего использования. Если ваши требования хорошо описаны, но плохо отформатированы, то ваш документ может стать бесполезным в использовании. Форматирование – это простой прием, но почему-то часто игнорируется. Здесь могут помочь корпоративные или международные шаблоны спецификаций, такие как Концепция (Vision), Спецификация требований (Software Requirement Specification) и др. Причем во всей организации должны применяться единые форматирование и шаблоны.

У вас бывали случаи, что вы не могли найти актуальную версию необходимого документа требований? Или вы не могли понять, что изменилось в последней версии документа? У меня были такие случаи. Так вот, на втором уровне модели зрелости для управления требованиями вы должны иметь единое централизованное хранилище всех требований, причем оно должно быть известно и доступно всем участникам проекта. Сразу подумайте о защищенности и сохранности ваших документов. Возможно, вы захотите, чтобы участники одного проекта не смогли модифицировать документы требований другого проекта. Или захотите увидеть и сравнить текущий документ с его вариантом, созданным месяц назад. Подумайте также о версионировании документов и описаниях протокола изменений: кто, когда и в какой версии что исправил.

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

Улучшив процесс управления требованиями, вы получаете ПО, которое лучше отвечает требованиям заказчика. Вы перестаете делать одну и ту же работу дважды, вы начинаете повышать квалификацию проектной команды.