Faculty of Computer Science & Information Technology

GRADUATION PROJECTS: Final Documentation Guidelines

April, 2014

© Mogadishu University, 2014

1. Project Documentation Structure:

Title Page (see sample)

Acknowledgements

Abstract

Table of Contents

Table of Figures

List of Tables

Chapter One: Project Initiation

Chapter Two: Literature Review

Chapter Three: Planning And Requirements

Chapter Four: Project Analysis and Design

Chapter Five: Implementations

Chapter Six: Testing

Chapter Seven: Conclusions and Future improvements

 Bibliography

1|Page

© Mogadishu University
Acknowledgements: The Acknowledgements lists the names of anyone who
may have given you valuable assistance in your project.

Table of Contents: The Table of Contents outlines the different sections of the
report, and shows the reader where to find them. It contains a list of all the
chapters, sections and sub-sections and their corresponding page numbers. The
Table of Contents can be generated electronically using Word.

Table of Figures: In this section, all figures (including photographs, drawings

and graphs) in the report are to be listed together with respective page numbers.
The numerals and title (legend) for a figure are placed below it and start at the
left margin at the bottom of the page.

List of Tables: In this section, all tables in the report are to be listed together
with respective page numbers.

Tables and figures should be placed as close as possible to the text where they
are first cited. Tables and figures in the appendices should be numbered
consecutively following those in the text.

Abstract: This gives the reader a general overview/summary of the whole

report without them having to read the entire document. It should be able to
stand alone as a separate document if required.

2|Page

© Mogadishu University
Chapter One: Project Initiation

The Project Initiation Phase is the first phase in the Project Management Life Cycle,
as it involves starting up a new project. You can start a new project by defining its
objectives, scope, purpose and deliverables to be produced.

The purpose of this chapter is to orientate your reader with the whole project.

In this phase you should include the following sections:

a. Problem Overview (Problem Definition)

b. Current / Existing systems
c. Purposes/Goals of the project
d. Stakeholder Analysis.
e. Risk Analysis
f. Project Constraints

a. Problem Overview

Before a project can begin, there has to be a reason why it should take place.

In this phase the problem that the system is meant to be overcome should be
defined.

For example the following statements may appear in the Problem Definition.

...The existing system cannot transfer data to the new invoice system...

...Staff member has to spend three hours loading information...

b. Evaluation of Current / Existing systems

In this section an evaluation of the existing systems which are related to the
project's problem should be produced. This evaluation discusses some examples
of current existing systems along with its functionalities, features, weaknesses
and technology used.

c. Purposes/Goals of the project

This is a short, measurable statement of what the product is intended to do and what
advantage it brings to the business.

Aspects of a Goal:

Purpose – what does it do?

Advantage – business advantage
Measurement – how to measure
Feasible – can product achieve measure?
Achievable – can organization build?

3|Page

© Mogadishu University
Project Goal Example

Goal measurement is testable and provides guidance to help the project team focus their
attention on those requirements that make the greatest contributions to meeting the goals.

d. Stakeholder Analysis

Stakeholders include anyone with an interest in, or an effect on, the outcome of the
product. For example, you are a stakeholder because you have an interest in the
requirements. The users of the product are stakeholders because they have an interest in
having a product that does their work correctly.

The importance attached to stakeholders comes from the fact that they are the
source of all your requirements.

The following table should be used in this section to list the stakeholders:

Stakeholder Inter Importance

e. Risk Analysis

Risk analysis should be performed as part of the initiation process for each project. The
data of which would be based on risk discussion to identify potential issues and risks
ahead of time before these were to pose cost and/ or schedule negative impacts.

4|Page

© Mogadishu University
 *scale from 1= low severity to 5= high severity
f. Project Constraints

Solutions Constraints

 Allowable Designs
 Pre-packaged Solutions – Commercial off-the-shelf applications

Product Constraints
 Financial constraints • Time constraints

The following deliverables should be given as well in this phase:

• Activities,sequencing and duration estimating (Use Gantt Chart)

