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

1
формальный процесс?
Ю.А.Назаренко
Полгода назад Вы утвердили у Заказчика Техническое задание на ПО. Свобода
творчества программиста ограничена суровыми рамками раз и навсегда утвержденного
документа. И вот продукт готов, все в строгом соответствии, но... Заказчик недоволен.
Вполне закономерный результат, ибо бизнес, как и все в этой жизни, меняется, не
взирая на то, что у вас записано в утвержденном ТЗ! Ваш приятель и коллега по цеху
проектных менеджеров, получив хороший заказ, напрочь отказывается от ТЗ, как
архаичного, попахивающего милитаризмом инструмента, и делает ставку на ум, талант
и интуицию программиста! Полгода упорного труда и... тот же результат. В чем корень
зла? Существует ли приемлемое решение навязшей в зубах проблемы?
В настоящей статье нет детального анализа и сравнительной оценки современных
методов и средств разработки требований к программному обеспечению
информационных систем. По глубокому внутреннему убеждению автора, корни многих
проблем отечественной IT-индустрии кроются не в отсутствии или неправильном
использовании соответствующих технологий, а в недостаточном внимании
руководителей организаций-разработчиков и заказчиков программного обеспечения к
вопросам проектного менеджмента вообще и управления требованиями – в частности.

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

Невозможно выработать приемлемую стратегию управления чем бы то ни было без
точного и однозначного понимания базовых составляющих соответствующей
предметной области. В чем состоит изначальный смысл и роль требований в проекте
разработки ПО? Какова иерархия и взаимосвязь различных видов требований? Какова
общая структура деятельности организаций-заказчиков и разработчиков ПО в области
требований? Какое место в этой структуре занимает управление требованиями? От
того, насколько адекватно менеджеры проектов ПО а также их руководители
ориентируются в этих вопросах, во многом зависит не только эффективность процесса
управления требованиями, но и успех соответствующих проектов в целом.
Требования заказчика и качество продукции
В повседневной жизни никто из нас не испытывает затруднений в оценке качества
окружающих нас предметов домашнего обихода, продуктов питания. Однако все мы,
разработчики ПО и поставщики современных информационных технологий, приходя
каждое утро в свой офис, на производство, и приступая к исполнению служебных
обязанностей, перестаем быть потребителями и становимся производителями. У многих
из нас имеются свои воззрения на качество нашей продукции и процессов, в
зависимости от характера производства, а также - нашей роли и места в нем. Нередко
эти воззрения весьма далеки от тех самых международных стандартов, о которых мы
так много говорим и которые только начинаем постигать.
Что же такое качество и как это понятие связано с требованиями к продукции?
Вот несколько примеров определения понятия качества из соответствующих
стандартов2:
Стандарт Определение
[1] ISO 9000-2000. Quality Качество – уровень соответствия совокупности присущих объекту
Management Systems – характеристик предъявляемым требованиям
Fundamentals and vocabulary ПРИМЕЧАНИЕ 1 Термин «качество» может употребляться совместно с

1
Статья изначально опубликована в №3/2002 журнала «Корпоративные системы». Повторно публикуется с
некоторыми изменениями с согласия Главного редактора этого издания.
2
Здесь и далее по тексту статьи используется авторская интерпретация на русский язык терминов и
определений, взятых из оригинальных версий международных стандартов
Ю.Назаренко. Управление требованиями к ПО: телепатия или формальный процесс?

