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

Проблемы при выполнении проектов создания автоматизированных систем могут возникать из-за неформального сбора информации, предполагаемой функциональности, ошибочных или несогласованных нефункциональных требований к системе, а также нерегламентированной процедуры их изменения. Организация управления требованиями прежде всего направлена на дезавуирование таких проблем за счет усовершенствования способов сбора, документирования, согласования и модификации требований к системе, отслеживания требований от заинтересованных лиц и из прочих источников, их порождающих. Регламентация процедур управления требованиями должна обеспечить высокое качество работы с ними в проектах, связанных с разработкой, сопровождением, созданием автоматизированной системы, разработкой их организационно методического обеспечения, а также внедрения готовых систем за счет уменьшения типичных ошибок при работе с требованиями. Существенный момент предлагаемой методики — использование международных и отечественных стандартов в области управления жизненным циклом автоматизированных систем, позволяющее практически без адаптации применять методики в рамках уже существующих, зарекомендовавших себя на практике процессах разработки. В качестве инструментария, поддерживающего моделирование требований на основе UML 2.0, авторами используется продукт Enterprise Architect компании Sparx System.

 

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

Под управлением требованиями обычно понимается систематический подход к выявлению, документированию, планированию реализации требований и отслеживанию их изменений [1]. Методика призвана регламентировать следующие процедуры работы с требованиями: выявление, документирование, верификация и утверждение требований, планирование реализации и отслеживание изменений требований.

Методика предусматривает две стадии: подготовку управления требованиями и непосредственно управление ими. Процесс подготовки управления требованиями представлен в таблице 1. Определение этапов жизненного цикла системы, на которых будет организована работа с требованиями, зависит от выбора его модели. Далее в качестве примера мы будем ориентироваться на ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания», в котором работа с требованиями в рамках процедур, регламентируемых методикой, осуществляется на следующих стадиях: формирование требований к автоматизированной системе, разработка ее концепции, техническое задание и сопровождение.

Подготовка шаблонов документов выполняется для каждого этапа жизненного цикла. Состав документов, оформляемых для выделенных этапов жизненного цикла, приведен в таблице 2. Часть документов, создаваемых и сопровождаемых при управлении требованиями, определена в соответствии с ГОСТ, а часть готовится по специальным шаблонам, которые разработаны авторами и созданы на основе обобщения методик Microsoft Solutions Framework (MSF), Oracle Custom Development Method (CDM), Rational Unified Process (RUP), а также [2]. В документах, формируемых с использованием подготовленных шаблонов, будут фиксироваться различные типы требований.

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

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

Следующим шагом процесса является разработка основных процедур управления требованиями: процедура выявления требований, процедура верификации требований, процедура изменения требований. При этом учитывается информация, поступившая от заинтересованных лиц по данным процедурам, и требования ГОСТ 34.602-89, ГОСТ 19. 201-78. В заключение создается шаблон модели требований и его описание. В качестве опорных документов используются ГОСТ 34.602-89, ГОСТ 19.201-78.

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

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

Если ориентироваться на ГОСТ 34.601-90, целесообразно использовать методику управления требованиями, согласно этапам жизненного цикла.

Стадия «Формирование требований к автоматизированной системе» включает этапы: «Обследование объекта и обоснование необходимости создания автоматизированной системы» и «Формирование требований пользователя к автоматизированной системе». Формируемые документы — «Интервью заказчиков и пользователей о проблемах».

Стадия «Разработка концепции» включает этапы: «Изучение объекта», «Проведение необходимых научно-исследовательских работ», «Разработка вариантов концепции автоматизированной системы, удовлетворяющих требованиям пользователя» и «Оформление отчета о выполненной работе». В ходе выполнения работ формируется документ «Концепция».

Стадия «Техническое задание» включает этап «Разработка и утверждение технического задания на создание автоматизированной системы». Формируемые документы — «ТЗ» по ГОСТ 34.602 -89; «Описание автоматизируемых функций» согласно РД 50-34.698-90 п. 2.5, «Словарь терминов», «Модель требований», «Описание модели требований».

Стадия «Сопровождение автоматизированной системы» включает этапы: «Выполнение работ в соответствии с гарантийными обязательствами» и «Послегарантийное обслуживание». Формируемые документы — «Интервью заказчиков и пользователей о проблемах», «ТЗ» по ГОСТ 34.602 -89, «Запрос на изменение требований», «Описание автоматизируемых функций» согласно РД 50-34.698-90.

Часть документов, создаваемых и сопровождаемых при управлении требованиями, таких как «Техническое задание», «Описание автоматизируемых функций», определена в соответствии с ГОСТ и РД, а часть, например «Словарь терминов», «Запрос на изменение требований», готовится по специальным шаблонам, ориентированным на применение для широкого класса проектов.

 

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

На основании регламентных процедур реализуется процесс управления требованиями (табл. 2).

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

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

 

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

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

В качестве примера рассмотрим формирование требований к системе учебного управления университета. Выявленные бизнес-процессы включают: зачисление студентов в университет; перевод студентов; отчисление студентов; подготовку отчетов; проведение сессии.

Для бизнес-процесса «Зачисление студентов в университет» определена следующая последовательность шагов.

  1. Секретарь деканата получает список студентов и приказ о зачислении из ректората.
  2. Декан на основании данной информации формирует списки групп.
  3. Информация из списка групп переносится секретарем деканата в личную карточку студент.
  4. Секретарь оформляет зачетную книжку на основании личной карточки студента;
  5. Выдача зачетной книжки регистрируется секретарем в журнале учета зачетных книжек.

Автоматизируемыми процессами являются: зачисление; перевод; отчисление; проведение сессии; подготовка отчетов. Шагами бизнес-процесса «Зачисление студентов в университет», подлежащими автоматизации, являются: формирование списков групп; заполнение личной карточки студента; регистрация выдачи зачетной книжки в журнале.

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

Пример управления требованиями: выявление — состав подсистем; состав функциональных требований подсистемы «Зачисление студентов»
Литература
  1. Карл Вигерс, Разработка требований к программному обеспечению. М.: «Русская Редакция», 2004.
  2. Липаев В. В., Документирование сложных программных средств. М.: «Синтег», 2005.

Роман Алфимов (rva@fvs.ru), Елена Золотухина, Светлана Красникова (ksa@fvs.ru) — преподаватели «Академии АйТи» (Москва).

 

Стандарты управления жизненным циклом автоматизированной системы

  • ГОСТ 19.102-77 Единая система программной документации. Стадии разработки
  • ГОСТ 19.201-78* Единая система программной документации. Техническое задание. Требования к содержанию и оформлению
  • ГОСТ 2.503-90 ЕСКД. Правила внесения изменений
  • ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания
  • ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы
  • ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств
  • РД 50-34.698-90 Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов
Таблица 1. Таблица 2.