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

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

Необходимость

Одна из первых работ при проектировании информационной системы — сбор и упорядочение требований к ней. Изначально требования собираются в виде протоколов совещаний и интервью с заказчиками и пользователями, копий и оригиналов различных документов, листингов отчетов, выданных старой ИС, и массы других бумаг. Потом их начинают упорядочивать и "очищать" от противоречий. Затем на их основе вырабатываются требования к компонентам ИС — базам данных, программным средствам, территориальному размещению. Но и они еще не содержат деталей реализации, таких как состав и вид экранных форм и отчетов, архитектура распределенных вычислений и баз данных. Решения о тех или иных способах реализации будут приняты позже, на этапе проектирования, на основе требований к системе и ее компонентам.

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

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

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

Без организованных усилий по регистрации и контролю выполнения этих требований велик риск их "потерять".

Возможность

Решение проблемы достаточно очевидно: в специально созданном хранилище документов следует вести учет собираемых требований и контролировать их обработку, оценку и реализацию (или отказ от реализации).

Существуют специализированные системы управления требованиями (Requirements Management Systems). Они обладают различными возможностями в зависимости от идеологии производителя. Стандартными можно считать две из них:

  • выделение требований непосредственно в документах (текстовых, .rtf, .doc, .html и др.) с сохранением ссылки на исходный текст;
  • отслеживание зависимостей между требованиями.

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

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

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

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

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

Доступность

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

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

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

  

Вариант схемы базы данных для хранения требований приведен на рисунке. В нем используется нотация Information Engineering (называемая также нотацией Д. Мартина). Кружочками обозначены необязательные связи, "гусиными лапками" — связи с максимальной коннективностью "много". Ключевые связи отмечены закрашенными ромбиками.

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

Функционал простой системы управления требованиями можно ограничить двумя основными возможностями:

  • ввод организованных в иерархические разделы требований (с некоторыми атрибутами);
  • установка связи между требованиями (с возможностью просмотра этой связи в обоих направлениях).

Желающие познакомиться к коммерческой системой управления требованиями могут посетить сайт Rational Software Corporation (www.rational.com). Там можно получить временную лицензию системы RequisitePro с учебным проектом для освоения. Приведенные в статье примеры созданы в этой системе.

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


Сергей Анатольевич Панащук — аналитик ЗАО "Фирма "АйТи". Информационные технологии". Ему можно написать по адресу span@it.ru.

Пример регистрации требований к ИС

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


Рис. 1. Исходные требования пользователей




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

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

В приведенном примере установлен следующий набор значений статуса требований: proposed — предложено, approved — одобрено, incorporated — встроено, validated — проверено.

Экран фиксации функциональных требований не показан (внешне он похож на окно описания пользовательских требований), но сами функциональные требования видны на рис. 2, где имеют префикс "Ф".