 |


Prescription:SD200 Systems Design |
| Aim of Module | To introduce the student to the basic concepts of design through the study of process design, input design, output design, developing program specifications and systems design documentation.
|
| Credits | 7
|
| Suggested Time | 70 student learning hours
|
| Prescription Expiry Date | Nov 2002
|
The Student Will
| | | | R | 1.1 | Describe the concept of a design methodology and list the standard characteristics. | |
| |
A | 1.2 | Given a design problem, apply a top-down (or similar) approach. | |
| |
R | 1.3 | Describe typical documents used in systems design, including: | |
| |
| | - organisation charts | |
| | - data flow diagrams | |
| | - data dictionaries | |
| | - structure charts | |
| |
> | Explanation should include basic characteristics, appropriate usage, cross-relationship between documents. | |
| |
A | 1.4 | Given a simple case study, create the appropriate design documen-tation. This should include details of logic using tools such as Structured English, Decision Tables and Trees etc.
| top
| | | | > | Note: all types of input devices should be considered, and their implications for design. | |
| |
R | 2.1 | Describe the characteristics of good input forms. | |
| |
R | 2.2 | Describe the characteristics of good screen design. | |
| |
A | 2.3 | Apply the above principles in the design of input forms and screens for a case study. (This should include the use of a variety of different types of dialogues). | |
| |
C | 2.4 | Explain how such design documents should be cross-referenced to the rest of the system specification. | |
| top
| | | | > | Note: All types of output devices should be considered, and their implications for design. | |
| |
R | 3.1 | Describe the characteristics of good report layouts. | |
| |
R | 3.2 | Describe the characteristics of good output screen design. (Will be related to 2.2 above). | |
| |
R | 3.3 | Describe the characteristics and function of turn-around docu-ments. | |
| |
A | 3.4 | Apply these principles in the completion of designs for a case study. | |
| |
C | 3.5 | Explain how such design documents should be cross-referenced to the rest of the system specification. | |
| top
| | | | C | 4.1 | List the basic contents of a program specification and show how the design documents produced above are incorporated. | |
| |
A | 4.2 | Complete program specifications for a case study, using techniques of narrative and process logic expression. | |
| |
C | 4.3 | Explain the effect of a multi-programmer team approach on the writing of program specifications. | |
| top
| | | | R | 5.1 | Outline the importance of documentation at each stage of system development. | |
| |
C | 5.2 | Explain the purpose and use of a documentation checklist. | |
| |
C | 5.3 | Explain the concept and application (at a superficial level) of a recognised system of documentation (e.g. NCC, Spectrum etc.). | |
| top
| | | | A | 6.1 | Apply the principles of security and audit in the completion of a case study.
| top
| | | | Note | | NOTE TO TUTORS | |
| |
> | This subject should be based upon the completion of case studies based on on-line (i.e. interactive) applications. |
|
|
|