ПРАКТИКА

Как собирают требования в большой команде (практический опыт)

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

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

В соответствии с конкурсными требованиями создаваемая система должна решать два рода задач:

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

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

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

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

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

Методология: что намечалось и что делалось

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

В качестве программного средства автоматизации управления требованиями был выбран продукт IBM Rational RequisitePro. Он позволяет вести коллективную работу над репозиторием требований как с использованием "толстого" клиента (в локальной сети), так и через Web-интерфейс. С самого начала была сделана ставка на то, что RequisitePro позволит нам автоматически "собрать" готовое ТЗ на основе информации репозитория. Мы не знали, каков будет объем собранной информации, и боялись, что вручную перенос требований в ТЗ займет слишком много времени, поэтому параллельно со сбором требований дорабатывался соответствующий шаблон ТЗ (в формате MS Word), содержащий скрипт для автоматической генерации ТЗ.

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

Для того чтобы все участники команды единообразно понимали процесс сбора и управления требованиями, мы разработали документ "Концепция управления требованиями". Сам процесс стал композицией процесса сбора требований с помощью "вариантов использования" (use cases), предложенного А. Коберном [1], а также упрощенного унифицированного процесса фирмы Rational [3]. Наибольший интерес, естественно, представляет не то, что мы декларировали в этом документе, а то, как мы на самом деле работали. Именно на этой реальной работе я и остановлюсь подробнее. Данная статья не ставит своей целью заменить указанные книги, поэтому в случае возникновения вопросов по терминологии и по самой методологии сбора требований обращайтесь к первоисточникам.

Нашей команде пришлось самостоятельно дорабатывать методологию сбора требований для проекта: его сложность не позволяет использовать готовые методологии, имеющие существенные ограничения. В частности, в книге Д. Леффингуелла [2], проповедующей унифицированный подход (Unified process), за описанием методов анализа систем и управления требованиями следует конкретный пример методологии, предваряемый описанием ограничений его применения. Так вот, практически каждый пункт этого списка [2, с. 364] относится к нашему проекту, т. е. приведенная методология в буквальном смысле не подходит нам "по всем пунктам".

Центральным местом взаимодействия команды, занимающейся сбором требований, стал репозиторий требований RequisitePro. А основным способом доступа к этому репозиторию - Web-интерфейс.

Для собственно требований мы создали в репозитории два типа требований: "вариант использования" и "требование", - имеющие различные наборы атрибутов. Мысль была такая: "варианты использования" содержат описания сценариев и другие атрибуты ("основное действующее лицо", "цель" и т. п., см. [1]), а "требование" - это нечто более простое, например фраза, описывающая это требование. Связь требований, в том числе и различных типов, мы указывали с помощью трассировки (трассировка и есть установление связи, зависимости). Помещать в репозиторий отформатированные варианты использования (файлы MS Word) было неудобно (RequisitePro не дает возможности "прикрепить" файл к "требованию"), поэтому, хотя варианты использования и создавались в удобном для восприятия человеком формате, их применение было затруднено тем, что они пересылались обычной почтой и выпадали за пределы автоматизированной части процесса сбора требований. В результате поля (body parts) вариантов использования помещались в репозиторий в виде неформатированного текста. Структурированные сценарии после такого копирования, к сожалению, уже не читаются. Мы это заметили сразу, но отступать было уже поздно.

Проиллюстрировать взаимосвязи собранных вариантов использования можно с помощью UML-диаграммы вариантов использования. Логичным шагом могла бы стать интеграция репозитория требований с соответствующими UML-моделями, и RequisitePro поддерживает интеграцию со средствами моделирования (IBM Rational XDE и Rose)... но не через Web-интерфейс, что в нашем случае было критически важно. И вообще, мы заметили, что для корректной работы репозитория через Web нужно избегать работы не через Web (по локальной сети с помощью "толстого клиента" RequisitePro), иначе могут появиться документы, доступ к которым возможен только из локальной сети.

