University of Zimbabwe

Computer Science Department

CT 260/ CT 360 Project Guidelines

Prepared by Zanamwe

Please note the following:

1) The report should be printed on one side of the page,

2) Number each sheet consecutively at the bottom of the page.
3) Headings: Chapter titles start on a new page. Chapter numerals should be Arabic, not
Roman numerals. Type the chapter number and title in upper and lower case, flush left, at
the top of the report page; leave an extra space and then begin the text. Since you will
have several levels of subheadings, distinguish one level from another in a consistent
way, such as (1, 1.1, 1.2, 2, 2.1, 2.1.1, 2.1.2, 2.2). Avoid having more than three levels of
subheadings.

Project Format

Note: Section numbers as shown below are mandatory; font, indentation and main section
titles in bold. They are merely for clarity here and are optional.

CHAPTER ONE

1. Introduction

1.1 Background
Here you develop the theoretical and conceptual framework upon which the project is
based. It is appropriate to describe relevant data representations and algorithms. The
developer must iinitiate reader into the project. The developer must begin with a general
overview and then narrow down to specific focus. The background paves way for the
statement of problem.

1.2 Statement of Problem or Nature of the Research Problem

The first stage of a project is to realize a problem and the problem has to be chronic. A
 problem statement is a clear concise statement that spells out the problem to be solved
and it also articulates the value added if added if problem is solved. The statement must
be brief and non-technical.
1.3 Previous and Current Work, Methods and Procedures
This is an historical or conceptual survey of relevant work done in the area by previous
investigators. Each contribution must be accompanied by appropriate references to be
listed in the reference section. The developer must identify existing systems that were
developed to address the current problem and how they are inadequate or what are their
weaknesses.

1.4 Project Description/ Novel Characteristics of the Research

This section presents a brief overview of new, extended or different functions, structure
or operation of the system. The developer must clearly show the novelty or newness of
system to be developed.
1.5 Research Purpose/ Research Objectives/ Aims
Developers are urged to focus on the statement to generate research objectives.
Objectives are evidence of focus/direction

1.6 Justification of Project/ Rationale/ Significance of project

Theoretical, practical, or educational impacts on hardware, software, or users
Rationale addresses among other issues the following:
• Why the research is necessary

• Why it is important i.e. its benefits to the users and the community at large

• Expressing value of project output to target users

1.7 Scope of the Study

This section specifies the system boundary that is it clearly spells out what is part of the
system and what is not part of the system.

1.8 Organisation of the project/ Summary / Presentation of Research

This section gives an overview of the whole project that is what is going to be covered in
each of the foregoing chapters.

CHAPTER TWO
2. System Specification

2.1. Introduction

Give a brief introduction about what this chapter covers.

2.2. System Functional Specification or Problem Definition

This is a detailed specification of functions performed by the proposed system, from an

external or user perspective, not from an internal or programmer viewpoint. Thus, the system
is regarded as a black box with various inputs and outputs related by the functions performed
by the system. The description should be sufficient for another programmer to implement the
system.

2.1.1 Functional Requirements

List and briefly describe each of the functions which the system will be designed to perform
for its user: What the system will do. The requirements must be complete and should not be
ambiguous.

2.1.2 Non-Functional Requirements

List and describe each of the internal (self) and external (environment) limitations and/or
restrictions on the range of system functions: What will the system not do. DO NOT INSULT
THE READER BY INCLUDING ITEMS THAT WOULD NOT BE A SURPRISE.

2.1.3 System Evolution

The developer must outline assumptions on which the system is based, anticipated changes
due to hardware and software evolution and changes in user requirements.

2.1.4 System Scope

This stage involves establishing the system boundary. A system boundary depicts the parts of
the original requirements that are to be computerised. The developer must realise that that the
boundary may or not may enclose all requirements. When setting up a system boundary the
developer must consider among other things, the available resources, user requirements and
other limitations in implementing the system. Further this section must give a description of
system components and the system environment

2.1.5 Prototyping
Developers may use this technique if they want to validate the requirements. Prototyping
involves developing a quick and dirty but still convincing model of the final system. The
developer must articulate the goals of prototyping, functions prototyped and results of the
prototyping process.

2.1.6 User Interface Design

