http://www.interface.ru/fset.asp?Url=/ca/TechStrReqSoftware.htm

© Н.А. Трушин,НП АТС© С.В. Тупчиенко,НП АТС

Технология структурирования требований к по с помощью AllFusion Process Modeler (ранее: bPwin) и AllFusion eRwin Data Modeler (ранее: eRwin) Введение Цель публикации

Цель данной публикации состоит в описании подхода к формированию и структурированию требований к программному обеспечению.

Рамки

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

Технология также включает в себя методику автоматической подготовки документа "Техническое задание на разработку ПО" (или "Спецификация требований к программному обеспечению").

Технология предназначена в первую очередь для использования её системными и бизнес аналитиками на этапе формирования требований.

Предположения и зависимости

Предлагаемая технология основана на использовании программных продуктов AllFusion Process Modeler (ранее BPwin),AllFusion ERwin Data Modeler (ранее: ERwin)и системы управления требованиями Doors (возможно, также, использование системы управления требованиямиIBM Rational RequisitePro).

Существующие технологии

Традиционно структурирование требований к программному обеспечению производится в рамках отдельного документа, например в формате Word, в соответствии с одним из шаблонов ГОСТ/SRS. Современные системы управления требованиями также предоставляют возможность ведения требований в специализированных базах данных или гибридных структурах Текстовый процессор + БД.

Рассмотрим кратко характеристики предлагаемых вариантов.

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

• Базы данных (собственного производства и, например, RequisitePro).Преимущества очевидны

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

• одно требование

• одна запись в БД. Недостатки также видны сразу

• невозможность использования графических объектов, несвязность текста и, наконец, что приводит в большинстве случаев к отказу от использования БД в больших проектах

• большая сложность получения документа/отчёта (например с помощью генератора IBM Rational SoDaдля RequisitePro), который будет утверждаться в качестве ТЗ, или SRS.

• Гибридные структуры.Опыт автора ограничивается использованием RequisitePro и Doors. Про Requisite можно отметить следующие плюсы: требования действительно можно вводить непосредственно в документ Word и присваивать им всю необходимую атрибутику, разработчик получает все преимущества текстового процессора по форматированию и вставке графики. Есть возможность автоматического версионирования документов целиком (например с использованием CVS). Отрицательными моментами является невозможность версионирования графических объектов и сложности работы с отсоединёнными документами (в частности в отсоединённом документе невозможно задавать иерархию требований), кроме того, периодически возникают сбои, присущие Word. Doors, собственно не является гибридным продуктом, а сам представляет собой текстовый процессор, положительные стороны

• все те же, что и у Requisite, плюс версионирование графики и меньшее количество сбоев (подробное сравнение не является предметом данного документа).

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

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

По сути, возможности современных систем управления требований покрывают все потребности аналитиков, но всё же остаётся разрыв между аналитическими моделями, и собственно требованиями к ПО. Предоставляемые возможности связывания требований и объектов

 это связь по ссылке, что не всегда удобно в использовании.

Ещё один подход к формированию требований к ПО.

• IDEF0 В описании стандарта IDEF0, в качестве одной из основных областей применения стандарта функционального моделирования приводится спецификация требований к ПО, цитирую: "For new systems, IDEF0 may be used first to define the requirements and specify the functions, and then to design an implementation that meets the requirements and performs the functions."

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

Рассмотрим возможности ведения требований на примере одного из самых известных продуктов, поддерживающих моделирование в стандарте IDEF0, AllFusion Process Modeler (ранее BPwin).

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

Таким образом, в рамках единой структурированной модели имеется возможность совместить и графическое и текстовое (в виде определений к графическим элементам) представление требований к ПО. Но остаётся проблема получения единого документа, содержащего все требования к ПО, структурированные в соответствии с одним из шаблонов ГОСТ/SRS, так как существующий генератор отчётов AllFusion Process Modeler (Bpwin) предоставляет достаточно скудные средства форматирования. Невозможна также трассировка требований и их версионирование (использование AllFusion Model Manager (ранее ModelMart)для получения истории изменения требований представляется сложным).