• Resource Planning
• Cost estimating and Budgeting.
• System Development Requirements (Environment and/or Tools, Utilities,
Software, Hardware, etc...)

Chapter Two: Literature Review

A literature review is the presentation, classification and evaluation of what other

researchers have written on a particular subject.

A literature review is organized according to your project objective.

(See Appendix D to view a sample of Literature Review).

5|Page

© Mogadishu University
Chapter Three: Planning and Requirements

In this phase the requirement specification should be produced using the Volere
Requirements Specification Template (see Appendix A).

Volere is the result of many years of practice, consulting and research in requirements
engineering. They have packaged their experience in the form of a generic
requirements process and requirements template.

The Volere requirements process is described in the book:

"Mastering the Requirements Process by Suzanne and James Robertson,

Addison-Wesley, London, 1999. ISBN is 0-201-36046-2"

The Volere Requirements Specification process required the following activities:

a. Setting The Scope (Scope Diagram) Deciding how much work will be
done. Should contain the product purposes and addresses the domains of
interest as well.

b. Define the Business Events from the Scope diagram (each of the flows that
enters & leaves the system is a business event). The business events are
user-defined. The response to each event represents a portion of work that
contributes to the total functionality of the work.

c. Discuss the requirements gathering and trawling techniques which used to

find and understand the requirements of the project.

d. Show how work responds to Events by writing the product use case
scenario for each Business Events.

e. Using the product use cases steps; write down the functional and non-
functional requirements with their fit criterion (measurement) and type.

6|Page

© Mogadishu University
Chapter Four: System Analysis and Design

Based on the understanding from the Planning and Requirements phase, this
chapter should include the analysis and design of your system. Sections of this chapter
should include (see Appendix B):

a. Project's main features along with their corresponding requirements.

b. Use Case Diagram.
c. Activity Diagram.
d. Class Diagram.
e. Sequence Diagram or collaboration Diagram.
f. State Diagram
g. Deployment Diagram
h. Database Design (ERD).

A detailed list of project's main features should be produced along with their
corresponding requirements for verification.

Chapter Five: Implementation

Based on the findings from the Requirements and Design phases, a detailed
description of the development of the project's features should be produced here along
with a detailed description of the Process Model used.

For each feature describe the following:

• Line of Code (LOC).

• Database tables and fields.
• Components and/or code reused (ReLOC).
• Interfaces with hardware devices.
• Describe any problems that may have arisen during implementation
• Requirement completed/ uncompleted list.

User Manual

In addition to the above, a System User Manual should be given here. User Manual
section provides a general overview and a detailed description of system functions.
In addition, a detailed list of the hardware devices, if used, should be given to cover
the full device specification.

Do not attempt to describe all the code in the system, and do not include large pieces
of code in this section.

7|Page

© Mogadishu University
Chapter Six: Testing

Requirement testing

When you have a requirement for the product to carry out some function or to have
some property, the testing activity must demonstrate the product does, indeed,
perform that function or possess the desired property.
To carry out such tests, the requirement must have a benchmark such that the testers
can compare the delivered product with the original requirement. The benchmark is
the fit criterion a quantification of the product that demonstrates the standard the
product must reach.
In this section all the project's features along with its requirements should be
tested here using the fit criterion.

System testing

In this section each goal of the project should be tested using the measurement which
defined and assigned to the goal.

Furthermore, a list of test cases along with its input and desired output should be
given and discussed in this section.

Chapter Seven: Conclusion and Future Improvements:

The purpose of the Conclusion is to restate in a shortened form the most important
points of your project. These must be clear and positive. Never introduce new
material in the conclusions. Another section in this chapter is the future improvement
section, which should purpose suggestions about the action(s) or future direction(s)
that should be taken as a result of your project. You should mention possible
enhancements or extensions to your project.

Bibliography:

This contains a list of all the sources you have either used or referred to in your
document. Harvard System for referencing should be used here (see Appendix C).

Appendices:

