Philadelphia University
Faculty of Administrative & Financial Sciences
Business Networking and Systems Management Department
Graduation project
Graduation project Requirements:
Abstract
An abstract is a short summary of your completed project. If done well, it makes the
reader want to learn more about your research.
Write your summary after the rest of the paper is completed. After all, how can you
summarize something that is not yet written? Economy of words is important
throughout any paper, but especially in an abstract.
These are the basic components of an abstract in any discipline:
1) Motivation/problem statement: Why do we care about the problem? What
practical, scientific, theoretical gap is your project filling?
2) Methods/procedure/approach: What did you actually do to get your results?
3) Results/findings: As a result of completing the above procedure, what did you
learn/invent/create?
4) Conclusion/implications: What are the larger implications of your findings,
especially for the problem/gap identified in step 1?
However, it's important to note that the weight accorded to the different components
can vary by discipline.
Guidelines
the report is completed, although it is intended to be read first.
contents and list of illustrations.
Style:





Single paragraph, and concise
As a summary of work done, it is always written in past tense
An abstract should stand on its own, and not refer to any other part of the
documentation such as a figure or table
Focus on summarizing results - limit background information to a sentence or
two, if absolutely necessary
What you report in an abstract must be consistent with what you reported in
the documentation.
1
Chapter (1): introduction :
The abstract is the only text in a research paper to be written without using paragraphs
in order to separate major points. Approaches vary widely, however for our studies
the following approach can produce an effective introduction.
General intent
The purpose of an introduction is to a quaint the reader with the rationale behind the
work, with the intention of defending it. It places your work in a theoretical context,
and enables the reader to understand and appreciate your objectives.
An Introduction should contain the following four parts:
1. Background.
In this part you have to make clear what the context is. Ideally, you should
give an idea of the state-of-the art of the field the project is about. But keep it
short: in my opinion this part should be less than a page long.
2. The Problem.
If there was no problem, there would be no reason for a project, and definitely
no reason for reading it. So, please tell the reviewer why she should proceed
reading. A simple sentence like "So far no-one has investigated the link..." or
"The above-mentioned solutions don't apply to the case ...", can sometimes be
enough to clarify the point you want to get at. Experience shows that for this
part a few lines are often sufficient.
3. The Proposed Solution.
Now - and only now! - you may outline the contribution of the project. Here
you have to make sure you point out what are the aspects of your work clearly
highlight what is the difference between your solution and the others. You can
take your time here, but I suggest avoiding getting into too much detail.
4. The project goals and objectives.
This part is related to the proposed solution but in this part u must specify the
goals and objectives for the project by using points.
In addition there can be the following optional ingredients:
5. Related work
6. An anticipation of the conclusions
If you decide to include this into the introduction, you might want to (a) keep
it as short as possible, (b) refer as much as possible to the concluding section,
and (c) keep it well separated from the rest of the introduction.
7. The outline (plan of the documentation)
Personally, I find it useful only for long documentation, otherwise I think it is
a waste of paper. But this is my very personal opinion.
Style:



Use past tense except when referring to established facts. After all, the paper
will be submitted after all of the work is completed.
Organize your ideas, making one major point with each paragraph. If you
make the four points listed above, you will need a minimum of four
paragraphs.
State the goals and objective precisely - do not oversimplify.
2

As always, pay attention to spelling, clarity and appropriateness of sentences
and phrases.
Theoretical background:
Characteristics and advantages of tools used to realise the elements and
components, which used during the project development including
development CASE tools and programming tools and languages.
Chapter (2): planning and analysis :
Project nature and scope.
o
o
o
o
The problem statement
Proposed solution.
Project constraints
Project objectives and goals
Project management:
1) Total cost.
Hardware and Software coast.
2) Time management (time needed to execute project ( use Gantt Charts or
PERT Diagram)) .
Fact finding:
To understand the system, you perform fact-finding using techniques such
as interviews, surveys, document review, observation, and sampling
- document the techniques that used to collect information and the
information that you obtained during this activity
Functional and non functional requirement
Functional requirements.
The functional requirement for a system describe the functionality or services
that the system is expected to provide these depend on the type of the project
which is being developed.
Non functional requirement
Constraints on the services or functions offered by the system.
You must mention the following system characteristics, speed, volume,
capacity, availability, and reliability
System use cases:
1) System actors.
An actor is someone or something that is external to the system, but
going to interact with the system.
3
that is
2) Use case description.
A use case description documents the name of the use case
Names of the actors, a description of the use case
A step by step list of the tasks and actions required for successful completion,
a description of alternative causes of action preconditions post conditions and
assumptions
3) Use case model.
A use case represents the steps in a specific business function or process, a use
case is a complete sequence of related actions initiated by an actor
System DFDs :
1) Contacts diagram.
The context diagram represents the information system’s scope and its
external connections but not its internal working; context diagram is the first
DFD in every business process.
Context diagram shows the context into which the business process fits it
contains only one process, representing the entire system.
2) Level zero diagram.
Diagram 0 displays the information system’s major processes, data stores, and
data flows and its exploded version of the context diagram’s process symbol,
which represents the entire information system
3) Lower level .
Lower level DFDs show additional detail of the information system through
the leveling technique of numbering and partitioning
Chapter (3): project design:
1- Data dictionary:
 A data dictionary, is a central storehouse of information about the system’s
data





Data item dictionary.
Data structure dictionary .
Data store dictionary .
Data flow dictionary .
Function description dictionary.
2- Data design
Determine the system entities and attributes.
Database design:
 create an initial ERD
 assign all data elements to entities
 create 3NF designs for all tables, taking care to identify all primary and
foreign keys
 generate the final ERD that will include new entities identified during
normalization
4
3-Interface & Screens Design
4-Input, Output & report Design.
5-Control Design.
Chapter (4) : project implementation :
Application Development
In this part you must document your software modules
 Module: A module consists of related program code organized into small units
that are easy to understand and maintain.
 you will refer to DFDs, process descriptions, ERDs, and anything else that
describes the functions that program or module must perform
_ User manual.
In this part you will refer to functional requirement part, mentioned each user,
describing how to execute each function using step by step method.
Chapter (5): Conclusion and future work:
future work .
In this part you can mention any future updates and upgrades that you can add to your
project, any new requirement and futures that can be added in later stages.
Conclusion.
Conclusion can be the most difficult parts of documentation to write. A writer needs
to keep in mind that the conclusion is often what a reader remembers best. Your
conclusion should be the best part of your paper. Conclusion frames your thoughts
and bridges your ideas for the reader. Your conclusion is your chance to have the last
word on the subject. The conclusion allows you to have the final say on the issues you
have raised in your project, to summarize your thoughts, to demonstrate the
importance of your ideas, and to propel your reader to a new view of the subject. It is
also your opportunity to make a good final impression and to end on a positive note.
A conclusion should



Stress the importance of the project statement,
Give the documentation a sense of completeness, and
Leave a final impression on the reader.
5
Suggestions

Answer the question "So What?"
Show your readers why this project was important. Show them that your
project was meaningful and useful.

Synthesize, don't summarize
o Don't simply repeat things that were in your documentation. They have
read it. Show them how the solution you made was not random.

Redirect your readers
o Give your reader something to think about, perhaps a way to use your
project in the "real" world. If your introduction went from general to
specific, make your conclusion go from specific to general. Think
globally.

Create a new meaning
o You don't have to give new information to create a new meaning. By
demonstrating how your ideas work together, you can create a new
picture.
References.
6