The IDABC Technical Design Checklist

This is a checklist for Technical Design from IDAC (Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens).

This checklist can be applied within the context of an Information Technology project where a system or set of software is being designed to met business requirements.
  • Introduction - provide an overview of the document and a description of the scope of the system and its intended usage
    • Purpose – purpose and intended readership of document
    • Scope – identify products to be produced; explain what the system will do; define objectives and benefits
    • Definitions, acronyms and abbreviations – include or refer to external glossary
    • References – list applicable and reference documents
    • Overview – describe structure of document
  • System overview- briefly introduce system context and design, and discuss background to project
    • System characteristics – Summarise architecture of system. Set system context by describing high-level data flows through external interfaces
    • System architecture – describe system architecture in more detail
    • Infrastructure services – describe how common services (e.g. security, audit, performance monitoring and reporting) will be used, and whether the specific development will contribute to new infrastructure services for re-use
  • System context - define all external interfaces. Include a system block diagram or context diagram
  • System design - should provide sufficient information for a developer to produce the system
    • Design method and standards – name and reference design method to be employed. Explain and justify deviations and extensions
    • Documentation standards – for software, include standard module and instructions for its completion. Make recommendations on approach to commenting
    • Naming conventions – for files, programs, modules and other structures
    • Programming standards – define (or reference) project programming standards. Specif ic points include modularity and structuring, headers and commenting, indenting and layout, library routines, language constructs to use and avoid
    • Software development tools – list tools to be employed for, e.g., application development, configuration management, HTML authoring, word processing, diagram drawing, testing
    • Outstanding issues – list unresolved design issues. Include options for resolution, their pros and cons, and their impact on the design
    • Decomposition description – summarise software components in structure charts or object diagrams
  • Component description - should provide sufficient information for a developer to produce the system. Descriptions of components should be laid out hierarchically. Each component should be uniquely identified, and described in terms of
    • Type – e.g. task, subroutine, subprogram, package, file
    • Purpose – Trace component to the requirement(s) it implements
    • Function – A short description of what the component does. (A fuller description is included in Processing)
    • Subordinates – Modules that are “called” by the component
    • Dependencies – e.g. operations that take place before or after the component is called, operations excluded when component operation is taking place
    • Interfaces – Specify control flow (how component is to be started and stopped) and data flow (input and output)
    • Resources – Itemise what the component needs from the environment to perform its function
    • References – Full references to other material which forms part of component description
    • Processing – Define processing by summarising control and data flow within the component. State or reference specific algorithms to be employed
    • Data – Define data internal to the component, including, for each element description relationships with other the elements range of possible values initial values
  • Software requirements traceability matrix
    • Include a table to summarise how each requirement has been met in this document. Tabular format permits one-to-one and one-to-many relationships to be shown
  • Document control
    • Document control, signoff and change record