Стандарт Определение
такими прилагательными, как плохое, хорошее или превосходное.
ПРИМЕЧАНИЕ 2 “Присущие” характеристики (в противоположность
“назначенным”) означают реально существующие, перманентные свойства
объекта.
[2] SEI CMM version 1.1 for Качество - (1) Уровень соответствия системы, компоненты или процесса
Software специфицированным требованиям; (2) Уровень соответствия системы,
компоненты или процесса потребностям или ожиданиям заказчика или
пользователя.
[3] ISO/IEC 14598-1. Качество – полная совокупность характеристик сущности, приводящих к
Information Technology - способности этой сущности удовлетворять сформулированным,
Software Product Evaluation - предполагаемым и подразумеваемым потребностям.
Part 1:
General Overview
Как мы видим, во всех определениях, в той или иной ипостаси, так или иначе,
присутствует ключевой элемент, без которого не существует самого понятия качества, -
требования к объекту, продукту, сущности. Последнее из приведенных определений
подчеркивает недвусмысленную связь между качеством производимого нами продукта
и уже сформулированными, еще предполагаемыми и даже только подразумеваемыми
потребностями наших заказчиков, т.е. требованиями.
Виды и иерархия требований
Как уже отмечалось выше, требования играют ключевую роль в определении качества
продукта, являясь оценочным (нормативным) базисом характеристик, соответствие
которым приводит к удовлетворенности заказчика/конечного пользователя. Тем не
менее, применение этого принципа в отношении программной продукции не столь
однозначно, как кажется на первый взгляд. Действительно, программное обеспечение
само по себе (т.е. - вне контекста использования), не может удовлетворять или не
удовлетворять потребности заказчика/конечного пользователя. ПО всегда является
составной частью или компонентой какой либо системы или бизнес-системы, так же как
оборудование, здания и сооружения, персонал, бизнес-процессы (см. Рис.1).
Следовательно и требования к ПО не должны существовать сами по себе, в отрыве от
требований к системе или бизнесу, в контексте которых это ПО будет использоваться.
Многолетний негативный опыт зарубежного и отечественного «тяжелого
программостроения» показывает, что игнорирование требований и условий бизнеса
(бизнес-системы) в требованиях к ПО непременно приводит к неудовлетворенности
заказчика/конечного пользователя.
Требования к
Бизнес-система Системе в
Бизнес-система целом

Здания и Программное Бизнес-

Здания и Оборудование Программное Бизнес- Персонал
сооружения Оборудование обеспечение процессы Персонал
сооружения обеспечение процессы

Требования к Требования к Требования к Требования к Требования к

Системе, Системе, Системе, Системе, Системе,
аллокированные на аллокированные аллокированные аллокированные на аллокированные на
зд ания/сооружения на оборуд ование на ПО бизнес-процессы персонал

Детальные Детальные
Детальные Детальные
требования к Детальные требования к
требования к требования к
зд аниям и требования к ПО бизнес-
оборуд ованию персоналу
сооружениям процессам

Рис.1
Харьков, 2002  TelesensKSCL Ukraine Ltd
2
Ю.Назаренко. Управление требованиями к ПО: телепатия или формальный процесс?

Де-факто признанный в мире стандарт SEI CMM for Software [2] следующим образом
трактует виды и иерархию требований, используемых при разработке программных
продуктов:
Уровень требований Определение

Требование к системе1 Состояние, которому должна соответствовать, или возможности, которые

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

Требования к системе занимают верхний уровень иерархии и являются предметом

