Skip to main content

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

Comments

Popular posts from this blog

Why Madge Networks, the token-ring company, went titsup

There I was shooting the breeze with an old mate. The conversation turned to why Madge Networks which I wrote about here went titsup. My analysis is that Madge Networks had a solution and decided to go out and find a problem. They deferred to more incorrect strategic technology choices. The truth of the matter is that when something goes titsup, its not because of one reason only, but a myriad of them all contributing to the negative consequence. There are the immediate or visual ones, which are underpinned by intermediate ones and finally after digging right down, there are the root causes. There is never a singular root cause for anything but I'll present my opinion and encourage everyone else to chip in. All of them together are more likely the reason the company went titsup. As far as technology brainfarts go there is no better example than Kodak . They invented the digital camera that killed them. However, they were so focused on milking people in their leg

Flawed "ITIL aligned"​ Incident Management

Many "ITIL aligned" service desk tools have flawed incident management. The reason is that incidents are logged with a time association and some related fields to type in some gobbledygook. The expanded incident life cycle is not enforced and as a result trending and problem management is not possible. Here is a fictitious log of an incident at PFS, a financial services company, which uses CGTSD, an “ITIL-aligned” service desk tool. Here is the log of an incident record from this system: Monday, 12 August: 09:03am (Bob, the service desk guy): Alice (customer in retail banking) phoned in. Logged an issue. Unable to assist over the phone (there goes our FCR), will escalate to second line. 09:04am (Bob, the service desk guy): Escalate the incident to Charles in second line support. 09:05am (Charles, technical support): Open incident. 09:05am (Charles, technical support): Delayed incident by 1 day. Tuesday, 13 August: 10:11am (Charles, technical support): Phoned Alice.

Updated: Articles by Ron Bartels published on iot for all

  These are articles that I published during the course of the past year on one of the popular international Internet of Things publishing sites, iot for all .  These are articles that I published during the course of the past year on one of the popular international Internet of Things publishing sites, iot for all . Improving Data Center Reliability With IoT Reliability and availability are essential to data centers. IoT can enable better issue tracking and data collection, leading to greater stability. Doing the Work Right in Data Centers With Checklists Data centers are complex. Modern economies rely upon their continuous operation. IoT solutions paired with this data center checklist can help! IoT Optimi