Значительной популярностью при разработке автоматизированных систем в настоящее время в России пользуется универсальный язык моделирования (Unified Modeling Language — UML). Несмотря на безусловные плюсы, использование UML сопряжено с рядом трудностей методического характера, на которые мы хотели бы обратить внимание читателя. Прежде всего, в UML вводится собственный понятийный аппарат, в рамках которого традиционные термины и понятия, связанные с созданием автоматизированных систем и используемые в течение десятилетий, заменяются на термины и понятия, не нашедшие пока в полной мере отражения в международных и отечественных стандартах в области информационных технологий.
Особенно это касается базового элемента языка UML «Use Case», который трактуется отечественными переводчиками как «вариант использования», «прецедент». При этом контекст, в котором переводится термин, не учитывается. Несмотря на то, что понятие активно используется уже довольно давно — путаницы возникает все больше и больше.
Проектная документация. Какие документы готовят бизнес и системный аналитики?
Так, участники некоторых Интернет- форумов дошли до того, что сравнивают «Use Case» с техническим заданием. По мнению авторов, все это обусловлено стандартным описанием UML, не связанным с процессом разработки автоматизированных систем (АС), а также упущенной возможностью при переводе оригинала такое сопоставление произвести. К тому же существующие современные методики создания программных систем от ведущих мировых производителей, основанных на использовании UML и других нотациях, к сожалению, большинству отечественных разработчиков в оригинале просто не доступны.
Как печальный итог, использование терминов и понятий UML, по существу представляющих собой ошибки отечественных переводчиков, в недостаточной мере знакомых с процессами создания АС, привели к тому, что в различных средствах информации появились статьи, книги, модели и прочие источники, имеющие откровенные ошибки в трактовке процессов, моделей, документов, связанных с созданием АС. Особенно это явно проявилось при описании предметной области и определения требований к АС.
В данной статье представлен способ описания функциональных требований к АС и ее функций с использованием стандартов в области информационных технологий, современных методологий создания АС, и диаграмм «Use Case Diagram» и «Actvity Diagram» универсального языка моделирования UML 2.0. Авторы рассчитывают, что использование «Use Case» в контексте определения требований в соответствии со стандартами создания АС приобретет большую ясность.
Итак, рассмотрим процесс определения требований согласно действующим отечественным стандартам.
При использовании стандартов создания АС в соответствии с [1, 2] на стадии «Техническое задание» в документе техническое задание (ТЗ) фиксируются функциональные и нефункциональные требования к АС. Схема функциональной структуры АС разрабатывается на стадии «Эскизное проектирование» и «Техническое проектирование», описание автоматизируемых функций АС производится на стадии «Техническое проектирование».
4. Функциональные требования, тикеты, JIRA (Курс бизнес-аналитик с нуля)
При разработке АС в соответствии с [1] должны быть отслежены связи между функциональными требованиями к системе и функциями системы, их реализующими. Функции системы в свою очередь должны быть детально описаны.
В табл. 1. представлены стадии работ по созданию АС и документы, формируемыми на стадиях, связанных с описанием требований и функций [1-3].
Как видно из табл. 1, создание АС на стадиях 3-5, подразумевает подготовку:
технического задания;
предварительной схемы функциональной структуры системы (эскизное проектирование);
окончательной схемы функциональной структуры (техническое проектирование);
описания автоматизируемых функций системы.
Таблица 1. Стадии создания АС и документы, связанные с требованиями к АС и функциями, их реализующими
№ стадии по ГОСТ 34.601-90
Наименование
стадии по ГОСТ 34.601-90
Документы, модели, создаваемые на стадиях по
ГОСТ 34.602-89,
ГОСТ 34.201-89
ГОСТ, в котором описан документ
Техническое задание (ТЗ)
Схема функциональной структуры
РД 50-34.698-90 п. 2.3.
Схема функциональной структуры
РД 50-34.698-90 п. 2.5
В соответствии с [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. Способ моделирования требований к системе
Рис. 2. Пример реализации требования
В дополнении к сказанному выше, хотелось представить определение модели «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. Сравнение определений моделей и их элементов
Определение схемы функциональной структуры
Определение модели «UseCaseModel»
В схеме функциональной структуры отображаются элементы функциональной структуры АС (подсистемы АС), автоматизированные функции и (или) задачи (комплексы задач), совокупности действий (операций), выполняемых при реализации автоматизированных функций только техническими средствами (автоматически) или только человеком
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
Определение элемента «UseCase»
Совокупность действий АС, направленная на достижение определенной цели. Описание процесса выполнения функции включает необходимые пояснения к разделению автоматизированных функций на действия (операции), выполняемые техническими средствами и человеком
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 Model, определения функции системы и элементов «Use Case» показывает, что эти модели и элементы сопоставимы друг с другом.
Таким образом, для моделирования требований к АС мы будем использовать элемент требование «Requirement», а функций, реализующих требование, элемент «Use Case».
В соответствии с [2] описание функционального требования должно включать, связанные с требованием: функции системы, пользователей системы, печатные документы, импортируемые/экспортируемые данные, правила и ограничения, нефункциональные требования, связи между функциональными требованиями, экранные формы.
Предлагается описывать функциональное требование к системе и функции, его реализующие, с использованием следующего шаблона. Описание шаблона дано на примере описания конкретного требования.
Шаблон описания требования
Общие сведения о требовании
Должно быть автоматизировано формирование отчета об остатках товара
Цель, которая будет
достигнута при реализации
требования
Оперативное получение информации о текущих остатках на складе компании
Требование руководителя компании
Пользователи, которым
доступна работа с функциями системы, реализующими требование
Источник данных (ручной ввод, использование записей БД, данных из смежной системы)
Отчет должен формироваться на основе записей в базе данных, содержащих информацию о количестве остатков товара на складе
Правила, связанные с
требованием
Отчет формируется в двух экземплярах
Функции, реализующие требования
Формирование отчета «Остатки товара»
Связи между требованием и функциями
В разделе должно быть представлена модель, отображающая связи между требования и функциями, реализующими требование, и если требуется, описание связей. Модель «Требование и функции»:
Описание процесса выполнения функции
В разделе должны быть представлены модели процесса выполнения функции и их описание. Основные этапы формирования отчета:
Источник: www.interface.ru
Анализ требований
Чтобы понять, как должна выглядеть и работать ваша система, наши аналитики составляют серию документов, необходимых для запуска процесса разработки.
Документы, создаваемые в процессе анализа
Концепция системы / Business Vision
В первую очередь мы проводим предварительное интервью с заказчиком, во время которого определяются цель создания системы, её границы и её место в окружающем мире. Иногда это называют концепцией системы или Business Vision.
Бизнес-требования / BRD
За этим следует серия уточняющих интервью, в которых заказчик развивает свою идею. Уточняется и углубляется понимание проблем, которые система должна решать. Результирующий документ мы называем бизнес-требования или BRD (Business Requirements Document).
Функциональные требования / FRD
Основной этап нашей работы состоит в тщательном анализе бизнес-требований. Мы ищем логические несоответствия, детализируем требования до уровня, понятного программистам.
Появляется документ, который содержит функциональные требования — FRD (Functional Requirements Document). Часто его называют техническим заданием (ТЗ). Это наш главный документ, являющийся фундаментом будущей системы. В документе, как правило, присутствуют:
— Общий список компонентов системы.
— Для каждого компонента — детальное описание его функций.
— Сценарии использования системы различными пользователями.
— Нефункциональные требования: особые требования к оборудованию, требования к производительности системы и предельной нагрузке.
План тестирования / Test Plan
План тестирования необходим для команды тестировщиков и составляется на основе FRD и других сопутствующих документов (примеры дизайна, протокол взаимодействия с сервером и прочее). Цель данного документа – ответить на 3 главных вопроса: что, как и когда будет тестироваться, иначе говоря:
— какие компоненты системы будут тестироваться
— какие виды тестов будут проводиться и что должно быть для этого сделано
— в каком порядке будут выполняться тесты
Совместно с планом тестирования идет список теcтовых сценариев, каждый из которых включает необходимую детализацию по выполнению теста. Это позволяет нам в любой момент выполнить весь набор тестов заново.
Риски / Risk List
Зачастую вместе с FRD составляется специальный документ — список рисков. В документе учитываются основные риски, которые могут повлиять на разработку системы в заданный срок. Указываются способы реагирования на те или иные риски. Список рисков — это ответы на множество вопросов «А что будет, если?», включающий самые пессимистичные сценарии разработки и внедрения системы. Документ этот, являясь внутренним, может быть интересен и для заказчика.
Зачем это нужно?
Работа аналитиков стоит денег. А зачем все это нужно заказчику? Документы бизнес-уровня (BRD) позволяют провести первоначальную оценку стоимости проекта и выявить организационные риски. Функциональные требования (FRD) позволяют нам сформировать точную оценку стоимости проекта и выделить технические риски.
FRD также служит краеугольным камнем при тестировании системы и разрешении всех спорных вопросов между заказчиком и исполнителем. Именно поэтому FRD написан максимально точным, формальным языком — прежде всего с целью избежать двусмысленного толкования.
Набор подготавливаемых документов сильно зависит от масштабов проекта. Например, для небольших проектов концепция системы укладывается в несколько предложений, а FRD можно составлять уже по итогам первого интервью.
Источник: www.gramant.ru
Документ о функциональных требованиях
Документ о функциональных требованиях (FRD) является формальным заявлением о функциональных требованиях приложения. Он служит той же цели, что и контракт. Здесь разработчики соглашаются предоставить указанные возможности. Клиент соглашается найти продукт удовлетворительным, если он обеспечивает возможности, указанные в FRD.
Функциональные требования отражают предполагаемое поведение системы. Это поведение может быть выражено в виде услуг, задач или функций, которые система должна выполнять. Документ должен быть адаптирован к потребностям конкретного проекта. Они определяют такие вещи, как системные вычисления, манипулирование и обработка данных, пользовательский интерфейс и взаимодействие с приложением.
Документ функциональных требований (FRD) имеет следующие характеристики:
- Это демонстрирует, что приложение обеспечивает ценность с точки зрения бизнес-целей и бизнес-процессов в течение следующих нескольких лет.
- Содержит полный набор требований к заявке. Никто не оставляет места для принятия чего-либо, что не указано в FRD.
- Это решение не зависит. ERD – это заявление о том, что должно делать приложение, а не о том, как оно работает. FRD не обязывает разработчиков разрабатывать дизайн. По этой причине любые ссылки на использование конкретной технологии совершенно неуместны в FRD.
Это демонстрирует, что приложение обеспечивает ценность с точки зрения бизнес-целей и бизнес-процессов в течение следующих нескольких лет.
Содержит полный набор требований к заявке. Никто не оставляет места для принятия чего-либо, что не указано в FRD.
Это решение не зависит. ERD – это заявление о том, что должно делать приложение, а не о том, как оно работает. FRD не обязывает разработчиков разрабатывать дизайн. По этой причине любые ссылки на использование конкретной технологии совершенно неуместны в FRD.
Функциональное требование должно включать следующее:
- Описания данных для ввода в систему
- Описание операций, выполняемых каждым экраном
- Описания рабочих процессов, выполняемых системой
- Описания системных отчетов или других выходов
- Кто может ввести данные в систему?
- Насколько система соответствует применимым нормативным требованиям?
Описания данных для ввода в систему
Описание операций, выполняемых каждым экраном
Описания рабочих процессов, выполняемых системой
Описания системных отчетов или других выходов
Кто может ввести данные в систему?
Насколько система соответствует применимым нормативным требованиям?
Функциональная спецификация предназначена для чтения широкой аудиторией. Читатели должны понимать систему, но для понимания этого документа не требуется никаких технических знаний.
Функциональные требования.
Документ бизнес-требований (BRD) состоит из –
Функциональные требования – документ, содержащий подробные требования к разрабатываемой системе. Эти требования определяют функциональные особенности и возможности, которыми должна обладать система. Убедитесь, что любые предположения и ограничения, выявленные в ходе бизнес-кейса, все еще точны и актуальны.
Модель бизнес-процесса – модель текущего состояния процесса (модель «как есть») или концепция того, каким процессом должен стать (модель «быть»)
Диаграмма контекста системы – Диаграмма контекста показывает границы системы, внешние и внутренние объекты, которые взаимодействуют с системой, и соответствующие потоки данных между этими внешними и внутренними объектами.
Блок-схемы («как есть» или «быть») – диаграммы, графически отображающие последовательность операций или движение данных для бизнес-процесса. Одна или несколько блок-схем включены в зависимости от сложности модели.
Бизнес-правила и требования к данным. Бизнес-правила определяют или ограничивают некоторые аспекты бизнеса и используются для определения ограничений данных, значений по умолчанию, диапазонов значений, количества элементов, типов данных, расчетов, исключений, обязательных элементов и реляционной целостности данных.
Модели данных – диаграммы отношений сущностей, описания сущностей, диаграммы классов
Концептуальная модель – отображение высокого уровня различных объектов для бизнес-функции и их взаимосвязи.
Логическая модель – иллюстрирует конкретные сущности, атрибуты и отношения, вовлеченные в бизнес-функцию, и представляет все определения, характеристики и отношения данных в деловой, технической или концептуальной среде.
Словарь данных и глоссарий . Сборник подробной информации об элементах данных, полях, таблицах и других объектах, которые составляют модель данных, лежащую в основе базы данных или аналогичной системы управления данными.
Карта заинтересованных сторон – определяет всех заинтересованных сторон, на которых влияет предлагаемое изменение, и их уровень влияния / полномочий для требований. Этот документ разработан на начальном этапе методологии управления проектами (PMM) и принадлежит менеджеру проекта, но должен быть обновлен командой проекта, так как новые / измененные заинтересованные стороны идентифицируются на протяжении всего процесса.
Матрица отслеживаемости требований – таблица, которая иллюстрирует логические связи между отдельными функциональными требованиями и другими типами системных артефактов, включая другие функциональные требования, сценарии использования / пользовательские истории, элементы архитектуры и дизайна, модули кода, тестовые случаи и бизнес-правила.
Источник: coderlessons.com