переговоров между Заказчиком и Исполнителем проекта системы. На практике при
наличии функционирующей системы, проекта на нее, как такового, а вместе с ним и
требований к системе может и не существовать. В этом случае организация-
исполнитель проекта ПО обязательно должна осуществить обследование
функционирующей системы и произвести т.н. реверс-инжиниринг требований к ней. В
результате такого обследования может оказаться, что простого внедрения нового или
модификации существующего ПО будет недостаточно и потребуется реинжиниринг всей
системы и функционирующих в ней бизнес-процессов.
Средний уровень рассматриваемой иерархии занимают требования к системе,
аллокированные на ПО. Требования этого вида являются предметом переговоров с
Заказчиком программного обеспечения. Они же образуют исходный базис для
планирования и контроля выполнения работ по проекту ПО. Относительно этих
требований производится валидация конечного продукта проекта ПО. Именно поэтому
аллокированные требования рассматриваются, как основной объект или предмет
дисциплины управления требованиями.
И, наконец, на нижнем уровне иерархии представлены собственно требования к ПО.
Эти требования являются результатом анализа и уточнения/детализации требований к
системе, аллокированных на ПО. Относительно этих требований производится
верификация выходной продукции проекта ПО.
Общая структура инженерной деятельности в области требований
Общая структура инженерной деятельности (инжиниринга) в области требований
включает два больших направления: разработка требований и управление
требованиями (см. Рис.2).
Первое направление включает такие виды работы, как извлечение, анализ,
специфицирование и верификацию требований. Второе - нацелено на установление и
поддержание между Заказчиком и проектной командой общего понимания требований,
которым должен удовлетворять разрабатываемый продукт. Эта деятельность включает
следующие виды работ:
рассмотрение и согласование требований
организация контролируемого использования требований
управление изменениями в требованиях
Не умаляя значение такого серьезного и важного направления, как разработка
требований, отметим, что отсутствие или недостаток культуры управления
требованиями являет собой серьезный барьер на пути получения качественных
требований, а затем и качественного выходного продукта проекта. Действительно,
управление требованиями является одной из основополагающих (базовых) областей
процессов, неисполнение или ненадлежащее исполнение которых, препятствует

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

Харьков, 2002  TelesensKSCL Ukraine Ltd

3
Ю.Назаренко. Управление требованиями к ПО: телепатия или формальный процесс?

достижению 2-го и всех последующих уровней зрелости по модели SEI CMM for
Software[2].

Инжиниринг требований
Инжиниринг требований

Разработка требований Управление требованиями

Разработка требований Управление требованиями

Извлечение и анализ Рассмотрение и согласование

требований требований

Специфицирование Организация контролируемого

требований использования требований

Верификация Управление изменениями в

требований требованиях

Рис.2

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

Согласно модели SEI CMM for Software [2], для достижения минимального 2-го уровня
зрелости, организация-разработчик ПО должна продемонстрировать безусловное,
устойчивое соответствие действующей в этих организациях практики управления
требованиями следующим целевым установкам:
Требования к системе (бизнесу), отнесенные (или аллокированные) на ПО,
находятся под контролем, как базис для разработки и управления разработкой ПО
Планы, выходная продукция и работы по проекту ПО соответствуют требованиям к
системе, аллокированным на ПО
Заметим сразу, что достижение того или иного уровня СММ не должно быть самоцелью,
лозунгом «соцсоревнования» или чем-нибудь иным, прямо не вытекающим из реальных
бизнес-целей организации-разработчика ПО. Кроме того, организации не должны
рассматривать взятые из упомянутой модели и приведенные ниже ключевые элементы
практики управления требованиями как догму или «серебряную пулю», использование
которой автоматически гарантирует решение всех проблем. Иными словами, впервые
устанавливая процессы управления требованиями на основе модели SEI CMM for
Software, организации следует определить собственные, использовать «как есть» или
адаптировать «под себя» приведенные ниже ключевые элементы практики с тем, чтобы
обеспечить:
(1) эффективное достижение бизнес-целей организации;
(2) безусловное выполнение приведенных выше целевых установок СММ в области
управления требованиями.
Итак, практика, рекомендуемая документом CMU/SEI-93-TR-025 «Key Practices of the
Capability Maturity ModelSM, Version 1.1»1 [2]:
А. Обязательность исполнения
На каждом проекте соблюдается задокументированная организационная политика в
области управления требованиями к системе, аллокированными на ПО
Это положение означает, что:

1
Интерпретация автора статьи.
Харьков, 2002  TelesensKSCL Ukraine Ltd
4
Ю.Назаренко. Управление требованиями к ПО: телепатия или формальный процесс?

а) в организации существует задокументированная политика в области управления

