Karmona's Pragmatic Blog

Don't get overconfident… Tiny minds also think alike

Karmona's Pragmatic Blog

High Level Design Review Check-List

December 12th, 2009 by Moti Karmona | מוטי קרמונה · 2 Comments

This is my recommended check-list for high level design review.

  • Reverify your Requirements //Keep it simple and make sure it answers all the requirements!
    • Functional specification, use cases and requirements are clear and publicly documented
    • Technical Requirements
    • Performance requirements
    • Security requirements
    • Resources (CPU, Memory, Storage, IO) consumptions limits
    • Audit requirements
    • Out of scope – What does the component NOT do? What NOT support?
    • Future extendibility of the component (options for future extension, generic features etc.)
  • High Level Design
    • Main components involved
    • Main Data flows
    • Components and sub-systems and how they relate to the component
    • Which sub-systems does it communicate with (e.g. Relation Façade)
    • Communication mechanisms (e.g. HTTP, WCF)
    • Which subsystems it is dependent on (e.g. Database, Gigaspaces) – What are the requirements?
    • Which sub-systems depend on it (e.g. App.) – What is the expectation?
  • Architectural Strategy
    • High availability and load balancing
    • Error detection, fault and recovery
    • Logging and statistics gathering
    • Capacity limitation, planning & resource management:
      • Memory consumption and management policies
      • CPU usage management
      • IO requirements
      • Storage requirement
  • Technical Assumptions
    • Limitations
    • Compromises
      • What does this design compromise? (Security, high availability, capacity, performance, quality…)
      • What are the engineering tradeoffs of this design, and why was the current design chosen?
    • Risks and weak points
  • Operation
    • Backward compatibility
    • Logging and Monitoring
    • Administration issues
    • Deployment issues:
      • How to deploy (e.g. can it be part of the regular release package?)
      • Required downtime?
      • Deployment risks?
      • Rollback capability
  • Testing strategy
    • What to focus on (80/20)
    • Functional test plan review
    • Deployment, environments, and setups
    • Fault and recovery
    • Load and capacity planning
  • Execution plan (phases, timeline, milestones, critical path, dependencies etc.)

 

Please comment if you think I  forgot something…

Tags: Development · Software

2 responses so far ↓

  • 1  Gadi // Dec 13, 2009 at 7:46 pm

    Very comprehensive list! One thing I do feel is missing, however, is prioritization (of the features being reviewed, not of that list…). I think it’s important to have the features to be implemented prioritized by the design review time, as this will at least mean someone had given thought to what’s more important in the feature to be designed and implemented, and can also give context to the other parties involved (QA, Operations, etc.), guiding them where to focus and what to attend to first (and hopefully saving precious DR meeting time of arguing on the lowest priority aspects in the feature list).

  • 2  Moti Karmona | מוטי קרמונה // Dec 22, 2009 at 8:26 pm

    You know it is very hard for me to admit but I think you are right… ;)

Leave a Comment

Allowed tags <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>