Introduction – Tell briefly about the purpose of the application.
Acronyms – Define this first to avoid confusion.Current version and version control
Application scope & namespace.
Naming conventions – are there any standard regarding naming of tables, scripts, update sets and other business logic?
Source control – Where are the latest builds of the application hosted and how can it be accessed? Could be update-sets in subprod environment but could also be a GIT repository for example.
User roles and entry points – Which user roles can access the application and do they access it the same way? An end-user might be seeing error messages in another user-interface than the administrators using the application natively in the back-end. Including screenshots or URLs might be a very good idea.
Service Accounts – do the application depend on a specific account for integrations, web services and so forth?
Business Logic Flows – I don’t want to review 25 business rules and try to reverse-engineer their purpose for every table. Include picture of flows in how functionality is being invoked and what the dependencies are. Process design but from a purely technical perspective. Even something created in Powerpoint can save a lot of time.
Field definitions – what means what?
List of the most critical- Important scripts and their purpose.
List of tables created – Extensions, prefixes, if table rotation is active, auditing turned on etc.
List of business logic created – Names of business rule, client scripts, UI policies- and actions, script includes etc. Briefly explain their function. One or two sentences is useful enough. Include every record created which can be defined as business logic relevant to the application.
List of views
Security (ACL, user criterias, other security) – Who is supposed to see what
Integrations or external sources – Direct REST calls, a MID-server or maybe a direct LDAP listener? Could be many things.
Data-sets and imports – What are the format of the data, which dependencies does it have, what are the transform rules, how often do the imports run?
Application dependencies / plugin activations – Sometimes your custom application might depend on or feed other applications. Things which might be unique to the application such as sensors and patterns for discovery, event- and alert rules for Service Mapping and so forth.
Application owner – Which team, person or department and the contact details.
Additional resources – Perhaps more functional examples exist in a knowledgebase or wiki, there are more documentation available, more documents.
