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

Оглавление

• Условные обозначения и сокращения
• Введение
• 1. Требования в процессе разработки ИС
• 1.1 Проектная документация при разработке ИС
• 1.2 Определение понятия требования
• 1.3 Классификация требований
• 1.3.1 Уровни требования по К. Вигерсу
• 1.3.2 Классификация требования по SWEBOK
• 1.3.3 Классификация RUP (FURPS+)
• 2. Методы определения требований
• 2.1 Методы описания требований
• 2.2 Методы работы с требованиями
• 2.3 Методы моделирования требований
• 2.4 Формальные модели требований
• 2.4.1 Формальная модель системного комплекса требований к АИС
• 2.4.2 Формальная модель рекурсивно-объектной модели требований
• 3. Подход к автоматизированному формированию требования на основе проектной документации
• 3.1 Архитектура решения
• 3.2 Формальная модель подхода
• 3.3 Описание предлагаемого подхода
• 3.3.1 Формирование корпуса документов и онтологий
• 3.3.2 Классификация и аннотирование корпуса документов
• 3.3.3 Модель требования
• 3.3.4 Формализация лексико-грамматических правил требований
• Реализация лексико-грамматических правил для аннотирования корпуса
• Заключение
• Библиографический список
• Приложения
• Приложения Г - OWL-код онтологии

Условные обозначения и сокращения

ИС - Информационная система;

ЖЦ - Жизненныйцикл;

GATE - General Architecture for Text Engineering;

GUI - Graphical User Interface;

JAPE - Java Annotation Patterns Engine;

OWL - Web Ontology Language;

UML - Unified Modeling Language;

XML - ExtensibleMarkupLanguage.

Введение

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

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

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

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

Большинство работ в области автоматизации процесса проектирования ИС, а также документирования этапов создания направлены на создание и совершенствование инструментария для сопровождения проектирования. Однако тематика анализа всей документации проекта по созданию ИС и автоматическое формирование требований, связей и извлечение ключевых моментов из документации затрагивается исследованиями гораздо реже. Значительный вклад в развитие тематики анализа технической документации внесли: А.В. Заболеева-Зотова, В.А. Камаев, В.И. Аверчинков, В.М. Курейчик, П.М. Мазуркини др. Проблема недостаточной исследованности автоматизированного формирования требований к созданию ИС на основе технической документации во многом связаны со сложностью автоматизации анализа и синтеза технической документации. Характерно, что информация в технической документации находится в преимущественно неструктурированном виде, которую трудно извлекать и анализировать при отсутствии современных аналитических ИС.

Объектом исследования в данной работе является процесс формирования требований к разработке ИС на основе анализа всей проектной документации. Предмет исследования - формальная модель требований к разработке ИС.

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

Для достижения этой цели в работе необходимо решить следующие задачи:

1. Проанализировать научные исследования по:

a. видам проектной документации, используемой при разработке ИС;

b. задачам работы с требованиями;

c. методам описания требований;

d. подходам к формализации требований.

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

3. Описать архитектуру решения.

4. Описать модель требований.

5. Реализовать лексико-грамматические шаблоны и условия для извлечения концептов требований.

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

Несмотря на сложность извлечения данных из неструктурированных документов существует довольно много разнообразных по структуре систем обработки связанных текстов, таких как: вопрос-ответные системы, диалоговые системы решения задач и др. (Alex, AURA, WordTabulator, ABBYYRetrievalи др.). Большинство из таких систем осуществляют анализ документов на основе семантического анализа на уровне предложения или слова, однако, они, в свою очередь, не учитывают семантической взаимосвязи документов друг с другом.

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

архитектура программный извлечение требование

1. Требования в процессе разработки ИС

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

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

Управление требованиями позволяет на самых первых этапах анализа и проектирования ИС определить и обозначить назначение и характеристики разрабатываемой ИС [13]. Большая часть требований заказчика и описание к требуемой ИС могут содержаться в проектной документации, и чем она подробнее и грамотнее составлена, тем качественнее будет проведена допроектная оценка разработки ИС. Однако при работе с требованиями могут возникать некоторые проблемы, такие как:

1. Отсутствие полноценного бизнес-анализа.

2.2. Нет уверенности в полноте покрытия бизнес-потребностей.

1.1.1. Бизнес плохо изучен.