аллокированными требованиями (см. Пример в Приложении А)
б) руководство и персонал проекта обязаны соблюдать и фактически соблюдают эту
политику
Б. Возможность исполнения
Для каждого проекта установлена ответственность за анализ требований к системе
и их аллокирование на оборудование, программное обеспечение и другие
компоненты системы.
Такая ответственность возлагается не обязательно на Группу разработки ПО (Software
Engineering Group). В зависимости от особенностей реализуемого проекта или принятой
в организации технологии производства работ, это может быть подразделение
системного проектирования (Systems Engineering Group) или, например, отдел
маркетинга
Аллокированные требования документируются
Аллокированные требования, как правило, включают:
а) нетехнические требования (состав поставляемой продукции, контрактные условия,
этапность, сроки поставки и т.п.);
б) технические требования (функциональность, производительность, надежность,
внешние интерфейсы и пр.);
в) а также критерии приемки выходной продукции проекта для использования при
оценке ее соответствия аллокированным требованиям
Адекватные ресурсы и финансирование предоставляются для управления
аллокированными требованиями
Это положение практически означает, что:
а) для управления аллокированными требованиями назначаются сотрудники, имеющие
опыт и навыки в прикладной области (Application domain), а также в разработке ПО
(Software Engineering)
б) инструментальные средства (универсальное и специализированное ПО) поддержки
работ по управлению аллокированными требованиями доступны на рабочих местах
исполнителей
Участники Группы разработки ПО (Software Engineering Group) обучены выполнять
свои обязанности по управлению требованиями
Такое обучение, как правило, включает изучение методов, стандартов и процедур,
используемых на проекте, а также прикладной области проекта (Application domain).
В. Выполняемые работы
Группа разработки ПО (Software Engineering Group) рассматривает и согласовывает
аллокированные требования перед тем, как они (требования) включаются в проект
разработки ПО
Практически это положение означает, что:
а) незаконченные и потерянные требования идентифицируются
б) аллокированные требования исследуются на предмет осуществимости, ясности и
правильности изложения, соответствия друг другу (непротиворечивости) и
тестируемости
в) всякое аллокированное требование, идентифицированное, как имеющее
потенциальные проблемы, рассматривается совместно с группой, ответственной за
анализ и аллокирование требований, после чего проводятся все необходимые
корректировки
г) обязательства, вытекающие из аллокированных требований, обсуждаются и
согласовываются со всеми группами, которых эти обязательства касаются (группой
разработки ПО, группой системного проектирования, маркетинга, тестирования,
конфигурационного управления, обеспечения качества, документирования, управления
контрактами и пр.)

Харьков, 2002  TelesensKSCL Ukraine Ltd

5
Ю.Назаренко. Управление требованиями к ПО: телепатия или формальный процесс?

Группа разработки ПО (Software Engineering Group) использует аллокированные

требования как исходный базис для плана разработки ПО, выходной продукции и
деятельности по проекту
Практически это означает, что аллокированные требования:
а) управляемы и контролируемы (предыдущие и текущие версии известны, а изменения
не проводятся бесконтрольно)
б) служат основой для плана разработки ПО (Software Development Plan)
в) являются исходным базисом для разработки требований к ПО
Изменения в аллокированных требованиях рассматриваются, согласовываются и
включаются в проект ПО
Это положение практически означает, что:
а) влияние предлагаемых изменений на существующие обязательства по проекту
исследуется, а сами изменения являются предметом соответствующих переговоров,
т.е.:
- изменения в обязательствах, принятых в отношении отдельных лиц и групп
сторонних организаций обсуждаются с высшим руководством
- изменения обязательств внутри организации обсуждаются между группами, работа
которых затрагивается этими изменениями
б) изменения в планах разработки ПО, выходной продукции проекта, а также работы,
вытекающие из изменений в аллокированных требования:
- идентифицируются
- оцениваются
- исследуются на предмет риска
- документируются
- планируются
- распространяются среди групп и лиц, затрагиваемых этими изменениями
- отслеживаются на предмет завершенности
Г. Измерения и анализ
Метрики по работам, связанным с управлением аллокированными требованиями
снимаются и используются для определения фактического статуса этих работ
Упомянутые здесь метрики могут включать статус каждого аллокированного
требования, статус каждого изменения в аллокированных требованиях, суммарное
кумулятивное число изменений (всех, а также по категориям «предложенных»,
«открытых», «утвержденных» и «реализованных»).
Д. Верификация исполнения
Деятельность по управлению аллокированными требованиями рассматривается и
контролируется высшим руководством на периодической основе
Основная цель такого рассмотрения – обеспечить информированность и понимание
высшего руководства сути происходящих процессов на требуемом уровне абстракции и
с достаточной периодичностью. Периодичность такого рассмотрения зависит от многих
факторов и может быть достаточно большой при наличии и доступности механизмов
оперативного информирования/реагирования высшего руководства в исключительных
ситуациях.
Деятельность по управлению аллокированными требованиями рассматривается и
контролируется менеджером проекта, как на периодической основе, так и разово
(по событию)
Как правило, такое рассмотрение производится в рамках и по регламенту
периодического и разового рассмотрения состояния и прогресса работ по проекту в
целом.

