The analysis section has provided the reader with a detailed understanding of your project environment, equal to your own.
The design section will provide the information needed for someone other than yourself to build the solution to the problem.
Expected contents for this section of the report are:
or
You do not have to cover all of the following points, only those that are relevant to your particular project. You do need to cover the sections that are relevant to your work in depth and detail. You should also bear in mind that the implementation section depends on design for the overall design, the user interface and the details of algorithms. The implementation (writing code) should reflect the design narrative, from overall design, through data structures and algorithms, user interface design, security considerations and testing.
Specify and document a design that meets the requirements of a real problem in terms of hardware and software, using methods such as
Use prototyping where appropriate - a test system to see if something works.
You must design a system that works, which will include:
Define the data requirements: scalar items, fields, records, tables and files, in a level of detail that you will need when you write your code. The design data dictionary will include normalised tables, if using a relational database.
Include details of file structure and processing: whether sequential or direct access, read, insert and edit routines. What file structures and operations does the user require?
Most programs will take data in and transform them in some way. A program that does no more than input, store and output will not get many marks at this level. Data are transformed by a process that can be described algorithmically. A simple algorithm would be to add 1 or calculate VAT; a more complex algorithm would search the data or sort them into order; a more suitable algorithm for an A Level project would take a photograph and analyse it in some way, or choose items from a list to meet a scheduling problem (e.g. greedy algorithm) or calculate how one member of a population affects the other members (e.g. infection, food chain).
Document algorithms at this stage in flowcharts or pseudo-code. In a later stage of the project (documentation) you will give details of the algorithms for technical maintenance: you could re-use the material here for that section.
If you are using OOP then you should combine your data structures (properties) with your algorithms (methods) and give a full account of your definitions.
This is about how your user will interact with your program. Will it be graphical or console? What form will the controls take? Options include: edit boxes, buttons, lists, panels, images, sliders...
Make sketches of your major input and output forms or draw them in a program such as Publisher. The input design will allow the user to enter data and possibly manipulate them, depending on the nature of the project. Output designs would be appropriate for reports on screen or paper.
For data processing systems you will need to make sure that data is secure: the main thing here is backing up as system security is dealt with in a separate section (below). Data integrity means keeping the data accurate and correct. Validation and verification deal with integrity at the input stage and testing should demonstrate that routines are effective.
If your data belongs to an organisation use a user name and password. Encryption? Unlikely.
The aim of testing is not just to show that your program works but also to show that you have met your user's requirements. You know what your program is going to do so define some criteria for testing this. Group tests by e.g. inputs, processes, outputs, storage, robustness.
You will undoubtedly test your code as you go along to make sure that it is syntactically correct and compiles successfully. This, however, is not testing in the strict sense but rather chcecking that your code does what you intend e.g. that data are stored in a file and can be loaded into your program, modified and stored again.
At this stage you should write an outline of how you will test your program. You must provide evidence that you have thought about testing and you should produce a plan. The idea is that if you can define how you will test your code then you will know what your code is meant to do. If you cannot define the tests at this stage it is because you are not completely sure what the code is meant to do. You should not think that the design process is complete until you are certain that you can implement your solution.
Testing strategy: you will need to cross-reference your tests in section 4 to the Testing section in Design; to do this you should clearly identify the components of testing that you have used. There is a lot of theory about software testing (Wikipedia) but at this level something basic, effective and well documented will almost certainly be enough.
A numbered list of tests that you will perform is one way to prepare a plan, then you can refer back to them as you carry them out.
Testing your algorithms is the central issue: does that greedy algorithm for allocating staff or choosing a team do its job properly? Testing input, storage and output is straightforward: what we want to hear about is whether your algorithms stand up to rigorous testing. How will you show that your algorithms work? There is a range of methods to choose from.
You can arrange your testing along hierarchical lines:
(see video). Here you have a glimpse of current theory about software testing. Not all these tests may be relevant to your work.
Or you can use the 'box approach':
The text book (pp 259-266) has some useful points. The first table lists possible tests at a general level:
| Test series | Purpose |
| 1 | Flow of control from main menu to forms and/or procedures |
| 2 | Validation of input data or use of controls for variables e.g. sliders |
| 3 | Calculations, searching, sorting routines |
| 4 | Data saved correctly in tables or files |
| 5 | Outputs are correct |
| ... |
This is for illustration only: your own table of tests should be longer and more detailed. The detail will come from developing your tests according to your program's functionality and your use of terms like 'unit testing', 'integration testing', 'black box', 'white box' and so on.
The second table suggests that you should define test data at the design stage and complete the actual results during testing proper. The full test results are in an appendix with a cross-reference. Note that this approach removes the need to cross-reference back to the test design because you are using the same table! Just a copy and paste will do. You can see from this what is expected here.
Table headings:
Test data should include:
See page 262 in the text book for further detail.
This should give you plenty of ideas to organise and structure your testing. Whatever approach you adopt it should look thorough and convincing. If you do the work you will get the marks!
You have to have something to which you can refer when you do the tests after implementation.
Just out of interest, testing in the way outlined here is bottom-up while your design and implementation were top-down.
Link to notes on old spec, (still relevant)