Give a detailed description of the system user interface including diagrams of all the ``work''
windows (or screens or panes), a table of operations for each work window, and precise
descriptions of each operation that the user would regard as unfamiliar. A work window is
one that contains data the user is editing, browsing or viewing. This section is required for all
programs that engage the user interactively.

2.1.7 Other User Inputs

Give a precise description of the other inputs to the system including source (human or
storage) syntax (format) and semantics (meaning). Give examples. This section is required
for all programs that obtain input from their environment non interactively.

2.1.8 Other User Outputs

Give a precise description of the other outputs of the system including syntax and semantics.
Correlate the outputs with the inputs and the functions performed. Give examples. This
section is required for all programs that obtain input from their environment non
interactively.
2.1.9 System Data Files
Give a precise description of the data files created or maintained by the system. Thus, for
example, you would include files in a database and you would exclude executable files and
text files.

2.1.10 User Interface Specification

• Interface Metaphor Model
• User Screens/Dialog
• Report Formats/Sample Data
• On-line Help Material
• Error Conditions and System Messages
• Control Functions

2.3. Feasibility Study

A feasibility study decides whether or not the proposed system is worthwhile. The goal
of feasibility study is to identify the existing system and note any problems associated
with it, establish if any practical solutions exist and determine whether it is worthwhile
to implement the system. A feasibility study checks the following:
• If the system contributes to organisational objectives
• If the system can be engineered using current technology and within budget
• If the system can be integrated with other systems that are used.

The developer must therefore conduct the following feasibility studies

2.3.1 Economic feasibility

Involves establishing whether it is possible to implement the system using the existing
monetary resources (hardware and human resources). Economic feasibility study also
involves carrying out a cost benefit analysis for each of the alternative solution.

2.3.2 Technical Feasibility

To a larger extent this involves assessing the knowledge and skills that the system developer
has and establishing whether it is possible to develop the system using the existing level of
skills and knowledge.

2.3.3. Operational Feasibility

An operational feasibility study tries to figure out whether upon completion the system is
going to be usable in the intended environment.

2.4.System Performance Requirements

2.4.1 Efficiency (speed, size, peripheral device usage)
2.4.2 Reliability
• Description of Reliability Measures (accuracy, precision, consistency,
reproducibility, etc.)
• Error/Failure Detection and Recovery (failure modes, failure consequences,
error logging and reporting, manual and automatic recovery procedures)
• Allowable/Acceptable Error/Failure Rate
2.4.3 Security
• Hardware Security
 • Software Security
• Data Security
• Execution Security (user validation)
2.4.4 Maintainability
2.4.5. Modifiability
2.4.6. Portability

2.5 Conclusion
Give a chapter conclusion

CHAPTER THREE
3. Project planning and Literature Review

3.1. Introduction
Give a chapter introduction

3.2. Project planning and scheduling

The project developer must clearly articulate the deliverables and milestones. Students can
also using project planning tools such as bar charts, project network charts, Gantt charts etc.
Project planning software may also be used.

3.3. Literature Review

This is a historical or conceptual survey of relevant work done in the area by previous system
developers. Each contribution must be accompanied by appropriate references to be listed in
the reference section. The developer must identify existing systems that were developed to
address the current problem and how they are inadequate or what are their weaknesses.
Further the developer must identify process models that that will be used and a justification
must be given as to why certain process models have been chosen. The user might choose
process models such waterfall, spiral, incremental etc. Be sure to choose a process model that
suits your project.

3.4. Conclusion
Give a chapter conclusion

CHAPTER FOUR
4. System Analysis and Design
This is a top level preliminary or provisional indication of the proposed system architecture
and flow. You should correlate system functions with system structure and interface
specifications. Further the developer should analyse both the existing and new system with
the aim of obtaining a fuller understanding of the system. The developer can use
questionnaires or interviews or both when investigating about the system. The developer
must not use technical tools in the analysis. At this stage, the developer can make use of the
following tools: dataflow diagrams, decision tables and trees, ERDs, sequence diagrams, use
case diagrams, class diagrams, data dictionary, petri nets, state transition diagrams.
4.1.Introduction
Chapter introduction

4.2.System Architecture

4.2.1. Data Flow Diagrams (level 1 and 2 DFDs)

This is a hierarchical (or levelled) set of diagrams showing the flow of data elements into and
out of the functional units of the program, data stores and environmental sources and sinks.
Labelled arrows denote data flows. This diagram is complementary to the structure chart
described next.

