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
The Essay on Manage Business Document Design & Development
1. Consider this scenario. You and four friends have developed a new environmentally friendly heater. You all have extensive business experience. Together, you have established a new company, Green Heaters Pty Ltd ACN 512 302 XXX, which will manufacture and sell the new heater to wholesalers. The five of you will comprise the board of directors. The board has forecasted that Green Heaters Pty Ltd ...
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 Appendix at the end of your SDS.
The Term Paper on Software Requirements Specification On E-Library
... other external systems. These requirements should include at a minimum a description of every input (stimulus) ... Provide a complete list of all documents referenced elsewhere in the SRS (2) Identify each ... machines and/or operating systems. This may include: Percentage of components with host-dependent code Percentage ... to organize requirements you write in section 3.2. At the end of this template there ...
11. Overview of Modules / Components
This subsection will introduce the various components and subsystems. You do not need to be too specific. You wish to give each module’s name and a brief description of its functionality (what it does).
12. Structure and relationships
A structure chart of some sort can be useful here. If you build the architecture design as described in Chapter 14, you may wish to include it here. There should be explanatory text to help the reader understand your charts/diagrams.
4. Detailed description of components (This is your procedural design.) 13. Component template description
List the points you will use in subsections 4.2-4.n. For your recollection, a template is a form with none of the fields filled out. Below I include a sample template. The purpose of a template is so that I can see the format of how each of your modules will be described.
Give a label and briefly explain the purpose of that point. Use a table or bullet list to make this presentation clear. You may simply decide to use the suggested template given below. 14. Description of component #1
Use exactly the template you define in 4.1. If a part of the template is not applicable for a given module, then mark it N/A rather than omitting it. 15. Description of component #2
16. Description of component #3
. . .
n. Description of component #(n – 1)
5. Interface Design
Here, you will present the modified description of your panels/frames/pages. You will want to include some discussion for each one. It is fine to refer the reader to the user’s guide for interfaces that have not changed. If you choose to refer the reader to the user’s guide, you should probably give me a zipped version of the user’s guide so that I can put it out on the web, and your evaluators may access it.
SDS component template
Each component described in Part 4 of the SDS must be thoroughly described. The template given below suggests a reasonable structure for the information to be given for each component. The specific information depends to a great extent on the design approach, so your team must customize and describe the template in section 4.1 of your SDS.
The Term Paper on Input And Output Devices And Computer Components
The purpose of this paper is to answer questions about various data input and output methods, various storage types and devices, and the speed of a computer. Each of the four questions is divided into a corresponding section below. In the input device section, this paper focuses primarily on user input, rather than the input devices used to extract information entered by a user. In all of the ...
Identification
The unique name for the component and the location of the component in the system. (You may want to include a reference to which part of the architecture diagram this component belongs.)
Type
A module, a subprogram, a data file, a control procedure, a class, etc.
Purpose
Function and performance requirements implemented by the design component, including derived requirements. Derived requirements are not explicitly stated in the SRS, but are implied or adjunct to formally stated SDS requirements. This is where you explain the connection of this component to some requirement(s) as specified in the SRS.
Function
What the component does, the transformation process, the specific inputs that are processed, the algorithms that are used, the outputs that are produced, where the data items are stored, and which data items are modified.
Subordinates/ Modules used
The internal structure of the component, the constituents of the component, and the functional requirements satisfied by each part.
Dependencies
How the component’s function and performance relate to other components. How this component is used by other components. Include the other components that use this component. Interaction details such as timing, interaction conditions (such as order of execution and data sharing), and responsibility for creation, duplication, use, storage, and elimination of components.
Resources
A complete description of all resources (hardware or software) external to the component but required to carry out its functions. Some examples are CPU execution time, memory (primary, secondary, or archival), buffers, I/O channels, plotters, printers, math libraries, hardware registers, interrupt structures, and system services.
The Essay on Functional and Non-functional requirements
... its component. A function is described as a set of inputs, the behavior, and outputs . Functional requirements may be calculations, technical details, data manipulation ... by just asking them what the system should do. Requirements elicitation practices include interviews, questionnaires, user observation, workshops, brainstorming, use cases, role ...
Processing
The full description of the functions presented in the Function subsection. Pseudo-code may be used to document algorithms, equations, and logic.
Data
For the data internal to the component, describes the representation method, initial values, use, semantics, and format. This information will probably be recorded in the data dictionary.