Для удобства разделения труда между рабочими группами соисполнителей проекта при одновременной работе с репозиторием все требования имели атрибут "владелец", идентифицирующий рабочую группу (организацию-соисполнителя), которая может изменять данное требование. Этот атрибут имел для нас только справочное значение: RequisitePro, к сожалению, не позволяет задать права доступа пользователей к отдельным требованиям. Работу с репозиторием требований параллельно вели около десяти человек.

Список терминов (глоссарий) проекта, список действующих лиц (участников "вариантов использования"), а также реестр регламентирующих документов (документов, на которых базируется работа системы) мы также стали вести в репозитории требований, создав для этого отдельные пакеты (для структурного выделения этих списков) и специальные "типы требований" для элементов этих списков (других вариантов и не было: ничего, кроме требований и документов, в RequisitePro не "живет").

Реестр регламентирующих документов практически так и не был заполнен. Вероятно, это было следствием того, что RequisitePro не поддерживает гиперссылки в тексте требований (могут быть созданы только отдельные атрибуты типа URL Link), а основной целью введения реестра регламентирующих документов была унификация ссылок на эти документы. Аналогичная судьба постигла и документ "Действующее лицо/цель": мы создали первоначальную его версию, которая, однако, не прижилась в репозитории требований.

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

Результаты и выводы

Ниже перечислены результаты, достигнутые на декабрь 2004 г., а также предварительные выводы, касающиеся управления требованиями в проекте.

- Требования собраны, на их основе сформировано ТЗ, которое согласовано и принято заказчиком.

Успешно прошел этап согласования ТЗ с большим количеством представителей заказчика. Для учета поступивших замечаний мы создали еще один тип требований: "замечания". Каждое такое замечание, снабженное именем его автора, мы связали трассировкой с соответствующим требованием, по поводу которого оно было высказано, (т. е. с предложением об изменении ТЗ). После этого работа по учету замечаний в ТЗ велась параллельно несколькими членами команды: каждый мог внести изменение в требования, а потом соответственно изменить статус "замечания" (принято/учтено/отклонено...). В результате в репозитории на 400 своих требований мы получили 200 замечаний.

- В процессе сбора требований структура репозитория все больше приближалась к структуре ТЗ, которая была предложена заказчиком и в которую нам было необходимо вписаться. По моему мнению, слишком детальная структура ТЗ, не учитывающая специфику конкретного проекта, мешала работе. Кстати, в упомянутой выше книге Д. Леффингуелла [2] в качестве одного из упрощающих предположений, позволяющих использовать приведенную автором методику управления требованиями, указывалось: "Также предполагается, что не существует оговоренных контрактом требований о специальном формате документов".

В то же время периодическая генерация ТЗ на основе репозитория требований позволяла нам визуализировать то, что "пряталось" в куче папок ("пакетов") самого репозитория. Таким образом, собранные требования стали трудно воспринимаемыми в отрыве от созданного на их основе ТЗ.

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

Причина неполноты требований к системе в целом, по моему мнению, такова: эксперты в предметной области распределили между собой задачи сбора требований к подсистемам и тем самым сразу "провалились" на уровень своих подсистем. Сначала мы никак не могли понять, почему у нас не возникает прогнозируемого (на основе опыта, описанного А. Коберном [1]) дерева вариантов использования, имеющего для всей системы в целом от двух до пяти вариантов использования верхнего уровня.

К моменту завершения этапа сбора требований для ТЗ у нас был фактически всего один вариант использования, описывающий сценарий одного из бизнес-процессов, в котором участвовало несколько подсистем. Не удивительно, что именно этот сценарий привлек наибольшее внимание участников проекта, в том числе и заказчика, и чаще всего подвергался доработке: в нем говорилось о том, что конкретно делает система.

