2.4.2 Формальная модель рекурсивно-объектной модели требований

Рассмотрим вторую формальную модель требований, представленную в работе YongZen [7], занимающегося со своей командой созданием рекурсивной объектной моделью для идентификации требований.

Данная модель основывается на двух простейших аксиомах:

Аксиома 1. Все в пространстве является объектом.

Аксиома 2. Объекты объединяют связи.

Модель включает в себя:

- множество объектов, ;

- множество отношений;

- множество типов отношений между объектами, где .

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

С точки зрения аксиомной теории структурная операция будет выглядеть следующим образом: где - это структура объекта.

Объект может включать в себя другие объекты ( , таким образом, получается: где m- произвольное число.

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

3. Подход к автоматизированному формированию требования на основе проектной документации

3.1 Архитектура решения

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

Для этого необходимы следующие основные компоненты архитектуры системы:

1. Компонент для извлечения информации из документов.

2. Компонент для аннотирования корпуса документов.

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

Рисунок 3.1 Пример онтологии требований

Данная онтология содержит не только классификацию требований и связи между требованиями, а также общие конструкции для идентификации требований, и идентифицирующие языковые конструкции для каждого вида требования. Приведем пример общей конструкции, характерной для любого вида требований: "Х должна содержать Nфункциональных элементов". Из данного пример можно отметить, что есть объект 1 = Х, объект 2 = N и языковая конструкция "должна содержать". Именно словосочетание "должна содержать" указывает на то, что эта компонента содержимого документы является требованием. Поскольку определено, что эта фраза является требованием, далее можно попытаться присвоить данную конструкцию к какой-либо классификационной группе. В предложении звучит "функциональных элементов", следовательно, если в онтологии, в одной из ветвей среди различных видов требований будет найден экземпляр, соответствующий тому, который звучит в данном требовании, тогда требованию можно будет присвоить группу.

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

Как уже отмечалось ранее, в качестве поддерживающего решения для процесса формализации требований будет выступать GATE. GATE - масштабный программный продукт с открытым кодом, который включает в себя инструменты для поддержания всего жизненного цикла ПО - от проектирования и разработки (GATE Developer, интегрированный с разнообразными плагинами и с системой извлечения информации) до совместного использования множеством серверов в целях аннотации документов (GATE Teamware, использующий парадигму потоков работ). Плюс ко всему инструмент предоставляет интерфейс (GATE Embedded) для приложений внутри организации - при помощи библиотеки объектов Java.

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

Архитектура GATE:

1. Компонент работы с лингвистическими ресурсами.

2. Компонент для обработки документов.

3. Компонент для графического интерфейса.

4. Компонент хранилища данных.

5. Компонент репозитория плагинов.

На рисунке 3.2 представлена схема организации архитектуры общего решения, а также в ней отображены связи между компонентами. В таблице 3.1 подробно описаны компоненты и модули общего решения системы.

Рисунок 3.2 Архитектура решения

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

V-Model (или VEE модель) является моделью разработки информационных систем (ИС) (см. рис. 3.3), направленной на упрощение понимания сложностей, связанных с разработкой систем. Она используется для определения единой процедуры разработки программных продуктов. Представляет из себя самую знаменитую диаграмму ЖЦ, и рассматривается как вариант вида ЖЦ "Водопадного" жесткого стиля - "каскад" перегнут в точке "разработки".

Таблица 3.1 Описание компонентов и модулей системы

Компонент\модуль	Решаемые задачи	Входные потоки	Выходные потоки
Компонент работы с лингвистическими ресурсами	Обработка документов, вводимых в ИС	Файлы, документов разных форматов
Модуль работы с документами	Обработка единственного документа	Документ	Аннотированный документ, есть возможность выгрузке в формате XML
Модуль работы с корпусом документов	Формирование из набора документов корпуса документов для дальнейшего анализа, аннотирования связанных документов	Корпус документов	Аннотированный корпус документов, есть возможность выгрузке в формате XML
Модуль работы с аннотациями	Формирование аннотация к документам, организованных в виде графов	Документ, корпус документов	Дерево, список ключевых слов, организованных в виде графа
Компонент для обработки документов	Обработка документов, вводимых в ИС: определение типа вводимой формы; обработка формы согласно алгоритму обработки типа форм	Документ	Структурированная/ полуструктурированная детальная информация формы; Данные формы, зафиксированные в учетной системе входящих форм
Модуль работы с параметрами документа	Последовательное применение цепочки процесса обработки текста к документу	Документ	Конфигурация приложения
Модуль работы с корпусом документов	Последовательное применение цепочки процессса обработки текста к корпусу документов	Корпус документов	Конфигурация приложения
Модуль создания приложений (сценариев обработки текстов)	Создание и хранение сценариев обработки текстов. На основе запоминания используемых плагинов и настроек	Информация о плагинах, последовательности запуска плагинова, настроек. Конфигурация приложений	Конфигурация приложения
Компонент для графического интерфейса	Определение разметки документов в соответствии с едиными правилами	Документ	Аннотация к документу, онтологии
Модуль для работы с разметкой документа	Определение разметки документов в соответствии с едиными правилами	Документ	Аннотация к документу, онтологии
Datastores	Хранилище данных. Позволяет создавать, открывать, сохранить документы и корпусы документы	Документы	Документы
CREOLE репозиторий плагинов	Позволяет проверять обновления, запускать необходимые плагины для работы с текстами (хранятся локально на компьютере)	Плагин	Плагин
Компонент ANNIE	Выполняет задачу обработки текстов. Модули объединены в приложения.	Документы	Обработанный документ пригодный для анализа по различным параметрам
Модуль подготовки документа	Удаляет разметку из документов	Документы	Документ без разметки
Модуль токенизации	Делит текст на токены, числа, знаки пунктуации, слова, символы, знаки пробелов	Документы	Документ разделенные на различные токены
Модуль gazetter	Определяет именованные сущности, определенные заранее (есть настрока на русский язык)	Документы	Документ с определенными именованными сущностями
Модуль разделения текста на высказывания	Делит текст на высказывания, используя различные списки стопслов, аббревиатур и пр.	Документы	Документы разделенный на высказывания
Модуль регулярных выражений	Альтернативный способ деления текста на высказывания с помощью регулярных выражений JAPE	Документы	Документ разделенный на высказывания
Модуль семантической аннотации	Семантическая аннотация с помощью правил JAPE-преобразователя	Документы	Семантическая аннотация
Модуль работы с онтологиями	Добавляет тип отношений к между тегами, создавая онтологию	Документы	Онтология
Модуль тестирования результатов обработки текста	Выполняет сравнение документов, вычисление метрик качества обработки текста	Документы	Метрики качества



Рисунок 3.3 V-модель разработки ИС

Однако V-образную модель разработки ИС в данном случае необходимо использовать с ориентацией на требования, формализацию и управление, тогда предлагается изменить стандартную модель ЖЦ и модель приобретет следующий вид (см. рис. 3.4):

Рисунок 3.4 V-модель разработки ИС с ориентацией на требования

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

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

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

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

3.2 Формальная модель подхода

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

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

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

Размещено на http://www.allbest.ru/

Рисунок 3.5 Пример схемы модального предложения

В основе большинства структурных схем лежат глагольные конфигурации, под которыми понимается сочетание глагольного ядра с его оптимальным окружением [12]. Каждый член окружения по отношению к своему ядру и другим членам окружения выполняет определенную функцию. Реализуясь в речи, конфигурации варьируются относительно материального выражения членов конфигурации и полноты окружения.

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

Для описания синтаксических моделей будем использовать следующие обозначения:

1) V - глагол,