4.2.2. Entity Relationship Diagram

This is a conceptual model of a system showing the entities and their attributes as well as the
relationships between or among entities.

4.2.3. System Structure Chart(s)

This is a (set of) chart(s) showing the functional units of the system hierarchically organized
to show which units call, use or contain other units. Each interface between two units (a call)
is annotated with small arrows and data item labels to show the data exchanged between the
units.

4.2.4. System Data Dictionary

This is a comprehensive dictionary of all the data items that appear in the system data flow
diagrams and the structure charts. At a minimum it contains, for each data item, its identifier,
any abbreviation used instead of the identifier, the name of the type of the data, and a
definition of the data item in the form of either a symbolic expression or a precise
description. The most appropriate way is to come up with data dictionary for each and every
technique that the developer would have used. The data dictionary should be part of every
project.

4.2.5. Equipment Configuration

Describe the equipment you will use to support the operation and development of your
system.

4.3. System Data Structure Specifications

4.3.1. Other User Input Specification

4.3.1.1.Identification of Input Data
4.3.1.2.Source of Input Data (NOT input device)
4.3.1.3.Input Medium and/or Device
4.3.1.4.Data Format/Syntax
4.3.1.5.Legal Value Specification
4.3.2. Other User Output Specification
4.3.2.1. Identification of Output Data
4.3.2.2. Destination of Output Data (NOT output device)
4.3.2.3 Output Medium and/or Device
4.3.2.4 Output Format/Syntax
4.3.2.5 Output Interpretation (meaning of output)
4.3.3. System Data Base/File Structure Specification
4.3.3.1Identification of Data Base/Files
4.3.3.2 (Sub) systems accessing the Data Base (creating, updating, using; frequency)
4.3.3.3 Logical File Structure (record formats, file organization, access methods, rationale, examples)
4.3.3.4 Physical File Structure (storage device, blocking, organization, access, etc.)
4.3.3.5 Data Base Management Subsystems Used (internal or external)
4.3.3.6 Data Base Creation and Update Procedure (if NOT by system)

4.3.4 System Internal Data Structure Specification

4.3.4.1.Identification of Data Structures
4.3.4.2.Modules Accessing Structures (creating, updating, using)
4.3.4.3.Logical Structure of Data (format, organization, access, rationale,
examples)

4.4. Module Design specifications

4.4.1. Module Functional specification
4.4.1.1 Functions Performed
4.4.1.2 Module Interface Specifications (input/output arguments/global
variables/files)
4.4.1.3 Module Limitations and Restrictions
4.4..2 Module operational Specification
4.4.2.1 Locally Declared Data Specifications (variable dictionary)
4.4.2.2 Algorithm Specification (flowchart, pseudo code, decision table, etc)
4.4.2.3 Description of Module Operation

4.5. Conclusion
Chapter conclusion

CHAPTER FIVE

5 Implementation and Testing

5.1. Introduction
Chapter introduction

5.1. Choosing the language

List the programming languages or scripting languages you have used for the
implementation of your project and give reasons for choosing each language.

5.2. Choice of environment

Indicate where applicable the databases that were used and justify why you chose for
instance Oracle instead of MySQL or vice versa. Indicate the operating system used
and web servers and other web authoring tools used and do not forget to justify why
you chose those tools.

5.3.Language specific algorithm

5.4.Efficiency
 5.5.Correctness
5.6.Documentation of code
5.7.Variables

5.8.System verification/ testing

5.8.1. Items/Functions to be Tested
5.8.2. Description of Test Cases
5.8.3. Justification of Test Cases
5.8.4. Test Run Procedures and Results
5.8.5. Discussion of Test Results
5.8.6. Evaluation of User System
5.8.6.1.Protocol Study
5.8.6.2.User Survey
5.8.6.3.Real Time Monitoring
5.8.6.4.Interviews
5.9.Conclusion
Chapter conclusion

CHAPTER SIX

6. Conclusions

6.1.Summary
6.2.Problems Encountered and Solved
6.3.Suggestions for Better Approaches to Problem/Project
6.4.Suggestions for Future Extensions to Project

REFERENCES

APPENDICES

Any other attachments

Program Listing
User manual
CDs or DVDs containing the system