Харьков, 2002  TelesensKSCL Ukraine Ltd

6
Ю.Назаренко. Управление требованиями к ПО: телепатия или формальный процесс?

Группа обеспечения качества (Quality Assurance Group) проводит рассмотрение

и/или аудиты деятельности и выходной продукции управления аллокированными
требованиями с выпуском отчетов по их результатам
Как минимум, в ходе такого рассмотрения/аудита группа обеспечения качества должна
удостовериться, что:
а) аллокированные требования рассматриваются, а выявленные проблемы
разрешаются до того, как Группа разработки ПО берет на себя соответствующие
обязательства
б) планы разработки ПО, выходная продукция проекта и работы по проекту
надлежащим образом пересматриваются, когда аллокированные требования
изменяются
в) изменения в обязательствах, вытекающие из изменений в аллокированных
требованиях, являются предметом переговоров с группами, работу которых эти
изменения затрагивают

Динамика управление требованиями

Описанные выше рекомендации SEI в области управления требованиями, носят
статический, универсальный характер. Это означает, что организация, внедряющая или
совершенствующая соответствующие процессы, должна побеспокоится об адаптации
этой практики к временной (динамической) составляющей процесса создания
программного обеспечения, т.е. модели жизненного цикла проекта ПО.
Жизненный цикл проекта ПО
Не отвлекаясь на сравнительный анализ различных моделей, останемся в рамках темы
статьи и воспользуемся эволюционно-итеративной моделью жизненного цикла
разработки ПО, примененной в технологии Rational Unified Process1[4].

Проектная стадия Производственная стадия

Фаза Inception Фаза Elaboration Фаза Construction Фаза Transition

Предварительные Производственные
Архитектурные итерации Внешние релизы
итерации итерации

R D I DP R D I DP R D I DP R D I DP
∇ ∇ ∇
LCO LCA IOC
Milestone Milestone Milestone
Рис.3
Как показано на Рис.3, для эволюционно-итеративной модели характерно то, что
практически все основные виды работ в области требований (R), дизайна (D),
реализации (I) и развертывания (DP) программного обеспечения выполняются
итеративно на протяжении всего цикла проекта (высота «столбиков» условно
индицирует примерную степень завершенности соответствующих частей проекта на
каждой фазе).

1
Здесь и далее по тексту автор не преследует целью адекватно отобразить статическую часть процесса
разработки ПО (потоки работ и артефакты), как это представлено в Rational Unified Process

Харьков, 2002  TelesensKSCL Ukraine Ltd

7
Ю.Назаренко. Управление требованиями к ПО: телепатия или формальный процесс?

Фазы проекта содержат от одной до нескольких итераций, целью которых обычно