1.1.2. Бизнес плохо задокументирован.

1.1.3. Знания о бизнесе разрозненные.

1.1.4. Знания о бизнесе слабо систематизированы.

1.2. Требования основываются на атомарных пожеланиях заказчика.

1.2.1. Требования могут противоречить задачам бизнеса.

1.2.2. Требования могут выходить за границы бизнеса, который автоматизируется.

1.2.3. Требования извлекаются из многих источников и не всегда однозначны.

1.2.4. Требования не всегда полные, уникальные, достаточные.

1.2.5. Требования могут быть очень детальными и, как следствие, неуправляемыми.

1.2.6. Требования могут изменяться.

1.2.7. Требования могут быть зависимы от времени.

2. В требованиях мало технических деталей.

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

2.2. Язык требований заказчика далек от языка разработчика.

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

1) анализ требований;

2) определение и формирование требований;

3) анализ корректности сформированных требований;

4) документирование требований [5].

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

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

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

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

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

1.1 Проектная документация при разработке ИС

В соответствии сГОСТ 34.601-90 при создании ИС должны выполняться следующие стадии ЖЦ проекта (с т. з. документирования):

Стадия 1. Формирование требований к АС.

Стадия 2. Разработка концепции АС.

Стадия 3. Техническое задание.

Стадия 4. Эскизный проект.

Стадия 5. Технический проект.

Стадия 6. Рабочая документация.

Стадия 7. Ввод в действие.

Стадия 8. Сопровождение АС.

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

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

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

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

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

Вышеописанные характеристики отображены на схематическом изображении модели документа проектной документации (см. рис.1.1.).

Рисунок 1.1 Схема структуры проектного документа

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

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

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

1.2 Определение понятия требования

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

В разных источниках по инженерии и управлению требованиями можно встретить разнообразные определения данного понятия. Например, Л. Новиков в русской редакции нотации RUP [7] приводит следующее определение: "Требование - это условие или возможность, которой должна соответствовать система".

АвIEEE Standard Glossary of Software Engineering Terminology (1990) [8] данное понятие трактуется шире. Требование - это:

1) условия или возможности, необходимые пользователю для решения проблем или достижения целей;

2) условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам;

3) документированное представление условий или возможностей для пунктов 1 и 2.

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

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

2. Требования - это любые определения системы, в которых присутствует обязательность к выполнению.

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

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

Кроме того, следует обратить внимание на 4 важных момента.

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

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

3. Термин "Требование" также включает в себя термин "Ограничение", поскольку ограничение - это некоторая область, также обладающая своими требованиями, в рамках которой могут быть реализованы возможности разрабатываемой ИС.

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

– уровень неформальности (текст-модель, текст-текст, модель-модель);

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

– информационные модели (онтологии, метамодели, глоссарии);

– спецификации требований (шаблоны концептов требований).

1.3 Классификация требований

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

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

1) уровни требований по К. Вигерсу;

2) классификация в рамках концепции SWEBOK;

3) классификация RUP (FURPS+).

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

1.3.1 Уровни требования по К. Вигерсу

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

В классификации требований по К. Вигерсу определено три уровня требований (см. рис.1.2) [11]:

1. Бизнес-требования определяют высокоуровневые цели организации или клиента (потребителя) - заказчика, разрабатываемого ПО.

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

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

Рисунок 1.2 Уровни требований по Вигерсу

Кроме трех уровней в данной классификации есть еще другие типы требований:

– Нефункциональные требования включают эксплуатационные характеристики и описание атрибутов качества.

– Системные требования описывают высокоуровневые требования для ПО, которые содержат множество подсистем.

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

1.3.2 Классификация требования по SWEBOK

Обращаясь к концепции по управлению требованиями, предлагаемой в SWEBOK, можно отметить, что в данном своде знаний есть отдельный раздел, отвечающий за программные требования, который уже включает в себя классификацию. Программные требования - Software Requirements - это свойства программного обеспечения, которые должны быть надлежащим образом представлены в нём для решения конкретных практических задач. Данная область знаний касается вопросов извлечения (сбора), анализа, специфицирования и утверждения требований [12].

Рисунок 1.3 Область знаний "Программные требования”

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

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

