Nature of solution
What is it?
This is where you look at the implementation of the system and decide on the aesthetics and storage of the system. Essentially you are looking at data structure design and input/output design.
Data dictionary
At this point you are not deciding on what data needs to be stored. The first step is to go through the requirements specifications and write down all of the data items which may need storing. This is best done in a table like the one below –
Customer table
Name |
Data type |
Size |
Description |
Surname |
Text |
40 |
Store customer surname |
Customer ID |
Integer |
4 |
Each customer will have a unique number – Primary Key |
As you are listing them try and assign them to tables. Once you have created the data dictionary you then need to normalize your database. You should refer to your lesson notes for this. Tables should then be written in the following form -
CUSTOMER(Customer ID, Surname, forename, DOB, email, phone number)
The next step is to create an ERD diagram to show the relationships between the different tables. Your final data structure design will include –
- ERD diagram
- Overview of tables
- The data dictionary
You do not have to show the steps of normalization nor do you get any marks for doing it. However if you do not normalize your database then you will get a lot of problems during implementation!
Input / output design
As you will most likely be producing a GUI you will need to design each screen before you implement them. This follows the exact same idea as what you did for F452 designing an interface. You will decide on how to make the users experience efficient and complete.
Note – You must include online help! You will potentially lose a lot of marks if you miss out online help.
When designing you need to -
- A screen number / code / name so it can be easily referenced
- Create a mock up of the screen with
- Online help
- User interface controls
- Include validation (where appropriate) for each GUI component.
- Describe what the buttons do including any buttons which take you to other forms.
Note – To speed things up design your forms in whatever you will be developing in. That way you only have to do it once!
Mark descriptions
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. |
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. |
1–2 marks |
Some vague discussion of what the system |
High mark boundary
- The user has signed and accepted the design
- There are no omissions in the design. Everything in the requirement specification has been included.
- Data structure is logically correct. A ERD diagram has been included.
- Each screen has been explained in detail including validation and what each function will do.
- The design is complete enough for another developer to pick up and implement.
- Online help is clearly evident
- Processes have been summarized in diagrams. (This is done in the next section!)
- Hardware and software requirements are clearly evident and are correct
Middle mark boundary
- All of the main features have been designed but some omissions have been made.
- Diagrams of the main processes have been produced but may lack detail.
- User has signed to say they have accepted the design
- Data structures have been designed but there may be some problems with normalization or missing fields.
Low mark boundary
- Screen designs have been poorly designed and some major omissions.
- Data structure design may be missing or may lack detail.
- There is some idea of how the system will work but not enough to produce a working system
Top tips
- Make sure you use Word’s headings feature. It makes life a lot easier!
- Each form should have it’s own section. Use heading 2 or 3 to help lay this out.
- Try and avoid drawing lines on top of screenshots. It tends to look messy!
- Use bullet points for writing validation rules or use a table.
- Do not start the form design until you have had your data structure design checked by your teacher!
- Have a nice clear section where the user can sign. Wait till the end of the project to get it signed as you will most likely be making tweaks!