The checklist for capture of requirements is as follows:

• The application offers a mechanism to facilitate extension of core capabilities by the vendor or end organisation
• The system responsible for persistence is governed by an entity model. The entity models are extensible to allow the modification of entity types or the creation of new entity types to match business needs.
• The application accountable for data processing is governed by a engine or model. The engine is extensible to facilitate refinement of existing processing rules or creation of new rules to match business needs.
• The information processed, derived, stored, and leverage is documented in an model and also includes the relationships between information types.
• There is a set of processes to control the extension of entities, rules, and information types to ensure business continuity
• There is a current state business process model describing how people, technology, and processes collaboratively work together to meet organization needs. This process model will be leveraged in planning, POC, and rollout of future changes to processes.
• Do all entity interactions take place via well-defined connectors and interfaces?
• Do the entities exhibit an appropriate cohesion level?
• Do the entities exhibit an adequate level of coupling?
• Are relevant business scenarios identified and leveraged to validate the applications behaviour?
• Is the functional coverage of the architecture assessed to ensure it meets its busness requirements?
• Has consideration been given as to how the architecture will cope with change scenarios in the future?

The checklist for architecture definition:

• Will the operations team be able to monitor and control the application landscape in a production environment?
  
• Does the backup technique ensure integrity of restored data?
• Does the backup technique support taking online backups, with acceptable degradation in performance?
• Will the system be able to respond gracefully to errors and exceptions, logging and reporting them into the management and monitoring solution?
• Is a standby site in the DR plan defined? Is the standby site identical to the primary site, or does it offer reduced performance?
• Has the impact of an availability solution on functionality and performance been assessed?
• Has the architecture been assessed for single points of failure and other bottlenecks?
• Do the fault-tolerant guidelines extend to all vulnerable entities in the landscape?
• Are standards, frameworks, and best practice for development established (for example, scheme techniques, programming, database approach, user interfaces)?
• Are the programs parameterized?
• Are logical values leveraged instead of hard coded values?
• Is it possible to modify input, control, processing, and output functions in order to change a way of work?
• Is it possible to configure menu structures?
• Is it feasible to set up the contents of the input screens?
• Is it feasible to set the layout of the input screens?