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

Ключевым содержанием подобных проектов является разработка программного продукта, а все остальные активности рассматриваются в качестве поддерживающих. Реализация программ может вестись на основе различных стратегий, следуя классическим моделям разработки: каскадной, итерационной и спиралевидной. Проекты имплементации информационных систем «с нуля» преимущественно ведутся на базе каскадной стратегии, а задачи тиражирования и развития систем в последнее время осуществляются с применением итерационных и спиралевидных подходов, например, Agile [2].

Следуя каскадной схеме внедрения программных продуктов, готовится ряд важных проектных документов, описывающих детали предлагаемого решения. В большинстве проектов имплементации систем класса ERP, создаются документы спецификаций на разработку [3]. В России действуют ГОСТ 34, посвященный разработке автоматизированных систем управления (далее – АС). Согласно ГОСТ 34.601-90 этапы разработки системы включают:

формирование требований к АС;
разработка концепции АС;
техническое задание;
эскизный проект;
технический проект;
рабочая документация;
ввод в действие;
сопровождение АС.

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

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

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

обзор типовой структуры функциональной спецификации на разработку;
рассмотрение примера спецификации для разработки отчета в SAP ERP;
анализ ключевых особенностей в рассмотренной спецификации.

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

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

Рассмотрим типовую структуру документа функциональной спецификации на разработку, предложенную в [3]. Плюс этой структуры состоит в том, что описание хода реализации ведется сверху вниз, кроме того, сохранена логическая последовательность отображения экранов программы, что упрощает понимание программы. Документ спецификации разделяется на 6-ть разделов (рис. 1.1):

Рис. 1.1 Типовая структура спецификации на разработку

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

2. Пример функциональной спецификации для разработки отчета в SAP ERP

Воспользуется типовой структурой спецификации, описанной на рис.1.1, и проанализируем пример подготовки документа для разработки отчета в системе SAP ERP (разделы 2.1-2.8). В качестве заказчика будем использовать тестовую организацию под названием ДСТ.

2.1. Оглавление

2.2. Требования
2.3. Концепция решения
2.4. Селекционный экран
2.5. Логика работы программы
2.6. Роли и полномочия
2.7. Тестовые данные
2.8. Допущения

2.2. Требования

Компания ДСТ занимается оптовыми продажами товаров. Большая часть продаваемой продукции закупается по импортной схеме. Импортная закупка требует учитывать сумму таможенных пошлин и сборов в стоимости закупаемых товаров, а также хранить данные ГТД (Грузовая таможенная декларация). В случае перепродажи продукции в сопроводительных документах (Счет-фактура) необходимо указывать номер исходной ГТД, полученной при оприходовании товара на склад. Согласно глобальному решению номер ГТД хранится в системе SAP ERP в признаках классификации партии, заполняемых при регистрации прихода товара транзакцией MIGO. Для целей контроля и прослеживаемости требуется разработать отчет, показывающий текущий складской запас SAP ERP с данными ГТД.

Таблица 2.2.1. Список требований

Gap №	Требование
144	Разработать отчет, аналог MB52 с возможностью отображения признаков партий

2.3. Концепция решения

Функционал разрабатываемого отчета в SAP ERP близок к стандартной транзакции MB52. Результаты работы отчета обогащены данными признаков классификации партии, в частности ГТД. Отчет показывает ненулевой оцененный свободно используемый запас в разрезе оргуровней предприятия:

завод;
склад;
партия;
материал;
данные ГТД и прочее.

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

Типовая структура спецификации на разработку — Рис. 2.3.1. Структура и логика взаимодействия экранов отчета по запасам: а) селекционный экран; б) ALV-список выбранных данных

2.4. Селекционный экран

Реализация требования табл. 2.2.1 предполагает разработку программы, архитектура которой описана в 4.3. Детали разрабатываемого приложения приведены в таблице ниже (табл. 2.4.1).

Таблица 2.4.1. Детали разрабатываемой программы

Параметр	Требование
Название программы	Stock report with classification/Отчет по запасам с классификацией
Код программы	ZRUIMSTKCLASSRPT
Название транзакции	Stock report with classification/Отчет по запасам с классификацией
Код транзакции	ZRUIMSTKCLASSRPT

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

Таблица 2.4.2. Селекционный экран программы

№	Наименование поля	Категория (Parametrs, Select-Options, RadioButton, CheckBox)	Тип (ссылка на элемент данных)	Обязатель-ность для ввода	Значение по умолчанию
Selection criteria’s/Ограничения
1	Plant/Завод	Parametrs	MCHB-WERKS	Х	RU01
2	Storage location/Склад	Select-Options	MCHB-LGORT
3	Material group/Группа материала	Select-Options	MARA-MATKL
4	Material/ Материал	Select-Options	MCHB-MATNR
5	Batch/Партия	Select-Options	MCHB-CHARG
6	GTD/ГТД	Select-Options
Format/Формат
7	Format/Формат	Parametrs			/ZGTD

После нажатие кнопки «Выполнить» осуществляется проверка полномочий согласно 2.6. В случае успеха осуществляется переход к экрану выбранных данных, описанному в 2.5.

2.5. Логика работы программы

Успешное выполнение проверки полномочий пользователя запускает экран выбранных данных в формате ALV-Grid (табл. 2.5.1). Экран должен содержать стандартные кнопки редактирования данных (рис. 2.5.1). Поля экрана упорядочиваются согласно заданному на селекционном экране формату («Формат» селекционного экрана).

