Приемы управления требованиями к ПО

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

Процесс управления требованиями

Под управлением требованиями подразумевают все действия, по обеспечению целостности, точности и своевременности обновления соглашения о требованиях в ходе проекта.
На рисунке «Основные составляющие управления требованиями» показаны базовые операции по управлению требованиями в четырех основных категориях:
— Управление версиями;
— Управление изменениями;
— Отслеживание состояния требований;
— Отслеживание связей требований.

Рисунок «Основные составляющие управления требованиями»

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

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

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

Базовое соглашение о требованиях

Стадия разработки подразумевает сбор информации, анализ, уточнение и утверждение требований к ПО в проекте. К результатам разработки требований относятся бизнес-требования, пользовательские требования, функциональные и нефункциональные требования, словарь данных и различные модели анализа. После рецензирования и утверждения любой из определенных наборов этих элементов составляет базовую версию требований.
Базовая версия (baseline) — это набор требований, согласованный заинтересованными лицами и часто определяющий содержимое определенного запланированного выпуска или итерации разработки. В проекте могут быть дополнительные соглашения относительно состава результатов, ограничений, графиков, бюджетов, переходных требований и контрактов, но это выходит за рамки этой книги.
Принятая базовая версия требований — как правило, версия становится базовой после официальных рецензирования и утверждения — передается в систему управления конфигурацией (или изменениями). Последующие изменения разрешается вносить в нее только через определенный в проекте процесс управления изменениями. До принятия базовой версии требования все еще изменяются, поэтому не имеет смысла ограничивать модификацию какими-то процедурами. Базовая версия может включать часть или все требования определенной спецификации (для всего продукта или одного выпуска) или определенный набор требований, хранящийся в системе управления требованиями, или согласованный набор пользовательских историй для одной итерации проекта гибкой разработки (agile).
Если границы выпуска меняются, в соответствии с этим нужно обновлять базовую версию требований. Необходимо ясно отличать требование в базовой версии от других, которые были предложены, но не утверждены, назначены в другую базовую версию или остаются не назначенными в резерве продукта. Если требования определены в форме документа, такого как спецификация требований к ПО, он должен быть ясно определен как базовый, чтобы отличать его от серии выполненных ранее набросков версий, которые еще не утверждены. Хранение требования в средстве управления требованиями облегчает идентификацию требований, принадлежащих определенной базовой версии, и управление изменениями в ней.
Разработчики, принимающие предлагаемые изменения или добавления требований, не всегда способны соблюдать текущий график и выполнять обязательства, касающиеся качества. Менеджер проекта должен обговорить изменения этих обязательств с другими менеджерами, работающими над проектом, клиентами и всеми заинтересованными в проекте лицами. При введении новых или изменении существующих требований существует несколько вариантов корректировки проекта:
• откладывание или полный отказ от реализации требований с низкими приоритетами;
• привлечение дополнительных сотрудников или аутсорсинг части работы;
• продление графика или добавление дополнительных итераций в проект гибкой разработки;
• снижение качества с тем, чтобы поставить продукт к оговоренному сроку.

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

Управление версиями требований

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

Это не дефект, а функция!
Разработчики, работающие по контракту, как-то получили массу отчетов об ошибках от людей, тестировавших последнюю версию системы, которую они только что поставили клиенту. Разработчики были в недоумении — система успешно прошла все их собственные проверки. После обстоятельного изучения проблемы, выяснилось, что клиенты тестировали новое ПО, сверяясь с устаревшей спецификацией требований. То, что тестировщики в отчетах называли ошибками, на самом деле было функциями.
В обычной ситуации это просто шутка, из тех, что любят программисты. Тестировщикам понадобилось много времени, чтобы переписать тесты в соответствии с последней версией спецификации и повторно протестировать продукт, а все из-за отсутствия управления версиями. Другой специалист, столкнувшийся с аналогичным непониманием при тестировании из-за отсутствия информации об изменении, рассказал: «Мы потратили на исправление от четырех до шести часов, которые пришлось потратить без возмещения, потому что мы не могли выставить счет за эти часы. Я думаю, что специалисты по разработке ПО придут в ужас, если умножат такие потраченные впустую часы на почасовую ставку и увидят, сколько денег они в виде недополученного дохода они теряют».
Аналогичный конфуз может произойти, когда над проектом работает несколько бизнес-аналитиков. Один бизнес-аналитик может начать редактировать версию 1.2 спецификации требований к ПО, а несколькими днями позже другой бизнес-аналитик может поработать над теми же требованиями, назначив им ту же версию 1.2, даже не подозревая о конфликте версий. Очень скоро изменения теряются, требования перестают быть актуальными, работу приходится переделывать и углубляется недопонимание.