является минимизация рисков невыполнения целей соответствующих фаз. Ключевым
моментом эволюционно-итеративной модели жизненного цикла является наличие
контрольных точек (milestones), в которых проверяется достижение установленных
целей соответствующих фаз/итераций проекта и принимается решение о переходе к
следующей фазе/итерации или о закрытии проекта. Назначение и смысл ключевых фаз
проекта - Inception, Elaboration и Construction – заключен в следующем определении
соответствующих главных контрольных точек (major milestones):
Контрольная точка Критерии прохождения

Lifecycle Objectives Соглашение между заинтересованными сторонами относительно

Milestone (LCO) определения объема и оценок стоимости/графика проекта достигнуто
Достигнуто соглашение относительно того, что правильный набор
требований получен и имеется общее понимание этих требований
Достигнуто соглашение о том, что оценки стоимости/графика проекта,
приоритеты, риски и процесс разработки ПО проработаны надлежащим
образом
Все риски идентифицированы и для каждого риска определена стратегия
минимизации/смягчения последствий
Lifecycle Architecture Концептуальное видение продукта (Vision) и требования к нему стабильны
Milestone (LCA) Архитектура продукта стабильна
Исполняемые прототипы ПО продемонстрировали, что главные элементы
рисков установлены, а потенциальные проблемы гарантированно
разрешимы
Планы итераций фазы Construction достаточно детальны и действительно
позволяют продолжить работы по проекту
Планы итераций фазы Construction сопровождаются заслуживающими
доверия оценками стоимости/графика работ
Все заинтересованные стороны согласны, что текущее видение продукта в
контексте текущей архитектуры может быть реализовано в законченной
системе, если текущий план будет выполняться
Фактические затраты ресурсов приемлемы по отношению к плановым
Initial Operational Версия продукта достаточно стабильна и созрела для развертывания у
Capability Milestone (IOC) конечного пользователя
Все заинтересованные стороны готовы к передаче продукта конечному
пользователю
Фактические затраты ресурсов все еще приемлемы по отношению к
плановым
Полагая краткое описание особенностей эволюционно-итеративной модели жизненного
цикла проекта ПО достаточным, обратимся к возможной интерпретации работ по
управлению требованиями для этой схемы.
Рассмотрение и согласование аллокированных требований
Из определения критериев прохождения контрольной точки LCO видно, что одной из
главных целевых задач фазы Inception является достижение между заинтересованными
сторонами (т.е. Заказчиком и Исполнителем проекта ПО) договоренности относительно
объема, стоимости, графика и основных требований к продукту проекта. Из этого же
определения совершенно очевиден тот факт, что предмет упомянутых договоренностей
есть не что иное, как требования к системе, аллокированные на ПО (технические и
нетехнические). Отсюда следует вывод, что рассмотрение и согласование
аллокированных требований должно происходить на фазе Inception, а соответствующие
договоренности должны быть достигнуты к завершению этой фазы.
Контролируемое использование аллокированных требований
Очевидно, что этот вид деятельности по управлению требованиями, включающий
надлежащее версионирование аллокированных требований и предупреждение
неконтролируемых изменений в них, осуществляется постоянно на протяжении всего
цикла проекта, начиная с момента появления первой эскизной версии этих требований
на фазе Inception, заканчивая закрытием проекта в конце фазы Transition.
Управление изменениями в аллокированных требованиях
До момента достижения окончательной договоренности с Заказчиком относительно
требований к системе, аллокированных на ПО, т.е. до завершения фазы Inception, эти
Харьков, 2002  TelesensKSCL Ukraine Ltd
8
Ю.Назаренко. Управление требованиями к ПО: телепатия или формальный процесс?

требования могут изменяться относительно неформально. Это означает, что пока

