After you know the project’s requirements, you can start working on the high‐level design. The high‐level design includes such things as decisions about what platform to use (such as desktop, laptop, tablet, or phone), what data design to use (such as direct access, 2‐tier, or 3‐tier), and interfaces with other systems (such as external purchasing systems).
The high‐level design should also include information about the project architecture at a relatively high level. You should break the project into the large chunks that handle the project’s major areas of functionality. Depending on your approach, this may include a list of the modules that you need to build or a list of families of classes.
For example, suppose you’re building a system to manage the results of ostrich races. You might decide the project needs the following major pieces:
- Database (to hold the data)
- Classes (for example, Race, Ostrich, and Jockey classes)
- User interfaces (to enter Ostrich and Jockey data, enter race results, produce result reports, and create new races)
- External interfaces (to send information and spam to participants and fans via e‐mail, text message, voice mail, and anything else we can think of)
You should make sure that the high‐level design covers every aspect of the requirements. It should specify what the pieces do and how they should interact, but it should include as few details as possible about how the pieces do their jobs.
To design or not to design
At this point, fans of extreme programming, Scrum, and other incremental development approaches may be rolling their eyes, snorting in derision and muttering about how those methodologies don’t need high‐level designs.
Let’s defer this argument until Chapter , “High‐Level Design,” which talks about high‐level design in greater detail. For now, I’ll just claim that every design methodology needs design, even if it doesn’t come in the form of a giant written design specification carved into a block of marble.
After your high‐level design breaks the project into pieces, you can assign those pieces to groups within the project so that they can work on low‐level designs. The low‐level design includes information about how that piece of the project should work. The design doesn’t need to give every last nitpicky detail necessary to implement the project’s major pieces, but they should give enough guidance to the developers who will implement those pieces.
For example, the ostrich racing application’s database piece would include an initial design for the database. It should sketch out the tables that will hold the race, ostrich, and jockey information. At this point you will also discover interactions between the different pieces of the project that may require changes here and there. The ostrich project’s external interfaces might require a new table to hold e‐mail, text messaging, and other information for fans.