Typically all design decisions (high-level-design) are written on the Software Architecture Specification (SAS) which is commonly a deliverable.
The pertinent milestone is called the Critical Design Review (CDR) unless you have provided the customer with a SAS V1 on PDR. If you did so, you'll probably end the CDR with SAS V2. If not you'll be releasing a SAS V1 apar with the code (and the binaries needed for deploying the system on a testing environment, for the next phase, the Validation Phase).
In some QMSs, some part of the design and the code are performed in the same phase (so that if you spot a need to change de design during the code, you are still able to change it).
Other Design Documents
Sometimes customers will ask for a Software Detailed Design (SDD is a kind of a programmer's manual that describes all source files contents including for an OOP language all classes, including data members, operations, interfaces and the algorithms being implemented in those source files). If possible, align the team with the proper coding conventions and comments to be produced aling the code, in order to be possible to reverse engineer te code to a modelling tool (that enables you to build in a faster way the SDD document). Sometimes this document is called Detailed Design Description.There are also special documents called Interface Control Documents (ICD) that come specially handy when you need to establish communications (data flows in and out) with external systems. These could be described in a section in the SAS, or sent to a separated ICD document (if you want to share just the interface control part to external departments and/or companies).
Database specification documents (DBS) are also considered detailed design documents and are typically generated from data modelling tools (or reversed engineered to a model and then to a document) for publication (to the customer, to the developer/maintenance teams).
This is where you want to define key technologies to use (what DB Server, what Application Server, what OS) up to the version if needed and the last great opportunity to think on reuse (COTS components, open source components, in-house components, etc.)
Main Activities (SW Design)
Mainly we'll be doing:- Architectural requirements (completing the requirements catalog with non-functional - or other organizational and even functional - requirements); Architectural Requirements are a subset of the user, system and software requirements, determined by architectural relevance.
- Architecture specification:
- Defining the meta-architecture options: principle, style, key-mechanisms
- Defining the conceptual architecture: Partition system, allocate responsibilities
- Defining the logical architecture: Model collaborations, design interfaces
- Architecture Validation: As in all things in life, we'll be peer reviewing the SAS document, and before that, we'll be brain-storming key decisions and thinking on Reuse (remember to use DAR).
You can find the process definition here.
For a good online resource on architecting remember to look at the The Visual Architecting Process (VAP, by Ruth Malan and Dana Bredemeyer, 2002)
