Project Documentation Report
Project Documentation Report
MASTER OF SCIENCE
IN
CHEMISTRY
January 2017
DECLARATION
I hereby declare that the contents of the thesis, “Title” is product of my own research and no part
has been copied from any published source (except the references, standard mathematical and
genetic models/ equations/ formula/ protocols etc.). I further declare that this work has not been
submitted for award of any diploma/ degree. The university may take action if the information
provided is found inaccurate at any stage (in case of default the scholar will be proceeded against
as per HEC plagiarism policy).
Name of Student
Registration No
(Sample Certificate Page)
This is one of the most important chapters of the report. It should begin with a clear
statement of what the project is about so that the nature and scope of the project can be
understood by any reader. It should summaries everything you set out to achieve,
provide a clear summary of the project’s background, relevance and main contributions.
The introduction should set the context for the project and should provide the reader
with a summary of the key things to look out for in the remainder of the report. When
detailing the contributions it is helpful to provide pointers to the section(s) of the report
that provide the relevant technical details. The introduction itself should be largely non-
technical. It is useful to state the main objectives of the project as part of the
introduction. Should have the following headings:
• Project Background/Overview
• Problem Description
• Project Objectives
• Project Scope
Chapter 2
Literature Review
Literature review is a systematic method of identifying, evaluating and interpreting the
work (similar to yours) produced by others. This chapter should set the project into
context and give the proposed layout for achieving the project goals. It is an important
chapter especially if the project involves significant amount of ground work. Review prior
work critically, identify gaps in knowledge/areas of application and build an argument for
your own work. When referring to other pieces of work, cite the sources where they are
referred
to or used, rather than just listing them at the end
Chapter 3
Requirement Specifications
In this chapter, first describe the existing system, its limitations or drawbacks and then
explain how the new or proposed system will overcome these problems. This should
then be followed by complete requirements specification for the proposed system.
Describe the behavior of the system to be developed and include a set of use cases
that describe interactions the users will have with the system. In addition also describe
non-functional requirements. Non-functional requirements impose constraints on the
design or implementation (such as performance engineering requirements, quality
standards, or design constraints). Should have the following headings:
• Existing System
• Proposed System
• Requirement Specifications
• Use Cases
Chapter 4
Design
Systems design is the process of defining the architecture, components, modules,
interfaces, and data for a system to satisfy specified requirements. This chapter should
have the following sections:
4.1 System Architecture
This section describes the system in narrative form using non-technical terms. It should
provide a high-level system architecture diagram showing a subsystem breakout of the
system, if applicable. The high-level system architecture or subsystem diagrams should,
if applicable, show interfaces to external systems. Supply a high-level context diagram
for the system and subsystems, if applicable.
4.2 Design Constraints
This section describes any constraints in the system design (reference any trade-off
analyses conducted such, as resource use versus productivity, or conflicts with other
systems) and includes any assumptions made during the developing the system design.
4.3 Design Methodology
Summarize the approach that will be used to create and evolve the designs for this
system. Cover any processes, conventions, policies, techniques or other issues which
will guide design work. This is for deciding whether you will use structured, object-
oriented or other specific methodologies. Most people will use some object-oriented
technique with UML.
4.4 High Level Design
This section describes in further detail elements discussed in the Architecture. High-
level designs are most effective if they attempt to model groups of system elements
from a number of different views. Typical viewpoints are:
1. Conceptual or Logical: This view shows the logical functional elements of the
system.
Each component represents a similar grouping of functionality. For UML, this would be
a component diagram or a package diagram.
2. Process: this view is the runtime view of the system. The components are threads or
processes or distributed applications. In UML, this would be a process interaction
diagram.
3. Physical: this view is for distributed systems. The components are physical
processors that have parts of the system running on them. For UML, this would be a
deployment diagram.
4. Module: this view is for project management and code organization. The
components are typically files or directories. This picture shows how the directory
structure of the build and development environment will be designed.
5. Security: this view typically focuses on the components that cooperate to provide
security features of the system. It is often a subset of the Conceptual view.
4.5 Low Level Design
This section provides low-level design descriptions that directly support construction of
modules. Normally this section would be split into separate documents for different
areas of the design. For each component we now need to break it down into its
fundamental units or modules. For an OO implementation in Java, our components
would become packages.
Then the low level design will take each package and break it down into its classes. For
smaller systems, you may have a single UML class diagram that each module
description refers to.
4.6 Database Design
The section should reveal the final design of all database management system (DBMS)
files and the non-DBMS files associated with the system under development. Provide a
comprehensive data dictionary showing data element name, type, length, source,
validation rules, maintenance (create, read, update, delete capability), data stores,
outputs, aliases, and description.
4.7 GUI Design
This section provides the detailed design of the system and subsystem inputs and
outputs relative to the user. Depending on the particular nature of the project, it may be
appropriate to repeat these sections at both the subsystem and design module levels.
4.8 External Interfaces
External systems are any systems that are not within the scope of the system under
development. In this section, describe the electronic interface(s) between this system
and each of the other systems and/or subsystem(s), emphasizing the point of view of
the system being developed.
Chapter 5
System Implementation
Implementation is the process of moving an idea from concept to reality. The System
implementation is a realization of a technical specification or algorithm as a program,
software component, or other computer system through programming and deployment.
5.1 System Architecture
Describe the architecture e.g. in terms of: System internal components, Functionality of
the components, Communication between the components Tools and Technology Used
Development Environment/Languages Used Processing Logic/Algorithms Application
Access Security Describe new application access related security measures, e.g. in
terms of: Security Zones/Firewalls, Encryption, Authentication, e.g. Account & Password
structures and rules, Authorization, e.g. operator rights and roles, authority handling,
Auditing / Access Logging, Safe Data Storage Database Security
Describe new DB related security measures, e.g. in terms of: Remote Access,
Authentication (Account & Password: structure, rules), Authorization (rights/roles,
handling), Anonymous and Group Users, Auditing/Logging (events, data, log handling).
Chapter 6
System Testing and Evaluation
The project’s conclusions should list the things which have been learnt as a result of the
work you have done. For example, "The use of overloading in C++ provides a very
elegant mechanism for transparent parallelisation of sequential programs". Avoid
tedious personal reflections like "I learned a lot about C++ programming..." It is common
to finish the report by listing ways in which the project can be taken further. This might,
for example, be a plan for doing the project better if you had a chance to do it again,
turning the project deliverables into a more polished end product.
References
It is important that the students should go to the primary sources of information and an effort
always be made to obtain the information from original articles published in a journal or a reprint
obtained from the author. The tendency to cite the literature from abstracting journals is neither
enough nor in scientific spirit. In only unavoidable circumstances, the secondary source of
information may be utilized or when the original article is in a language other than English.
Secondary reference(s) should be written in parenthesis after quoting primary reference without
the main heading. Following points should be kept in mind while enlisting references.
i. References should be arranged alphabetically according to author and then according to
the year.
ii. A complete reference includes author(s), year of publication, complete title of the paper,
and reference to journal
iii. The number of the issue of the volume of a journal may not be given, unless paging of
each number starts from 1 or issue number may be given in all the references
consistently.
iv. In case of book, the name of the author(s), year of publication, title, edition and complete
address of the publisher must be given and should not be underlined.
v. Names of journals and number of their volumes should not be underlined.
vi. The words ‘Idem’ and ‘Ibid’ may be avoided in citing references.
vii. The word ‘References’ may be used in preference to ‘Literature Cited’.
viii. The title must appear exactly as it does on the first page of article or the title page of the
book.
ix. For titles of scientific papers, only the first letter of the first word is capitalized.
(exceptions are proper names, scientific names or certain other words which are
capitalized always).
x. The family name of the first or sole author precedes the initials or given names. The
names of co-author(s) follow in normal order and are separated by comma.
xi. When the reference is the proceedings of a symposium etc. and the author to be cited is
the editor, it may be indicated as such in parenthesis.
xii. References except of publication by Government department or other organization for
which no author is known, may be listed as Anonymous.
xiii. In case of publications of organizations, learned societies or Government department, the
name of the organization, Government department, Ministry or Division be given in place
of author, if no author is indicated in the publication.
xiv. Work of authors, whether individual or joint should be discussed under different topics or
headings in the review, i.e. integration and analytical treatment.
xv. There are many systems of writing References in vogue in various sciences and journals.
With this end in view, a model list is given below to be followed for uniformity in the
thesis preparation.
2. Nazli, Z. H., M. Arshad and A. Khalid. 2003. 2 – Keto – 4 – methyl thiobutyric acid
dependent biosynthesis of ethylene in soil. Biol. Fertil Soils, 37(): 130–135.
3. Arshad, M. and Z. A. Zahir. 2004. Kinetics of effects of trace elements and electron
complexes on 2 – Keto – 4 – methyl thiobutyric acid – dependent biosynthesis of ethylene in
soil . Letters in Applied Microbiology. 39(): 306 – 309.
Appendices are generally included to help clarification and make readers Understand statements
in the main body of theses or dissertations. In addition, sometimes appendices are useful to
support the interpretation of results. This becomes a record of data for different computations
later by the author or the readers