Наиболее надежный метод управления версиями заключается в хранении требований в базе данных серийного средства управления требованиями. Эти средства отслеживают полную историю изменений требований, что особенно важно, если нужно вернуться к более ранней версии требования. Такое средство позволяет вносить комментарии, где можно разумно обосновать решение о добавлении, изменении или удалении требования; эти комментарии могут оказаться полезными при обсуждении требования в будущем.
Если вы сохраняете требования в документах, вы можете отследить коррективы с помощью режима изменений текста. Эта функция выделяет внесенную правку, зачеркивая удаленные фрагменты, подчеркивая добавленные и помечая вертикальными линиями на полях положение каждого изменения.
После того как вы составите базовую версию документа с такими пометками, сначала создайте архив версии с пометками, затем примите все коррективы, а затем сохраните очищенную версию за новую базовую версию для следующего раунда изменений. Храните документы требований в таком средстве управления версиями, как тот, что применяется для контроля исходного кода с помощью системы управления версиями (check-in и check-out). Это позволит при необходимости вернуться к более ранним версиям и знать, кто, когда и почему изменил документ. (Кстати именно так мы писали эту книгу. Мы писали главы в Microsoft Word, используя режим исправлений в процессе работы над главами. Несколько раз нам приходилось возвращаться к предыдущим версиям.)
Существует один проект, когда несколько сотен написанных в Microsoft Word вариантов использования продукта сохраняется в таком средстве управления версиями. Члены команды имеют доступ ко всем предыдущим версиям каждого варианта использования, для которых фиксируется история изменений. Бизнес-аналитику этого проекта и его заместителю, отвечающему за архивирование, предоставлен доступ на чтение и запись; остальным членам команды — доступ только на чтение. Такой подход хорошо себя зарекомендовал в этой команде.
Простейший механизм управления версиями — именовать вручную каждую версию спецификации требований к ПО согласно стандартному соглашению. Попытка различать версии документов по дате изменения или дате печати часто приводит к ошибкам и неразберихе. Несколько команд, в которых я работал, успешно применяли такое соглашение: первая версия любого нового документа называется «Версия 1.0 черновик 1». Следующий черновик называется «Версия 1.0 черновик 2». Автор последовательно увеличивает номер черновика при каждом изменении до тех пор, пока документ не будет одобрен или утверждена базовая версия документа. Тогда название меняется на «Версия 1.0 утвержденная». Следующие версии называются «Версия 1.1 черновик 1» при небольшом изменении или «Версия 2.0 черновик 1» при значительном изменении. (Разумеется, термины «небольшой» и «значительный» субъективны или, по крайней мере, зависят от контекста.) При применении этой схемы ясно различаются черновики и версии базового документа, однако необходимо соблюдать строгий ручной порядок в ведении документации.

Атрибуты требований

Представьте себе каждое требование в виде объекта, который обладает свойствами, отличающими его от других требований. В дополнение к тестовому описанию, каждое функциональное требование должно иметь несколько поддерживающих его фрагментов информации, или атрибутов (attributes), связанных с ним. Эти атрибуты представляют контекст и основу каждого требования, они располагаются за описанием предполагаемой функциональности. Вы можете сохранить атрибуты в таблице, базе данных или, что наиболее эффективно, в средстве управления требованиями. Сложно управлять более десятком атрибутов, когда они хранятся только в документах. Средства управления требованиями предоставляют несколько сгенерированных системой атрибутов, а также предоставляют возможность определить другие атрибуты, часть из которых может создаваться автоматически. Эти средства позволяют фильтровать, сортировать выбранные подмножества требований на основании значений их атрибутов и запрашивать базу данных для их просмотра. Например, можно вызвать список всех высокоприоритетных требований, которые Шери должна реализовать в версии 2.3 и которые имеют статус Approved (Одобрено). Далее приведены возможные атрибуты требований:
• дата создания требования;
• номер текущей версии требования;
• автор, создавший требование;
• приоритет;
• состояние требования;
• происхождение или источник требования;
• логическое обоснование требования;
• номер выпуска или итерации, на которую назначено требование;
• контактное лицо или ответственный за принятие решений по внесению изменений в требование;
• метод проверки или критерий приемки.

