Software Design Goals
Jakob Jenkov |
As mentioned in the Software Design Introduction - software design is typically attempting to achieve certain functional and structural design goals - as illustrated in this diagram:
The functional design goals are typically derived from the operational goals of the organization developing the software. Thus, the functional goals tend to be very project specific.
The structural design goals, on the other hand, tend to come from a set of general non-functional goals the organization has, and tend to be more similar between projects.
Software Design Goals Tutorial Video
If you prefer video, I have a video version of this tutorial here: Software Design Goals
Root Software Design Goals
The root software design goals tend to be quite similar across projects and organizations. The most common root software design goals are:
- Functional Goals
- Non-functional Goals
- Software Quality
- Development Speed
- Development Cost
- Operational Cost
- Other Goals
- Legal Requirements
- Personal Goals
- Other Goals
Here are the same software design goals illustrated in a diagram:
Derived Software Design Goals
Below the root design goals there exists several levels of derived software design goals. I have drawn a diagram of derived design goals here:
This is not a complete list of all derived design goals. This diagram just attempts to give you a feeling about how these commonly occurring derived design goals relate to the root design goals.
Trace Design Decisions Back Up to the Root Design Goals
Whenever you make a design decision I believe you should be able to trace that design decision back up to the root design goal you are trying to achieve. For instance, if you spend time trying to come up with more saying variable names, you should know why. Similarly, if you split a big method into smaller methods, you should know exactly why you are doing it - meaning what you are hoping to achieve by doing so.
This diagram shows an example of tracing your design decisions (blue boxes at the bottom) back up to the root design goals:
Design Decisions are Trade-offs, Remember?
As I have mentioned in my Software Design Introduction, all design decisions are trade-offs! Thus, when you attempt to achieve one design goal, you might have to give up achieving another design goal.
For instance, by spending time coming up with good variable, method and class names, you might slow down development speed here and now, but gain development speed in the future because the code is now easier to read, and thus easier to maintain and extend.
| Tweet | |
Jakob Jenkov | |