2) N - существительное (падеж существительного обозначается соответствующей цифрой, например: N1, N2),

3) Adj - прилагательное,

4) D - детерминант,

5) Adv - наречие,

6) Vcop - связочный глагол,

7) Vmod - модальный глагол,

8) Nv - отглагольное существительное,

9) Cl - придаточное предложение,

10) Inf - инфинитив,

11) Praed - предикативное наречие,

12) Ш-незаполненная позиция.

Выделим следующие схемы синтаксической организации предложений слексемами со значением необходимости:

1. N1 + VcopШ + Adjmod + Inf: Система должна активироваться первой.

2. N3 + VcopШ + Praedmod + Inf: Пользователь должен запустить.

3. N3 + Vmod + Inf: Функциональный элемент выполняется поочередно.

4. N3 + VcopШ + Praedmod + N1: Системе нужны ресурсы.

5. Nv1 + VcopШ +Adjmod: Завершение обаятельно.

6. Nv1 + VcopШ + Adjmod + Inf: Элемент должен бытьреализован на языке.

По аналогии можно формировать и другие конструкции.

Таким образом, сформируем формальную модель требований:

- это область проектной деятельности,

- это область этапов ЖЦ ИС,

Обозначим следующие множества:

множество проектов: ;

множество этапов ЖЦ ИС: ;

множество бизнес-процессов: ;

множество атрибутов проектного документа: ;

множество элементов содержимого проектного документа: ;

множество требований: ;

множество классов требований: ;

множество элементов предложения: .

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

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

