Contents

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. Where a section is not applicable, it must be explicitly marked as such. 
• 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, except for Conversion Specifications which use the number assigned in the master data register. 
• 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.).
• Security is important and needs to be detailed by providing standard or required custom authorization objects.
• ALL config required for the process and development to work needs to be completed before development can start.
• Label for Pod and Release to be assigned to the spec in Confluence.
• Test cases need to be maintained in detail, like positive, negative tests and expected result.

Development Type Specific Checks

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

Application Job (custom)

Conversion

Enhancement

Form

HANA CDS View

Integration Process (custom)

Integration Process (standard)

Mobile App

Modification

Program

Report/Analytics

System Interface

User Interface

Workflow (custom)

Workflow (standard)

How to find the right specification template

Below table details the Scaffold Specification template needed per the Development Id's Type of Development.

How to create a specification using the template can be found here: Creating Functional Specifications