There are many decisions to be taken when designing a system, regarding usability, features, performance and others. Unfortunately, many design decisions are taken without realizing the results for the complete lifecycle of the system. Here are 15 questions on system design to be a reference checklist. The additional question is on a different plane, but important nevertheless.
- Design to goal –Is the goal of the system understood? How the goals reflect of the decisions taken? The rest of the questions try to identify the different options in regard to the goals of the system.
- Flexible – Is the system flexible? Can the design adapt to the changing needs, especially when the time between writing the first requirements and deploying the system can be long?
- Efficient – Does the system effectively use the budget effectively? In time of shrinking budgets, efficiency to lower deployment costs is important.
- Modular – Is the system modular? Can it be expanded or scaled to fit? Modularity also helps in other questions here, but being modular can be a valid requirement.
- Coherent – how many high availability methods are used? Is the same configuration used? In a complex system, reusing ideas and concepts is important for deployment and maintainability.
- Robust – is the system capable of handling abnormal situations? What is the capability of the system to recover and continue normal operation after such events?
- Maintainability – Is the lifespan of the system known? The longer the life span of a system after the deployment and commissioning, maintainability becomes more important.
- Absences of defects – How many defects are? defects are design errors that limit the system for the goals defined. Such defects must be avoided as the end result is a system that does not fulfill the goals.
- Absence of bugs – What is the bug count? The phrase “there is always one more bug” is true for any non-trivial system. The importance is the separation between bugs and defects. are defects there is no system, but the bugs should be limited to bugs that are not defects.
- Secure – Is the system secure? Is the system resilient to external attacks while keeping information from leaking or being too accessible? In contrast, is the user able to access the required information with relative ease?
- Documentation – What is documented in the system? The documentation should provide the reasoning and why decisions were taken, so future people handling the system can comprehend the system and be able to perform the required changes.
- Recoverability – In event of failure, what is required for bringing the system up and running? What is the data loss?
- Redundancy – what is the high availability scheme? Active-active, active-standby or cold spare?
- Testability – how can the system be tested? Component testing is good, but complete system testing isn’t easy.
- Predictable – Are the performance and stability figures predictable? What happens if the system needs to scale up or down?
+ 1 Human – is the system human? At the end every system has interaction with a human being, so special care must be taken into making the system human, this is especially true in service systems, as explained in this article
If you read this far, you should follow me on twitter here.