требования не утверждены, нет необходимости в проведении специальной формальной
процедуры управления изменениями. Достаточно обеспечить надлежащее
версионирование и предупреждение неконтролируемого редактирования
аллокированных требований. При этом, разумеется, должен быть обеспечен
надлежащий доступ к актуальной версии соответствующих документов для всех
заинтересованных групп, использующих и/или рассматривающих эти требования.
После утверждения согласованной со всеми заинтересованными сторонами версии
аллокированных требований (в конце фазы Inception) вступает в действие специальная
формальная процедура управления изменениями. В соответствии с этой процедурой
сначала проводится анализ влияния предложенного изменения на имеющийся задел
выходной продукции, стоимость и график проекта. Затем группа официальных
полномочных представителей руководства организаций Заказчика и Исполнителя на
основании результатов такого анализа, с учетом взаимных интересов, достигает
консенсуса и принимает обоснованное решение о дальнейшей судьбе предложенного
изменения. Только после получения положительного решения упомянутой группы,
подразделение разработки ПО приступает к реализации предложенного изменения.
Такой порядок действует далее в отношении аллокированных требований на
протяжении всех последующих фаз проекта – Elaboration, Construction, Transition.
Аналогичный подход применяется и к требованиям на ПО, являющимся результатом
анализа и детализации аллокированных требований. Разница состоит лишь в том, что
утвержденные требования к ПО появляются позднее – в середине или даже в конце
фазы Elaboration, а состав группы полномочных представителей, принимающих
решение по изменениям, может быть ограничен только представителями
заинтересованных подразделений организации-разработчика.
Необходимо отметить, что формальный подход к управлению изменениями в
требованиях обеспечивает постоянный баланс интересов всех участников проекта со
стороны Заказчика и Исполнителя, побуждая их к тесному и плодотворному
сотрудничеству во имя получения конечного продукта с приемлемым качеством, в
требуемые сроки и при имеющихся ограничениях бюджета.

Вместо заключения
По утверждению ведущего эксперта в области совершенствования процессов
разработки ПО Карла Виггерса [5], деятельность в области инжиниринга требований в
большей степени носит коммуникативный, нежели технический характер.
Действительно, невозможно переоценить роль коммуникаций между Заказчиком и
Исполнителем проекта ПО в процессе управления требованиями – составной и
основополагающей части инжиниринга требований. Надо сказать, что в обоих примерах
неудачной реализации IT-проектов, приведенных в начале статьи, напрочь
отсутствовало управление требованиями, как формальный процесс, а вместе с ним и
коммуникации между Заказчиком и Исполнителем проекта.
Многих из нас часто и сильно пугает само словосочетание «формальный процесс». В
нашем воображении возникают горы толстых многотомных инструкций и процедур,
одно только чтение которых, не говоря уже об их исполнении, вызывает устойчивую
головную боль. И здесь, как в случаях с неудачными проектами, свою пагубную роль
играет дефицит коммуникации – едва ли не самая большая профессиональная ошибка
руководителей проектов и IT-организаций, предпочитающих решать технические, а не
организационные проблемы. А ведь даже самый простой, кратко и ясно описанный
процесс, не будет работать в компании, где отсутствуют механизмы доведения до
сотрудников политической установки высшего руководства следовать формальным
процессам. Если конечно таковая имеется.
На сегодняшний день существует множество современных, гибких, масштабируемых,
адаптируемых, несложных в понимании и применении технологий и инструментов,
обеспечивающих требуемый уровень формализации процессов создания ПО. Кроме
того, существует множество квалифицированных опытных консультантов, готовых
прийти на помощь в обучении персонала и внедрении формальных процессов. Дело за

Харьков, 2002  TelesensKSCL Ukraine Ltd

9
Ю.Назаренко. Управление требованиями к ПО: телепатия или формальный процесс?

малым – нужна добрая, но твердая воля руководителей IT-компаний плюс

коммуникации, коммуникации, и еще раз – коммуникации...

