Design
You are about to begin the 16 mark design section and although this is worth less than 25% of the marks it is possibly the most important section – this is our last chance to shape your project before you waste a spectacular amount of time trying to code solutions to impossible problems.
In Summary.
A clear design specification that specifies the objectives relating them to the requirements specification
Input design
Output design
A clear test strategy including test data needs to be developed to ensure the system meets the design objectives.
Data structures/variables
Algorithms and the processes involved.
Test algorithms
What am I looking for?
A clear design specification
This section is about looking at the user requirements and breaking them down into design objectives. It is about adding detail to what the user wants. One way to think about it is there will be minimal technical language used in the user requirements but in the design specification it will be used more.
The best way to achieve this is to copy and paste your user requirements table across to the design section, add a column and then increase the detail on each user requirement in the right column
For example, in the Analysis > User Requirements section your client may have told you that they would like to store client information – in the design objectives this should be broken down into smaller objectives as shown in the table below.
User Requirement
DESIGN OBJECTIVE
Store Client Information
§ Store client data (Name, Address, Telephone, Date Of Birth)
§ Add New Clients
§ Search Clients by Name
§ Delete Client
§ Edit Client
§ Validate Client Details (Email, Date Of Birth)
Data Structures
You need to think about the data requirements of your program. If this is a standalone program you should create a variable table but for database style projects each of your required tables should be described in a table using the headings:
· Field Name
· Data Type
· Field Size
· Example Data
· Validation
· Notes e.g. Primary Key, Auto-Increment, Links to other tables.
You must also give an estimate of the table size and overall system size.
· Add up total Field size in bytes to give a row size
· Multiply by estimated number of rows to give rough table size
· Add 10% for overheads.
· Divide by 1024 until in suitable size e.g. KB or MB
You should also describe any file structures you use such as text and or xml files.
I/O Designs
Each of your input / output screens should be designed. Powerpoint is a good way to achieve this because you can leave a large border to each screen display providing a space for annotations. PowerPoint also provides a save as images feature which converts all the slides into their own images.
Designs should include links to the data structures, processes and algorithms in addition to the font styles, colours and sizes etc.
Flowcharts and Dataflow models.
You need to show how your system links together and how each different part works. If you are producing a database solution and want to produce a generic flowchart for Creating, Reading, Updating and Deleting (CRUD) records from your database then thats fine but you must highlight the differences e.g in validation.
End User Involvement
Have your user sign copies of your IO designs and maybe annotate a few.
Detailed written descriptions of process/modules
Any complex areas of your program should be explained in full. One way to do this is to prepare your comments now e.g.
Insert Client Function
This function inserts a new client into the database providing it validates
call the validate function first if returns true then insert client.
@var This function needs all client data fields e.g. name, address etc.
@return It will return true if client inserted or false.
If you follow this advice then you can just copy and paste your algorithm designs into your code and then use a program called Doxygen to produce all the technical documentation – three for the price of one.
Test Strategy
You have to show that you have planned your testing. Copy and past your design requirements table again under the title of Test Plan. As a minimum add the following columns:
· Input Data,
· Expected Output
Make sure to include Normal Tests, Extreme Tests and Abnormal Tests.
The exam board says “you should be able to”
a: specify the objectives of the proposed system and relate them to the requirements specification;
b: design and document data capture forms and/or screen layouts, drawing up detailed mock-ups of the proposed interface;
c: design and document report layouts, screen displays and/or other forms of output (for example, audio output), drawing up detailed mock-ups of the proposed interface;
d: identify, develop and document a test strategy for the design;
e: select suitable test data for the design;
f: design and document using appropriate techniques (for example, data flow diagrams) the data structures necessary to solve the inefficiencies/problems indicated in the requirements specification;
g: design and document an algorithm/pseudo- code/top-down diagram or other form of process model;
h: using appropriate techniques test that the algorithms meet the design objectives.
How will I be marked?
(i) Nature of the solution [6 marks]
A detailed systems design (including appropriate diagrams) should be produced and agreed with the users. Proposed record, file and data structures should be described and design limitations should be included. Design of data capture forms, input formats (with examples of screen layouts) and output formats should be included. A detailed summary of the aims and objectives should also be included. These items are the design specifications, which should be agreed with the user.
1-2 marks - Some vague discussion of what the system will do with a brief diagrammatic representation of the new system.
3-4 marks - The major objectives of the new system have been adequately summarised, but omissions have been made. There is a brief outline of a design specification, including mock ups of inputs and outputs, and the process model has been described (including a diagram: structure diagram, data flow diagram or system flowchart). There is some evidence that the end user has seen these designs. However; there is a lack of completeness with omissions from the process model, inputs and outputs. Data structures have been identified but there may be inadequate detail.
5-6 marks - A clear set of objectives with a detailed and complete design specification, which is logically correct. There is evidence to show that the end user has seen and agreed these designs. There are also detailed written descriptions of any processes/modules and a clear, complete definition of any data structures. The specification is sufficient for someone to pick up and develop an end result using the software and hardware specified in the requirements specification.
(ii) Algorithms [5 marks]
Detailed language independent algorithms should be developed together with evidence that the algorithms have been tested to ensure they meet the design objectives.
1-2 marks - Some vague algorithms detailing how the system will be developed.
3-4 marks - A complete set of detailed algorithms covering the system as specified.
5 marks - A complete set of algorithms with evidence to show that they have been assessed by the candidate to show that they will meet the design specification. (Evidence should show how these algorithms form a complete solution and that they have been tested for functionality using appropriate techniques.)
(iii) Test strategy [5 marks]
A detailed test strategy and plan together with appropriate test data should be developed and documented. It is vital to produce test cases and to show that they work. To do this, it is necessary not only to have test data, but to know what the expected results are with that data.
1-2 marks - A vague discussion of how the system might be tested.
3-4 marks - A detailed test strategy and a plan covering several aspects of the system but with inadequate data to effectively test the system, e.g. data covers only normal circumstances or covers only a limited part of the design specification.
5 marks - A detailed test strategy and plan covering all aspects of the system with data to test under normal, extreme and abnormal circumstances.
In Summary.
A clear design specification that specifies the objectives relating them to the requirements specification
Input design
Output design
A clear test strategy including test data needs to be developed to ensure the system meets the design objectives.
Data structures/variables
Algorithms and the processes involved.
Test algorithms
What am I looking for?
A clear design specification
This section is about looking at the user requirements and breaking them down into design objectives. It is about adding detail to what the user wants. One way to think about it is there will be minimal technical language used in the user requirements but in the design specification it will be used more.
The best way to achieve this is to copy and paste your user requirements table across to the design section, add a column and then increase the detail on each user requirement in the right column
For example, in the Analysis > User Requirements section your client may have told you that they would like to store client information – in the design objectives this should be broken down into smaller objectives as shown in the table below.
User Requirement
DESIGN OBJECTIVE
Store Client Information
§ Store client data (Name, Address, Telephone, Date Of Birth)
§ Add New Clients
§ Search Clients by Name
§ Delete Client
§ Edit Client
§ Validate Client Details (Email, Date Of Birth)
Data Structures
You need to think about the data requirements of your program. If this is a standalone program you should create a variable table but for database style projects each of your required tables should be described in a table using the headings:
· Field Name
· Data Type
· Field Size
· Example Data
· Validation
· Notes e.g. Primary Key, Auto-Increment, Links to other tables.
You must also give an estimate of the table size and overall system size.
· Add up total Field size in bytes to give a row size
· Multiply by estimated number of rows to give rough table size
· Add 10% for overheads.
· Divide by 1024 until in suitable size e.g. KB or MB
You should also describe any file structures you use such as text and or xml files.
I/O Designs
Each of your input / output screens should be designed. Powerpoint is a good way to achieve this because you can leave a large border to each screen display providing a space for annotations. PowerPoint also provides a save as images feature which converts all the slides into their own images.
Designs should include links to the data structures, processes and algorithms in addition to the font styles, colours and sizes etc.
Flowcharts and Dataflow models.
You need to show how your system links together and how each different part works. If you are producing a database solution and want to produce a generic flowchart for Creating, Reading, Updating and Deleting (CRUD) records from your database then thats fine but you must highlight the differences e.g in validation.
End User Involvement
Have your user sign copies of your IO designs and maybe annotate a few.
Detailed written descriptions of process/modules
Any complex areas of your program should be explained in full. One way to do this is to prepare your comments now e.g.
Insert Client Function
This function inserts a new client into the database providing it validates
call the validate function first if returns true then insert client.
@var This function needs all client data fields e.g. name, address etc.
@return It will return true if client inserted or false.
If you follow this advice then you can just copy and paste your algorithm designs into your code and then use a program called Doxygen to produce all the technical documentation – three for the price of one.
Test Strategy
You have to show that you have planned your testing. Copy and past your design requirements table again under the title of Test Plan. As a minimum add the following columns:
· Input Data,
· Expected Output
Make sure to include Normal Tests, Extreme Tests and Abnormal Tests.
The exam board says “you should be able to”
a: specify the objectives of the proposed system and relate them to the requirements specification;
b: design and document data capture forms and/or screen layouts, drawing up detailed mock-ups of the proposed interface;
c: design and document report layouts, screen displays and/or other forms of output (for example, audio output), drawing up detailed mock-ups of the proposed interface;
d: identify, develop and document a test strategy for the design;
e: select suitable test data for the design;
f: design and document using appropriate techniques (for example, data flow diagrams) the data structures necessary to solve the inefficiencies/problems indicated in the requirements specification;
g: design and document an algorithm/pseudo- code/top-down diagram or other form of process model;
h: using appropriate techniques test that the algorithms meet the design objectives.
How will I be marked?
(i) Nature of the solution [6 marks]
A detailed systems design (including appropriate diagrams) should be produced and agreed with the users. Proposed record, file and data structures should be described and design limitations should be included. Design of data capture forms, input formats (with examples of screen layouts) and output formats should be included. A detailed summary of the aims and objectives should also be included. These items are the design specifications, which should be agreed with the user.
1-2 marks - Some vague discussion of what the system will do with a brief diagrammatic representation of the new system.
3-4 marks - The major objectives of the new system have been adequately summarised, but omissions have been made. There is a brief outline of a design specification, including mock ups of inputs and outputs, and the process model has been described (including a diagram: structure diagram, data flow diagram or system flowchart). There is some evidence that the end user has seen these designs. However; there is a lack of completeness with omissions from the process model, inputs and outputs. Data structures have been identified but there may be inadequate detail.
5-6 marks - A clear set of objectives with a detailed and complete design specification, which is logically correct. There is evidence to show that the end user has seen and agreed these designs. There are also detailed written descriptions of any processes/modules and a clear, complete definition of any data structures. The specification is sufficient for someone to pick up and develop an end result using the software and hardware specified in the requirements specification.
(ii) Algorithms [5 marks]
Detailed language independent algorithms should be developed together with evidence that the algorithms have been tested to ensure they meet the design objectives.
1-2 marks - Some vague algorithms detailing how the system will be developed.
3-4 marks - A complete set of detailed algorithms covering the system as specified.
5 marks - A complete set of algorithms with evidence to show that they have been assessed by the candidate to show that they will meet the design specification. (Evidence should show how these algorithms form a complete solution and that they have been tested for functionality using appropriate techniques.)
(iii) Test strategy [5 marks]
A detailed test strategy and plan together with appropriate test data should be developed and documented. It is vital to produce test cases and to show that they work. To do this, it is necessary not only to have test data, but to know what the expected results are with that data.
1-2 marks - A vague discussion of how the system might be tested.
3-4 marks - A detailed test strategy and a plan covering several aspects of the system but with inadequate data to effectively test the system, e.g. data covers only normal circumstances or covers only a limited part of the design specification.
5 marks - A detailed test strategy and plan covering all aspects of the system with data to test under normal, extreme and abnormal circumstances.