Purpose

The purpose of this checklist is to fast-track the creation and review of Specifications by describing the minimum set of acceptance criteria required for such a Specification to meet before it is accepted by the Technical team for implementation. By describing up-front the standards and expectations placed by the Technical team upon the authors of Specifications, we hope to speed up delivery of specs and their reviews, and to reduce rework with the goal to meet project timeline and quality objectives.

Assumption

The overriding requirement is for the Specification to be completed with enough detail so that a technically sound solution can be implemented.

Fitness for Purpose

The Specification serves several purposes that are equally important for the document to be acceptable. The specification must describe:

Why the solution was designed in the way described in the document; and
How it will address the gap between a genuine Syensqo requirement and SAP standard; and
What is required to be developed to meet the requirements of the business process.

Specifications communicate with two different and equally important audiences:

Project team members, such as developers who must build the solution you have in mind, Testers who need to validate it, etc.
Support and Operations people who must support this in future, resolve problems, extend it after go-live, and otherwise maintain it for 10 years or more.

Both of these groups are important customers, and their needs must be taken into account when writing Specifications.

With the above in mind, these items must be adhered to :

A Specification should not focus on the implementation details of how you feel the development should be completed, i.e. it should not contain pseudo-code.
The author has not injected actual code into the spec. This creates redundancy that becomes out of date with the actual code in the system, and developers are instructed to ignore this.
Avoid huge amounts of implementation detail in the documentation, which someone must read and keep updated over time. Instead, talk to the developer.
Describes exactly one development, and does not contain multiple developments or developments of different types (e.g. describes both an interface and the workflow it triggers)
Content aligns with all applicable ERP Rebuild standards, and explains the reasons for any deviations where they occur.
Check that the Specification describes how the functional gap identified in SAP Standard will be addressed. For example, rather than saying ‘Users will be able to change data’, specify how they will be able to change data, e.g. ‘A UI app” will be created for users to change data’.
The specification should point to what type of artifacts will need to be created, e.g. BAdI implementations should specify the BAdI provided by SAP, etc.
Any dependency on custom data dictionary objects or new custom data dictionary objects have been identified and created. If not, the corresponding functional specification for these objects is indicated.
Authorization information (groups/objects/parameters...) are specified.
The author has not left any sections blank or with the placeholder text still showing.
Assumptions are documented clearly, and must be validated before development work starts to avoid ambiguity and rework.
Test data and test steps are to be verified by the Author before documenting in Specifications, this is to ensure that the system and configuration prerequisites are ready for development work.
Besides positive testing, negative testing will also be required to ensure Error handlings are tested properly to improve program resiliency.

General Checks

One or more Custom Development IDs have been allocated and defined as part of the Specification.
Development IDs are provided in the Specification.
A reference to the relevant process or process step within Signavio has been inserted as a hyperlink. This is important so we have traceability on which business processes will be impacted if such objects for maintainability and supportability purposes.
No spelling mistakes are present in the document, and any abbreviations are documented in the Glossary.
Formatting is neat and tidy, and presents the specification in a professional light. An inconsistent mixture of font faces, colors, sizes, etc. is unprofessional and should be avoided.
Embedded diagrams are encouraged, but the original source files used to construct the diagrams must also be included. This allows future authors to amend the diagram via the original source file as necessary. Ideally, the embedded Draw.io functionality in Confluence is used.
Dependencies on other technical objects or business processes are identified, and dependent documents and specifications are available via hyperlinks.
Key contacts are identified (functional owner, business owner, technical, etc.)
ALL config required for the process and development to work needs to be completed before development can start.

Development Type Specific Checks

Different types of custom developments introduce additional requirements to consider when writing the Specification.

Conversion

Logical Source and Target Systems are identified.
Processing Type is specified (i.e. Direct Input, BAPI, IDoc, Web Service, OData API, etc.)
Standard load program name/BAPI/IDoc is specified if one exists to support this functionality
Data Mapping is provided for mappings which are not obvious to a suitably-skilled and experienced developer
All translation requirements are clearly defined (including data validation rules, data derivation/calculation and default values, if applicable)Input and/or Output file layouts are provided for all record types possible
Transaction volume is specifiedExecution frequency is specifiedRestart/Recovery requirements have been defined
Error handling requirements are specified, including alerting requirement and expected action on failure.

Enhancement

The main Fiori app/transaction/program being enhanced.
The proposed enhancement mechanism has been provided. Please note that this can only be finalized with input from the Technical team.
Customizing requirements specified (views to be updated, etc).

Form

The author has inserted screen mock-up or actual screenshot with annotations where visual UI enhancements are needed. Forms should be specified using hi-fi mock-ups which show all of the required elements with annotations and explanations.
The process for initiating the output generation is clearly specified.
Type of output specified (i.e. to a screen for download, for Desktop printing by the user, for non-interactive direct printing).
Existing forms similar to the proposed form have been identified as appropriate, and included as samples.
Paper size is specified (A4, Letter, Label dimensions, etc).
Form layout is provided with real positions and sizes of each page.
Page format and orientation are included for each page.
Layout is harmonized with other similar forms.
The Locale of the form is specified; this will determine things such as language, date and number formats, address formats, etc.
If applicable, pre-printed form identified (a document is included with this pre-printed at real size or the pre-printed is sent by posting).
Maximum lengths are suitable for layout.
Field descriptions provided for each form field that is not obvious to a suitably experienced developer.
Standard texts to be used are defined.
Deviations from standard SAP address format are identified.
The form language(s) is indicated and is not a constant, specially if translations are required.
Form layout and translation have been provided for all (additional) languages, If any.
Special requirements (i.e. envelope, terms and conditions file, fax number generation procedure) have been clearly documented.
The printer type is specified and further considerations are not forgotten for special printer types (laser printer, dot printer, thermal printer, etc...).
The paper type is specified and further considerations are not forgotten for special paper types (continuous stationary, sticker).
Desired persons signature which are supposed to be included in form on right with necessary information and desired language must be properly mentioned.

HANA CDS View

to be completed by the Tech team during Detailed Design

Integration Process (custom)

Logical Source and Target Systems are identified.
Initiation method is specified (e.g. user action, event, incoming message, timed job, polling, etc.)
A UML Sequence Diagram should be included showing the flow of messages, whether a push or pull pattern is used, which communication links are synchronous and which are asynchronous, etc.
Data Mapping is provided for mappings which are not obvious to a suitably-skilled and experienced developer
Input and output messages are provided
Error handling requirements are specified, including alerting requirements and expected action on failure.
Defines the volumes of data being handled per invocation, the frequency of invocation, and expected execution times.

Integration Process (standard)

Logical Source and Target Systems are identified.
References, including with URL, the vendor-provided integration content that is being deployed
Explicitly calls out any modifications or adjustments needed to be applied.
Defines the process for updating the content of the integration process whenever a vendor releases an update for it.
Initiation method is specified (e.g. user action, event, incoming message, timed job, polling, etc.)
A UML Sequence Diagram should be included showing the flow of messages, whether a push or pull pattern is used, which communication links are synchronous and which are asynchronous, etc.
Error handling requirements are specified, including alerting requirements and expected action on failure.
Defines the volumes of data being handled per invocation, the frequency of invocation, and expected execution times.

Mobile App