Rule Brick
SECTION A: Selection, Investigation and Analysis
Problem Definition [5]
Name of system e.g. Marymount Student Fees Payment System
Location (Physical location)
Brief history (of the current system including major activities - Population size)
Books or files found in the existing system
Data flow diagram
Investigation of the current system [10]
Research instruments
At least two instruments (their roles they play in data gathering in the project)
Data flow diagram or entity Relation Diagram
Problems/challenges with the current system-weaknesses
Feasibility Study [5]
5 elements (TELOS for schedule-time)
Requirements Specification [2]
Software requirements-software for designing the system (e.g. any language, software for
documentation-word, software for operating system)
Hardware requirements (4 functional parts of the computer system) what is used in the system
e.g. mouse in relation to the program
Aims and Objectives
Aims (broader requirements) [2]
Aim(s) not measureable e.g. secure
Objectives (3 objectives) [3]
Can be realigned after the system has been designed
Objectives should be S.M.A.R.T - i.e. what your system is able to do
Evidence of research [6]
To appear at the appendix
Include sample instrument document for each target group
SECTION B: DESIGN
Alternative Method (one method) [2]
Designing the system using another language or buying off the shelf and outline why you
suggested that system and the challenges associated with it
Justification of the proposed solution [2]
Compare the chosen system with other alternatives
1
Data Structures or File Design [4]
If file based system, produce a table with field name, field type, size and validation rule.
Minimum of three tables.
Input Design (No screenshots) [6]
Data capture forms and screen layouts (use any package to produce). Minimum 2 forms-drawn
to scale
Screen layouts (the interface produced by the system. At least 2 layouts)
File design (if c++. Java produce classes)
Overall Plan [5]
Tree structure displaying the system. Should have an exit module
Output Design (not screenshots) [4]
Describe what is produced by the system
Produce the interface with on screen commands minimum of two commands
Test Plan [5]
Choose one type and justify why you chose the type e.g. whitebox, beta or blackbox testing
Section C: Software Development
Technical Documentation [3]
Choose any three modules and write their pseudocodes, at least quarter of a page (for all modules)
Flowcharts [9]
At least 3 flowcharts
Code listing [5]
The minimum number of pages is five
Techniques that improve the code
o Proper indentation should be visible on print out
o Blank lines (end of each procedure put a blank line)
o Use of comments (at the top or in text at the far right-comment a section) e.g. comment
on the variables, and computations. Every page should have the above three.
User Documentation [4]
Installation (the steps on how to install the system)
Starting the system (from desktop up to the main menu)
Navigation (from the main menu to other modules)
Exiting the system
2
Section D: Testing and Evaluation
Testing [5]
Testing for normal data
Table showing test data and expected results
Testing for extreme
Test data and expected outcome
Testing of abnormal
Test data and expected outcome
Sample Runs
Normal and extreme then error messages from abnormal data
Error messages (from abnormal data)
Queries and reports [2]
Produce samples of queries and reports
Evaluation [5]
Achievements against objectives
Opportunities for future developments (which are realistic) e.g. adding another module. At least
two.
Evidence of system ownership, creativity, originality [6]