Для чего нужно это требование?
Менеджер продукта в компании, выпускающей электронные измерительные приборы, хотел просто записать включенные требования, потому что продукт конкурентов обладал теми же функциями. Такие функции хорошо отмечать с помощью атрибута Rationale (Обоснование), позволяющего указать, почему конкретное требование включено в продукт. Представьте, что вы включили определенное требование, потому что оно отвечает потребностям определенной группы пользователей. В дальнейшем в отделе маркетинга решили, что эта группа нас больше не интересует. Наличие такого обоснования в виде атрибута требования поможет решить, стоит ли реализовывать такое требование.
Еще один бизнес-аналитик удивляется включению требований без явных на то оснований. Он сказал: «По своему опыту могу сказать, что многие требования не подтверждены реальной потребностью. Они введены, потому что клиенты не понимают технологий, некоторые заинтересованные лица очарованы технологией и хотят произвести впечатление или наш отдел продаж осознанно или по недомыслию ввел клиента в заблуждение». Если не представить убедительного обоснования и не связать требование с бизнес-потребностью, бизнес-аналитик может поставить под сомнение, стоит ли вообще тратить на него силы.

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

Набор требований, запланированный для определенной версии, будет изменяться по мере добавления новых и удаления или отсрочкой до более поздних версий существующих требований. Разработчики могут перемещать отдельные документы требований между выпусками и итерациями. Если отложенные требования или те, от которых вы решили отказаться, остаются в спецификации требований, читатели спецификации могут запутаться в том, какие требования включены в конкретную базовую версию. Один из способов решения этой проблемы — сохранить требования в средстве управления требования и определить атрибут Release Number (Номер версии). Отсрочка требования означает изменение его запланированного выпуска, поэтому просто обновив номер версии, вы передвинете требование в другую базовую версию. Теми требованиями, от которых вы решили отказаться, лучше всего управлять с помощью атрибута состояния, как описано в следующем разделе.
На определение и обновление этих атрибутов требуется часть затрат, отведенных на управление требованиями, однако эти инвестиции в значительной степени окупаемы. В одной компании периодически генерировался отчет о требованиях, в котором показывалось, какое из 750 требований в трех связанных спецификациях назначено каждому дизайнеру. Один из дизайнеров обнаружил несколько требований, которые он не считал своими. По его расчетам он сэкономил от одного до двух месяцев, отведенных на переделку дизайна, которые бы понадобились, если бы он выяснил ситуацию с этими требованиями позднее. Чем крупнее проект, тем легче возникают недопонимания, отнимающие лишнее время.

Отслеживание состояния требований

Иногда разработчики ПО слишком оптимистичны, когда сообщают об объеме выполненных работ по задаче. Обычный синдром «90 процентов» не говорит Дейву, насколько Иветт на самом деле приблизилась к завершению своей подсистемы. Но Иветт может сообщить о состоянии дел и так: «Все очень даже неплохо, Дейв. В моей подсистеме 84 требования: 61 из них реализованы и проверены, 14 реализованы, но не проверены и 9 требований ожидают реализации». Отслеживание состояния каждого функционального требования на протяжении всей разработки позволяет более точно оценивать готовность проекта.
Состояние — один из атрибутов требований, предложенный в предыдущем разделе. Отслеживание состояния означает определение готовности по отношению к тому, что это означает в текущем цикле разработки. Например, вы планируете реализовать в следующей версии только часть варианта использования, оставив полную реализацию до будущих версий. В этом случае вам нужно отлеживать состояние тех функциональных требований, которые запланированы для ближайшего выпуска, потому что этот набор требований должен быть выполнен на 100% до выпуска продукта.

