Design
Stages of Design
i. Nature of the solution
1.
2.
3.
4.
5.
6.
Agreed set of objectives
Output design
Input design
Data structures design
Process model design
Test plan
ii. Intended benefits
iii. Limits of the scope of the solution
i. Nature of the Solution
• How will you proceed with the designing of the
new system?
• This will be a small introduction specifying the
sub-stages that follows below. That is:
1.
2.
3.
4.
5.
6.
Agreed set of objectives
Output design
Input design
Data structures design
Process model design
Test plan
1. Agree a set of objectives with the
Client
• It is important that the user requirements are
broken down into specific and measurable
objectives.
• Here you are looking at the scope of the
project.
• This list would contain points that can be
considered at the end of the work as having
been achieved or not.
Note
• The agreed Design objectives and the input
and output design makes up the:
DESIGN SPECIFICATION
• Objectives must be SMART
– Specific—What exactly are we going to do for whom?
– Measurable—Is it quantifiable and can WE measure it?
– Attainable/Achievable—Can we get it done in the
proposed time frame with the resources and support
we have available?
– Relevant—Will this objective have an effect on the
desired goal or strategy?
– Timely –When will this objective be accomplished?
• The table below uses an example objective from a fictional
software company, to illustrate how to apply the SMART
objective principle.
Examples of objectives whose success
would be difficult to measure:
• “The solution must be easy to use”
• “The solution must be presented in pleasant
colours”
Objectives where success could be
readily identified:
• “Mr. Clerk must able to access all customer and sales
staff records”.
• “A form teacher must be able to print a student
performance report for each student at the end of
every term.”
Important:
• Read Section 4.3 a, Page 310
• This document must be signed of by both student and
client
2. Output Design
•
•
•
•
Show detailed models of the proposed interface.
Discuss these with the client before implementation.
Show any changes made. Use this as an opportunity to involve the client again in
modifying the design specification.
Document all such occurrences and how they were resolved.
Include:
– report layouts
– screen displays
– other forms of output (for example, charts, sound, animation)
– screen layout
Important:
• Read Section 4.3 b, c Page 310 - 311
• Must be drawn up via the computer using Microsoft Visio or any other software you can use to
produce diagrams.
• Ensure that you have uncluttered screens and clear annotations of each control / field on the
form
•
This document must be signed of by both student and client.
•
(Identify Purpose, Link to table(s), Fields used, Criteria, Sorting, Grouping, Annotation of
elements)
3. Input Design
• This section deals with designing and documenting data capture
forms and/or screen layouts.
• The data capture forms might be paper-based but might also be online forms.
• The form designs should reflect the medium used (no dropdown
boxes on a paper-based form).
Important:
• Read Section 4.3 b, c Page 310 – 311
• Must be drawn up via the computer using Microsoft Visio or any
other software you can use to produce diagrams.
• Ensure that you have uncluttered screens and clear annotations of
each control / field on the form.
• (Identify Purpose, Link to table(s), Fields, Annotation of elements)
• This document must be signed of by both student and client.
Main Menu Design
Tips on Screen Designs
• http://www.databasedev.co.uk/user_interface_design.html
• Ensure that the design pattern is consistent across the software. For
example if you double click to open an item on one list ensure that
you can do the same on another form.
• Use colour sparingly. Stick to the gray/blue backgrounds and limit
the extensive use of colour. If there are items such as required fields
on a form, use one background colour for all of these fields, e.g.
yellow
• Ensure a consistent easy navigation between screens/modules. You
should have a consistent top toolbar wherever the user is in the
software (except the main screen, this may be different)
• Keep screens as uncluttered as possible and ALIGN the controls on
the form.
• Ensure that data in fields is justified appropriately. Right for
numbers (integers) and Left for strings.
Tips on Screen Designs
• http://www.databasedev.co.uk/user_interface
_designs.html
• You can use the above link for information.
Tips on Screen Designs
• You must go through the following link on
Form Design:
• http://www.slideshare.net/psykoreactor/bestpractices-for-form-design
Project Approval Form
• This should be used after every stage.
• However, you must list ALL the deliverables you
created.
• Failure to list all may result in obtaining a lower
mark.
• Also put in a Project Approval Form immediately
after the deliverable where it is absolutely
necessary to have client approval (such as the
Design Objectives, Output Design and Input
Design.
4. Data Structure Design
• The aim of this stage is to determine what data will be processed by
the system and what data will be stored within it.
• The simplest way to do this is to draw it.
• Your underlying aim is to convey to the reader that there is a clear
idea of how the different parts of the system are related and how
the various data flows.
• Your ability to draw pretty boxes is not tested here, simply your
understanding of the logic of the intended solution and of how the
various processes and data work together.
• This pertains to the data structures that solve the inefficiencies
identified in the requirements specification.
This section must contain:
a) Normalization
b) Entity Relationship Diagram showing the relationships
between the different files or tables should be created.
c) Data Storage: Files
1.
If the data are to be organized as files we must decide:
1.
2.
3.
2.
3.
4.
The file organization that is , serial, sequential or direct access.
The methods of file access
Each file’s structure, e.g. user – defined “record” data types.
Identify the data fields for each file or tables, Primary Keys,
Foreign Keys, data types
Data Validation - Validation must be performed on data
inputted into the system. These proposed validated checks
must be documented in detail. Can summarise this
information in the form of a table with a row for every field.
(You can use a table similar to the following:
Calculate the file size
You can use tables such as these. Ensure you have included all aspects.
Field Name
e.g
CustomerID
4.
Type
e.g. Autonumber (Text currency number
etc)
Size Description
e.g. e.g. The key identifier of
5
each customer This is a
unique number
Calculate the file size
File Size Estimation
• Estimation of data files generated by the system.
example:
Total number of bytes for 1 record = 250
10% slack = 25
Estimated number of records per year = 500
Total number of bytes for 500 records = 250 + 25 X 500
= 1250 (Read Section 2.3d Page 148)
Important: Read Section 4.3 b,c Page 311 – 312
Validation
e.g.
Presence
check
Example
e.g. 12345
5. Process Model Design
• Dataflow diagram showing the data flow in the new system (Read
chapter 1.6 Page 60)
• System Flowchart showing the processes and their data (Read chapter
1.6 Page 60 - 61)
• Jackson Diagram showing how the problem has been modularized.
• A complete set of algorithms in appropriate form (pseudocode or
system flowchart or a written description) which describe the
method of solution and the original coding which is intended.
Important: Detailed textual descriptions of each
diagram in this section are needed.
Read Section 4.3 e Page 312
6. Test Plan
•
You are required to design and document a test plan that includes test data and expected
outcomes.
•
•
The intention of this stage is to provide evidence to the end user that the solution works.
Assessment of the Test Plan is based on completeness and clear presentation.
•
Encourage or a test plan to ensure all elements are fully tested and students to fully justify the
choice of data.
Relate your discussion to normal, erroneous and extreme data.
Test plans are often best set out on tabular form clearly cross referenced to annotated output.
The following headings might be appropriate for the test plan table:
•
•
•
–
–
–
–
–
–
Test No
Purpose
Data
Expected Results
Actual results
Remedial Action
Important: Read Section 2.6 b Page 172 – 173
6. Test Plan
Test Strategy
Document the following:
• What is the aim of testing the new system?
• What particular features of the new system do
you intend to test?
• What kind of testing will you be performing
yourself? (dry run, variable dumps, black box).
• Important: Read Section 2.6 b Page 172 – 173
6. Test Plan
Test
no.
1
Test
Objective
CustomerID should
be automatically
generated
Test
Method
Click on
Add
Button
Test Data
Used
n/a
Expected
Outcome
Next ID
should be
generated
Actual
Evidence on
Outcome
page…
Test Successful
95
ii. Intended benefits
• This must be a comparison of merits of the new
system in relation to the old system
• You must comprehensively describe the benefits
of the new system.
• What benefits will the new system bear for the
user?
• TIP: Cost benefit, time saving, increase in
productivity, increase in efficiency, customer
satisfaction etc.
iii Limits of the scope of the solution
You must present a detailed description of the system
limitations , including, the estimate of the size of the
files required for the implemented system, time,
budget, available hardware, computer literacy etc.
System Limitations
• Things/processes that the new system will not do.
(example: system will not handle accounts, system will
not be able to handle more than 100,000 records etc.)
Important: Estimation of file size required for the
implemented system must be a limitation