Рис. 2.5.1. Стандартные кнопки редактирования данных

Таблица 2.5.1. Поля ALV-списка выбранных данных

№	Техническое название поля	Элемент данных	Тип данных	Длина данных	Краткий текст
1	WERKS	MCHB-WERKS	-	-	Plant/Завод
2	LGORT	MCHB-LGORT	-	-	Storage location/Склад
3	MATKL	MARA-MATKL	-	-	Material group/Группа материалов
4	WGBEZ60	T023-WGBEZ60	-	-	Material group name/ Наименование группы материалов
5	MATNR	MCHB-MATNR	-	-	Material/Материал
6	MAKTX	MAKT-MAKTX	-	-	Material name/ Наименование материала
7	CHARG	MCHB-CHARG	-	-	Batch/Партия
8	CLABS	MCHB-CLABS	-	-	Valuated stock/ Оцененный запас
9	MEINS	MARA-MEINS	-	-	Base unit of measure/БЕИ
10	GTD_1	-	CHAR	10	GTD part 1/ГТД часть 1
11	GTD_2	-	DATS	8	GTD part 2/ГТД часть 2
12	GTD_3	-	CHAR	10	GTD part 3/ГТД часть 3
13	GTD_4	-	CHAR	10	GTD part 4/ГТД часть 4
14	GTD	-	CHAR	38	GTD/ГТД

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

Таблица 2.5.2. Алгоритм заполнения полей ALV-списка выбранных данных

№	Техническое название поля	Краткий текст	Правило	Алгоритм
	1. Основной алгоритм выбора из таблицы остатков по партии MCHB Select * from MCHB where WERKS = «Завод» селекционного экрана (если заполнен) and LGORT = «Склад» селекционного экрана (если заполнен) and MATNR = «Материал» селекционного экрана (если заполнен) and CHARG = «Партия» селекционного экрана (если заполнен) and CLABS > 0
	2. Алгоритм выбора группы материалов Loop at MCHB (step 1) Select MATKL from MARA where MATNR = MCHB-MATNR
	3. Алгоритм выбора названия группы материалов Loop at MARA (step 2) Select WGBEZ60 from T023 where MATKL = MARA-MATKL
	4. Алгоритм выбора названия материала Loop at MCHB (step 1) Select MAKTX from MAKT where MATNR = MCHB-MATNR
	5. Алгоритм выбора базовой ЕИ материала Loop at MCHB (step 1) Select MEINS from MARA where MATNR = MCHB-MATNR
	6. Алгоритм выбора признака ГТД_1 Loop at MCHB (step 1) Select ATINN from CABN where // Выбрать код признака классификации ATNAM = ‘GTD_1’ Select CUOBJ_BM from MCH1 where // Выбрать ссылку на партию и материал MATNR = MCHB-MATNR and CHARG = MCHB-CHARG Select ATWRT from AUSP where // Выбрать значение по коду признака и ссылке ATINN = CABN-ATINN and OBJEK = СЛидирующимиНулями(MCH1-CUOBJ_BM) and KLART = ‘023’
1	WERKS	Plant/Завод	=	MCHB-WERKS
2	LGORT	Storage location/Склад	=	MCHB-LGORT
3	MATKL	Material group/Группа материалов	=	MARA-MATKL
4	WGBEZ60	Material group name/ Наименование группы материалов	=	T023-WGBEZ60
5	MATNR	Material/Материал	=	MCHB-MATNR
6	MAKTX	Material name/ Наименование материала	=	MAKT-MAKTX
7	CHARG	Batch/Партия	=	MCHB-CHARG
8	CLABS	Valuated stock/ Оцененный запас	=	MCHB-CLABS
9	MEINS	Base unit of measure/БЕИ	=	MARA-MEINS
10	GTD_1	GTD part 1/ГТД часть 1	=	AUSP-ATWRT для признака ‘GTD_1’
11	GTD_2	GTD part 2/ГТД часть 2	=	AUSP-ATWRT для признака ‘GTD_2’
12	GTD_3	GTD part 3/ГТД часть 3	=	AUSP-ATWRT для признака ‘GTD_3’
13	GTD_4	GTD part 4/ГТД часть 4	=	AUSP-ATWRT для признака ‘GTD_4’
14	GTD	GTD/ГТД	=	GTD_1 + “” + GTD_2 +GTD_3 + “” + GTD_4 (поля ALV-Grid)
	7. Алгоритм постобработки позиции для группы материалов селекционного экрана If MATKL <> «Группа материалов» селекционного экрана (если заполнено), then Удалить запись из ALV-Grid
	8. Алгоритм постобработки позиции для ГТД селекционного экрана If GTD <> «ГТД» селекционного экрана (если заполнено), then Удалить запись из ALV-Grid ...

Литературный источник

Степанов Д.Ю. Подготовка функциональных спецификаций для доработки корпоративной информационной системы на примере ABAP-отчета в SAP ERP // Корпоративные информационные системы. – 2021. – №1 (13). – С. 93-107. – URL: https://corpinfosys.ru/archive/issue-13/145-2021-13-functionalspecification.

Функциональная спецификация на разработку ERP-системы на примере ABAP-отчета