Например, наиболее популярная модель зрелости в индустрии программного обеспечения - CMMI включает разный объем и содержание работ по определению и управлению требованиями для уровней зрелости 2 и 3.

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

Кроме того, SWEBOK отмечает, что имеется явное пересечение между описанными в нем измерениями и атрибутами требований.

1.3.3 Классификация RUP (FURPS+)

В спецификациях Rational Unified Process при классификации требований используется модель FURPS+ со ссылкой на стандарт IEEEStd 610.12.1990 [14].

Акроним FURPS обозначает следующие категории требований: Функциональность; Применимость; Надежность; Производительность; Эксплуатационная пригодность.

Символ "+" расширяет FURPS-модель, добавляя к ней: ограничения проекта,

требования выполнения, требования к интерфейсу, физические требования.

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

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

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

Учитывая особую трудность в определении качественных характеристик можно выделить следующие качественные показатели-характеристики ПО с атрибутами:

1. Переносимость: адаптируемость; простота настройки; совместимость; заменяемость; согласованность.

2. Эффективность: реактивность; используемость ресурсов; заменяемость.

3. Сопровождаемость: анализируемость; изменяемость; стабильность; тестируемость; согласованность.

4. Удобство применения: понимаемость; обучаемость; привлекательность; согласованность.

5. Надежность: завершенность; отказоустойчивость; восстанавливаемость; согласованность.

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

2. Методы определения требований

Дисциплина, изучающая практически применимые методы работы с требованиями, инженерия требований, является очень широкой и разнородной областью, включающей рассмотрение огромного множества вопросов от синтаксиса документов, описывающих требования, до учета социокультурных особенностей пользователей при проведении семинаров и составлении списков вопросов. Поскольку нашей целью является выделение всех основных задач работы с требованиями, остановимся на рассмотрении стандартов IEEE 830 [11] и IEEE 1233 [16], определяющих необходимые характеристики требований, и раздела Свода знаний по программной инженерии (SWEBOK) [12], посвященного работе с требованиями. SWEBOK выделяет в работе с требованиями следующие четыре вида деятельности.

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

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

Рисунок 1.4 USE-CASEдиаграмма работы с требованиями

Рисунок 1.5 Процессы работы с требованиями

В вышеобозначенных стандартах IEEE 830 и IEEE 1233 описываются как раз те характеристики, которые должны иметь требования, чтобы их можно было с успехом использовать для разработки ПО, и которые должны проверяться во время валидации по SWEBOK.

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

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

a. Свойства, касающиеся связи требований с предметной областью:

Адекватность, однозначность, полнота, непротиворечивость, минимальность, систематичность.

b. Свойства, касающиеся использования требований в процессе разработки (внешние): проверяемость, прослеживаемость, модифицируемость.

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

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

2.1 Методы описания требований

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

Большинство работ, ведущихся в области управления требованиями при разработке ИС, направлены на анализ проектной и технической документации, из российских исследований особенный вклад внесли: А.В. Заболеева-Зотова [1,2], В.И. Аверчинков, В.М. Курейчик, Ю.А. Орлова [3]. Но тематики, направленные на управление требованиями проекта в целом, на поиск схожестей с другими требованиями проекта, а также задачи автоматического формирования требований на основе анализа проектной документации, выделение ключевых понятий на уровне слов, затрагивается исследованиями гораздо реже.

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

Анализ отечественной и зарубежной литературы, а также научных исследований, ведущихся различными научными сообществами в данной области, позволяет сделать вывод, что исследованием и разработкой подходов и инструментов к решению вышеуказанных проблем занимаются даже крупные информационные компании, такие как IBM и Borland. Они предлагают такие мощные программные продукты для управления требованиями как RequisitePro [5], DOORS [6], CaliberRM [7], IRqAподходящие для поддержки процесса документирования требований в крупных проектах. Все эти инструменты больше направлены на поддержание процессов управления требованиями, и в них отсутствует понятие формализованной модели требований и ни одна из них не поддерживает работу с семантическими признаками требований, иными словами данные системы не позволяют находить семантически схожие требования из комплекса требований существующего проекта. Кроме того, при анализе документов требования могут быть выражены неявно и не будут определены системой, если в ней отсутствуют механизмы формального представления требований и их семантического описания.

