...

• 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.

...

...

...

...

...