Design

1. Design

2. Stages of Design • Nature of the solution • Agreed set of objectives • Output design • Input design • Data Flow Diagram • System Flowchart • Data structures model • Process model • Test plan • Intended benefits • Limits of the scope of the solution

3. 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: • Agreed set of objectives • Output design • Input design • Data structures/model • Process model • Test plan

4. 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.

5. Note • The agreed Design objectives and the input and output design makes up the: DESIGN SPECIFICATION

6. 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?

7. The table below uses an example objective from a fictional software company, to illustrate how to apply the SMART objective principle.

8. 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”

9. 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

10. 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.

11. 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 on-line 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. • This document must be signed of by both student and client.

12. Main Menu Design

13. 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.

14. Tips on Screen Designs • http://www.databasedev.co.uk/user_interface_designs.html • You can use the above link for information.

15. Tips on Screen Designs • You must go through the following link on Form Design: • http://www.slideshare.net/psykoreactor/best-practices-for-form-design

16. 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.

19. 4. Data Flow Diagram DFD must show the data flow in the new system (Read chapter 1.6 Page 60)

20. 5. System Flowchart System Flowchart must show the processes and their data (Read chapter 1.6 Page 60 - 61)

21. 6. 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.

22. This section must contain: • Normalization • Entity Relationship Diagram showing the relationships between the different files or tables should be created. • Data Storage: Files • If the data are to be organized as files we must decide: • 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

23. Identify the data 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(ReadSection2.3d Page 148) Important: Read Section 4.3 b,c Page 311 – 312

24. 7. Process Model

25. 8. Test Plan

26. ii. Intended benefits • 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.

27. 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 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.)