Detailed Design Package Template
Use this page to structure the detailed design document or package for the preferred design selected in Block 4.
How to use this template
Students should only include the design tools that are relevant to the chosen solution, but the package should still clearly show enough detail to guide development in Unit 4.
Cover Information
| Field | Student entry |
|---|---|
| Project title | |
| Student name | |
| Date | |
| Version | |
| Preferred design selected |
1. Preferred Design Summary
Write a short summary that explains:
- which design was selected in Block 4
- why it was selected
- what kind of software solution it represents
- which user needs it is intended to meet
2. Consistency with the SRS
Complete the table below to make sure the detailed design still matches the approved SRS.
| SRS item | How the detailed design addresses it |
|---|---|
| Key functional requirements | |
| Key non-functional requirements | |
| Constraints | |
| Scope boundaries |
3. Data Dictionary
Add a data dictionary for the variables and data structures in the solution.
| Name | Type | Size | Scope | Format | Purpose | Example |
|---|---|---|---|---|---|---|
Add more rows as needed.
4. Object Descriptions
Repeat this section for each major class or object.
4.1 Object or class name
Example:
User,Booking,TaskManager,MainForm.
4.2 Purpose of this object
Explain what this object is responsible for in the solution.
4.3 Properties or attributes
| Property or attribute | Type | Purpose |
|---|---|---|
4.4 Methods
| Method | Purpose | Inputs if relevant | Output if relevant |
|---|---|---|---|
4.5 Events if relevant
| Event | When it occurs | What should happen |
|---|---|---|
4.6 Relationships or inheritance if relevant
Describe any parent-child relationships, linked objects or dependencies between classes.
5. Mock-ups and Annotated Diagrams
Insert the interface mock-ups and annotate them clearly.
For each screen or output, include:
- screen name or output name
- purpose of the screen or output
- labelled controls, fields, buttons, menus or output areas
- annotations explaining behaviour, design decisions or constraints
5.1 Main screen
Insert mock-up and annotations.
5.2 Additional screens or outputs
Duplicate as needed.
6. IPO Charts
Create IPO charts for the important functional requirements in the solution.
6.1 Functional requirement covered
Name the functional requirement this IPO chart relates to.
| Input | Process | Output |
|---|---|---|
Duplicate this section for each additional IPO chart.
7. Pseudocode
Write pseudocode for the important algorithms, workflows or modules in the solution.
7.1 Module or process name
Example: login validation, save record, calculate total, search data.
Duplicate this section for each additional algorithm or module.
8. User Experience, Design Principles and Data Considerations
Use this section to show that the design has considered more than just functionality.
8.1 User experience considerations
- affordance:
- security:
- usability:
- interoperability if relevant:
8.2 Design principles affecting appearance and functionality
- layout:
- consistency:
- readability:
- colour and contrast:
- feedback to the user:
8.3 Data protection, ownership or privacy considerations
- what data will be stored:
- whether any personal data is involved:
- how privacy or ownership issues affect the design:
9. Build Notes for Unit 4
Summarise the most important points that must guide development.
- essential screens or outputs to build:
- essential classes or objects to build:
- critical algorithms to implement:
- features that must be tested carefully:
Final Check Before Submission
- [ ] The preferred design is clearly identified.
- [ ] The package matches the SRS.
- [ ] A data dictionary is included.
- [ ] Object descriptions are included where relevant.
- [ ] Mock-ups are clearly annotated.
- [ ] IPO charts are included.
- [ ] Pseudocode is included.
- [ ] UX, design principles and data considerations are addressed.
- [ ] The document is detailed enough to guide development.