The Appendices contain any supplementary materials you have used in your project
or that you would like to include to complete the reader's understanding of your
project.. Each Appendix needs to be labelled and numbered and listed in the Table of
Contents.

8|Page

© Mogadishu University
2. Documentation Style:
2.1 Language:
The document must be written in English and should not exceed 50 pages in total
excluding Appendices. Make sure that the document is free from spelling or
grammatical errors.

2.2 Format:
The final project report should be prepared in accordance with the following
instructions for consistency and to facilitate the binding process.

 The document should be printed on plain white paper of A4 size (210 x 297 mm). It
should be free from any visible corrections (no cross outs, type-over, or handwritten
corrections).

 Use Times New Roman font, of point size 12. Text font color – black. Use
double spacing.

 Pages should be printed on one-side only.

 Margins should be left justified and 1 inch on top, bottom and right; 1.5 on
left.

 Number the pages on the bottom, right, using Arabic numbers for the body. Use
lower case Roman numerals for the preliminary pages. Number the pages in the
appendices with the appendix letter and a page number, e.g., A-1, A-2,…, B-1.

 Figures and tables should fit on the A4 size paper. They may be in landscape
orientation and you may use a smaller font (no smaller than 8 point).

 Figures and tables must be made self-explanatory by proper labeling and

captions. Captions should be centered under the tables and figures.

 Sections should be numbered as decimals of the chapter number (e.g. 1.1., 1.2,
1.3). You can use a maximum of three level headings.

2.3 Submission:

You must submit THREE copies of your project to your supervisor. The copies should be
soft bound.

9|Page

© Mogadishu University
Appendix A. Volere Template
Volere is the result of many years of practice, consulting and research in requirements
Engineering. They have packaged their experience in the form of a generic
requirements process, requirements training, requirements consultancy, requirements
audits and this requirements template.

The Volere requirements process is described in the book:

"Mastering the Requirements Process by Suzanne and James Robertson,

Addison-Wesley, London, 1999. ISBN is 0-201-36046-2"

10 | P a g e

© Mogadishu University
Case Study - IceBreaker

IceBreaker is a case study we’ll use to demonstrate the Volere process. It uses a
variety of data to predict exactly when ice will form on roadways , and it uses
these predictions to schedule trucks to treat the roads with deicing material (a salt
compound) before the roads become dangerous.

The IceBreaker case study uses subject matter knowledge from the many weather/ice
forecasting and road de-icing systems, and other products produced by Vaisala (U.K.)

Project Goal Sample:

1. Setting the Scope

— Deciding how much work will be done. Should contain the product purpose
and other constraints. Also should address the domains of interest is a subject
matter area.

— Domains of Interest – IceBreaker Case Study

— Roads
— Weather
— Scheduling
Trucking
Scope Diagram

11 | P a g e

© Mogadishu University
 2. Business events

To identify logical chunks of the system that can be used as the basis for
discovering detailed requirements. These business events also provide the
subsystems that can be used as the basis for managing detailed analysis and
design.

The business events are user-defined. The response to each event represents a
portion of work that contributes to the total functionality of the work.

An event list identifies all the business events to which the work responds. The
event list includes:

 Event Name
 Input from other systems
 Output from other systems

Event List

3. Requirements gathering and trawling techniques

This section explores the techniques for discovering and determining both the
requirements and the people involved in the process. You have two major
concerns here: finding all of the requirements and finding the correct
requirements.

12 | P a g e

© Mogadishu University
 4. Product use case scenario

Determine the best response that the organization can make to the business
event. It also determines the way that the product will contribute to the
desired response.

The product use case sets out the functionality of the product by showing
the steps that will be part of the product.

The following template should be used in writing the product use case
scenarios:

Business Event Name: The name of the business event to which the business use case responds.

product Use Case Name and Number: Give each business use case a unique
identifier and a name that communicates the functionality for example, Record
Library Loan, Register New Student Enrollment.