Об авторе
Юрий Анатольевич Назаренко является заместителем директора
TelesensKSCL Ukraine по качеству и управлению персоналом.
Отвечает за совершенствование бизнес-процессов создания и
поддержки программных продуктов компании на базе стандартов SEI-
CMM и ISO9000:2000, подготовку и переподготовку кадров. Обладает
более чем 15-летним практическим опытом инженерной и
руководящей работы в аэрокосмической отрасли и ядерной
энергетике. Принимал непосредственное участие в разработке и
испытаниях компьютерных систем управления и программного
обеспечения военного и гражданского назначения. Участвовал в
создании и руководил работой инженерного подразделения первого
украинско-американского совместного предприятия по автоматизации
украинских АЭС.
Тел.: +380(572)190-568
mailto:Y.Nazarenko@telesenskscl.com.ua

Ключевые ссылки по теме

[1] – ISO 9000-2000. Quality Management Systems – Fundamentals and vocabulary
[2] – CMU/SEI-93-TR-025 «Key Practices of the Capability Maturity ModelSM, Version 1.1»:
http://www.sei.cmu.edu/publications/documents/93.reports/93.tr.025.html
[3] – ISO/IEC 14598-1. Information Technology - Software Product Evaluation - Part 1:
General Overview
[4] – Rational Unified Process
www.rational.com
[5] – Karl E. Wiegers. «When Telepathy Won’t Do: Requirements Engineering Key
Practices»
http://www.processimpact.com/articles/telepathy.html

Харьков, 2002  TelesensKSCL Ukraine Ltd

10
Ю.Назаренко. Управление требованиями к ПО: телепатия или формальный процесс?

Приложение А

Политика компании “АВС” в области управления

требованиями
Политика компании “АВС” в области управления требованиями состоит в
гарантированнии того, что:
1 Начальник отдела маркетинга и продаж назначает группу1 специалистов,
отвечающих за аллокирование требований бизнеса на программное обеспечение
(ПО) соответствующего проекта
2 Группа, ответственная за аллокирование требований бизнеса на ПО документирует
аллокированные требования
3 Коммерческий директор выделяет адекватные ресурсы, включая финансирование,
для деятельности группы, ответственной за аллокирование требований бизнеса на
разрабатываемое ПО
4 Руководитель проекта организует и предоставляет необходимое целевое обучение
в области управления требованиями персоналу проекта (сотрудникам
подразделений разработки, тестирования, обеспечения качества и
конфигурационного управления, участвующим в проекте ПО)
5 Подразделения разработки, тестирования, обеспечения качества и
конфигурационного управления рассматривают и согласовывают аллокированные
требования в сфере своей ответственности перед их использованием
6 Для производства и оценки качества версий программного продукта,
предназначенных для поставки конечному пользователю, используются только
согласованные2 аллокированные требования
7 Не допускается внесение изменений в согласованные аллокированные требования
без предварительного их рассмотрения и согласования подразделениями
разработки, тестирования, обеспечения качества и конфигурационного управления
в части, их касающейся
8 Подразделения разработки, тестирования, обеспечения качества и
конфигурационного управления производят измерения и анализ своей
деятельности в области управления требованиями
9 Технический директор рассматривает и проверяет деятельность по управлению
требованиями в компании не реже, чем один раз в полгода
10 Руководитель проекта еженедельно, а также по мере необходимости рассматривает
и контролирует деятельность персонала и статус выходной продукции проекта в
области управления требованиями
11 Подразделение обеспечения качества не реже, чем один раз в полгода, проводит
аудит деятельности и выходной продукции в сфере управления требованиями на
каждом проекте

1
Здесь и далее по тексту настоящей Политики под группой специалистов, отвечающих за аллокирование
требований бизнеса на ПО, понимается один и более бизнес-аналитиков, квалифицированных в предметной
области и в сфере разработки прикладного программного обеспечения
2
Согласованным считается требование, по которому все идентифицированные критические проблемы
разрешены, а по некритическим – достигнута договоренность о способе и сроках разрешения

Харьков, 2002  TelesensKSCL Ukraine Ltd

11