За последние годы значительный вклад в развитие тематики формализации требований при проектировании и разработке ИС внесли исследователи университета Concordia [9,10,11], которые для трансформации требований, выраженных на естественном языке, предлагают строить концептуальные модели. Для отображения концептуальных моделей предлагается использовать RecursiveObjectModel (ROM). Тем не менее, выявленные реалии позволяют отметить, что модель, которую предлагают исследования университета Concordia находится на исследовательском уровне и пока не проходит промышленную эксплуатацию.

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

– отсутствие полноценного бизнес-анализа предметной области разработки ИС (разрозненность данных о бизнесе, отсутствие систематизированных данных, связей, иерархий);

– формирование требований на основе атомарных пожеланий заказчика, что приводит к противоречивости требований и задач, а также к выходу за границы предметной области разработки ИС;

– отсутствие или малое количество технических деталей в требованиях;

– отсутствие единого архитектурного решения при разработке ИС;

– отдаленность языка разработки ИС от языка описания требований.

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

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

Необходимо отметить, что на пути совершенствования нотации UML были разработаны некоторые модификации UML, например, были разработаны: семантический подход для обработки диаграмм классов [12], конечные автоматы [11], взаимодействия прецедентов [12], OCL [13]. Тем не менее все эти совершенствования нотации UML не отменяют программную ориентированность языка. UML не поддерживает основные потребности проектирования в других областях, отличных от разработки ИС. Эту ситуацию немного изменяет диалект UML - SysML, который используется для определения, анализа и проектирования систем, которые могут включать в себя аппаратные средства, программное обеспечение и персонал, а также, что немаловажно, язык SysML позволяет описывать требования.

Помимо языка SysML есть еще много различных подходов в инженерии требований, много исследовательских работ было направлено на развитие автоматизированного или полуавтоматизированного перехода от естественного языка на концептуальные модели. В работе [14] был предложен подход к трансформации спецификации требований естественного языка, ориентированного на конкретные модели типа EER. Кроме этого более современные исследования [15] представляют подход к извлечению объектно-ориентированных элементов разрабатываемой системы. Например, группа исследователей Gnesi и др. разработала автоматический инструмент для анализа требований естественного языка. А в работе [16] предложена методика прецедентов языка схем автоматизации анализа требований естественного языка и диалекты класса на базе модели Rational Unified Process (RUP). Из-за трудностей в обработке естественного языка и большого разрыва между естественным языком и структурированных моделей результаты каждого исследования обладают большим набором ограничений.

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

2.2 Методы работы с требованиями

Работа с требованиями выполняется в рамках различных методов разработки ИС. Будут рассмотрены следующие методы работы с требованиями:

- унифицированный процесс разработки Rational (RUP);

- метод управления требованиями DOORS;

- метод разработки RAISE;

- методология SSM.

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

Унифицированный процесс разработки Rational (RUP) [15] широко используется при полномасштабных процессах разработки ИС. Идея RUP состоит в том, что процесс разработки ИС приспосабливается к эффективной работе при изменяющихся условиях окружения и позволяет реализовывать требования пользователей, даже если они претерпевали изменения в ходе проекта. Это достигается за счет отслеживания происходящих изменений и их постепенного включения в контекст разработки с помощью следующих путей:

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

– Архитектура ИС является основой разрабатываемой системы и дополнятся элементами, которые не нарушают целостность всей системы.

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

Метод DOORSявляется основной в использовании оноименного инструмента управления требованиями DOORS [12] представляющую из себя динамическую объектно-ориентированную систему управления требованиями. В основе этого подхода лежит представление о том, что требования к сложной системе очень сложны, сильно взаимосвязаны, разнородны и в своем исходном виде не могут быть использованы для разработки. Чтoбы стать ее частью, oни дoлжны быть пoдвергнуты пoэтапнoму утoчнению, прoвoдимoму нескoлько раз, а также фoрмулирoваться сoвместнo с правилами их прoверки. При этoм крайне важнo сoхранить всю истoрию прoведенных утoчнений и пoстрoенных тестoв, явнo зафиксировать все привлекаемые для этого дополнительные свойства и ограничения окружения, чтобы быть в состоянии анализировать влияние отдельных допущений, возможных изменений требований и покрытие требований в ходе разработки и верификации системы. Основной техникой, используемой в DOORS, является представление требований в виде структурированного набора текстовых и графических документов, моделей и других объектов, имеющих расширяемый набор атрибутов и связанных размеченными связями. Таким образом, большая часть работ с требованиями выполняется с помощью анализа и модификации этих атрибутов и связей.

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