- это вектор атрибутов k-ого требования, где j-ого проекта i-ого домена, где - это текстовая формулировка требования,

- это множество концептов (групп),

- множество несемантических атрибутов требования.

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

Предлагаемая формальная модель позволяет рассматривать требования не обособленно, а связанно с проектом, ЖЦ ИС. Кроме того, учитывается множество объектов предложения, поскольку для идентификации требований и синтаксических конструкций модального характера, необходимо рассматривать корпус документов вплоть до слова.

3.3 Описание предлагаемого подхода

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

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

1) формирование корпуса документов и онтологий (требований, проекта);

2) классификация и аннотирование корпуса.

Каждый из этапов опишем более подробно, схема подхода представлена на рис. 3.6.

3.3.1 Формирование корпуса документов и онтологий

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

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

Рисунок 2.6 Схема подхода

3.3.2 Классификация и аннотирование корпуса документов

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

Для отражения в аннотации элементов требования (например, исполнителя, модальное выражение, тему, условие и пр.) необходимо применить к корпусу лексико-грамматические правила. Данные правила будут выполнены на языке JAPEв среде GATEDeveloper.

3.3.3 Модель требования

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

Опишем модель требования:

1. Каждое отдельное требование состоит из:

a. Формального обозначения требования.

b. Критериев валидации (для определения выполнимости требования).

c. Атрибутов:

– уникальный идентификатор;

– категория (требование к данным, внешнее требованиеAPI, функциональное требование и др.),

– критичность для заказчика (критично, очень критично, средне, низкая критичность),

– критичность для пользователя (критично, очень критично, средне, низкая критичность),

– ожидаемый ценовой диапазон (высокий, средний, малый),

– частота исполнения (высокая, средняя, низкая),

– статус реализации (реализуем, не реализуем),

– оправданность реализации (оправданно, не оправданно),

– владельцы (акторы),

– приоритет (реализация в текущей версии, реализация в следующем релизе, не приоритетен),

– риск, связанный с реализацией (высокий, средний, малый),

– источник (документ, интервью, цель стейкхолдера и др.),

– статус (предложено, анализируется, разрабатывается спецификация, реализуется, применяется, подтвержден, заморожен и др.),

– методы валидации (анализ, демонстрация, инспекции, тестирование),

– статус валидации (валидируемый, невалидируемый),

– изменчивость (высокая, средняя, малая).

d. Принадлежит к части диаграммы требований проекта.

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

– типа требования,

– подхода к анализу требований,

– подхода к спецификации требований.

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

Рисунок 3.7 Фрагмент онтологии

3.3.4 Формализация лексико-грамматических правил требований

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

Таблица 3.2 Характеристики элементов требования

Класс элемента	Описание	Пример	Возможные варианты звучания элемента
Агент (А)	Объект, который выполняет какое-либо действие	"Компания обязуется выполнить работы в срок до конца 2016 г. "	Система, сервис, приложение, подсистема, функциональный элемент, заказчик, компания
Условие (У)	Ограничивающие рамки	"Компания обязуется выполнить работы в срок до конца 2016 г. "	Каждые 60 сек., в срок до
Инструмент (И)	Объект, с помощью которого будет достигнут результат	"Система должна быть разработана на платформе MSSharePoint"	Используя IE6, с помощью макроса, на языке Java
Действие (Д)	Событие (инфинитив)	"Система должна обладать следующим функционалом"	Реализовано, автоматизировано, обладать, предполагает, содержит
Модальность (М)	Глагол, указывающий на предмет долженствования	"Система должна обладать следующим функционалом"	Должна (-о, - ы,-ен) /быть

Семантический анализ выражения требования позволяет отметить наиболее часто встречающиеся структуры выражений:

- Агент (А) +действие (Д) +условие (У);

- Агент (А) +модальность (М) +действие (Д) +условие (У) /инструмент (И);

- Действие (Д) +условие (У) /инструмент (И);

- Модальность (М) +действие (Д) +предмет (П).

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

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

Реализация лексико-грамматических правил для аннотирования корпуса

Реализация лексико-грамматических правил для аннотирования корпуса документов ведётся на базе среды GATE за счет применения JAPE-правил. Это позволит использовать уже имеющиеся открытые ресурсы для обработки текстов на естественном языке и создать комбинацию языковых плагинов для дельнейшего наложения структур аннотирования на корпус документов.

Описание правил на языке JAPEсостоит из двух частей. Синтаксис левой (LHS) и правой (RHS) части правила. Левая (LHS) часть содержит регулярное выражение для поиска необходимых фрагментов текста.

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