Trigger: The data or request for a service that arrives from an external source and
triggers a response from the work. The trigger may be the arrival of data from one of
the adjacent systems that is, from outside of the work area that you are studying.

Preconditions: Sometimes certain conditions must exist before the use case is valid.
For example, a customer has to be registered before he can access his frequent-flyer

Interested Stakeholders: The people, organizations, and/or representatives of

computer systems who have knowledge necessary to specify this use case or who
have an interest in this use case.

Active Stakeholders: The people, organizations, and/or computer systems that are
doing the work of this use case. Don't think about users just yet; instead, think of the
real people who are involved in the work of the business use case.

Normal Case Steps: The steps that this use case goes through to complete the normal
course of its work. Write the steps as clear, natural-language statements that are
understandable to business people related to the project. There are usually between
three and ten steps.

Step 1 ...
Step 2 ...
Step 3 ...

Alternatives: Alternatives are acceptable variations on the normal case of processing.

For example, gold cardholders may be given an invitation to the lounge when they
check in. Tell the story in the same way:

Alternative step 1 . . .
Alternative step 2 . . .

13 | P a g e

© Mogadishu University
 Alternative step 3 . . .

Exceptions: These are unwanted but necessary variations. For example, a customer
may have insufficient funds for a withdrawal at an ATM.
Tag each exception to the appropriate step:

Exception 2.1 . . .
Exception 2.2 . . .
Exception 2.3 . . .

Outcome: The desired situation at the end of this use case

5. Functional Requirements

Functional requirements describe what the product has to do to satisfy the

work or business, and are independent of any technology used by the product.

How to Find Them

Product use case steps provide a medium for determining all of the functional
requirements that are needed by each step.

14 | P a g e

© Mogadishu University
 Example:

Let's see how this process works by using an example of a product use case
scenario. In the IceBreaker road de-icing system, one of the use cases is
"Produce Road De-icing Schedule."

Product use case: Produce road de-icing schedule

Steps:

1. Engineer provides a scheduling date and district identifier.

2. Product selects the relevant thermal maps.
3. Product uses the thermal maps, district temperature readings, and
weather forecasts to predict temperatures for each road section for the
district.
4. Product predicts which roads will freeze and when they will freeze.
5. Product schedules available trucks from the relevant depots.
6. Product advises the engineer of the schedule.

For each one asks, "What does the product have to do to complete this step?"
For example, the first step in the scenario is

1. Engineer provides a scheduling date and district identifier.

The first functional requirement to come from this step is fairly obvious:

The product shall accept a scheduling date.

15 | P a g e

© Mogadishu University
When you ask the stakeholders whether there is anything special about the scheduling
date, they tell you that scheduling is never done more than two days in advance. This
information suggests another functional requirement:
The product shall warn if the scheduling date is neither today nor the next
day.

Another requirement from the first step is

The product shall accept a valid district identifier.

Functional Requirements Fit Criterion

Each functional requirement must have a fit criterion. The fit criterion depends on the
required action. For example, if the requirement is to record some data, then the fit
criterion would say that the data must be able to be retrieved and must match certain
standards.

"We add a fit criterion to the requirement to clarify it and make it testable".

For example:

Description: The product shall record the weather station readings.

Fit Criterion: The recorded weather station readings shall be identical to the
readings as recorded by the transmitting weather station.

6. Nonfunctional Requirements

The nonfunctional requirements are the qualities your product must have, or how well
it does the things it does. They make the product attractive, or usable, or fast, or
reliable, or safe.

You write nonfunctional requirements when you need your product to have a
particular appearance, or be used by nonreaders, or adhere to laws applicable to your
kind of business.

A product use case represents an amount of work the product does when the work is
responding to a business event. The scenario breaks the product use case into a

16 | P a g e

© Mogadishu University
number of steps; for each of these steps, you can determine the functional
requirements.

Some of The nonfunctional requirements can be linked directly to a functional

requirement, some apply to the use case as a whole, and some apply to the entire
product.

Following are the nonfunctional requirement types that should be used:

