Технология структурирования требований к ПО
1
Введение
1.1 Цель документа
Цель данного документа состоит в описании подхода к формированию и структурированию требований к программному обеспечению.
1.2 Рамки
Предлагаемая технология относится к этапу формирования требований к ПО и предлагает один из возможных вариантов структурирования, ввода и хранения требований. Использование предлагаемой технологии позволяет подготовить систему требований, неразрывно связанную с процессной моделью и моделью сущностей предметной области разрабатываемой системы (термин "функциональная" модель не отражает сути предлагаемого подхода).
Технология, также, включает в себя методику автоматической подготовки документа "Техническое задание на разработку ПО" (или "Спецификация требований к программному обеспечению").
Технология предназначена в первую очередь для использования её системными и бизнес аналитиками на этапе формирования требований.
1.3 Предположения и зависимости
Предлагаемая технология основана на использовании программных продуктов AllFusion Process Modeler, AllFusion Data Modeler и системы управления требованиями Doors (возможно, также, использование системы управления требованиями RequisitePro).
2
существующие
технологии
Традиционно структурирование требований к программному обеспечению производится в рамках отдельного документа, например в формате Word, в соответствии с одним из шаблонов ГОСТ/SRS. Современные системы управления требованиями также предоставляют возможность ведения требований в специализированных базах данных или гибридных структурах Текстовый процессор + БД.
Рассмотрим кратко характеристики предлагаемых вариантов.
- Документ Microsoft Word.
Текстовый процессор предоставляет широкие выразительные возможности по оформлению текста, вставке графических объектов и т.п., что, однако, предъявляет достаточно высокие требования к дизайнерским способностям аналитиков.
Ведение требований в рамках одного/нескольких документов Word, ограничивает аналитика в возможности управления отдельными требованиями как самостоятельными информационными единицами. Также невозможно установить прямую связь между требованиями, и аналитическими моделями, разрабатываемыми на последующих этапах разработки. - Базы
данных (собственного производства и, например, RequisitePro).
Преимущества очевидны – требования являются отдельными информационными единицами со всевозможными атрибутами, поддерживается хранение истории изменения требований, есть возможность устанавливать трассировку между требованиями и, наконец, удобство ввода – одно требование – одна запись в БД.
Недостатки также видны сразу – невозможность использования графических объектов, несвязность текста и, наконец, что приводит в большинстве случаев к отказу от использования БД в больших проектах – большая сложность получения документа/отчёта (например с помощью генератора SoDa для RequisitePro), который будет утверждаться в качестве ТЗ, или SRS. - Гибридные
структуры.
Опыт автора ограничивается использованием RequisitePro и Doors.
Про Requisite можно отметить следующие плюсы: требования действительно можно вводить непосредственно в документ Word и присваивать им всю необходимую атрибутику, разработчик получает все преимущества текстового процессора по форматированию и вставке графики. Есть возможность автоматического версионирования документов целиком (например с использованием CVS).
Отрицательными моментами является невозможность версионирования графических объектов и сложности работы с отсоединёнными документами (в частности в отсоединённом документе невозможно задавать иерархию требований), кроме того, периодически возникают сбои, присущие Word.
Doors, собственно не является гибридным продуктом, а сам представляет собой текстовый процессор, положительные стороны – все те же, что и у Requisite, плюс версионирование графики и меньшее количество сбоев (подробное сравнение не является предметом данного документа).
Таким образом, на собственном опыте автора логичным выбором для разработки технического задания, или SRS, является ведение требований в рамках единого документа с возможностью управления требованиями как отдельными объектами.
В рассмотренных системах управления требованиями (RequisitePro & Doors) предоставляется также возможность связывания отдельных требований с объектами (классами, или прецедентами) аналитических моделей (UML), разрабатываемых на последующих этапах разработки.
По сути, возможности современных систем управления требований покрывают все потребности аналитиков, но всё же остаётся разрыв между аналитическими моделями, и собственно требованиями к ПО. Предоставляемые возможности связывания требований и объектов - это связь по ссылке, что не всегда удобно в использовании.
Ещё один подход к формированию требований к ПО.
- IDEF0
В описании стандарта IDEF0, в качестве одной из основных областей применения стандарта функционального моделирования приводится спецификация требований к ПО, цитирую: "For new systems, IDEF0 may be used first to define the requirements and specify the functions, and then to design an implementation that meets the requirements and performs the functions."
Стандарт IDEF0 и продукты, поддерживающие его, достаточно хорошо известны в нашей стране, так что нет смысла останавливаться на его плюсах и минусах, а также на самой применимости парадигмы к проектированию ПО.
Рассмотрим возможности ведения требований на примере одного из самых известных продуктов, поддерживающих моделирование в стандарте IDEF0, BPwin.
Продукт позволяет в соответствии со стандартом создавать связные графические модели разрабатываемых систем, а в дополнение к стандарту, для каждого графического элемента имеется возможность задавать значения множества атрибутов.
Таким образом, в рамках единой структурированной модели имеется возможность совместить и графическое и текстовое (в виде определений к графическим элементам) представление требований к ПО. Но остаётся проблема получения единого документа, содержащего все требования к ПО, структурированные в соответствии с одним из шаблонов ГОСТ/SRS, так как существующий генератор отчётов BPwin предоставляет достаточно скудные средства форматирования. Невозможна также трассировка требований и их версионирование (использование ModelMart для получения истории изменения требований представляется сложным).
3
предлагаемая Технология
3.1 Описание технологии
В описываемой технологии предлагается использование связки нескольких систем. Далее приведены этапы предлагаемой технологии структурирования требований.
3.1.1 Построение процессной модели (IDEF0/DFD/IDEF3)
На первом этапе, в соответствии с принятыми ограничениями, аналитик производит формирование процессной модели системы (методология IDEF0/DFD/IDEF3) с использованием программного продукта AllFusion Process Modeler (BPwin). По мере уточнения требований производится декомпозиция функций системы до необходимого уровня. Все функции системы должны быть связны, а информационные потоки, увязывающие функции должны быть строго определены.
3.1.2 Построение ER модели (IDEF1X)
В рамках сбора требований к ПО производится определение требований к информации, которую будет обрабатывать система. Данные требования обычно включают в себя описание видов и атрибутики обрабатываемой информации.
Технология предполагает разработку связной ER модели сущностей предметной области на этапе сбора требований. ER модель разрабатывается с использование программного продукта AllFusion Data Modeler (ERwin), при этом ERwin рассматривается как система формирования требований к информации.
3.1.3 Связывание процессной и ER моделей
Между процессной моделью и моделью сущностей устанавливается связь с использованием механизма связи, предоставляемого BPwin. При установлении связи в BPwin модель копируется словарь сущностей и атрибутов, включая определения и типы данных.
Для каждого информационного потока модели BPwin при помощи средств BPwin выбирается набор сущностей и атрибутов, включённых в соответствующий поток.
3.1.4 Экспорт данных в систему управления требованиями
После разработки связной функциональной модели при помощи специального модуля сопряжения производится экспорт информации, подготовленной в BPwin модели, в систему управления требованиями. В настоящий момент разработан модуль сопряжения с системой Doors, однако, существующий API для RequisitePro позволяет осуществлять экспорт требований в базу данных этой системы.
Для экспорта требований используется шаблон документа Doors, включающий в себя разделы, которые соответствуют разделам технического задания (также разработан шаблон документа описания бизнес-процесса).
В систему управления требованиями экспортируется иерархия деятельностей (наименования и определения), введённая в процессной модели. Кроме того, экспортируется информация об информационных потоках, связях между функциями и других элементах существенных для описания системы (полный список экспортируемых данных показан на примере подготовки ТЗ).
Таким образом, например, уникальным функциональным требованием в системе будет являться деятельность с заданными в BPwin наименованием и определением. Иерархия экспортируемых функциональных требований полностью повторяет иерархию деятельностей BPwin.
3.1.5 Ведение нефункциональных требований
Нефункциональные требования ведутся в рамках системы Doors в отдельных разделах документа в соответствии со структурой шаблона документа.
3.1.6 Трассировка требований
Между любыми требованиями, как экспортированными, так и введёнными в DOORS вручную может быть установлена связь, которая остаётся неизменной при повторном экспорте.
3.1.7 Изменение требований
· Для требований, которые введены непосредственно в Doors, изменения производятся из среды Doors.
· Для изменения требования к функциям – изменения вносятся в BPwin модель, далее производится повторный экспорт информации в Doors.
· Для изменения требования к информации – изменения вносятся в ERwin модель, далее производится повторный экспорт информации в BPwin, а из BPwin в Doors.
Для соотнесения требований в Doors и объектов BPwin используется уникальный идентификатор объектов, присваиваемый BPwin. При экспорте производится проверка неизменности передаваемой информации, в случае изменения, требование Doors модифицируется новым значением.
При изменении атрибутов требований Doors автоматически производит сохранение версий требований.
3.1.8 Формирование печатной версии документа
Для формирования печатной версии документа используется стандартное средство экспорта документа Doors в формат Microsoft Word. При этом производится форматирование информации на основании стилей документа Microsoft Word в соответствии с её типом (примеры типов: наименование требования, определение требования, наименование сущности, атрибут…).
3.2 Структура итогового документа ТЗ/SRS
Далее, кратко, описана структура разделов результирующего документа, которые автоматически заполняются при экспорте требований из BPwin модели в Doors. Кроме них в документе существуют разделы, которые изначально ведутся в Doors, однако они не рассматриваются.
3.2.1 Краткая характеристика системы
В разделе приводится:
3.2.1.1 Характеристика системы верхнего уровня
Выводятся:
- текстовое описание системы (Definition для A0);
- перечень регламентирующей информации;
- перечень входящей информации;
- перечень ресурсов (механизмов);
- перечень исходящей информации;
3.2.1.2 Краткое описание деятельностей первого уровня
Фактически, это краткая характеристика основных прецедентов.
Выводится перечень деятельностей первого уровня (диаграмма A0) вместе с их кратким текстовым описанием (Description);
3.2.2 Описание окружения
В разделе перечисляются Externals & Referents, которые являются источниками, или приёмниками информационных потоков BPwin модели и помечены, как внешние системы (при помощи UDP переменной). Вместе с наименованиями внешних систем, выводится их описание.
3.2.3 Описание ролей
В разделе перечисляются все роли, которые были указаны в каких-либо деятельностях BPwin модели. Для каждой роли приводится список деятельностей, в которых она принимает участие.
3.2.4 Требования к функциям
В раздел полностью переносится иерархия деятельностей, представленная в BPwin модели.
Для каждой функции выводится:
- Наименование функции, вместе с номером деятельности BPwin модели.
- Определение функции (Definition), в котором должны быть перечислены все требования к функции.
- Примечание функции (Note).
- Перечень регламентирующей информации (наименования управляющих стрелок).
- Перечень входящей информации (наименования входящих стрелок).
- Перечень ресурсов (наименования стрелок-механизмов).
- Перечень исходящей информации (наименования исходящих стрелок).
- Перечень ролей, участвующих в исполнении деятельности.
- Перечень вызовов, осуществляемых функцией (Call стрелки)
- Перечень переходов к исполнению определённых сценариев, при выполнении заданных условий (используется в IDEF3 диаграммах).
Если входящие, или исходящие стрелки имеют своим источником/приёмником External или Referent, то вместе с наименованием стрелки приводится наименование источника/приёмника информации.
Все типы стрелок сгруппированы под соответствующими заголовками.
Существует возможность вывода в документ нескольких сценариев (декомпозиций) IDEF3 для одной деятельности.
3.2.5 Требования к информации
В раздел выводится информация по входящим, или исходящим дугам BPwin модели, которые помечены (при помощи UDP переменной) для вывода в раздел требований к информации. В зависимости от типа пометки, информация по дугам относится в один из подразделов: "Информационные потоки", "Системные сообщения", "Документы/неструктурированная информация".
Для каждой дуги выводится:
- Наименование дуги (Name).
- Описание дуги (Definition).
- Примечание дуги (Note).
- Перечень сущностей, ассоциированных с дугой.
Для каждой сущности выводится:
- Наименование сущности (Name).
- Описание сущности (Definition).
- Перечень атрибутов, ассоциированных с дугой.
Для каждого атрибута выводится:
- Наименование атрибута (Name).
- Тип атрибута (тип, заданный в ERwin модели).
- Описание атрибута (Definition).
3.3 Необходимые комментарии к технологии
3.3.1 Недостатки подхода
1. Один из недостатков (который с другой стороны является преимуществом, как будет сказано ниже) состоит следующем: для внесения изменений в требования к системе, приходится вносить изменения в BPwin, или ERwin модели, и это само занимает ощутимое время, а при неправильно разработанной модели, некоторые изменения могут привести к значительным переработкам.
2. При экспорте данных в Doors наименование и определение к функции выводится как одно требование, т.е. в текущей версии модуля сопряжения нет возможности разделить на отдельные требования текст, введённый в определении функции – поле Definition (в настоящий момент, для преодоления этого недостатка рекомендуется производить дополнительную декомпозицию сложной деятельности).
3.3.2 Преимущества и другие характеристики
1. Требования к ПО изначально организованы в виде системы связных функций, что позволяет уже на этапе сбора требований описать интерфейсы между различными функциональными блоками. Связность модели исключает наличие в требованиях "изолированных" функций, или "изолированных" информационных потоков.
2. Фактически, модель BPwin является прототипом системы и предоставляет возможность судить о расширяемости и изменяемости разрабатываемой системы в будущем. На практике так и происходит, поскольку все изменения к требованиям необходимо проводить через BPwin и ERwin модели, и чем "правильнее" построена модель, тем легче провести изменения.
3. Любое единичное требование, или изменение к требованию вносится единожды и только в одном месте – в ERwin модель – для требований к информации, в BPwin модель – для требований к функциям, в Doors – для других требований. В окончательный документ требование/изменение попадает автоматически при помощи операций экспорта.
4. В любой момент времени модели BPwin, ERwin и текст документа находятся в полном соответствии. Т.е. информационная модель соответствует процессной (функциональной) модели, а процессная (функциональная) модель полностью соответствует документу Техническому заданию.
5. Процессная модель BPwin должна отражать автоматизацию некоторых процессов (процессный подход), и это даёт возможность вместе с разработкой модели оптимизировать автоматизируемые, бизнес-процессы.
6. Одним из побочных эффектов применения технологии стали хорошие результаты в структурировании требований к графическому интерфейсу, формулировка и структуризация которых всегда вызывает определённые сложности.
7. Нельзя не отметить следующий положительный эффект - на выходе мы получаем три документа, обращённых к различным категориям лиц, воспринимающих информацию со своей определённой точки зрения:
- хорошо структурированный текстовый документ для тех, кто лучше воспринимает печатный текст;
- IDEF0/DFD/IDEF3 модель, для тех, кому необходима функциональная схема ПО;
- IDEF1X модель, для тех, кто воспринимает требования "от объектов", хотя могут понадобиться дополнительные диаграммы, например, StateChart.
3.4 Опыт применения
Отдельные элементы технологии разрабатывались и применялись с 2002-го года. Полностью технология была внедрена в эксплуатацию в начале текущего года и успешно используется и совершенствуется в настоящее время.
С использованием данного подхода сформулированы требования к пяти подсистемам, которые разработаны и внедрены, изменения к требованиям к данным подсистемам также проводятся с использованием описанной технологии.
Кроме того, технология позволила построить модель основных бизнес-процессов компании, документировать их и поддерживать модель и документацию в актуальном состоянии.
Авторы:
Трушин Н.А.
– идеология, импорт и структурирование информации из BPwin
Тупчиенко С.В.
– экспорт информации в Doors, технология управления требованиями
4 Приложения
4.1
Приложение
1 Модель для ТЗ "Подсистема контроля филиалов "
|
A-0 Подсистема контроля филиалов |
|
A0 Подсистема контроля филиалов |
|
A1 Загрузка данных |
|
Организационная структура |
4.2 Приложение 2 Текст технического задания, получаемый из модели
|
|
Подсистема контроля филиалов
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
на разработку программного обеспечения
5
Краткая
характеристика подсистемы
5.1 Подсистема "Подсистема контроля филиалов (A0)"
Подсистема контроля качества должна обеспечивать возможность
проведения комплексного анализа данных, характеризующих процесс оперативного
управления, проводимого дочерним предприятием.
Регламентирующая/управляющая информация
– Приказ
N 6 от 12.06.2004
– Регламент
управления предприятием
Входящая информация
– Пакет
данных о деятельности филиала (XML-файл) (см. раздел "Информационные
потоки")
источник: Информационная система филиала
– Тарифы
на продукт деятельности филиала (см. раздел "Информационные потоки")
источник: Система хранения данных
Ресурсы
– ПО
Подсистемы контроля филиалов
Исходящая информация
– Отчёты
по результатам контроля за деятельностью филиалов
5.2 Основные
решаемые задачи
5.2.1 Загрузка данных
Данные, предоставляемые филиалом, загружаются в БД Системы
контроля, проводится контроль корректности данных и их предварительная
обработка.
5.2.2 Контроль расчётных значений за сутки
Пользователь, посредством табличных и графических форм, проводит
оценку индикативных результатов работы филиала за выбранный расчетный период.
5.2.3 Контроль суммарных расчётных значений
Для заданного временного интервала, посредством табличных форм,
пользователь проводит оценку индикативных величин, характеризующих ведение
режима Системным оператором, агрегированных за период.
6
Описание окружения
6.1 Система хранения данных
Система хранения данных накапливает информацию о финансовых потоках
филиалов.
7
Описание ролей
Отдел контроля филиалов
Оператор контролер
–
Контроль суммарных расчётных значений (A3)
–
Контроль расчётных значений за сутки (A2)
Отдел обмена данными с филиалами
Оператор обмена данными
–
Загрузка данных (A1)
8
Требования к
функциям
8.1 Загрузка данных (A1)
Процесс загрузки данных, полученных от информационной системы
филиала, должен осуществляться в соответствии с порядком, установленным
Техническим заданием на Технические средства обмена данными между головным
офисом и филиалами.
Регламентирующая/управляющая информация
– Управляющие
команды пользователя
Входящая информация
– Пакет
данных о деятельности филиала (XML-файл) (см. раздел "Информационные
потоки")
Ресурсы
– Модуль
загрузки данных
Исходящая информация
– Расчётные
данные о товарах (см. раздел "Информационные потоки")
адресат: блок "Контроль расчётных значений за сутки (A2)
адресат: блок "Контроль суммарных расчётных значений (A3)
Исполнители
Отдел обмена данными с филиалами
Оператор обмена данными
8.1.1 Загрузка данных о филиалах во временные структуры данных (A1.1)
Загрузка пакета данных о филиалах должна производиться по команде оператора.
На этапе предварительной загрузки данных должна проводиться проверка корректности формата переданного информационного пакета.
В случае несоответствия формата переданного пакета, в системный журнал Системы контроля филиалов должно записываться соответствующее сообщение, кроме того, оператор, инициировавший загрузку должен информироваться об ошибочном формате.
Входящая информация
– Пакет
данных о деятельности филиала (XML-файл) (см. раздел "Информационные
потоки")
Исходящая информация
– Данные
о филиалах (см. раздел "Информационные потоки")
адресат: БД Подсистемы контроля филиалов
– Сообщение
о некорректном формате XML-файла (см. раздел "Информационные
сообщения")
адресат: Системный журнал Подсистемы контроля филиалов
8.1.2 Актуализация данных о филиалах (A1.2)
При загрузке данных о файлах должна проводиться их проверка на непротиворечивость, включая:
- проверку полноты данных о филиалах (данные о каждом филиале должны быть полными);
- проверку на соответствие итоговых данных предыдущего периода и начальных данных загружаемого периода.
При отрицательном результате указанных проверок, в системном журнале должны быть сохранены соответствующие сообщения, данные не подлежат загрузке.
Для обеспечения выполнения процедур контроля для любого периода времени и с учётом периодического изменения данных о филиалах при загрузке должны сохраняться "исторические" состояния данных о филиалах.
В целях унификации и с учётом существующих наработок, для хранениия истории реестра, должна быть использована методика, принятая в "Подсистеме контроля за работой предприятия".
Входящая информация
– Данные
о филиалах (предв. загрузка)
источник: БД Подсистемы контроля филиалов
Исходящая информация
– Загруженные
данные о филиалах
адресат: БД Подсистемы контроля филиалов
8.1.3 Загрузка данных о движении товара (A1.3)
В случае успешной актуализации данных о филиалах, должна быть произведена загрузка данных о движении товара.
Загрузка данных по движению товара должна проводиться с использованием новых данных о филиалах. На этапе загрузки расчётных данных должен быть проведён ряд проверок, включая проверку на наличие информации по всем филиалам из загруженных данных о филиалах и проверку на отсутствие данных по несуществующим в филиалам.
В случае обнаружения ошибок в системном журнале должны быть сохранены соответствующие сообщения.
Для каждого филиала, для каждого рабочего дня, при наличии признака собственное управление, информация о движении товара, должна преобразовываться следующим образом:
Оборот товара (шт) = Продажа товара (шт) + Приход товара на склад (шт)
Баланс на складе (шт) = Продажа товара (шт) - Приход товара на склад (шт)
При загрузке информации о движении товара должна проводиться проверка на повторно передаваемую информацию, при наличии изменений к ранее загруженной информации, новая информация должна замещать ранее загруженную, а старая информация должна сохраняться в исторических данных, с указанием даты замещения. Контролю на изменения подлежат следующие величины:
- Оборот товара (шт)
- Баланс на складе (шт)
__________________
В связи с тем, что исходные данные для расчёта ряда величин загружаются независимо, с разной периодичностью, а также могут перезагружаться, - на этапе разработки необходимо определить порядок формирования расчётных данных о движении товара.
Как варианты, возможны следующие решения:
- создание materialized view над загружаемыми данными;
- включение формирования расчётных данных в общий план перерасчётов для Расчётной системы.
Входящая информация
– Данные
о движении товара (предв. загрузка)
источник: БД Подсистемы контроля филиалов
– Загруженные
данные о филиалах
источник: БД Подсистемы контроля филиалов
– Информация
об общих объемах продаж в регионе
источник: БД Подсистемы контроля филиалов
– Информация
об объёмах продаж
источник: БД Подсистемы контроля филиалов
Исходящая информация
– Расчётные
данные о товарах (см. раздел "Информационные потоки")
– Изменения
в повторно переданных данных о движении товара
адресат: БД Подсистемы контроля филиалов
– Данные
о движении товара
адресат: БД Подсистемы контроля филиалов
– Расчётные
данные о товарах (см. раздел "Информационные потоки")
адресат: БД Подсистемы контроля филиалов
– Сообщение
о некорректных данных о филиалах
адресат: Системный журнал Подсистемы контроля филиалов
8.1.4 Загрузка финансовых данных (A1.4)
Вне зависимости от результатов загрузки данных о движении товара, должна быть проведена загрузка финансовых данных.
При загрузке финансовых данных, должны проводиться проверки на корректность данных, включая:
- проверку на правильность нумерации счетов и актов приема-передачи;
- проверку на вхождение суммы каждого счета и акта приема-передачи в финансовые лимиты на единичную операцию для филиала.
В случае наличия данных, которые не проходят проверку в системный журнал подсистемы контроля филиалов должны записываться соответствующие сообщения.
Входящая информация
– Финансовые
данные (предв. загрузка)
источник: БД Подсистемы контроля филиалов
Исходящая информация
– Финансовые
данные
адресат: БД Подсистемы контроля филиалов
– Сообщение
о наличии ошибочных финансовых данных (см. раздел "Информационные
сообщения")
адресат: Системный журнал Подсистемы контроля филиалов
8.2 Контроль расчётных значений за сутки (A2)
Для проведения контроля ежедневных объемов операций филиалов, должен быть разработан функциональный блок, позволяющий производить обработку объемов операций филиалов, включая все выды операций по движению всех видов товаров и все операции по движению денежных средств в едином формате и компактной форме.
Исходные данные и расчётные значения должны предоставляться пользователю, как в табличной, так и в графической форме.
__________________
Для всех сформированных табличных форм должна быть обеспечена возможность экспорта информации в формат Microsoft Excel.
Регламентирующая/управляющая информация
– Управляющие
команды пользователя
Входящая информация
– Расчётные
данные о товарах (см. раздел "Информационные потоки")
источник: блок "Загрузка данных (A1)
– Тарифы
на продукт деятельности филиала (см. раздел "Информационные потоки")
Ресурсы
– Блок
контроля ежедневных объемов операций
Исходящая информация
– Отчёты
по результатам контроля за деятельностью филиалов
Исполнители
Отдел контроля филиалов
Оператор контролер
8.3 Контроль суммарных расчётных значений (A3)
Для проведения контроля ежедневных объемов операций, должен быть разработан функциональный блок, позволяющий производить обработку суммарных расчётных данных за период (включая объемы движения всех типов товара и все виды движения денежных средств) в едином формате и компактной форме.
Расчётные значения должны предоставляться пользователю в табличной форме.
__________________
Для всех сформированных табличных форм должна быть обеспечена возможность экспорта информации в формат Microsoft Excel.
Регламентирующая/управляющая информация
– Управляющие
команды пользователя
Входящая информация
– Расчётные
данные о товарах (см. раздел "Информационные потоки")
источник: блок "Загрузка данных (A1)
– Тарифы
на продукт деятельности филиала (см. раздел "Информационные потоки")
Ресурсы
– Блок
контроля суммарных значений
Исходящая информация
– Отчёты
по результатам контроля за деятельностью филиалов
Исполнители
Отдел контроля филиалов
Оператор контролер
9
Требования к
информации
9.1 Информационные потоки
9.1.1 Данные о филиалах
Данные о филиалах являются составляющей частью пакета данных о
деятельнсти филиала и описывают основные характеристики филиала.
 Филиал
Атрибуты
– ИД_Филиал
– Наименование
Полное наименование филиала
– Адрес
Почтовый адрес офиса филиала
– Реализация
товара план
Плановое значение по реализации товара на текущий год (руб.)
9.1.2 Пакет данных о деятельности филиала (XML-файл)
Пакет данных о деятельности филиалов поступает по электронной почте
в виде прикрепленного файла в формате XML
 Движение товара
Атрибуты
– ИД_Движение
товара
– Наименование
Полное наименование товара
– Дата
Дата движения товара
– Источник
Начальная точка движения товара
– Приемник
Конечная точка движения товара
– Количество
Количество товара в штуках
 Объемы продаж
Атрибуты
– ИД_Объем
продаж
– ИД_Движение
товара
Код движения товара
– ИД_Филиал
Код филиала
– Стоимость
товара
Стоимость товара в рублях
– Затраты
при продаже
Различные затраты при продаже:
- доставка
- скидка
- подарок
- т.д.
 Расчетные данные
 Филиал
Атрибуты
– ИД_Филиал
– Наименование
Полное наименование филиала
– Адрес
Почтовый адрес офиса филиала
– Реализация
товара план
Плановое значение по реализации товара на текущий год (руб.)
9.1.3 Расчётные данные о товарах
 Расчетные данные
Атрибуты
– ИД_Расчета
– ИД_Товара
Код товара
– Чистая
прибыль
Чистая прибыль, которую приносит товар в рублях
– Индекс
затрат
Специльный индекс, позволяющий оценить затраты на гарантийное
обслуживание товара
9.1.4 Тарифы на продукт деятельности филиала
Тариф на продукт деятельности филиала предоставляется региональным
представительтвом по определению тарифов на продукты в регионе
__________________
Формат предоставления данных может различаться в зависимости от региона. На данный момент используются форматы XML и CSV.
 Товар
Атрибуты
– ИД_Товара
– Наименование
Полное наименование товара
– Описание
Описание товара
– Тариф
Тариф на товар в рублях