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

Авторы:   Алфимов Р.В., Красникова С.А., Золотухина Е.Б. (сертифицированный специалист по решениям IBM Rational, преподаватель в Учебно-Консалтинговом центре компании "Интерфейс").

Особенно это касается базового элемента языка UML "Use Case", который трактуется отечественными переводчиками как "вариант использования", "прецедент". При этом контекст, в котором переводится термин, не учитывается. Несмотря на то, что понятие активно используется уже довольно давно - путаницы возникает все больше и больше. Так, участники некоторых Интернет- форумов дошли до того, что сравнивают "Use Case" с техническим заданием. По мнению авторов, все это обусловлено стандартным описанием UML, не связанным с процессом разработки автоматизированных систем (АС), а также упущенной возможностью при переводе оригинала такое сопоставление произвести. К тому же существующие современные методики создания программных систем от ведущих мировых производителей, основанных на использовании UML и других нотациях, к сожалению, большинству отечественных разработчиков в оригинале просто не доступны.

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

В данной статье представлен способ описания функциональных требований к АС и ее функций с использованием стандартов в области информационных технологий, современных методологий создания АС, и диаграмм "Use Case Diagram" и "Actvity Diagram" универсального языка моделирования UML 2.0. Авторы рассчитывают, что использование "Use Case" в контексте определения требований в соответствии со стандартами создания АС приобретет большую ясность.

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

При использовании стандартов создания АС в соответствии с [1, 2] на стадии "Техническое задание" в документе техническое задание (ТЗ) фиксируются функциональные и нефункциональные требования к АС. Схема функциональной структуры АС разрабатывается на стадии "Эскизное проектирование" и "Техническое проектирование", описание автоматизируемых функций АС производится на стадии "Техническое проектирование".

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

В табл. 1. представлены стадии работ по созданию АС и документы, формируемыми на стадиях, связанных с описанием требований и функций [1-3].

Как видно из табл. 1, создание АС на стадиях 3-5, подразумевает подготовку:

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

Таблица 1. Стадии создания АС и документы, связанные с требованиями к  АС и функциями, их реализующими

В соответствии с [4] ТЗ на АС есть документ, оформленный в установленном порядке и определяющий цели создания АС, требования к АС и основные исходные данные, необходимые для ее разработки, а также план-график создания АС.

В ТЗ определяются:

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

Функциональные требования к системе определяют, действия системы, которые она должна выполнять. Функциональные требования реализуются через функции системы [5]. Под функцией АС подразумевается совокупность действий АС, направленная на достижение определенной цели или аспект определенного поведения системы [6], а под задачей - функция или часть функции АС, представляющая собой формализованную совокупность автоматических действий, выполнение которых приводит к результату заданного вида [4].

Не функциональные требования есть ограничения, накладываемые на работу системы, и стандарты, которым должна соответствовать система [5].

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

В описании автоматизируемых функций [7] приводят:

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

Теперь рассмотрим определение требований с использованием понятия "Use Case". Как уже говорилось ранее, в стандарте UML отсутствует привязка к стадиям создания АС, однако, производители CASE - средств для работы с UML и методологий использования UML, как правило, предлагают схожие подходы к работе с требованиями.

Рассмотрим, например, подход компании Sparx System, являющейся производителем инструментария Еnterprise Architect, поддерживающим создание моделей предметной области и АС с использованием UML 2.0. Ими предложен шаблон модели требований, представленный на рис. 1. На рис. 2 представлен пример модели требования с использованием шаблона.

Как видно из шаблона модели требований и его примера для моделирования требований предлагается использовать элемент UML "Requirement". Для моделирования функций системы предлагается использовать элемент "Use Case". При этом элемент "Use Case" в описании UML, представленном в инструменте Еenterprise Architect, трактуется следующим образом: "Use Case elements are used to build Use Case models. These describe the functionality of the system to be built. Use Case Model describes a system's functionality in terms of  Use Cases".

Другими словами, элемент "Use Case" используется для построения модели "Use case Model". Модель "Use case Model" используется для описания функциональности системы.

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

В спецификациях OMG UML ( UML Superstructure Specification, v2.0, p. 17 ) элемент  "Use Case" определяется как: "The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system".

Другими словами, элемент "Use Case" определяет последовательность действий системы, которые она может выполнять, включая ее взаимодействие с пользователем системы.

Рис. 1. Способ моделирования требований к системе

 

В дополнении к сказанному выше, хотелось представить определение модели "Use Case Model" из популярного в нашей стране и за рубежом процесса разработки систем Rational Unified Process компании IBM: "The use-case model is a model of the system's intended functions and its environment …"[5] (рис. 3).

Рис. 3. Определение модели "Use Case Model"

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

В табл. 2 представлено сравнение определений схемы функциональной структуры в соответствии с ГОСТ и модели "Use Case Model", функции системы и элемента "Use Case" в соответствии с описанием UML 2.0.

Таблица 2. Сравнение определений моделей и их элементов 

Сравнение определения схемы функциональной структуры с определением модели Use Case Model, определения функции системы и элементов "Use Case" показывает, что эти модели и элементы сопоставимы друг с другом.

Таким образом, для моделирования требований к АС мы будем использовать элемент требование "Requirement", а функций, реализующих требование, элемент "Use Case".

В соответствии с [2] описание функционального требования должно включать, связанные с требованием: функции системы, пользователей системы, печатные документы, импортируемые/экспортируемые данные, правила и ограничения, нефункциональные требования, связи между функциональными требованиями, экранные формы.

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

Шаблон описания требования

Общие сведения о требовании

Функции, реализующие требования

Связи между требованием и функциями

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

Описание процесса выполнения функции

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

  Поиск товара:

 Печать отчета:

Описание процесса выполнения функции "Формирование отчета об остатках" 

Состав, экранных форм, связанных с функцией

Описание печатных форм

Описание импортируемых/экспортируемых данных (импортируемых данных нет)

Нефункциональные требования, связанные с функциональным требованием

Временной регламент

Если требуется в разделе указывается время выполнения функции. Время формирования отчета не должно превышать 5 сек.

Надежность

Если требуется в разделе указывается требования к надежности выполнения функции.

Точность

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

Достоверность

Если требуется, в разделе указывается требования к достоверности результатов выполнения функции.

Связи с другими функциональными требованиями

Если требуется, в разделе указываются  связи между требованиями.

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

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

Список литературы 

1. ГОСТ 34.601-90 "АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. СТАДИИ СОЗДАНИЯ";
2. ГОСТ 34.602-89 "ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ";
3. ГОСТ 34. 201-89. ВИДЫ, КОМПЛЕКТНОСТЬ И ОБОЗНАЧЕНИЕ ДОКУМЕНТОВ ПРИ СОЗДАНИИ АВТОМАТИЗИРОВАННЫХ СИСТЕМ;
4. ГОСТ 34.003-90. "АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ";
5. IBM/RATIONAL UNIFIED PROCESS;
6. ГОСТ Р ИСО/МЭК 15026-2002. ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. УРОВНИ ЦЕЛОСТНОСТИ СИСТЕМ И ПРОГРАММНЫХ СРЕДСТВ;
7. РД 50-34.698-90. "АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ";
8. ГОСТ 28806-90. ГОСТ КАЧЕСТВО ПРОГРАММНЫХ СРЕДСТВ. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ;