Checklist Description

This checklist can be used to determine if all aspects of the design process have been covered. It could be used to check a bought-in methodology (e.g. SSADM, SDM, HOOD etc.), or to validate a home-grown methodology to ensure nothing has been missed.

Look at each element and examine if all the different aspects within each element have been covered by the method.

Checklist

1. Defining (the what and why):

   1. Defining the requirements (see also Chapter 3 Business analysis checklists )

      1. capture business definitions business terms, critical calculations, derived data

      2. capture prototype screens and reports and what they do (include data validations)

      3. look and feel issues use of menus, icons, toolbars, function keys

      4. may be based on old system.

   2. Defining the framework

      1. technical architecture (especially if constrained by existing architecture)

      2. user base (types of users and types of usage matrix)

      3. volumes throughput and response times.

2. Designing (the how part l):

   1. Conceptual design ( blue sky )

      1. major application functional areas and what they do

      2. major interface areas (context diagrams and system boundary analysis).

   2. Logical design (workable)

      1. Logical Data design (ERD, TNF, CLDD, Classes)

      2. Function design (Function description, Methods, Message Paths, DFDs and Process decomposition)

      3. Event design (Event lists, Use-Cases)

      4. Function, data, Event xrefs (CRUD matrix, Access Paths, ELHs).

   3. Physical design (buildable)

      1. physical data design (denormalized, indexes, SQL-Views)

      2. component/module design

         • coupling and cohesion

         • tiers

         • common modules

         • DB rules and procedures

         • transaction design

         • locking strategy

      3. on-line help

      4. security

      5. backup and...