1. Для извлечения модальной конструкции.

2. Для извлечения выражения, содержащего модальную конструкцию.

3. Для извлечения действия.

4. Для извлечения предмета требования (система, модуль).

5. Для извлечения инструмента.

6. Для извлечения условия.

7. Для извлечения ссылки на др. документ.

Пример JAPE-правила на извлечения условия (см. листинг 3.1):

Phase: Action

Input: Lookup Token Action

Options: control=all

Rule: rule1

(

({Lookup. majorType == modal_phrase}): left

({Token}) [0,9]

({Action}): right

)

: ann-->

{

Node start = ( (AnnotationSet) bindings. get ("left")). firstNode ();

Node end = ( (AnnotationSet) bindings. get ("right")). firstNode ();

FeatureMap features = Factory. newFeatureMap ();

features. put ("type","action");

outputAS. add (start,end,"action",features);

}

Листинг 3.1 Пример JAPE-правила

Помимо всех вышеперечисленных правил, в рамках магистерской диссертации будет увеличено количество и качество лексико-грамматических правил. Пример аннотированного документа представлен на рисунка 3.7 и 3.8.

Рисунок 3.7 Пример извлечения концептов требований

Рисунок 3.8 Пример аннотирования технического задания

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

В дальнейшем необходима реализация следующих плагинов:

- для классификации требований по онтологии;

- для вычленения всех концептов модели.

Все описанные выше обрабатывающие ресурсы работают на основе результатов работы открытых обрабатывающих ресурсов для GATE. Весь перечень используемых ресурсов для первоначального этапа аннотирования представлен на рис. 3.9

Рисунок 3.9 Используемые ресурсы для аннотирования

– В первую очередь применяется работа Tokenizer (токенизатор, определяющий слова, числа, пунктуацию, символы, пробелы);

– затем Gazetteer (словарь русский-английский);

– далее применяется OrthoMatcher (орфографическая кореференция);

– после POSTagger (семантический теггер по частям речи);

– далее вступает в работу Sentence Splitter (сплиттер предложений);

– JAPEправила для поиска компонент требований;

– OntoGazetter для мэппинга вершин онтологии с аннотацией корпуса документов.

Рисунок 3.10. Онтология требований, представленная в инструменте GATE

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

Рисунок 3.11. Онтология требований, представленная в инструменте GATE

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

Рисунок 3.12 Фрагмент размеченного текста в формате XML

Заключение

Основным направлением данной работы являлось формирование подхода для автоматизированного формирования требований к разработке ИС на основе анализа проектной документации. В работе были исследованы такие предметные области, как проектная документация, требования и классификация требований, методы описания требований, формальные модели требований и подходы к автоматизированному формированию требований.

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

– сформирован подход к автоматизированному формированию требований на основе проектной документации;

– описана архитектуру решения;

– описана модель требований;

– описан алгоритм формализации требований;

– разработаны лексико-семантические правила для извлечения концептов требований.

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

Библиографический список

1. Заболеева-Зотова А.В. Автоматизация семантического анализа документации технического задания // Вестник компьютерных и информационных технологий. Машиностроение. 2008. №9. С.26-34.

2. Заболеева-Зотова А.В. Автоматизация процедур семантического анализа текста технического задания // Известия ВолгГТУ. Сер. "Акутальные проблемы управления, вычислительной техники и информатики в технических системах": межвуз. сб. науч. ст. / 2007. Вып.2 №2. С.39-42.

3. Орлова Ю.А. Методика анализа текста технического задания // Информатика, вычислительная техника и управление // Известия ТулГУ. Сер. "Техническиенауки": межвуз. сб. науч. ст. / 2011. Вып.3. С.213-220.

4. Система стандартов по информационному, библиотечному и издательскому делу. Управление документами. Общиетребования [Текст]: ГОСТ Р ИСО 15489-1-2007. - М.: Стандартинформ. 2007.34 с.

5. Унифицированные системы документации. Унифицированная система организационно-распорядительной документации. Требования к оформлению документов [Текст]: ГОСТ Р 6.30-2003. - М.: 2003.19 с.

6. Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем [Текст]: ГОСТ 34.201-89 - М. Изд-во стандартов, 1991.

7. ElderJ. PracticalTextMiningandStatisticalAnalysisforNon-structuredTextDataApplications. - London, UK: Springer. 2012.812 p.

8. E. Hull. Requirement management. London, UK: Springer. 2005.240 p.

9. Min Wang. Requirements Modeling: from Natural Language to Conceptual Models Using Recursive Object Model Analysis. A thesis in the Department of Electrical and Computer Engineering Concordia University. 2013.