Look and Feel: the spirit of the product's appearance

Usability and Humanity: the product's ease of use, and any special usability
considerations needed for a better user experience

Performance: how fast, how safe, how many, how available, and how accurate the
functionality must be

Operational: the operating environment of the product, and any considerations that
must be taken into account for this environment

Maintainability and Support: expected changes, and the time needed to make them;
also specification of the support to be given to the product

Security: the security, confidentiality, and recoverability of the product

Cultural and Political: special requirements that come about because of the culture and
customs of people involved in the product's operation

Legal: the laws and standards that apply to the product

The requirement type is a device to help you to find the requirements; think of it as a
checklist.

Non-functional Requirement Fit Criteria:

17 | P a g e

© Mogadishu University
Example:

Description: The product shall be user-friendly.

A suggested fit criterion for this "user-friendly" requirement is this:

Fit Criterion: New users shall be able to add a road, change a road, and delete
a road within 30 minutes of their first attempt at using the product.

18 | P a g e

© Mogadishu University
Appendix B. System analysis and design
a. Grouping Requirements into features

The scope diagram is the highest level statement of requirements; it is decomposed

into the next level, the business events. The level below the business events comprises
the product use cases, each of which is decomposed into a number of product use case
steps. Then it becomes possible to group atomic requirements into features;

b. Use Case Diagrams

Use case diagrams show business use cases, actors, and the relationships between
them.

19 | P a g e

© Mogadishu University
 c. Activity Diagram

To understand a product use case, the information from the use case diagram
is not sufficient. The chains of interactions that are behind each product use
case have to be described.

Activity diagram of a steps of the product use case “check-in”

20 | P a g e

© Mogadishu University
 d. Sequence Diagram

If a customer uses an offered service, partners communicate with each

other. The process can be described as a series of interactions. These
interactions are clearly laid out in the sequence diagram.

A sequence diagram illustrates the various steps of a product use case

For more information about UML diagrams and their notations visit this Link

21 | P a g e

© Mogadishu University
Appendix C. References/Bibliography - Harvard Style

Referencing with Harvard

When writing you must acknowledge the source of your ideas and quotes in sufficient
detail so that those reading can locate the item. Referencing is important to avoid
plagiarism, to verify quotations and to enable readers to follow up what you have
written and locate the cited author’s work.

The ―Harvard style‖ is a generic author-date style for citing and referencing
information used.

Keep in mind the following points:

 Write down all the citation details of a source as you use it.
 Place quotation marks ― ― around a direct quote and include page number(s)
when quoting directly.
 Insert brief citations at the appropriate places in the text of your document.
 Compile a reference list at the end of the document that includes full details of
all references cited.

In-text citations:
In an author-date style, in-text citations usually require the name of the author(s) and
the year of publication.

(Redman, 2006)

How to create a reference list/bibliography

A reference list contains only the books, articles, and web pages etc that are cited in
the text of the document. A bibliography includes all sources consulted for
background or further reading.
A reference list is arranged alphabetically by author. If an item has no author, it is
cited by title, and included in the alphabetical list using the first significant word of
the title.

Book with one author

The required elements for a book reference are:

Author, Initials., Year. Title of book. Edition. Place of publication: Publisher.

Example:

Redman, P., 2006. Good essay writing: a social sciences guide. 3rd ed. London: Open
University in assoc. with Sage.

22 | P a g e

© Mogadishu University
Books with two, three or four authors

For books with two, three or four authors of equal status the names should all be
included in the order they appear in the document. Use and to link the last two
multiple authors.

The required elements for a reference are:

Author, Initials., Year. Title of book. Edition. Place: Publisher.

Example:

Weiss, T.D. and Coatie, J.J., 2010. The World Health Organisation, its history and
impact. London: Perseus.

An in-text reference for the above examples would read:

Leading organisations concerned with health (Weiss and Coatie, 2010) have proved
that…………

E-Books and PDFs

The required elements for a reference are:

Authorship, Year, Title of book. [type of medium] Place of publication: Publisher.

