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

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

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

• формирование требований к АС;

• разработка концепции АС;

• техническое задание;

• эскизный проект;

• технический проект;

• рабочая документация;

• ввод в действие;

• сопровождение АС.

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

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

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

• обзор типовой структуры функциональной спецификации на разработку;

• рассмотрение примера спецификации для разработки отчета в SAP ERP;

• анализ ключевых особенностей в рассмотренной спецификации.

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

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

Рассмотрим типовую структуру документа функциональной спецификации на разработку, предложенную в [3]. Плюс этой структуры состоит в том, что описание хода реализации ведется сверху вниз, кроме того, сохранена логическая последовательность отображения экранов программы, что упрощает понимание программы. Документ спецификации разделяется на 6-ть разделов (рис. 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. Список требований

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

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

• завод;

• склад;

• партия;

• материал;

• данные ГТД и прочее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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