<Bulleted list of linked major sections (first-level linked subsections may be included as well if the artifact is long).>
<Summary of the current design of the software and a detailed explanation as to why the design was chosen over other alternatives, what the other alternatives were, and why the other alternatives were not chosen.>
<Some designs may require research into what has been done in the past and what is current practice. Also, some designs may need to incorporate past or current work. Learning about what already exists enables you to build upon the work of others, rather than reinventing the wheel. You can get your work done faster and probably do it a little better. Also, if you are trying to build a better system than what is currently available, you can demonstrate that effectively by showing how it improves over past or current work.
You should summarize the past and current, similar and supporting work in YOUR OWN WORDS that pertains to your project. Your summary should include a critical analysis as to the advantages and disadvantages of the work. Your summary serves to focus the past or current work on the project work.
References that you use to show past or current work should be cited here and listed in the Reference Materials Section.>
<This diagram (note that it should be one or at most four diagrams) should show how the major system functionality is mapped through subsystem nodes or if the system is small, individual nodes (such as 15 or fewer nodes). It should show at a high level the carefully chosen subsystem nodes (possibly being for processes, data, or both) organized by similarity of function and/or data usage. It is helpful to show the data and commands exchanged between the subsystem nodes. The diagram must show how the subsystems are deployed on the target hardware. In particular, if the system is distributed, the network configuration is given.
Modeling notation that is appropriate for this diagram is at the subsystem level, such as UML package, component, and deployment diagrams. The detail of individual node function control and data flow should not appear here. Instead, a designer should be able to take, for example, one of the subsystems in the diagram and do the detailed design for it.
The modeling notation that you use for this section should be with instructor permission.
The goal is to partition the system into loosely coupled parts that can be designed as independently as possible. Keep in mind, however, that design is an iterative process which may necessitate changes in the architecture and other design portions as design proceeds and more is known about the system. Do a lot of brainstorming and keep flexible so that you do not lock yourself into one particular design when another would be better.>
<Each component in this section must have a unique ID to support cross-referencing. You will want to refer back to the appropriate ID's in this section from the detailed design.>
<The diagram in this section should show all user interfaces (screens and reports) and how they relate to each other. The relationship shown would be parent-child. If that relationship is not possible, an "order of display on the screen" relationship may be used. Other types of relationships should be done with instructor permission.
The diagram should only show the user interface names framed in boxes, the user interface names should match those given below, and the lines or arrows connecting the boxes.>
<This section shows the user interface screens/menus that will be shown as the program is running. All screens/menus should be shown including error handling screens.
The information in this section should not be repeated in other sections, but you may cross-reference back to it, such as from the detailed design.>
<The screen/menu design is shown here, not the actual screen in the program.>
<Bulleted list of component descriptions including format of inputs and outputs.>
<Bulleted list of errors that can occur with the screen and how they are handled. If error displays are shown, make a cross-reference to them in this document, do not show them again.>
<...>
<The report design is shown here, not the actual report in the program.>
o Individual Recall Score = Number Right / 0.1
o Efficiency = Individual Recall Score / Average Recall Score for college students
o If Efficiency > 1, set Efficiency = 1.
o If Efficiency <= 0.5, recommend professional assessment
<What are the hardware devices, function keys, or other means that the user will employ to communicate with the software.>
<...>
<If data structures, files, or databases are to be used, then describe them here.
The information in this section should not be repeated in other sections, but you may cross-reference back to it, such as from the detailed design.
Entity relationship diagrams from the requirements document should be converted into the data structures, files, or databases that will actually contain the data. All sizes, formats, and estimated/actual data quantity should be given.
The format below must be used with the <ID> field to support cross-referencing.
<...>
<...>
<...>
>
<This section details the external systems and their interfaces that will be used with the system designed in this document. Examples of external systems are database or other servers, COM objects, other programs (even dll's that are specifically written or purchased for the application) commercial-off-the-shelf systems, other programs, credit card systems, and the like.
The information in this section should not be repeated in other sections, but you may cross-reference back to it, such as from the detailed design.
The format below must be used with the <ID> field to support cross-referencing.
<Describe in detail the purpose of the external system, why it is to be used, and what the external system will provide to the software system designed in this document.
Organize the subsections below that describe the actual interface to the external system by function.
Describe in detail how the interface is to be used from the software system to connect to the external system. Show function names, types, and parameters if applicable or whatever is used to connect to the external system. In all cases, expected input and output should be given along with time delays or problems that could occur and what to do about them.
If the external system has a specific language by which it communicates, be sure to document where its language description can be found (the reference should be given in the references section and cited here). If the language is small, such as 20 or fewer commands, then it may be detailed here.
<...>
>
<This section of the Design Document is organized by the subsystems given in the System Architecture Section. It addresses all levels of abstraction of the system.
The design modeling notation that you use should be with instructor permission.
All algorithms, units, modules, subsystems, classes, etc., are specified in detail. How the software interacts with external systems will be given here. If data structures, files, or databases are used, it will be given here how the software interacts with the them. How the software interacts with the user interaction components is also given.
Special attention should be given to issues, such as performance, error handling, fault tolerance, failure recovery, efficiency, and the like.
It does not repeat the material of other sections in the document, but instead cross-references to them.
All components in the detailed design must have an ID to support cross-referencing. >
<A diagram of the components of this subsystem must be given and how they relate to each other.>
<A detailed description of the component must be made with the instructor approved modeling notation. This may include showing control and data flow, communication with other components, and other portions of the instructor approved modeling notation.
At any level of the detailed design, if a subsystem is broken into other subsystems or component parts, make a diagram of those subsystems or component parts and how they relate to each other. Then go into the detailed design of those subsystems or components.
If a component communicates or interacts with a medium to large number of other components, then a diagram should be shown of how that interaction occurs.>
<...>
<A unique ID must be given to the components in this section to support cross-referencing.>
<A precise, bulleted-list description is given here of the development platform to be used. This includes software and any other special needs.
<A precise, bulleted-list description is given of the client's delivery platform. This includes software and any other special needs.>
<Reference materials used to write the design document and cited in the text. These should be listed here in an organized and appropriate bibliographic format.>
<List of items to be completed in THIS artifact.>
| Items |
<List of issues that the design team has with the requirements or how the design differs from the requirements.>
| Items |
<List of issues/questions needing to be resolved by other team members. Should be organized by receiving team member and within that by reverse chronological order.>
<Table showing the cross-referencing of design to requirements. Each requirement and subrequirement along with use cases must be listed and made to correspond to all individual design elements listed in the User Interaction, Data Storage/Format, Detailed Design, and Implementation Platform Sections.
Table entries are given below.
| Requirements Component | ID | Design Component | ID |
| Date | Name | Revision |