Практически каждый SAP-новичок, пришедший на проект внедрения ERP-системы, сталкивается с задачей написания функциональной спецификации и дальнейшего тестирования ABAP-разработки. Казалось бы, задача весьма несложная, но не для специалиста, только ступившего на путь SAP. Конечно, никто не доверит SAP-новобранцу подготовку по-настоящему сложной спецификации, поэтому, как правило, на них возлагается один из самых простых с технической точки зрения видов разработки – печатные формуляры (F по категоризации RICEFW). В то же время, эти формуляры являются самыми трудоёмкими для тестирования и поддержки - малейшее изменение в реализации бизнес-процесса или функции приведёт к неработоспособности алгоритмов выборок.

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

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