DESIGN AND TEST PLAN DOCUMENT ASSIGNMENT
Part A: Design Plan
The following is a template for a Design Document. Feel free to add to this template as you see fit. Remember this is only a template to give you an idea of what a design document should contain. The design document is the document that programmers will use to know how to implement the system. Thus, the design document needs to be clear on how your system will be implemented as opposed to what it is supposed to do This is handled in the requirements document that you completed in the previous assignment.
What is Needed:
.
[Project Name] Design Document
[Document Version Number]
[Date]
[Author]
1. Introduction: Provide a brief description of the purpose of this document
2. Project Scope and Description: This section is similar to the Project Description but add a little more info.
3. Related Documents: Any other documents you used during the development of the design document.
4. System Overview: Provide an overview of the system in this section, detailing the subsystems and modules of your system design.
5. Design Description: This section presents the architectural design of your system. Choose at least three of the following diagram to use to describe your system You must draw these items using a UML diagramming tool such as Visio
. •Data Flow/Structure
•Sequence Diagrams
•Class Diagrams
•Context Diagram
•Activity Diagram
•Etc.
6. Subsystem and Module Specification- Specify the design for each subsystem and module in your software system. All functions should be described in detail. (Detail means providing a brief description of the subsystem and more detailed information about the modules including a processing narrative, a description of the
interface(s) associated with this module, references to other modules used by this module, any data structure internal to the module and any additional information
(comments, restrictions or limitations) about the module. Feel free to use diagrams in this section to help describe the subsystems/modules. Very high-level, English- like pseudocode is fine -- this does not need to be specified in a programming language. In other words, your class diagrams describe the classes in the system. This section should tell the reader what those classes do and what other classes they collaborate with to accomplish their goals.
7. File Structure and Global Data- Describe any information pertaining to database requirements and the types of data that will reside in the database. (Identify data, describe organization of data, specify types of data, note any constraints or valid/invalid ranges of data and any other information you might deem important! This data might be data maintained in a file, database or in common memory.)
8. Interface Design- Human - Machine Interface Specification For example:
•GUI designs
•External Interface Design
•Interfaces to External Data
•Interfaces to External Systems or Devices
•Internal Interface Design Rules
•Rules that specify how modules, functions, methods, etc. interface with other modules, functions or methods.
9. Requirements Cross Reference- List any additional/changed requirements which are identified during the design process. Also provide a cross reference of design to the requirements in the requirements document to show that all the requirements are being met by your design. Discuss any requirements that are not
fulfilled by the design.
10. Document Revision History- This section includes a list of significant changes that have been made to this document after 1.0version has been submitted for assessment. The revision history should contain a dated list of revisions to the document consisting of: the date of each change, the person responsible for the
change, and a description of the change. You should be able to trace changes to the individual who completed the modification. Changes are to be listed in reverse chronological order, recording the following information for changes:
•Version File - version number.
•Name(s) - Name of individual(s) responsible for the change.
•Date - Date of change.
•Change Description - Description of the changes made to the file.
Part B: Test Plan
The test plan will cover how you plan to test the system. You will not actually build the system, but you will outline a test plan for the system as if you were to build it.
Here are the sections and information that needs to be included in this document:
•Introduction: This section will include a discussion of:
O The overall strategy and scope of the testing for the system.
O How you will accomplish the validation and verification of the system.
O This section is worth 15 points
•Testing Methodology: This section will include a discussion of:
O The different types of testing needed to completely test the system and why
O The exit and entrance criteria for each type of testing specified. (How do you know when you can start a new type of testing and
When a testing type is complete.)
O Determination for the completion of testing and determining when the product is ready to be released to the customer.
O Consideration for what should happen when testing goes badly
O This section is worth 35 points and will be assessed based on the completeness of testing without over-¬-testing and consideration for how the process works.
•Test Cases: This section will outline test cases for each type of testing.
O You will have 3 test cases detailed for each of the types of testing you specified in the second section.
O Each test case will clearly indicate a pass/fail criteria
O This section is worth 35 points. Test cases will be evaluated by their appropriateness to the type of testing specified.
• Risks/Issues: This section will cover the risks and issues that should be considered when planning the testing for this system.
O This section is worth 15 points.