Department of Computer Science
Software Design and Development COMP 566
This document is largely borrowed from a similar document used at the University of Texas at Austin in teaching the software-engineering course and the adapted version from one of my Professors from Saint Joseph’s University (now at Standford).
I am citing one other document here from the scholars.google.com search where I was looking to see some more detail to the architectural design. This template was the closest to ours and also gives you guys the freedom to use more than one template. You can feel free to make a hybrid document too. The major differences I see are that the “ Architectural Strategies” section that is not included in this template and hence making it different. I like the details described and I strongly urge you to read through both of these documents before you start writing your SDS. http://www.cmcrossroads.com/bradapp/docs/sdd.html
Remember that the design specification has as its primary audience the developers/coders who will implement the design and the testers who will need to verify that the software does do what it is supposed to do, and does not contain errors. The SDS has several goals: to facilitate full understanding of the problem being solved, to decompose the problem into appropriate parts, and to provide a high-quality basis for the implementation phase.
The following content suggests a reasonable organization for the Software Design Specification. 1. Introduction
1. Purpose of this Document
This section should contain a full description of the main objectives of the SDS document. 2. Scope of the Development Project
This will be similar to what was written in the SRS.
3. Definitions, Acronyms, and Abbreviations
Please alphabetize! This should be the same as what is in the SRS with any necessary additions. 4. References
This section will include more technical books and documents than was probably included in the SRS. At a minimum, this should reference the SRS! If you reference a web site, you should include references to the exact pages that you used, not just to the name of the site. For example, www.yahoo.com is not an ok reference as this does not specify exactly which page(s) was/were used. 5. Major software requirements
6. Design constraints, limitations
7. Changes to requirements
It is likely that you will have decided to add/change/delete various requirements. If this were the real world, you would need to get all sorts of approvals to do this. But, what I would like you to do here is (after discussing with me your specific modifications to your SRS to get my approval) to list all of your requirements modifications, along with a reason that justifies that modification. In this section, you should list: 1. the original requirement (or write none if this is a new requirement), 2. the change to that requirement, and
3. the rationale.
8. Overview of Document
This should include a short description of how the rest of the SDS is organized and what can be found in the rest of the document. This is not simply a table of contents. Try to motivate the various parts! 2. Data Design
9. Data Objects and resultant data structures
10. File and database structures
4. external file structure
5. global data
6. file and data cross reference
3. System Architecture Description (This is your architecture design.)
This section is very important! This is where you will focus much of your energy. This should give a good view of exactly how your solution is to be organized. I would suggest using the text as a guide in helping you to develop your system architecture diagrams. The diagram(s) should be included, either in this section or as a referenced...