How to write the Project Proposal Tutorial 2019
The final year projects are considered as one of the core modules for computer science and information technology studies at the undergraduate levels.
This tutorial explains how to write the Project Proposal and select a topic for the project. And explores all the phases of a project planning and Proposal with best sample templates and examples in 2019.
Regardless of different approaches in computer science and IT education at different universities, the main theme of the final year projects is to implement an idea using software development tools. Although the projects are mostly individual projects, however, there are cases in which group projects are considered as final year projects.
However, when it comes to the final year project, it is considered to be more comprehensive and to cover and utilize most of the knowledge that students have already been obtained.
In fact, when students start their final year projects it is assumed that they have received the fundamental knowledge that they need in order to sufficiently conduct their projects and other final year modules/ courses should be considered supplementary to the project implementation.
Despite the fact, when it comes to the action point, students face many issues, such as:
What is a proper topic that I can choose?
How can I conduct my project?
What is the methodology and which one is good enough for my project?
What are the stages that I should go through?
What kind of tools should I use?
How can I prepare my report?
What kind of documents should I submit?
Although some of these questions might have been answered within the guidelines that faculties/ departments/schools provide students with, in reality, many of students ask their lecturers/professors these questions again. The followings aim to answer these questions and to show students how to tackle their final year projects.
The discussion would start by showing how to choose a project topic and continue on how to conduct the project methodology.
How to Choose a Project
To choose a proper topic is the first step in doing your project. Usually, according to their procedures, the school/department, where you are studying, publishes a list of project topics at the beginning of every semester/year. Different schools, however, follow different approaches in publishing this list.
Some publish the list, which only includes the project topics, some others allow every supervisor to publish their own list, some publish the supervisor's list alongside their related projects, and yet some publish the list with a brief explanation of the problem area.
Regardless of whichever of these approaches is the case, almost all schools give an opportunity to the students to suggest their own ideas and topics for their final year projects. However, whether the schools accept the suggestion or not depends on the criteria that they consider in their proposal acceptance process.
In the following sections, the project selection task will be discussed in detail. In this discussion two main cases, namely, to choose to form a list or to suggest your own topic will be explained.
In addition, a method will be provided that enables you to choose your project objectively and to eliminate the subjectivity as much as possible. Moreover, although the topic selection is the main theme of this, a section on choosing a supervisor has been provided for the situations that it is applicable
Choosing a Topic from the Project List
Like many other activities, usually, the first steps of a project are very crucial. In your final year project, the first step is to choose your project topic. It is very important to dedicate a proper amount of time in order to make your decision.
Bear in mind that you have to live with your project for a semester or in most cases for a year, so it is better to choose a topic, which is true of your interest.
Equally important, do not forget that you should be wise enough to choose a topic that you can accomplish. Therefore, you should be as honest and frank with yourself as possible.
Sometimes, the supervisor who is supposed to supervise you may know your background and advise you to do not take the project that you have selected and choose another one instead.
In the majority of cases, it is better to take this kind of advice. Indeed, if you could not strongly defend your suggestion and to convince your supervisor that you would be able to accomplish the project, it would be much more wise and safe if you reconsider your proposal and change your topic.
Below you can find a general guideline that you can follow. Experience has shown that it works fine.
Tips on choosing a project topic before Project proposal
Study the topics carefully and thoroughly. This is important because if you miss a topic that can be suitable for you, one of your classmates may take it. Although this is not a competition per se, the projects assignment cannot avoid applying some sort of prioritization procedures.
Consider the harmony between the heart and the brain!
Choose a topic that is attractive but at the same time, you think that it is doable. This is important to understand that no matter how much the topic is attractive at the end of the day if you do not deliver its minimum requirement you cannot receive a pass.
Choose among the topics of a supervisor(s) with whom you feel that you can comfortably communicate.
Choose more than one topic to have more flexibility; three is a good number, then!
Before having further discussions on the case, it is worth it to notice that you can decide on your final project, intuitively, which means without investigating any fact and factor and simply by following your desires and feelings. However, you will be lucky if it comes out as the right decision.
Nevertheless, if you do not want to take this risk, and then follow a systematic approach to make your decision. In order to show you how to follow a systematic approach to select your final year project, let us consider an example.
Suppose that you have chosen three project topics, among the 30 ones that are available and you have prepared a short list of which, without any prioritization, as below:
Assuming that all three are open to you to choose from, how can you prioritize this short-list? Obviously, the above selection shows a very broad boundary of desire. In fact, they have been deliberately selected to be so in order to show you the important parameters that you should take into account when you make your decision.
Moreover, later in this section, you will find out that each one of those projects needs different levels of skills and requires knowledge of different areas. Now, you have to decide how to prioritize this short list.
First, you should consider that these projects need different levels of programming and technical skills. In addition, they need different levels of knowledge of other subject areas. While all of them need good programming skills, certainly a higher level of programming challenges would be anticipated for the first and the third topics.
On the other hand, the second topic needs a good knowledge of business system analysis and database applications. Moreover, the third topic needs some knowledge of mobile computing and applications.
Again, this topic needs some background on cryptography, while the first topic needs a good understanding of the speech-related technologies. Now, we go back to the question that we had at the beginning of this paragraph, “How can you make your final decision?”
In order to answer this question, you have to measure each project’s “suitability ” degree to you. In order to do so, a method will be introduced that helps in this measurement process. To keep this measurement method simple, we assign some measurable parameters to each project and we call them selection parameters.
Again, for the sake of simplicity and applicability, we summarize these selection parameters into three categories, namely, Interesting, Background Knowledge, and Required Skills.
The parameters will be described shortly. In addition, to measure each parameter, we assign each one two attributes, namely a Coefficient and a Percentage. As a result, we have a proper foundation based on which we can apply our method.
Now, to measure each project’s “suitability”, you should assign a percentage to the Degree parameters to show each parameter’s value. The coefficient is a fixed number, from 1 to 5, which shows the weight of the parameter, or its importance, if you prefer. The Coefficient must remain the same for all projects that you have selected.
Consequently, the revised list should be considered as your guide in order to choose your project topic. However, sometimes we might not like the outcome! Well, this is the reason for the measurement process. Indeed, it prevents any subjective decision and shows you the factual and objective outcome.
Nevertheless, the harmony between the heart and the brain, as it was mentioned earlier, is very important. But, instead of trying to change the result mechanically, be careful when you are providing the data for each parameter in the first place and do accept the result, afterward.
Proposing Your Own Topic
There are situations that you cannot find a proper project in the school’s proposed list. You may face this situation because of different reasons.
For instance, it might be because you are simply not satisfied with the proposed topics, or it might be because all the topics, which are of your interest, have already been taken by your classmates.
Whatever the reason is, you should either select a project that does not suit you or propose your own topic(s). The farmer choice would not be a wise one unless you are forced to do so.
If that is the case then you should apply the same method that was introduced to you in the previous section. However, in this new situation, you are going to select among the closest topics that still are open to being selected.
If you have to propose your own idea, it would be better to think about more than one topic; again, three would be a magic number. This time, the situation can be more difficult than the normal circumstances that we discussed, earlier.
In fact, you need to use your creative talents to come up with proper ideas. However, the general guidelines below can help you to find your way:
Tips on proposing your own topic for Proposal
Be creative. Look around at the school, university, your hometown, province, state, and country and try to find a subject, which has not been automated.
Look at new technologies, specifically those that are related to mobile computing and web technology. You can find many areas that these technologies can be applied for the first time. Clearly, this situation is more popular in developing countries and regions.
Focus on the subjects that you like their status to be improved using automated systems and computers. These subjects can be selected from different origins such as education, health, globalization, tourism, global warming, lifestyle, culture, entertainment (specifically gaming), etc.
Choose three topics in order to provide your school and yourself proper flexibility with your proposals.
Write a couple of paragraphs that state the problem area and why you think this topic is important to be considered as a final year project. The writing process provides you an opportunity to rethink the topics and to establish the grounds based on which you can defend your proposals.
As soon as you prepared your short list, apply the method that we discussed, earlier, to prioritize the topics. Next, provide the list to the proper authority, who is supposed to decide on your topics.
Normally, in this situation, you have to talk to your prospect supervisor. As it was mentioned in the previous section, although you need to defend your proposal strongly, however, it is very important to listen to your supervisor carefully and to take her/his advice on your proposals seriously.
Choosing a Supervisor
Some schools allow you to choose your supervisor, but some do not. If you do not have the opportunity to choose your supervisor, then maybe you can simply skip this section, however, even if that is the case, you still can get some good advice regarding supervisors in this section.
The supervisor’s responsibility is explained by most of the guidelines that schools prepare and disseminate regarding the final year projects. Usually, these guidelines properly inform the students that their supervisors do not provide them with solutions but the general roadmap to the solution.
Moreover, the guidelines advise them about the main issues of the project. Nevertheless, students expect to have at least some hints about their projects during different stages of the project and to receive some feedback, which is specifically addressing different aspects of the selected topic. However, students are told that the project is their responsibility.
It means that they have to accept all the consequences of not attending to the supervisor meetings. Again, this is the student responsibility, to seek and follow their supervisor feedbacks on their project according to a preplanned timetable.
Nevertheless, supervisors can have a significant impact on your project. Many factors participate in this impact such as supervisor’s experience in the project area, her/his experience on the supervision, the time she/he can dedicate to each student, her/his interest in the project topic, her/his personality and communication style.
However, it is not always possible to choose your favorite supervisor. This is because sometimes the supervisor that can help you more does not propose the topics of your interest.
Because of all the topics that she/he has proposed have already been assigned to your classmates. Below you can find some general hints regarding supervisor selection.
Tips on choosing a supervisor for Proposal
Choose among the topics of a supervisor with whom you feel you can comfortably communicate. However, you should consider the topics based on the topic selection, at the first step
Choose a supervisor that has the knowledge of the area of the chosen topic.
Consult with graduate students about their experiences with different supervisors.
Choose more than one supervisor and prioritize your list.
Talk to the prospect supervisors as soon as you can and register your name with them.
If you have selected more than one supervisor, let them be informed that you have done so.
Project proposal planning
The next step, after you selected your project topic, is Project proposal. Project planning subject is taught, one way or another, at different schools.
Despite the fact, Project proposal is quite a common phenomenon among the students to undermine this step extensively, which cause them to submit incomplete projects or face late submission.
Actually, in software engineering and development, project planning is intertwined with the methodology in a way that sometimes it is difficult to separate these subjects from each other.
However, to understand the whole roadmap of conducting a project, these two concepts would be discussed in two different, though the relation between the two would be maintained and addressed wherever appropriate.
Having this, in the current we will focus on the planning step, then we will discuss the methodology and its influence, and impacts on the project plan in the next.
Main phases of a project plan and Proposal
Using one of the tools, such as Microsoft Project, Microsoft Visio, and OpenProj, etc. that can help you in preparing a Gantt chart, devise a first-cut plan including the following major steps:
Understanding the problem area
If you are not familiar with the Gantt chart, which was mentioned in the previous step, and have not experienced the tools that you can use to create one at this stage, do not worry because these concepts would be presented in the following sections.
However, although we are not going to discuss these concepts in a very detailed format, you can find general explanations that can help you plan and manage your projects, effectively.
Project plan in a simple format is a document that explains 4Ws + H, which means What is going to be done, When it is going to be done, Who is going to do it, Where this is going to be done, and How it is going to be done. This concept has been rephrased again as below:
Questions about the Project and Proposal Plan
However, although the above topics are typical for all projects, every specific project has its own specialties, which makes its project planning unique.
Many students underestimate this activity. They think that this is an individual activity that is totally under their control; hence, there is no need for wasting time on this somehow “superficial” and “mechanical” activity. As it was stated before, if you do not know how you are going to do your project, it is highly likely to fail to do it.
At the first step, the plan seems to be very vague to you. At this stage, do not worry about the details. Simply, think about the major steps that you should take and make a list that depicts those major steps, which should be taken. Look at the following example to find out how it can be done.
As you can realize these may slightly be different in your case, however, the main theme remains similar. This task – making a list by breaking down the whole job into specific manageable tasks – is called Work Breakdown and the result of which is called Work Breakdown Structure.
Work Breakdown Structure (WBS) sample
Preparing Problem Statement
Understanding general requirements
Meeting with my supervisor
Writing Project report
Now, this list needs two important things, which should be added to it in order to make it a plan: timing and resourcing. By timing, I mean, you have to say when the task is expected to be started and when it is expected to be accomplished (finished).
By resourcing, I mean the human beings and any material/ equipment that any specific task of the above list needs to have in order to be done.
In fact, in your specific project, the main human resource of the project is you. However, sometimes you need other resources such as your supervisor. In terms of material/equipment you may need a computer (which you normally have one) and in some cases, specific devices or software that should be obtained before the task is started.
Having these items ready, it is good to know that there are two major approaches with adding these details to your plan and applying the required changes: a top-down approach and a bottom-up approach.
As the names imply, and as you might have heard about these approaches in other courses/modules, if we follow the former approach we start from the top task in the list and will apply resources and timings one by one until we reach to the end of the list.
Whereas if we follow the latter approach, we should start with the last task and assign resources and timings to task backwardly.
The main reason for this is that the delivery time of your project is very restricted and normally bound to the specific university timetable for the assessment schedules. Hence, some major dates are not under your control and you are obliged to stick with a predefined university/school plan.
Let us apply the approach to the mentioned example. All you need is to have a pen and paper, or a word processor, and a calendar. We assume that the project should be done within a semester.
For the sake of simplicity, we assume the semester starts on October 1 and ends on January 27. Again, suppose you should submit your project by January 15 and you should be ready to present your project on January 22. Having this information, let us prepare a schedule based on which you can conduct your project.
Applying the bottom-up approach implies that we should start from the last date, which is January 20 and set this date as the finish date for the last task, which is “Presentation”.
Then, we examine the mentioned task and we estimate a duration within which we think that the task is getting accomplished. We try to be as realistic as we can in this regard.
However, you may ask how you should know how long the task might take to get accomplished. In reality, there are different ways that help project planners with the time estimation process, which unfortunately most of them do not work for you and therefore we are not discussing them, here.
In fact, you have to establish this version of your schedule by guessing the required time for accomplishing each task. Then, you have to refine it by consulting your supervisor, later.
Refining the Project Plan for proposal
In the previous section, you prepared your first cut project plan. It was shown that this first cut version of the plan needed to be reviewed based on the characteristics of each task, in order to adapt it to the real situation. For example, the following tasks should start earlier:
Writing Project Report
Furthermore, you can do some tasks in parallel. Well, when we talk about parallelism do not forget that the concept should be understood in its context. Indeed, although it seems that these tasks are in parallel, but they are not. Because you have only one resource to perform these tasks, and it is you, yourself.
Therefore, in this case, the situation resembles more to multitasking rather than parallelism. To understand it better, you can compare the situation with the multiprocessor and single processor concept that you might have seen in the Operating Systems context.
A single processor in your computer does several jobs in a multitask format which seems to be done in parallel.
Below is a group of tasks that can be done in parallel:
Meeting with my supervisor
Again, this is another group:
Writing Project Report
Project proposal Methodology
The methodology seems to be a buzzword in the academic context. However, it is not as well understood and known in undergraduate as it is in postgraduate studies.
Besides, because the term and its concept have widely been customized and adapted in software engineering and development, it becomes somehow difficult for students, especially in undergraduate level, to properly understand and apply it.
Usually, final year students in computer science, software engineering and other divisions of computing have studied the concept of software development methodology in modules/courses such as software engineering, IT project management, system analysis, and design, etc.
However, I found it useful to review the concept again and to focus on this issue from another perspective.
The methodology has different meanings. As a branch of logic, it is about understanding the way that human beings know is formed.
It is also the combinations of best practices, procedures, rules, and guidelines, in one word the methods, of the specific field of science and art by which professionals, specialists, and researchers can conduct their projects, research, development and study activities.
Again, from another perspective, it is the study of those methods, which were just mentioned.
By giving different meanings of methodology, I did not want to confuse you. It was just to let you have a wider perspective of what the methodology can be in the different contexts.
However, for our purpose, the second meaning plus a trivial part of the first one is sufficiently more than enough.
It means that we are taking the methodology as the combination of methods by which we can conduct our project, and control it, on one hand, and the methods that we can apply in software development in order to deliver a software product, on the other hand. Moreover, we consider different methods and we argue why we have chosen a particular method.
Clearly, if your project is not involving software development, such as a research project for instance, then the methodology should be chosen and discussed based on a generally established approach for scientific research.
However, we are not going to discuss this concept in this blog, instead, we will discuss and explain some of the major adapted approaches in software development context will be discussed and explained.
Software Development Methodology for Project Proposal
Fortunately, we have left this perception behind that software development is a synonym to programming, long time ago. Nowadays, most of the software developers, with or without a formal educational background in the field, have a clear idea that this activity is far beyond sole programming.
They understand that it has more science and engineering in it than art. Indeed, the term “software engineering” has widely been accepted despite some trivial arguments against it that can be heard, here and there, from time to time.
My personal experience has brought me to this belief that software development, as a production activity, should be considered “naturally” and “mainly” an engineering process.
However, like many other engineering activities it includes and actually, it needs some artistic endeavors and flavors.
Moreover, in many cases, when the activity is not a simple reproduction or mass production of software, it becomes much more difficult to manage. This is what I have tried to teach my students in the academy or share with my colleagues in the industry over the years.
The problem is, and surprisingly most of the software developers, at least verbally, confirm it as a problem, that because of the nature of software, which mainly comes from its intangibility, this engineering process can sometimes be jeopardized.
There is a large tendency towards the ignorance of the engineering process in software development as the process it is very difficult to follow and control, especially when novice developers are involved.
However, the complete argument on this subject is beyond the scope of this blog. Indeed, I assume that, hopefully, most of the readers of the blog are already familiar with the concept and, again, hopefully, in line with the idea of taking software development as an engineering process.
Having what was mentioned, you could select and follow one of well known and well-practiced (software engineering) methods to accomplish your projects.
Perhaps you have heard about different methods such as waterfall, spiral, prototyping, agile, Xtreme, object-oriented, structured, Model View Controller (MVC), Rapid Application Development (RAD) and different frameworks such as Unified Process, Rational Unified Process (RUP), Microsoft SolutionFramework, and many more.
How can we survive within this jungle of methods? How can we choose among them? To give you a straight answer is not easy though, it is not impossible!
It would not be a wrong claim that the notion that software development is an iterative activity has almost unanimously been accepted by developers. Whether by following a spiral method or non-spiral, you would usually build software during an evolutionary process.
The process, at least most of the time, is iterative, and the final result can be obtained through accumulative increments, each one of which is supposed to satisfy one or several parts, but not all, of the requirements.
There is another decision that should be made before the development process starts. Which approach are you going to use to analyze, design, and implement your software? Structured, or object-oriented?
Some people may have a single and simple answer to this question. They would say, “Certainly, it is object-oriented.” If you ask about the reasons for this decision, you may receive several arguments which most of them are legitimate but not complete.
For example, an argument can be about the dominance of the object-oriented paradigm and its related technologies in the market and industry. Another one can mention the technical and theoretical capabilities of this method.
Although, as it was mentioned, these arguments and other similar reasons are quite legitimate and understandable, yet the answer to that question, especially in your case, is not that straightforward. We will discuss this issue in the following section.
OO vs. Structured
OO or Structured? Which one is better? The second question is not appropriate. When we are in the process of choosing a method, we are not talking about these methods in general.
We have to consider them in a specific context, which here is your project. The mentioned questions should be changed to “OO or Structured, which one is the most suitable approach to do my project?”
The answer depends on several parameters and conditions. Below you can find these conditions in the format of some questions that can guide you through your decision.
How familiar are you with the method?
How complex is your project?
Which method is more suitable to analyze and design your system?
What kind of development tools are you going to use?
Is there any technical specification in your project definition of the methodology?
Is there any preference or evaluation bonus on choosing a method?
A Mixed-mode Approach
There are many undergraduate projects, which are not dealing with complex systems. They are not using complex objects and the functionality of the system is not difficult to understand.
Most of these projects aim to equip the students to understand a general-purpose system and to utilize their knowledge in order to build a system from scratch.
Many of these systems are using some kind of database, which users create and update them. In addition, these systems usually provide different kind of reports and outputs based on the expected functionality.
Hence, the analysis and design of this type of projects would focus on the user interface and database design, none of which requires an advanced object-oriented approach.
However, one aspect of object-oriented, the Use Case Modeling, should be considered as a powerful tool that makes requirement management, analysis, and user interface design to be sound and flexible.
Use Case Modeling has steadily become a powerful instrument in different steps of software development, since the 1990s. This model has proven itself as a reliable, user-friendly, flexible, and powerful instrument to catch and model the software requirements.
The independence of the model from other sections of the design gives the model the flexibility to be used with both object-oriented and structured approach in the software development.
This is why when it is used with the traditional (structured) approach I call it “Mixed-mode ” method, in order to show that this method has its roots from both main methods. Indeed, in this case, I have replaced the traditional Data Flow Diagrams (DFDs) with the Use Case Modeling.
The mixed-mode approach uses the Use Case Modeling in four stages of your software development, which are Requirement Management, Analysis, User Interface Design, and Testing. It also helps you during the Database Design and users guide compilation.
As it is obvious, this method does not consider Class Modeling and Object Modeling so you can use development tools and programming environments in a traditional, structured method. But, it does not mean that you cannot use object-oriented aspects of your development environment.
[Note: You can free download the complete Office 365 and Office 2019 com setup Guide for here]
It is a well-known fact that for a long while lacking proper requirement management has been one of the main factors for the failure of software and information technology projects.
This factor still plays a great role, not as much in the failure as previously it was doing, but in the success of the projects.
Simply, understanding software and information technology projects mean that the project owner and the project developer have both agreed on certain requirements that should be met when the project is finished.
In reality, two main sides of the project, the project owner, and developers, would agree on some sort of contract within which they precisely articulate what the owner wants and what the developer should do.
The similar situation would apply to your final year project. The school/department is one side, as the project owner, and you are on the other side, as the project developer.
To manage the requirements of your project you have to articulate the project needs in a formal and precise way. I assume that you have received proper education on the requirements management and requirements categories.
In addition, I assume you have learned different techniques on how to catch the requirements, how to put them under a specific category, and how to use them during the further stages of software development. Therefore, I am not intended to repeating those subjects in detail.
Instead, in the following sections, I would briefly explain a customized approach to the requirements management that suits the final year projects more properly.
To simplify, we can define a requirement as a brief explanation, mostly in one sentence, by which we explain something that we want a system to be able to accomplish.
This explanation should be as precise and free of ambiguity as possible. A system may have several to several hundred requirements. However, when the number of requirements rises, usually, the system should be broken down into the smaller subsystems, each of which aims to address and fulfill a subset of the requirements list.
Although requirement specification is very important in all kind of projects, in your final year project, it becomes even more crucial. The reason is in other projects, sometimes, there are some ways of compensation and/or boosting the development process.
It can happen by asking for more time, or more budgets, or more human resources. Unfortunately, none of these can be applied to your final year project.
You are totally on your own; academic period cannot be extended (forget about cumbersome process of appeals for a week or so extension!) and no one can be added to your project.
Therefore, it is highly crucial for you to know what you are going to do. Below you can find some examples of good and poor requirement specifications.
Requirement specification examples – poorly specified
The project aims to develop a system for the university library, which fulfills the following requirements:
To keep and maintain all library records.
To keep track of the borrowing and returning material.
To keep and maintain library members information.
To provide different reports.
The project aims to develop a speech recognition system for a specific language. The system should be able to do the following:
Understand different speeches.
Show the spoken sentences in a word processor
None of the above samples talks about the level of the functionalities. Indeed, they are vague and interpretable. For instance, there is no specification for the period and numbers of borrow and return logs.
Again, “To provide different reports”, in the first sample, is a very broad requirement that whatever you prepare as a report, one still can say that there is a report that you have not prepared. In the case of the second sample, the first requirement is too broad.
It is not clear that what “different speeches” means. Again, the second requirement does not specify any word processors. Should it be Microsoft Word, Neo Office, OpenOffice, or Apple i-Work word processor?
To overcome these problems you should work on the requirements to make them as specific and accurate as possible. This way the requirements can be quantifiable, manageable, testable, and traceable.
Several models and approaches have been designed and introduced for the requirement management during the past decades in the software industry.
Almost all of these models are trying to help developers and users to understand the nature of requirements and to categorize which in such a way that guides the project to produce a system, which maintains an agreed (standard) level of quality.
One well-known model for classifying requirements is called FURPS+, which stands for:
In addition, the “+” has been added to extend the classification to cover other areas such as Design, Implementation, and Physical requirements. In the real-life projects, it is important to consider all of these categories and to articulate each one, deliberately, in your project plan and other related project documents.
However, neither in real life nor in your final year project all of these subjects weigh the same weight. In fact, in different projects, the weight of each class might change according to the nature of the system.
In your final year project, though, the Functionality would play the major role. Hence, you should pay more attention to this class of the requirements.
The rest is up to you and your supervisor. In my opinion, if your system is a general-purpose one, then you can classify all the rest as Non-functional requirements. However, be aware that there are final year projects, which may have the Performance as there heavyweight class within the requirement classifications.
Functional requirements are those features of the system by which the system fulfills the core responsibility that is expected to accomplish.
You will see some examples of functional requirements for the proposed samples in this in the following sections. Although this is the focus area in almost all software projects, however, it becomes more crucial in many final year projects.
The reason is, although non-functional requirements are plying a great role in software systems, however, you are expected to show that your final year project product is able to do its core responsibility as its main concern, and then you have to show that you have considered non-functional requirements as well.
The main purpose of the requirement prioritization is to let developers and customers make an agreement on the sequences of the implementation process. What are the core functionalities without which the system cannot be utilized?
What is the sequence of dependency between different features? It is quite usual, even necessary, to ask these questions and many more during the requirement management phase.
There are many reasons for this. For example, these questions and their proper answers help developers to plan for the iterative and incremental development. They let customers identify their core functionalities. They help both sides to focus on the core and not to assign their resources to the surface problems.
Several models and techniques have been produced to help developers to prioritize project requirements. There are even automated tools that help developers in this regard.
However, like other concepts of development in this blog, I am not going to repeat what you can find elsewhere in the related resources.
You can refer to the bibliography section at the end of the blog or simply have a search in your university library or even much simple than that to go online and you can find more than what you want about the concept.
I want to discuss the issue in the context of your final year project. Notwithstanding, the approach is applicable to many other small-scale real-life projects as well.
Prioritize the functional requirements based on two factors, their importance, and their sequence. For importance, you can use the following labels:
Must have – label with this those requirements that together create the core functionalities of your system without which your system would not provide the minimum capability that your customer expects.
Should have – label with this those requirements that although are not part of the core functionalities of your system, however, they can be very useful and you would try to implement them if the project schedule allows you to do so.
Nice to have – label with this those requirements that they do not play the main role in the functionality of the system, at least at the scope of this project; however, they would give more facilities to the users if the schedule of the project allows them to be implemented.
Use Case Modeling and User Interface Design
Use Case Modeling is a powerful modeling technique that can be used in different stages of system and software development. Its understandability by technical and non-technical people alongside its simplicity, high flexibility, and readability has made it a first choice to capture and organize requirements.
It can also be used in analysis, design, and testing processes. Use case modeling is supported by the Unified Modeling Language (UML) as well.
Use case modeling plays a great role in capturing requirements, as well as in presenting the behavior of the system. It can be used both in understanding the current system, whether it is manual or automated, and to model a new system.
Having both a diagrammatical view and explanatory document makes it an excellent tool for communication between developers and users. Again, like other subjects in this blog, I will explain the concept of Use Case Modeling and User Interface Design in the context of final year projects.
A use case has two formats. The first one is a diagrammatic format, which includes a watermelon shape, a matchstick man, and a line between these two. It depicts a major functionality in the system and the way that a user, which is called an actor, would communicate to the system to acquire the mentioned function.
The second format is a textual description, which explains what will be happening when the actor (user) requests to use the “use case”, in other words, what would be the case of using the system by the actor.
Using the examples of the previous s, you can find out a Use Case, which corresponds to the first requirement of sample 1 in the 5
These simple items, as you have learned before, show that a Librarian communicates with a system to maintain the library catalog through the Catalog use case. This is not its responsibility to do so.
In order to use case to be able to tell about the detail of its functionality, it should be accompanied by a textual explanation, which will be discussed in the next section.
Use Case Template
This explanation should follow a template. You can find many templates for the use case and perhaps you have seen some up to this point of your study. Most of these templates have several items in common, which together forms their main characteristics.
Some of these templates are too detailed and some are very simple. Below I will introduce a template, which I have found suitable for your final year project.
Use Case Granularity
How many use cases you should have in your system? This question should be answered carefully. The answer depends on many factors such as the scope of the system, the complexity of the system, the relations with another system, and some other factors.
However, some rules of thumb can help us to stay on the right track. Usually, in a project of the size of your final year project, you might have between 5 to 15 use cases.
If you have less than 5 use cases, then it seems that something is wrong. It can be the size of the system, which means that it is not a full system, rather it is a part of a system, or it can be from not understanding use case modeling properly. Whichever is the case, it would be better if you think about it again and to consult with your supervisor about it.
If you have more than 15 use case, I do not think can be because of your project size, rather it is because of your misunderstanding of the definition of use cases. Many students get confused about use cases.
Sometimes experts do the same. Anyway, look at your use cases again and make sure that you have not taken a single step as a use case. The use case should fulfill part of a requirement, a requirement, or more than one requirement.
But, in any case, it starts with a stable situation of the system and leaves the system in a stable situation, when it finishes.
Nonetheless, there are situations that either you have less than 5 or more than 15 use cases and you cannot find any serious problems in your modeling. Well, here I should introduce to you a concept, which is called “use case granularity”.
If your use cases number is less than 5, and you have a real system, then if it is helpful in managing the system, both from a development perspective and from a functionality perspective, then try to decompose one or more use cases into other use cases to increase the system granularity.
If your use cases number is more than 15, then try to identify or define some subsystems to which you assign use case which is more related to each other. Normally, a subsystem is better not to include more than 10 use case.
More applications of Use Case
As it was mentioned, the main purpose of use cases is to capture requirements and then to use them in the analysis in order to provide a more understandable view of the system, both for developers and customers. However, a use case can be used in other stages of the system and software development.
One case was user interface design, which was discussed earlier in this. In addition, a use case can be used in the testing process. Moreover, they can be used for users guide and system help preparation.
The scenarios that you have already explained and the screen snapshots that you have already embedded into use case explanations can act as a rough material for the mentioned purposes.
Furthermore, use case documents can be used as rough material to prepare training documents, as well. Now, can you tell me how amazing this use case thing is? Thank you, Ivar Jacobson, for introducing this excellent idea!
Database design plays a major role in application systems. Almost all courses/programs, which are related to software development and information technology, include at least one module on database systems.
Like other sections of this blog, the intent of the blog is not to repeat the concepts that you might have studied thoroughly, rather show you the way that you can adapt your knowledge about the subject and utilize it properly in your final year project.
Database Management Systems
Database Management System (DBMS) is a software system, which manages database construction, update, and access control, and maintenance. I assume that you are familiar with some DBMSs such as My SQL, MS SQL, MS Access, Oracle, etc.
Some DBMSs are licensed software and some others are open source. You have to choose a DBMS as the database tool for your final year project if you are going to develop a database application.
Below you can find some tips on selecting a DBMS.
Choose a DBMS that you have already your hands dirty with it.
Unless you have strong reasons do not go for small/medium-scale databases such as MS Access.
Choose among large-scale databases e.g. My SQL or MS SQL.
Relational vs. Object-Oriented Database
The most common DBMSs in the market are Relational Database Management Systems (RDBMS). Their popularity, both in the market and education, make them the first choice for most of the final year projects.
However, other types of databases, particularly Object-Oriented Database Management Systems (OODBMS), have steadily been growing during the past decade.
In fact, you can download and use some of them such as ObjectStore and combine them with your programming environments i.e. MS Visual Studio.
So, which one is preferable? RDBMS or OODBMS? My quick answer to this question is “if you are about to do an ordinary application and you do not have the previous background on OODBMS, and particularly if your methodology is not object-oriented do not think about using an OODBMS.
In other words, unless you have a strong reason and desire to use OODBMS, from one side, and it can give more facility and robustness to your system that is not achievable using RDBMS, choose one of the well-known RDBMSs, especially among those with which you have already had some experience”.
Finally, some RDBMSs support Object Relational Models (ORM), which allow developers to map their object models into relational models. Although the process of mapping your class model into an ERD might persuade you to use ORM, you should be careful about the concepts behind each one. To clarify, you can use ORM only if the DBMS supports it.
In this case, you should develop your data layer in your system architecture according to this decision. However, if you are not planning to use ORM, then you have to map your persistent classes into an ERD, and then apply normalization techniques on the result to obtain your relational database design.
In this case, you have to develop your data layer, accordingly, which might not be the same as you could have in the previous situation.
Data modeling, which is also called conceptual database design, is a core activity in database applications. It is comparable with the importance and the role of foundations of constructions in civil engineering.
I assume you have had at least one module/course about database design before you start your final year project. However, this familiarity cannot guaranty that your database design is proper. Below you can find some tips on data modeling.
Tips on Data Modeling
Use an automated tool, preferably the one that your chosen DBMS provides, for your data model.
Apply normalization rules and normalize your database design at least to the 3rd Normalization form or to BCNF.
Use understandable names for relations/tables and attributes/fields.
Use proper data types and apply DBMS provided restrictions and rules such as Not Null.
Use proper naming for Foreign Keys and Relationships.
Check your design by providing data through DBMS interface and control the expected outputs by running some Structured Query Language (SQL) commands on the provided data.
If you follow an ordinary (structured) methodology, then you would provide an Entity Relationship Diagram (ERD). You can use this diagram to provide a normalized data model, afterward. However, if you follow object-oriented methodology then you should know how you could map your class model to an ERD.
Most of IDEs and development tools are providing tools, add-ons, and facilities to help in the mapping process. If you are using one of these tools then your job is easier. Simply use the facilities that they provide.
However, if you do not have an automated tool to do so, below you can find some rules of thumb for mapping a class model into an ERD, manually.
Mapping a Class Diagram into an ERD
Indicate your persistent class, e.g. by using a persistent stereotype.
Create an Entity for any persistent class, giving the name of the class.
Map all data members of the class as attributes of the created Entity.
Give the same, or equivalent, the data type to the attributes.
Make the class identity (ID) the Primary Key for the Entity.
Map associations, aggregations, and compositions to relationships and use class IDs as Foreign Keys.
Change generalization/specialization relations of the class model to superclass/subclass relations and apply ERD rules, accordingly.
Map multiplicities of associations to the equivalent cardinalities in the ERD.
The next step is to prepare a database design, which is also called a physical database design, based on the data model. This model is quite similar to your data model. However, the data model is a DBMS independent model while the database design should be prepared according to a specific DBMS.
The reason is in database design you have to specify the attribute types, length, key types, attributes’ default values, and other parameters, which may be slightly different from one DBMS to another, yet this slight difference can make your design to work on one DBMS, but not the other.
Using Stored-Procedures and Triggers
Stored-procedure is a specific procedure that is written in Standard Query Language (SQL) as a database item. Stored-procedures can accomplish database related requirements efficiently.
Although they are part of the database, however, many experts categorize them under the business logic layer in a three-tier/multi-tier software architecture. Stored-procedures are independent of specific tables.
The trigger is a piece of SQL, which can perform a sequence of actions if an action such as Create, Update, and Delete happens on the specific table.
If your project were a database application, and if your DBMS supported stored procedures and triggers, it would be a good practice to use these features. In this case, do not forget to document stored procedures and triggers properly and provide them as part of the supplementary documents in your final report.
Extensible Markup Language (XML) is a markup language that you have studied during modules related to database or web technology. I advise you to consider XML as a data container in your final year project if one or more of the following conditions are applicable.
Be careful about the term “data container” that I used. Differentiation between a “data container” and a “database” is important. Several arguments and discussions can be found on whether you can use XML as a database or not.
However, many DBMSs provide a diverse number of utilities to facilitate using XML with databases. This phenomenon, in its essence, shows that the arguments against using the skeletal format of XML as a database have been widely accepted.
On the other hand, providing specific tools regarding securing the XML files and treating them as a database, particularly for semi-structured or unstructured data is becoming very popular.
If you use XML in the context of DBMS, then you have to follow and apply specific rules that are pertinent to using XML in that context. You can find several resources on this in the bibliography section.
Anyway, I will leave you in peace by avoiding more technical (even philosophical!) discussions on this matter, rather, I provide with some tips on using XML in your final year project.
XML is mainly a technology to be used to organize/standardize data exchanges -Consider using XML as a data container in your final year project if:
Your data is semi-structured or unstructured
You do not have a heavy update on your database
Security is not the main concern
You do not deal with a large amount of data
Ignore all the above and use XML if you are not obliged to use a traditional database! This is an opportunity for you to practice amazing software technology.
By implementation, here, I mean programming. I mention this because the word “implementation” is used for two different purposes in the software development context.
It is used to address the programming phase of software development, as its widely used concept, however, it is used as installation and making the system ready for use as well, in some other contexts.
Programming phase of the software development is the phase that gives “birth” to your system. It is the time when you materialize what you have analyzed and then designed on paper or electronic diagrams. In fact, this is the time when your thoughts become real. Of course, the separation of phases in software development is not too strict.
However, different phases are clearly distinguishable. When we talk about an implementation phase as the programming time, it does not mean that you are only doing programming at this time, rather it means that your main activity is programming, while you may still do a little design and even analysis activities.
However, it is crucial to every kind of software development and information technology projects that you have everything designed and thought about before you start the implementation phase.
To make an analogy, it is similar to when a civil engineering team starts to build a construction, a house, a bridge, or a road. They cannot start the building without having all their blueprints ready. If they do, it is more likely to them to end up with a disaster or a catastrophe rather than what they would expect.
In order to make the implementation phase a success, the first step is to decide what kind of tools and what programming environment you are going to use. Indeed, you should have decided and documented this in the previous phases, as we discussed in the design phase.
There is a jungle of programming languages and environments out there. How can we decide on which one to choose in this extremely variable environment?
Testing is a process; it means that it normally should receive some inputs, processes them, and provides some outputs. It includes several activities, which should be carried out in different stages of software development. However, as it was mentioned, the core activities would be carried out during the testing phase.
Normally, several different specialties are needed for the testing process to be accomplished. But, again, we are not discussing the process outside of the context of the final year projects. Consequently, you are expected to play most of the roles that are required in this process.
In fact, you should design test cases, provide test scenarios, collect and arrange test data, perform the test, and document the result. These activities have been shown by using a UML activity.
If you compare this simplified testing process with similar testing process diagrams, regardless of the way that they are presented, you can realize that some detailed activities and loop-backs in the process have been removed. It does not mean that this has unreasonably diluted the testing process.
Again, I would like to emphasize that many parameters such as size, human resources, time, and the complexity level of the system affect the testing process.
For example, “regression test” is an important concept in the testing process. Simply, the regression test means that you have to repeat the tests that you have performed earlier if you change your system.
This idea has been implemented in many testing tools, however, in my opinion, it is not necessary for the majority of final year projects.
As another example, we can talk about “automated testing”. Simply, it means that either you use automated tools to test your system, or you create necessary programs that performing the tests, automatically.
Is automating the testing process necessary in your final year project? Well, in most of the cases the answer would be “No”.
However, you have to look at the context and the development environment. If the development tool that you have selected provides you with the efficient testing tool, certainly, it would be a good idea to use it.
However, you should be careful to not spend more than the scheduled time that your project allows you for testing just because the “automated testing” is a fashion that you should follow.
Below we are going to discuss the test classification at the first step, and then we will discuss test cases and test data preparation. In addition, the test result documentation would be discussed.
Throughout the years, the test has been classified into several categories. Below, these categories have been summarized in order to provide you with the general topics of testing
Software testing can be categorized from different perspectives as below. However, these categories are neither complete in terms of its diversity nor rigid in terms of classification. They have been provided to let students have a general view of the testing categories.
Validation and Verification
Validation and Verification (V&V) is a concept in software testing and quality control. By validation, you have to answer this question, “Are you developing the right system?” whereas, by verification, you have to answer this question, “Are you developing the system right?”
As you can realize, the first question is validates the system, which you are doing it through the testing process. But, the second question is about the process that you have followed to develop the system.
Although you should answer this question and you should be able to show evidence of the positive answer to this question, however, this is the supervisor that can help you through her/his feedbacks by letting you know that you are on the right track.
Furthermore, your supervisor or evaluation panel would judge on this issue when you deliver your final project. You can find more on this issue by consulting the bibliography section of this blog.
Finally, I did not discuss the debugging process in this blog as I assume that you have received enough lessons about it in different programming modules/courses and practiced it during laboratory exercises.
However, although debugging is considered as a test activity in many contexts and it is specially categorized under the validation process, it should not be confused with the testing process. To my view, debugging is part of programming.
It is so interconnected to the programming tasks that you cannot assume it as a separate task. On the other hand, as it was mentioned, the test is a planned process that might be performed independently of programming.
Presumably, you think that writing the report of your final year project is the last step that you should do. Although this assumption is partially correct, however, it should not lead you to postpone the report writing activity to the last minute of your schedule. In fact, you have to start to write your report in the early stages of your project.
If you have a look at again, you can find out that the report-writing task has been considered as an ongoing task after literature review finished. This means that your report is gradually completed alongside other activities that you would perform during the development process.
Clearly, as you can move towards the end of your project, the time and effort that you dedicate to this task would increase.
You can find a template for the report structure below. However, depending on your specific project you may revise it.
Table of Contents
List of Figures
List of Tables
User Interface Design
Conclusion and Future works
Each item of the above structure would be briefly explained in the following subsections.
The cover page is the identity of your final year report. I have seen many carelessly prepared cover pages and have penalized the providers (my students are well aware of this)! Unless there is a specific template in your department, make sure that you have provided at least the following information on your final year project report.
Table of Contents
Prepare Table of Contents (TOC), List of Figures, and List of Tables. Most of the word processors, e.g. MS Word help you in automatically prepare and update these lists. Utilizing these facilities prevents your document from wrong page references.
Executive Summary (ES) is a one-page explanation that explains to the reader the problem, how it has been tackled, and what the outcomes are. Although it is placed as the first page after the cover page, however, it is normally written at the end of the project, when everything is clear!
As the name is applying, it is a short summary for the executive management of your project, here the supervisor or the evaluation panel, to let them understand in a glance what the project is about, how it has been done and what the conclusion is.
If the project is a research-based project, usually, Executive Summary is replaced by “Abstract” title. However, the main theme remains similar, largely.
It is placed as the first page after the cover page
It is normally written at the end of the project when everything is clear!
It is a short summary to show:
what the project is about,
how it has been done,
and what the conclusion is.
It is NOT an explanation on the report structure!
I have seen many reports within which the students have confused between Executive Summary and Introduction. Be careful on this
issue and look the hints on these two to understand their differences.
This of your report provides a background of the project, states, in general terms, what the report is about and how it has been structured. The introduction can be divided into subsections such as Overview, Background, and Report Architecture.
As you can see below, the introduction has a clear-cut difference with the Executive Summary/Abstract. However, I have seen many reports with transposition of Introduction and ES.
Although this section mainly applies to the research-based projects, however, it is a good idea to have it in the normal projects as well. In this, you should acknowledge the previous works on the area of the project in order to show their main outcomes, strengths, and spaces for improvement.
Consequently, you can show how your project has been built upon the previous ideas and works and how it would contribute to add more to this background.
Students, sometimes, refer only to the tools that they have used and the subjects that they have studied as their methodology. However, you should not write this, aftermath! The methodology is something that you have to decide on during the early stages of your project.
As a result, you can write this as soon as you made your decision. This was one reason, among many, that I mentioned that report writing was an ongoing activity and should not be postponed to the last minute.
This can be considered as a subsection to the methodology or as an individual one. Whichever way you choose, you have to clearly state that why you have taken this specific approach to developing the system.
In this, show the project requirements. Use the classification that was used or other classifications that you have studied. But, this is important to depict the requirements clearly.
Do not forget to pay proper attention to the functional requirements. Try to write this when you finished the activity or at least draft its contents, otherwise, you may lose lots of data when you start writing it at the end of the project.
Depending on your methodology, this would contain use case modeling or data flow analysis. Whichever is the case, show the analysis steps and try to use proper figures (e.g. UML diagrams) to show the general view of the system.
If you have restrictions on the word count of your report, then provide the main analysis here and move the details to the appendices of your report.
Depending on your methodology, this would contain different materials. However, structuring it as three subsections can be a good idea.
In this subsection, you should provide your software design. I did not discuss software design in details as it is beyond the scope of this blog, and you can find enormous resources about the subject (see the bibliography for instance).
However, you should show the system architecture, decompositions, and modularity in this section. If you followed an OO method, then, you may provide a package model, class model, and interaction model in this, as well.
You should introduce the User Interfaces (UI) in this or show a sample of which and explain the way that you have designed it, then, leave the details to the appendices. You can use the approach that I advised you in 6 to combine the UI design with use case description.
If your project is a database application, I advise you to be as generous as you can with the explanation of your data model and database design.
In this subsection, you can provide the ERD and then the normalized version of your database design. Providing the details of your tables can give your project, more flavor and would show your profession. However, you can move some samples of triggers and stored procedures, if you have any, to the appendices section.
Implementation should focus on the codes. In addition, you should present the general architecture of implementation. Provide samples of codes. Explain the algorithms used.
If you have a considerable amount of code, then either provide them through a supplementary media or as one the appendices.
Testing and results
Testing should show how the test process has been implemented, in general, and how the verification/validation techniques have been applied, in particular. Samples of test cases and test data explanation should be provided here.
Importantly, test results, the outcome not the detail, should be provided as well. You can provide details of the test process as one of the appendices.
Conclusion and Future Works
Although it is usually short, however, conclusion and future works is the distillation of your report. It should show the main outcome of your project. You should critically discuss the outcomes of your project, and point out your opinion on the results and outcomes. Try to be neutral at this stage and look at the outcomes as an outsider.
To clarify, the bibliography is the list of resources that you have consulted with for your project but not directly cited, while, references is the list of resources that you have cited.
Most of the departments have their suggestion for using bibliographical/citation style. However, in some cases, you might not receive any specific suggestion.
In this case, choose a style that you are already familiar with such as APA or Harvard citations and bibliography style. Fortunately, most of the word processors, e.g. MS Word, can provide you with tools, which support several common citations and bibliographic styles.
Well, the name is pretty much reflecting the content, and hence, there is no need to talk more about it. In addition, in the previous sections, I addressed those parts of the report that can be extended more by moving material to appendices section, wherever it was appropriate.
You have to follow academic writing techniques in your report writing. You have received proper training on this subject during your study at the university. However, most of the time, we forget to check our writing according to these techniques.
This is important for both native speakers and those who use English as the second (perhaps third or fourth) language (like me, me!). Unfortunately, most of the time students are careless and negligence about this activity. Below you can find some hints about proofreading.
Use spell checkers.
Do NOT trust spell checkers!
Print your report; forget about being “green” at this stage.
Find a quiet place.
Read your report word by word, loudly.
Correct errors with a distinguishable pen/marker.
However, if you are so interested to remain “green”, some word processors and some digital gadgets allow you to perform proofreading, digitally. Therefore, there is no way to escape proofreading and no excuse that justify our errors (please let me know about mine in this blog!).
To support your final report with more evidence, it is a good idea to have an appendix through which you can provide some extra documents. These documents should aim in helping your supervisor to have a better figure on what you have done during your final year project.
This appendix may include several items. Certainly, there is no restriction in it, however, below some specific parts have been suggested, which I think can be considered as the minimum.
Depending on your department request, you might or might not include your codes in your report. In some cases when you are using open source systems they provide you with a framework and its related source of codes, such as those which are used for building portals, for example.
It is not necessary, if not applicable, to print all the codes that are not yours. Rather, it is better to concentrate on the customized parts and print some samples of which.
In addition, there are non-open source projects for which enormous codes are created, whether automatically or manually. For this type of projects as well, some samples of the code would suffice. Below you can find some tips on how you should prepare your codes for your final report.
Tips on presenting software code in your report
Include those parts of the code that is your work.
Make sure that you have properly commented on the codes.
Provide a title that represents the main functionality of the code.
If you have customized an open source, make sure that you have properly referenced its origin.
Do not include parts of the code, which are automatically generated by the tool you have used for the implementation.
The presentation is the way that you are going to sell your products. You might face different situations. Some departments ask students to present the outcome of their projects in front of a panel of academic staff in a way that is expected for a viva in postgraduates. However, many departments are not asking for this kind of presentations.
As this blog aims to help postgraduates in their final project as well, I decided to dedicate a to this activity. As undergraduate students, even if you are not requested to present your final year project, the guide can be useful in other situations when you have to do so.
The presentation is an activity, which takes place in a short period, usually between 10 to 20 minutes. Therefore, its structure, preparation, contents, and delivery should be very well designed and implemented.
The presentation provides you with a unique opportunity within which you are able to introduce your capabilities on the subject, understanding of the chosen topics, and presenting the results and outcomes of your project.
In this, I will give some specific explanation on how you can prepare yourself for this important event. Do not forget that this activity must have been planned and scheduled for your project plan and you should be very careful about the timing of the event.
The presentation should be organized based on the allowed timing. Below I will provide two scenarios. In the first scenario, I assume that you have 20 minutes, which has been dived to three sections; 5 minutes for preparing the environment, 10 minutes for your presentation, and 5 minutes for question and answers.
In the second scenario, I assume that you have 30 minutes of which 5 minutes are for preparation, 15 minutes for your presentation, and 10 minutes for questions and answers.
It is important to use presentation tools such as Microsoft PowerPoint or Apple i-Work as they help to organize your presentation in an efficient manner. In addition, they can provide you with some predefined templates, which make your job easier to do.
However, if your department requires you to prepare your presentation based on a departmental template then you are obliged to follow their template and structure.
The present structure has been proposed for 30 minutes as below:
Presentation Structure 2 (for 30 minutes)
Presentation time: 30 minutes as below:
Preparation: 5 minutes
Presentation: 15 minutes
Questions/Answers: 10 minutes
Number of slides: 12
Slide 1: Project information (15 seconds)
Slide 2: Agenda/Topics (15 seconds)
Slide 3: Problem Statement/Project Definition (1 minute)
Slide 4: Main Requirements (1 minute)
Slide 5: Background/Literature Review (1.5 minute)
Slide 6: Methodology (1 minute)
Slide 7: Analysis (1.5 minutes)
Slide 8: Design (2.5 minutes)
Slide 9: Implementation (3 minutes)
Slide 10: Findings and Evaluation/ Links to live system or other documents (2 minutes)
Slide 11: Conclusion and Future Works (1 minute)
Slide 12: Thank you and Q/A