Followed by Available at: include web address or URL for the actual pdf, where
available [Accessed date].

Example:

Bank of England, 2008. Inflation Report [pdf] Available at:

<http://www.bankofengland.co.uk/publications/inflationreport/ir08nov.pdf>
[Accessed 20 April 2009].

An in-text reference for the above example would read:

Recent evidence (Bank of England, 2008, pp.32-33) show the trends ...

Journal articles

For journal articles the required elements for a reference are:

Author, Initials., Year. Title of article. Full Title of Journal, Volume number
(Issue/Part number), Page numbers.

Example:

Boughton, J.M., 2002. The Bretton Woods proposal: an brief look. Political Science
Quarterly, 42(6), p.564.

23 | P a g e

© Mogadishu University
Course material / lecture notes

The required elements for a reference are:

Lecturer/Author, initial. Year. Title of item, Module Code Module title. HE

Institution, unpublished.

Example:

Williams, B., 2008. Guide to project management, BD45001S Management. Anglia

Ruskin University, unpublished.

An in-text reference for the above example would read:

(Williams, 2008)

Websites

For websites found on the worldwide web the required elements for a reference are:
Authorship or Source, Year. Title of web document or web page. [type of medium]
(date of update if available) Available at: include web site address/URL (Uniform
Resource Locator) [Accessed date].

Example:

NHS Evidence, 2003. National Library of Guidelines. [online] Available at:

<http://www.library.nhs.uk/guidelinesFinder> [Accessed 10 October 2009 ].

For more information about Harvard referencing system visit the following link:

Harvard System

24 | P a g e

© Mogadishu University
Appendix D. Literature Review Sample

Topic: "Using computer technology to focus on form in corrective

feedback".

[Introduction]
Linguists and educationalists have for many years had conflicting views about the
value of correcting linguistic errors (Dawson, 2001] in the speech and writing of
second language learners. With regard to the practice of correcting written errors, one
extreme view is that corrections do not have a significant effect on student errors and
teachers should, therefore, adopt less time-consuming efforts to direct students'
attention to surface error (Robb, Ross and Shortreed 1986:91). The more moderate
view does not dismiss the value of correction as a useful teaching technique, but
rather, it emphasises the importance of consistency and systematicity if the positive
effects of correction[2] are to be realised (Cohen and Robbins 1976:60; Rivers
1981:306; Lalande 1982:140.

In second language teaching/learning, the purpose in providing feedback such as

'correction', i.e., 'corrective feedback' (Schachter 1991:89), is to supply learners with
'negative evidence'[3] which attempts to draw their attention to the linguistic errors
made (Ellis 1994:584), or to "what is ungrammatical in their sentences" (p. 434).
According to Gass (1991:140), focusing attention on form through corrective
feedback is similar to grammar instruction in the way that it alerts "learners to the
mismatch between their learner language form and the target language". Indeed, a
number of studies investigating the effect of corrective feedback in speech (Tomasello
and Herron, 1989:394; Lightbown and Spada 1990:443; Carroll and Swain,
1993:372), and in writing (Lalande 1982:145) support the view that learners can
improve their conscious knowledge of the target language through a focus on form in
the corrective feedback.

[Conclusion]
The above discussion has highlighted the benefits of using a concordance as a
research tool for investigating and focusing on regular patterns of language use
(Lalande 1982:145) and [Carroll and Swain, 1993:372]. It reviews a range of previous

25 | P a g e

© Mogadishu University
applications that have used concordance data as stimuli for investigating students'

linguistic errors. The technique proposed in this study extends on these previous
applications by providing students with two types of stimulus for focusing on
linguistic form (Carroll and Swain, 1993:372): 1) the negative evidence of extensive
corrective feedback, and 2) the positive evidence of concordance data which the
students generate independently from a corpus of their own reformulated texts. The
next section elaborates further on the proposed technique and provides a detailed
account of the method used to trial it.

26 | P a g e

© Mogadishu University