Внимание! Существует старая шутка, что на первую половину проекта по разработке тратится 90% ресурсов, а на остальную половину — оставшиеся 90% ресурсов. Чересчур оптимистичная оценка и попустительское отношение к отслеживанию состояния — верный путь к перерасходам в проекте. В таблице «Рекомендуемые состояния требований» перечислено несколько возможных состояний требований. Некоторые специалисты добавляют другие состояния, такие как состояние Designed (Разработано) (если элементы дизайна, в которых отражены функциональные требования, созданы и проверены) и Delivered (Выпущено) (ПО отдано в руки пользователей для приемки или бета-тестирования). Полезно отслеживать требования, от которых вы отказались, и причины этого, потому что отвергнутые требования имеют обыкновение «всплывать» в ходе разработки или в последующих проектах. Состояние Rejected (Отклонено) позволяет оставить предложенное требование доступным для будущего использования, не создавая беспорядка в наборе утвержденных требований для определенного выпуска. Не обязательно отлеживать все возможные состояния в таблице «Рекомендуемые состояния требований» — выберите те, что важны для работы с требованиями.

Таблица «Рекомендуемые состояния требований»

Распределение требований по нескольким категориям состояния имеет больший смысл, чем попытка контролировать процент завершения каждого требования или всей базовой версии. Обновляйте состояние требования, только когда удовлетворены определенные условия перехода. Определенные изменения состояния также ведут к обновлению данных о связях требований, когда указывается, в каких элементах дизайна, кода и тестирования отражено требование.
На рисунке «Отслеживание распределения состояний требований в цикле разработки проекта» показано, как контролировать состояние требования в гипотетическом 10-месячном проекте: на графике показано, сколько процентов требований к системе в каждом состоянии имеется в конце каждого месяца.
Обратите внимание, что при этом не устанавливается, изменяется ли со временем количество требований в базовой версии. Число требований увеличивается при расширении границ проекта и уменьшается при удалении функциональности из базовой версии. Кривые иллюстрируют, как достигается такая цель проекта, как полная проверка всех утвержденных требований.
Основная часть работы считается выполненной, когда всем требованиям назначено состояние Verified (Проверено), Deleted (Удалено) или Deferred (Отложено).

Рисунок «Отслеживание распределения состояний требований в цикле разработки проекта»

Разрешение проблем с требованиями

В процессе проекта возникнет много связанных с требованиями проблем, решений и конфликтов. Это могут быть элементы, помеченные как «TBD» (to be determined — необходимо определить), отложенные решения, необходимая информация, неразрешенные конфликты и т.п. Очень легко потерять эти проблемы из виду. Регистрируйте проблемы в средстве отслеживания дефектов, чтобы у всех заинтересованных лиц был доступ к ним. Сделайте процесс отслеживания и разрешения проблем максимально простым, чтобы ничего не оставалось без внимания. У использования средства отслеживания дефектов есть ряд преимуществ:
• проблемы, обнаруженные в ходе разных процессов рецензирования требований, собираются вместе и ни одна из них не теряется;
• менеджер проекта может легко увидеть текущее состояние всех проблем;
• каждой проблеме можно назначить отдельного ответственного;
• сохраняется история обсуждения проблемы;
• команда может начать разработку с известным набором открытых проблем, не ожидая завершения работы над спецификацией требований.

Проблемы с требованиями нужно разрешать своевременно, чтобы они не мешали созданию базовой версии высококачественных требований для следующего выпуска или итерации. График сгорания задач, показывающий оставшиеся проблемы и скорость их разрешения, помогает спрогнозировать, когда все проблемы будут закрыты, чтобы при необходимости ускорить их разрешение. Разбиение проблем на категории помогает определить разделы требований, нуждающихся в дополнительной работе. Несколько открытых проблем в разделе могут означать, что требование еще не прошло рецензирование или открытые проблемы в целом разрешены.
Практически все дефекты, зарегистрированные на ранних стадиях проекта, связаны с проблемами в требованиях — в их числе запросы на уточнение требований, решения о границах, вопросы возможности реализации и необходимость доработки в самих требованиях. В процессе рецензирования требований все участники могут вносить вопросы. В таблице «Проблемы, которые возникают с требованиями» перечислены обычные проблемы, которые возникают с требованиями.

