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

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

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

• описание исходных бизнес-требований;
• модель TO-BE;
• допущения;
• концепция решения;
• логика взаимосвязи экранов, их полей и алгоритмов заполнения;
• сценарии функционально-модульного тестирования;
• роли и полномочия.

Бизнес-требования, описание процесса с учетом текущей разработки в модели TO-BE, а также концепция решения необходимы для того, чтобы пользователи могли однозначно идентифицировать исходные потребности в текущей разработке и ознакомиться с верхнеуровневым решением, не вдаваясь в технические подробности. Последнее весьма существенно, так как одним из подтверждающих документа спецификации всегда является бизнес-представитель, далекий от таблиц баз данных, языков программирования и программной архитектуры.

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

Определение 10. Допущение – это предположение или гипотеза, выдвижение которых равнозначно самостоятельному ответу на открытый вопрос, что позволяет снизить неопределенность в процессе имплементации КИС.

Рис. 23. Пример использования допущений для исключения неопределённостей

Следуя изначально продуманной концепции решения, описываются экраны пользовательской программы и логика перехода между ними, кроме того поля, кнопки, функции и подэкраны каждого экрана, а также алгоритмы обработки данных, что обсуждалось ранее в п.3.2-3.3. Детализация указанных элементов – самая трудоемкая задача процесса подготовки спецификации, требующая львиную долю плановых трудозатрат.

Рис. 24. Пример структуры спецификации для разработки C-программы по обработке данных

Проведение испытания разработанной на основе спецификации программы осуществляется в среде разработки путем функционально-модульного тестирования. Сценарии тестирования, дополненные тестовыми данными, приводятся в одноименном разделе. Документирование и отслеживание последующих видов испытаний: системного, интеграционного и непрерывного тестирований, ведется отдельно, преимущественно в программной системе ALM (Application Lifecycle Management) от компании HP.

Реализованные с нуля отчеты, программы, формуляры и интерфейсы должны быть добавлены в технические роли для возможности использования пользователями в ERP-системе. Присвоение пары «программа – роль» описывается в разделе ролей и полномочий. На рисунке ниже даны несколько примеров содержания спецификации на разработку для получения более полной картины возможных способов наполнения документа.

Полный текст статьи: https://corpinfosys.ru/archive/issue-8/69-2019-8-functionalspec