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

3.1.5. Трассировка требований

Одной из главных проблем сбора требований является проблема их изменения. Требования создаются итерационно путем постоянного общения представителей заказчиков с аналитиками и разработчиками будущей системы в целях выявления потребностей. Требования изменяются в зависимости от задач и условий их определения, а также постоянного уточнения на этапе заключения договора на создание системы. На момент заключения договора состав требований, их виды и свойства становятся более полными, т.е. соответствуют взглядам заказчика на создаваемую систему [3.4].

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

Рис. 3.3. Типы трассируемости требований

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

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

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

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

Процедура трассирования состоит в следующем:

• выбирается элемент (функция, фрагмент или некоторая часть) из матрицы трассирования требований, за которым проводится прослеживание на этапах ЖЦ;
• составляется список вопросов, по которым на каждом этапе проверяются связи при реализации требований в продукте, и если изменяется какое-то звено в цепочке требований (рис. 3.3.), то может модифицироваться процедура разработки этого элемента на последующем этапе ЖЦ;
• проводится мониторинг статуса каждого требования на соответствие выполнения согласно принятому плану;
• уточнение ресурсов выполнения проекта при необходимости проведения изменений в требования и в элементы проекта.

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

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

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

3.2. Объектно-ориентированная инженерия требований

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

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

3.2.1. Сценарный подход

Одним из методов построения проектной модели системы, логической и физической моделей являются сценарии use case, используемые для визуального представления требований в проектной модели системы. Эта модель уточняется и дополняется новыми сценариями для получения логической и физической моделей. Термин сценарий обозначает некоторый вариант представления модели выполнения системы [3.1, 3.5].

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

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

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

Т.е. имеем цепочку трансформаций:

проблема цель сценарий объект.

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

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

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

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

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

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

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

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

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

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

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

Рис. 3.4. Пример диаграммы сценариев