- Из-за того, что при сборе требований были упущены самые верхние уровни, в поисках необходимого объема требований (для оправдания своей работы) мы слишком углубились в детализацию и даже в реализацию системы. Да, мы не справились с широко известной трудностью: не смогли выдержать высокого, концептуального уровня описания системы.

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

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

-  Недостаточно явно проведена граница между тем, что уже есть, и тем, что будет создано в рамках данного проекта. Заказчик уже имеет множество информационных систем, закрывающих отдельные текущие задачи и по кусочкам автоматизирующих бизнес-процессы. У нас не было достаточной информации (и времени на ее изучение) о существовании таких систем, и заказчик подталкивал нас к тому, чтобы мы разрабатывали новую систему без оглядки на уже имеющиеся решения. В результате, естественно, многие из наших предложений совпали с тем, что уже есть у заказчика хотя бы в одной из множества существующих систем. И когда мы "опустились на землю" и конкретно заговорили об интеграции с работающими системами, нашу систему уже трудно было позиционировать.

Об IBM Rational RequisitePro

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

Структурирование требований

Удобным для работы в RequisitePro является только один вариант структурирования требований, при котором требования группируются в оглавления (пакеты) и детализируются требованиями следующего уровня [связь "родитель - ребенок" (parent - child)]. Однако отношение "родитель - ребенок" возможно только для артефактов одного типа: например, требованию типа "вариант использования" нельзя назначить в качестве "ребенка" ни текстовый документ, содержащий подробное описание этого требования в удобном формате, ни требование другого типа (у нас были и такие типы требований: "требование", "замечание").

Другой вариант структурирования требований - с помощью трассировки (traceability). Трассировка возможна между артефактами (в том числе требованиями) любых типов, однако сама она должна быть только одного типа! Наш же набор трассировок, созданных с разными целями, постепенно превратился в кучу, в которой уже нет наглядности. Особенно печально стал выглядеть репозиторий после появления более сотни замечаний и их трассировки на требования.

Связь репозитория с внешними ресурсами

В использовавшейся нами версии RequisitePro 2003 не было удобной возможности организовать связь репозитория требований с внешними ресурсами, расположенными в глобальной Сети (с помощью URL). Это ограничение по сути похоронило наши идеи о размещении дополнительных документов, относящихся к требованиям, на Web-серверах. (Здесь нужно заметить, что в выпуске RequisitePro 2003.06.13 рядом с атрибутом, содержимое которого имеет тип URL Link, появилась кнопка, по которой указанный URL открывается в окне Интернет-браузера.) Кроме того, мы предполагали связать требования с базой (или базами) регламентирующих (нормативных) ресурсов, размещенных в Интернете. Для этого нами была разработана унифицированная система ссылок на регламентирующие ресурсы, но воплощения эта система не нашла, потому что атрибуты требований RequisitePro представляют собой неформатированный текст и гиперссылки в нем не поддерживаются. А ведь гиперссылки, как известно, наиболее удобны непосредственно в тексте...

Выводы по RequisitePro

Да, RequisitePro помог нам "собрать" документ "Техническое задание". Это немало, но:

- во-первых, дальнейшая судьба самого репозитория требований находится сейчас под вопросом: будет ли удобно использовать его дальше или придется начинать управление требованиями сначала?

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

Несомненное преимущество от использования RequisitePro в том, что теперь стало гораздо понятнее, чем хороша система автоматизации управления требованиями и что нам может понадобиться от нее. 4 С автором, аналитиком отделения системного анализа Департамента интеграционных решений IBS, можно связаться по адресу: YVolkov@IBS.RU.

Литература

1. Коберн А. Современные методы описания функциональных требований к системам. М.: Лори, 2002. Домашняя страница А. Коберна в Интернете: http://alistair.cockburn.us/.

2. Леффингуелл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. М.: ИД "Вильямс", 2002.

3. Крачтен Ф. Введение в Rational Unified Process. - Изд. 2-е. М.: ИД "Вильямс", 2002.