10. Y. Zeng. A science-based approach to product design theory. Part II. Formulation of design requirements and products. Robotics and Computer Integrated Manufacturing 15.1999. pp.341-352.

11. Y. Zeng. Recursive Object Model, Modelling of linguistic information in engineering design.computers in Industry 59.2008. pp.612-625.

12. Z. YChen. and Y. Zeng. Classification of product requirements based on product environment. Concurrent Engineering: Research and Applications, An International Journal, 14 (№3). 2006 pp.219-230.

13. K. Lano and D. Clark. Direct semantics of extended state machines, TOOLS'07.2007

14. Chen, L. and Zeng, Y., 2009. Automatic generation of UML diagrams from product requirement requirements described by natural language, The 2009 ASME International Design Engineering Technical Conferences (IDETC) and Computers and Information in Engineering Conference, San Diego, USA.

15. Markovic, S. and Barbosa, L.S., 2008. Semantics of OCL specified with QVT. Software and Systems Modelling, 7 (4).

16. Tjoa, A.M. and Berger, L., 1993. Transformation of requirements specifications expressed in natural language into an EER model, Proceedings of the 12th International conference on Entity-Relationship Approach (ER'93), Airlington, Texas USA.

17. Mala, G.S.A. and Uma, G.V., 2006. Automatic construction of object oriented design models [UML diagrams] from natural language requirements specification, Pricai 2006: Trends in Artificial Intelligence, Proceedings. Lecture Notes in Artificial Intelligence, pp.1155-1159.

18. Gnesi, S., Lami, G., Trentanni, G., Fabbrini, F. and Fusani, M., 2005. An Automatic Tool for the Analysis of Natural Language Requirements. International Journal of Computer Systems Science and Engineering, 20 (1).

19. Model Requirements for the Management of Electronic Records. MoReq2 Specification. Update and extension. - European Commission. 2008.212 p.

20. Recommendations for the expungement of information recorded on write-once optical media [Text]: ISO/TR 12037: 1998. - ISO: 1998.12 p.

21. Recommended Practice for Architectural Description of Software-Intensive Systems. Control Objectives for Information and related Technology (COBIT 4.0).: ANSI / IEEE Std 1471-2000. IT Governance Institute (ITGI). 2005

22. Riis J.O. Design of Enterprise Information Systems: Roots, Nature and New Approaches // 5^th IFIP WG 8.9 Working Conference. - Aalborg, Denmark. 2011.

23. Shilakes C.С. Enterprise Information Portals. // IS Journal. November, 1998.

24. Shwartz D.G. Encyclopedia of Knowledge Management. - London, UK: Idea Group Reference. 2006.946 p.

25. The AIIM Document Management Alliance (DMA) specifications [Электронный ресурс] [Режим доступа: http://dmatech. info/] [Проверено: 14.04.2016].

Приложения

Типовой состав документации для каждой стадии ЖЦ проекта по созданию ИС

Таблица А. Типовой состав проектной документации

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

Приложение Б - Сравнительный анализ методов работы с требованиями

Таблица Б.1. Сравнительный анализ методов работы с требованиями

Задачи	Подзадачи	RUP	CORE	SSM	RAISE
Извлечение требований	Выявление источников	Анализ целей системы	Анализ документов и целей системы	Анализ документов и целей системы	-
	Извлечение требований	Моделирование сценариев	Анализ документов, моделирование	Прототипирование	Интроспекция, анализ документов
	Согласование требований	Моделирование сценариев	Моделирование точек зрения, уточнение требований	Моделирование точек зрения	-
Структурирование требований		Построение модели вариантов использования и концептуальной модели	Иерархическая модель точек зрения, модель системных функций	Построение целостной картины, ситуации, выделение точек зрения	Система формальных моделей
Описание требований		Модель вариантов использования, концептуальная модель	Иерархическая модель точек зрения системных функций, модель системных транзакций	Целостная картина ситуации, концептуальная модель	Система формальных моделей
Валидация требований		Прототипирование, рецензирование	Рецензирование, интервью	Когнитивные техники, прототипирование	Анализ сценариев
Верификация требований	Проверка однозначности	Рецензирование аналитиком, автоматизированный статический анализ	Рецензирование аналитиком, уточнение	-	Рецензирование аналитиков, автоматизированный статический анализ
	Проверка полноты	Рецензирование аналитиком	Рецензирование аналитиком	-	Рецензирование аналитиком, формальный анализ
	Проверка непротиворечивости	Рецензирование аналитиком, автоматизированный статический анализ	Рецензирование аналитиком	-	Рецензирование аналитиком, автоматизированный формальный анализ
	Проверка минимальности	Рецензирование аналитиком	-	-	Рецензирование аналитиком, формальный анализ
	Проверка систематичности	Рецензирование аналитиком	Рецензирование аналитиком	Рецензирование аналитиком	Рецензирование аналитиком

Приложения - Сравнительный анализ методов моделирования требований

Таблица В.1. Сравнительный анализ методов моделирования требований

Критерий	SysML	RIF	GRL+UCM	RFLP	ArchiMate	MBRD	BMM	Planguage	ISO 15926	Modelica
Возможность изменения модели	Визуальный редактор	Нет	Визуальный редактор	Визуальный редактор	Визуальный редактор	Редактор текстов	Редактор текстов	Редактор текстов	Редактор текстов, визуальный редактор	Редактор текстов, визуальный редактор
Тип синтаксиса	Графический, есть стандартизированное XMI представление	Текстовый	Текстовый	Текстовый	Текстовый	Текстовый	Текстовый	Текстовый	Текстовый	Текстовый + диаграммы
Наличие диаграмм	Да	Нет	Нет	Нет	Да	Да	Нет	Да	Да	Да
Наличие возможности семантической связи требований	Да	Нет	Нет	Нет	Да	Нет	Нет	Нет	Нет	Нет
Связь с архитектурной моделью	Да, встроенная	Есть, не встроена	Есть	Есть	Есть	Нет	Нет	Нет	Есть	Нет
Возможность исполнения модели	Нет	Нет	Нет	Нет	Нет	Нет	Нет	Нет	Нет	После компиляции в традный язык прогр-ия
Пользовательский синтаксис	Диаграмма, текст нередакт.	Диаграмма текст нередакт.	Диаграмма, текст нередакт.	Диаграмма, текст нередакт.	Текстовый	Текстовый	Текстовый	Текстовый	Текстовый	Текстовый
Наличие языка запросов	Нет	Нет	Нет	Нет	Нет	Нет	Нет	Нет	Нет	Нет

Приложения Г - OWL-код онтологии

<? xml version="1.0"? >

<Ontology xmlns="http://www.w3.org/2002/07/owl#"

xml: base="http://www.semanticweb.org/ebrezgina/ontologies/2016/2/untitled-ontology-16"

xmlns: rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns: xml="http://www.w3.org/XML/1998/namespace"

xmlns: xsd="http://www.w3.org/2001/XMLSchema#"

xmlns: rdfs="http://www.w3.org/2000/01/rdf-schema#"

ontologyIRI="http://www.semanticweb.org/ebrezgina/ontologies/2016/2/untitled-ontology-16">

<Prefix name="" IRI="http://www.semanticweb.org/ebrezgina/ontologies/2016/2/untitled-ontology-16#"/>

<Prefix name="owl" IRI="http://www.w3.org/2002/07/owl#"/>

<Prefix name="rdf" IRI="http://www.w3.org/1999/02/22-rdf-syntax-ns#"/>

<Prefix name="xml" IRI="http://www.w3.org/XML/1998/namespace"/>

<Prefix name="xsd" IRI="http://www.w3.org/2001/XMLSchema#"/>

<Prefix name="rdfs" IRI="http://www.w3.org/2000/01/rdf-schema#"/>

<Declaration>

<Class IRI="#Сопровождаемость"/>

</Declaration>

<Declaration>

<NamedIndividual IRI="#закрыто"/>

</Declaration>

<Declaration>

<ClassIRI="#Критичность_для_заказчика"/>

</Declaration>

<Declaration>

<Class IRI="#Владелец"/>

</Declaration>

<Declaration>

<ObjectProperty IRI="#является_результатом"/>

</Declaration>

<Declaration>

<Class IRI="#Нефункциональные"/>

</Declaration>

<Declaration>

<ObjectProperty IRI="#сопровождается"/>

</Declaration>

<Declaration>

<Class IRI="#Актор"/>

</Declaration>

<Declaration>

<Class IRI="#Источник"/>

</Declaration>

<Declaration>

<Class IRI="#Адаптируемость"/>

</Declaration>

<Declaration>

<Class IRI="#Условие"/>

</Declaration>

<Declaration>

<Class IRI="#Модальность"/>

</Declaration>

<Declaration>

<Class IRI="#По_источнику"/>

</Declaration>

<Declaration>

<Class IRI="#Стейкхолдер"/>

</Declaration>

<Declaration>

<ObjectProperty IRI="#имеет_приоритет"/>

</Declaration>

<Declaration>

<Class IRI="#К_оборудованию"/>

</Declaration>

<Declaration>

<Class IRI="#Категория"/>

</Declaration>

<Declaration>

<Class IRI="#Функциональные"/>

</Declaration>

<Declaration>

<Class IRI="#Менеджер_проекта"/>

</Declaration>

<Declaration>

<Class IRI="#К_обеспечению"/>

</Declaration>

<Declaration>

<Class IRI="#ID"/>

</Declaration>

<Declaration>

<ObjectProperty IRI="#обладает"/>

</Declaration>

<Declaration>

<Class IRI="#Агент"/>

</Declaration>

<Declaration>

<Class IRI="#Приоритет"/>

</Declaration>

<Declaration>

<Class IRI="#Держатель_требований"/>

</Declaration>

<Declaration>

<Class IRI="#Пользователь"/>

</Declaration>

<Declaration>

<Class IRI="#Эффективность"/>

</Declaration>

<Declaration>

<Class IRI="#По_предмету"/>

</Declaration>

<Declaration>

<Class IRI="#Критичность_для_пользвоателя"/>

</Declaration>

<Declaration>

<Class IRI="#Инструмент"/>

</Declaration>

<Declaration>

<Class IRI="#Класс_требования"/>

</Declaration>

<Declaration>

<Class IRI="#Исполнитель_требований"/>

</Declaration>

<Declaration>

<Class IRI="#Аттрибут_требования"/>

</Declaration>

<Declaration>

<Class IRI="#Abstract"/>

</Declaration>

<Declaration>

<Class IRI="#Переносимость"/>

</Declaration>

<Declaration>

<NamedIndividual IRI="#адаптирована_к_условиям"/>

</Declaration>

<Declaration>

<Class IRI="#Средний"/>

</Declaration>

<Declaration>

<Class IRI="#Низкий"/>

</Declaration>

<Declaration>

<Class IRI="#К_обслуживанию"/>

</Declaration>

<Declaration>

<Class IRI="#Ограничение"/>

</Declaration>

<Declaration>

<Class IRI="#Заказчик"/>

</Declaration>

<Declaration>

<ObjectProperty IRI="#исполняется"/>

</Declaration>

<Declaration>

<NamedIndividual IRI="#сделано"/>

</Declaration>

<Declaration>

<Class IRI="#Аппаратные"/>

</Declaration>

<Declaration>

<Class IRI="#Качественные"/>

</Declaration>

<Declaration>

<Class IRI="#По_виду_использования"/>

</Declaration>

<Declaration>

<Class IRI="#Статус_реализации"/>

</Declaration>

<Declaration>

<Class IRI="#Действие"/>

</Declaration>

<Declaration>

<Class IRI="#Простота_настрйоки"/>

</Declaration>

<Declaration>

<Class IRI="#К_ИС"/>

</Declaration>

<Declaration>

<Class IRI="#Совместимость"/>

</Declaration>

<Declaration>

<Class IRI="#Требование"/>

</Declaration>

<Declaration>

<Class IRI="#Проектная_группа"/>

</Declaration>

<Declaration>

<Class IRI="#Высокий"/>

</Declaration>

<Declaration>

<Class IRI="#Выражение_требования"/>

</Declaration>

<Declaration>

<Class IRI="#Заменимость"/>

</Declaration>

<EquivalentClasses>

<Class IRI="#Агент"/>

<Class IRI="#Актор"/>

</EquivalentClasses>

<SubClassOf>

<Class IRI="#ID"/>

<Class IRI="#Аттрибут_требования"/>

</SubClassOf>

<SubClassOf>

<Class IRI="#Агент"/>

<ClassIRI="#Выражение_требования"/>

</SubClassOf>

<SubClassOf>

<ClassIRI="#Адаптируемость"/>

<ClassIRI="#Переносимость"/>

</SubClassOf>

<SubClassOf>

<Class IRI="#Актор"/>

<Class IRI="#Abstract"/>

</SubClassOf>

<SubClassOf>

<ClassIRI="#Аппаратные"/>

<ClassIRI="#По_предмету"/>

</SubClassOf>

<SubClassOf>

<ClassIRI="#Аттрибут_требования"/>

<Class IRI="#Требование"/>

</SubClassOf>

<SubClassOf>

<ClassIRI="#Владелец"/>

<ClassIRI="#Аттрибут_требования"/>

</SubClassOf>

<SubClassOf>

<ClassIRI="#Выражение_требования"/>

<Class IRI="#Abstract"/>

</SubClassOf>

<SubClassOf>

<Class IRI="#Высокий"/>

<Class IRI="#Приоритет"/>

</SubClassOf>

<SubClassOf>

<Class IRI="#Действие"/>

<ClassIRI="#Выражение_требования"/>

</SubClassOf>

<SubClassOf>

<ClassIRI="#Держатель_требований"/>

<Class IRI="#Актор"/>

</SubClassOf>

<SubClassOf>

<ClassIRI="#Заказчик"/>

<ClassIRI="#Держатель_требований"/>

</SubClassOf>

<SubClassOf>

<Class IRI="#Заменимость"/>

<Class IRI="#Переносимость"/>

</SubClassOf>

<SubClassOf>

<ClassIRI="#Инструмент"/>

<ClassIRI="#Выражение_требования"/>

</SubClassOf>

<SubClassOf>

<ClassIRI="#Исполнитель_требований"/>

<Class IRI="#Актор"/>

</SubClassOf>

<SubClassOf>

<ClassIRI="#Источник"/>

<ClassIRI="#Аттрибут_требования"/>

</SubClassOf>

<SubClassOf>

<Class IRI="#К_ИС"/>

<ClassIRI="#Класс_требования"/>

</SubClassOf>

<SubClassOf>

<ClassIRI="#К_обеспечению"/>

<Class IRI="#По_предмету"/>

</SubClassOf>

<SubClassOf>

<ClassIRI="#К_оборудованию"/>

<ClassIRI="#По_предмету"/>

</SubClassOf>

<SubClassOf>

<Class IRI="#К_обслуживанию"/>

<Class IRI="#По_предмету"/>

</SubClassOf>

<SubClassOf>

<ClassIRI="#Категория"/>

<ClassIRI="#Аттрибут_требования"/>

</SubClassOf>

<SubClassOf>

<Class IRI="#Качественные"/>

<Class IRI="#Нефункциональные"/>

</SubClassOf>

<SubClassOf>

<ClassIRI="#Класс_требования"/>

<ClassIRI="#Требование"/>

</SubClassOf>

<SubClassOf>

<ClassIRI="#Критичность_для_заказчика"/>

<ClassIRI="#Аттрибут_требования"/>

</SubClassOf>

<SubClassOf>

<ClassIRI="#Критичность_для_заказчика"/>

<ObjectSomeValuesFrom>

<ObjectProperty IRI="#имеет_приоритет"/>

<Class IRI="#Приоритет"/>

</ObjectSomeValuesFrom>

</SubClassOf>

<SubClassOf>

<ClassIRI="#Критичность_для_пользвоателя"/>

<ClassIRI="#Аттрибут_требования"/>

</SubClassOf>

<SubClassOf>

<ClassIRI="#Критичность_для_пользвоателя"/>

<ObjectSomeValuesFrom>

<ObjectProperty IRI="#имеет_приоритет"/>

<Class IRI="#Приоритет"/>

</ObjectSomeValuesFrom>

</SubClassOf>

<SubClassOf>

<Class IRI="#Менеджер_проекта"/>

<ClassIRI="#Исполнитель_требований"/>

</SubClassOf>

<SubClassOf>

<ClassIRI="#Модальность"/>

<ClassIRI="#Выражение_требования"/>

</SubClassOf>

<SubClassOf>

<Class IRI="#Нефункциональные"/>

<Class IRI="#К_ИС"/>

</SubClassOf>

<SubClassOf>

<Class IRI="#Низкий"/>

<Class IRI="#Приоритет"/>

</SubClassOf>

<SubClassOf>

<Class IRI="#Ограничение"/>

<Class IRI="#Нефункциональные"/>

</SubClassOf>

<SubClassOf>

<ClassIRI="#Переносимость"/>

<ClassIRI="#Качественные"/>

</SubClassOf>

<SubClassOf>

<ClassIRI="#По_виду_использования"/>

<ClassIRI="#Класс_требования"/>

</SubClassOf>

<SubClassOf>

<ClassIRI="#По_источнику"/>

<ClassIRI="#Класс_требования"/>

</SubClassOf>

<SubClassOf>

<ClassIRI="#По_предмету"/>

<ClassIRI="#Класс_требования"/>

</SubClassOf>

<SubClassOf>

<Class IRI="#Пользователь"/>

<ClassIRI="#Держатель_требований"/>

</SubClassOf>

<SubClassOf>

<ClassIRI="#Приоритет"/>

<ClassIRI="#Аттрибут_требования"/>

</SubClassOf>

<SubClassOf>

<Class IRI="#Проектная_группа"/>

<ClassIRI="#Исполнитель_требований"/>

</SubClassOf>

<SubClassOf>

<ClassIRI="#Простота_настрйоки"/>

<Class IRI="#Переносимость"/>

</SubClassOf>