Software Design Document (SDD)

As also noted in our project overview document, the Software Design Document includes a more detailed system description than in the SRD; [including] (1) an architectural design showing the system architecture (e.g., major application systems or sub-systems, client-server relationships, and GUI) and related external elements (e.g., files, networks, cooperating applications or services, databases, concurrent processes, and user groups or agents); (2) a GUI design showing how the user interface is expected to appear and function (which could include flowchart-type diagrams indicating the main processes supported by the user interface), (3) a component-level design showing the application decomposed into the object classes, or functional decomposition, for the GUI, application functions, data storage, and support functions.  Also, as indicated in our discussion on Software Design the diagrams in the SDD are to provide successive refinement in detail in preparation for implementation.  With these thoughts in mind, here are a few principles to apply and suggestions for content as your develop your document.

SDD Principles:
bullet Begin by thinking about what data your application needs:  what information is presented, consumed, produced or transformed?  Does the data need to be created or sensed or does it already exist (and where)?  Does the data need to persist beyond the execution of the application?  If so, then some type of database or file system is probably required.  Also consider how the data will be represented internally while the application executes:  will it be in a persistent store or in-memory data structure?  Is the data streaming from some source (e.g., sensors or users events)?  Although we want to characterize the data at this point, its actual representation (data structure or encoding) does not need to be fully elaborated yet.
bullet Next, look at the list of elements in the description of the system architecture above.  Which of these elements belong to the context of your application?  How are they related (what information do the elements exchange)?  Are some elements core functional objects, supporting or supervising?  Do they collectively implement some process, provide some capability, represent some object, manage some data?  Can any elements be grouped into related functional areas?  Answers to these questions will help determine the overall system architecture.
bullet Consider your user stories from the SRD.  What objects (nouns) are actors in these stories (these could likely be component classes in your design) and what actions (verbs) are the actors taking (these are the methods of the classes) and what messages (information) do they exchange (these are the attributes and interface parameters)?  Are there any constraints in the stories (i.e., in capability, range of data, performance, host environment, etc.)?  Are there any sequences of operations or processes?  If so, are the processes required procedures are notional?
bullet Refine the user interface(s) you described in the SRD.  How will you implement the interface controls:  typical windowed GUI, hardware switches and displays, web interface, or something else?  Should your application objects (or functions) be called directly from the interface or managed by some supervisory class?  Perhaps you should build a UI prototype at this point to experiment with your ideas.  As a minimum, you should create some diagrams to help others envision what the interface might look like.
bullet Continue to refine your diagrams and class (and function) descriptions, adding support and utility classes and suitable data structures and algorithmic word descriptions until you feel confident that you have a good enough problem understanding to begin writing code.  If you're not sure whether your environment supports a capability or a manner of operation, then implement a prototype (a "spike" solution or a proof-of-concept) to test your ideas.  However, don't allow yourself to spend too long on "research" without returning to design.  That is, you want your design to guide development--not the other way around.

SDD Content:  Please include as a minimum the following in your document:
bullet Project Introduction:  Identifies team, project purpose, application overview:  these words can be the same taken from your SRD simply to provide minimal context for the reader.
bullet Design Introduction:  Provide any lead-in comments which provide a context for and help your reader understand your design ideas.  For example, indicate if you are using a unifying metaphor for the design, or a particular published pattern or architecture.  If it helps to reiterate what business function the application is trying to accomplish, then do so here.
bullet Design Viewpoints
bullet Data Description - defines what data the application uses, transforms, or produces and how that data is acquired and stored.  Be careful to address all your data (e.g., business data, configurations files, user-generated data and profiles, sensed data, events, transformations or calculations, etc.), not just the obvious (which would generally have been identified in the SRD).  As you address the data, indicate which processes, objects, sub-systems, components, users, or sensors produce, transform, or consume the data.  That is, put the discussion of the data in context of the application.
bullet Architectural Design - indicates major sub-systems or components of the application and their relationships with one another.  This top-level diagram can be taken from your SRD (with possibly some minor elaboration).
bullet If the application contains distinct components (i.e., not a single executable), then your architecture design should include at least one diagram showing how the application will be hosted on the target system.
bullet GUI Design - elaborates on the GUI presented in the SRD by showing new detail (e.g., additional screens or sub-menus, UI class decomposition, more detailed layout of interface objects, actual screen shots of UI, etc.) The design may also be represented by a prototype. 
bullet Component Design - The reason for your project is to build an application that serves some primary function.  How your application's classes, components, interfaces and algorithms operate on your data to accomplish that primary function is the nexus of your design.  The component design is your strategy for assembling the various parts of your application to solve the application problem.  Therfore, is this section you want to use text and probably several diagrams to communicate to the reader how the various components (i.e., classes, processes, functions, and data flows, etc.) are assembled (i.e., how the collaborate) to realize the application's capability.