Метод разработки RAISE (строгий подход к промышленной программной инженерии, Rigorous Approach to Industrial Software Engineering) [18]. Он имеет много общего с другими формальными методами разработки ПО - Z, VDM, B [18] - и рассматривается здесь как их представитель. Основная идея метода RAISE - сводится к тому, что разработка разбивается на шаги: во-первых, описывается максимально простая и абстрактная модель, далее строится более подробная и конкретная модель ИС, на каждом шаге проверяется согласованность моделей предыдущих шагов.

Сравнение перечисленных методов приведено в таблице Б.1 приложения Б. В ней методы рассматриваются с точки зрения общих задач работы с требованиями. Для каждой задачи перечисляются применяемые в рамках данных методов способы решения этой задачи.

Анализируя таблицу можно отметить, что только метод работы с требованиями в рамках RUP определяет полное семейство техник, способное решить все задачи работы с требованиями. Методы CORE и SSM фокусируют внимание на выделении, описании и уточнении требований, и ничего не говорят об их верификации, обеспечении проверяемости и модифицируемости. Метод RAISE, наоборот, делает акцент на верификации требований, не определяя детально способов их выделения.

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

2.3 Методы моделирования требований

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

1) принадлежность к семейству (с т. з. языков программирования);

2) возможность изменения модели;

3) тип синтаксиса;

4) наличие диаграмм;

5) наличие семантической связности требований;

6) связь с архитектурной моделью;

7) возможность исполнения модели;

8) пользовательский синтаксис;

9) наличие языка запросов.

На основе вышеперечисленных критериев будут рассмотрены следующие методы (спецификации и стандарты) по управлению и моделированию требований:

1) SysML;

2) RIF (ReqIF, IntRIF);

3) GRL+UCM;

4) Языки подхода GORE:

a. RFLP;

b. ArchiMate;

c. MBRD;

d. BMM;

e. Planguage.

5) ISO 15926.

Рассмотрим каждый из методов моделирования подробно.

1. SysML (диалект UML).

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

– Основное использование требований в SysML-аннотация требований архитектуры.

– Возможны следующие привязки требований к модели: соответствие, обоснование, трассировка, уточнения, наследование.

– Форма отображения требований: табличная.

– Существует возможность повторной используемости (есть требования-оригиналы, требования-производные).

– Существует мэппинг требований в формате SysML в RIF.

2. RIF (ранее ReqIF, сейчас IntRIF).

– Назначение: облегчение обмена данными между инструментами работы с требованиями (ранее для требований области автомобилестроения, теперь стандартизируется как универсальный).

– Язык даталогичен, семантика требований отсутствует, определяются "элементы данных", передающиеся между программами.

– Существует возможность мэппинга основных инструментов разработки.

3. GRL+UCM (goal-orientend requirements language).

– 2 языка, описывающих цели/намерения (goals/intentions) систем и заинтересованные стороны в GRL, а также пользовательские сценарии в UCM, плюс связи между элементами этих языков.

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

4. Языки подхода GORE.

– Требования в подходе GOREвведены для связи требований и архитектурного описания в стандартах подхода GORE. Стандарты не самостоятельны, в подход входят:

5. ISO 15926

– Предусмотрено определение требования REQUIREMENT типа DOCUMENT_DEFINITION с определением "спецификация чего-то, что должно быть поставлено"

– Модальность не предусмотрена.

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

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

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

2.4 Формальные модели требований

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

2.4.1 Формальная модель системного комплекса требований к АИС

Например, Н.Н. Яковлев в работе по системной модели комплекса требований к АИС [6] предлагает следующую формальную модель.

Обозначим множество всех атрибутов требования, как Attr(R), где R-это требование.

(1)

Тогда множество атрибутов каждого требования, которые при визуализации группируются в область знаний , и их может редактировать пользователь с ролью , когда требование находится на стадии ; - это область знаний; - это роль пользователя; - это стадия ЖЦ, при Тогда

, (2)

- множество доменов (предметных областей), ;

- множество проектов i-ого домена, где ;

- множество требований j-ого проекта i-ого домена, где и .

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

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

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