Таблица «Проблемы, которые возникают с требованиями»

Могут произойти очень нехорошие вещи, если у вас не упорядочен процесс разрешения проблем с требованиями. В одном проекте один участник говорил, что нам нужно обрабатывать что-то «в портале». Я впервые услышал о портале и спросил об этом. Участник проекта заверил меня, что серийное решение, которое планируется приобрести, включает портал, который просто нужно будет соответствующим образом настроить. Мы не включали в свои планы никаких требований о наличии портала, поэтому я подумал, что здесь у нас пробел. Я попросил коллегу зафиксировать проблему с порталом, чтобы мы не упустили эту потребность. Несколькими неделями позже мне пришлось покинуть проект.
Как оказалось, мой коллега записал проблему с порталом на доске, которую потом стерли, так что он не зафиксировал ее в средстве отслеживания дефектов. Через полгода после начала проекта ко мне пришел руководитель заказчика, взбешенный тем, что никто не выяснил, что требуется портал. Мне пришлось выяснять, почему мы не разработали требования к порталу: мы просто забыли о нем. Регистрация проблемы в средстве отслеживания дефектов избавила бы нас от горячечной доработки в последний момент и неудовольствия клиента.

Определение усилий, необходимых для управления требованиями

Как и при разработке требований, в план проекта надо включить задачи и ресурсы для выполнения задач по управлению требованиями. Если вы выясните, сколько усилий тратится на управление требованиями, вы сможете оценить — мало их, достаточно или слишком много — и изменить рабочие процессы и будущие планы соответствующим образом. Карл Вигерс изучает измерение различных аспектов работы над требованиями в проекте.
Для измерения непосредственных усилий на разработку и управление проектом необходимо заняться корпоративной культурой и дисциплиной сотрудников — только так удастся фиксировать ежедневную работу. На это уходит не так много времени. Команда сможет получить ценные идеи, поняв, как на самом деле тратятся усилия на различные задачи проекта по сравнению с личным представлением о потраченном времени и тем, как должно тратиться время. Отслеживание усилий также указывает, справляется ли команда с запланированными действиями по работе с требованиями.
Заметьте, что рабочие усилия — это не то же самое, что прошедшее календарное время. Выполнение задач может прерываться или необходимо переговорить с другими людьми, что ведет к задержкам. Общие усилия, необходимые для выполнения задачи и измеряемые в человеко-часах, не обязательно изменятся из-за этих факторов (хотя частые прерывания снижают продуктивность отдельных людей), однако продолжительность выполнения задачи увеличится.
В процессе отслеживания усилий по разработке требований может оказаться полезным отделить время, затрачиваемое бизнес-аналитикам, от времени работы других участников проекта. Отслеживание времени бизнес-аналитиков поможет вам планировать их усилия в будущих проектах. Измерение общих усилий, потраченных на разработку требований всеми заинтересованными лицами, дает представление об общей стоимости работы над требованиями в проекте. Зафиксируйте число часов, потраченных на разработку требований, в том числе на:
• планирование работы с требованиями в проекте;
• проведение семинаров и интервью, анализ документов и выполнение других действий по выявлению требований;
• написание спецификаций требований, создание моделей анализа и определение приоритетов требований;
• создание и оценку прототипов в процессе разработки требований;
• рецензирование требований и выполнение других действий по проверке требований.

Считайте усилия для выполнения следующих действий усилиями по управлению требованиями:
• конфигурирование средства управления требованиями в проекте;
• предложение изменения требований и новых требований;
• оценка предложенных изменений, включая оценку влияния изменения и принятие решений;
• обновление хранилища требований;
• сообщение об изменениях требований заинтересованным группам и отдельными заинтересованными лицами;
• контроль и отчет о состоянии требований;
• сбор информации о связях требований.
Время, затраченное на преобразование требований в дизайн, — это не затраты, а отличная инвестиция в успех проекта. Чтобы оценить их пользу, сравните эти затраты времени с временем, которое команда тратит на разрешение проблем из-за того, что некоторые вещи не были сделаны, — это цена, которую приходится платить из-за плохого качества.