Capstone Project and Dissertation Foundations

Introduction

The final-year major project is often the most integrated learning experience in a Bachelor of Electrical Engineering programme. It requires students to combine engineering science, mathematics, design, experimentation, computation, communication, project management and professional judgement. However, not every major project is the same. A project may be an engineering design, an implementation exercise, an experimental investigation, a feasibility study, or a research dissertation. Confusing these forms can lead to inappropriate objectives, weak methods and unfair assessment.

This chapter establishes a foundation for planning, conducting and evaluating capstone projects and dissertations. It distinguishes engineering projects, design studies and research dissertations; explains originality and contribution at bachelor level; identifies expected deliverables; and clarifies the responsibilities of students, supervisors, sponsors and examiners. The central principle is alignment: the question, method, evidence, deliverables and assessment criteria must support one another.

A successful project is not necessarily the most complex project. It is one in which a significant and manageable problem is clearly defined, an appropriate method is selected, evidence is collected systematically, limitations are acknowledged and conclusions are justified.

Learning Objectives

By the end of this chapter, students should be able to:

1. Distinguish an engineering project, design study and research dissertation.
2. Formulate a feasible problem statement, aim, objectives and success criteria.
3. Explain what originality and technical contribution mean at bachelor level.
4. Select appropriate deliverables and evidence for a project type.
5. Apply a logical project lifecycle from proposal to final defence.
6. Describe the roles of students, supervisors, sponsors and examiners.
7. Recognise ethical, safety, intellectual-property and data-governance obligations.
8. Critically evaluate the quality and limitations of a completed project.

1. The Nature of a Capstone Experience

A capstone project is a substantial, supervised engineering activity that integrates knowledge acquired across a programme. It is normally more open-ended than a laboratory exercise. In a laboratory, the equipment, procedure and expected theory may already be specified. In a capstone project, the student must make decisions about scope, architecture, methods, testing and evidence.

The capstone is therefore both a technical task and a professional simulation. Engineers rarely receive perfectly defined problems. They must identify stakeholders, interpret requirements, manage constraints and communicate decisions. A project demonstrates not only what a student knows, but also how the student uses knowledge under realistic conditions.

A dissertation is the scholarly document through which the project is argued and evidenced. The physical artefact, simulation, dataset, prototype or design may be important, but it does not replace the dissertation. The dissertation explains why the problem matters, what was done, how it was evaluated and what can reasonably be concluded.

1.1 Project, design study and research dissertation

These categories overlap, but their dominant purposes differ.

An engineering project can contain research, and a dissertation can contain a prototype. Classification depends on the dominant claim. If the main claim is “this system meets its requirements,” the work is primarily an engineering project. If the claim is “this alternative is preferable under specified constraints,” it is primarily a design study. If the claim is “these results provide evidence about a question not adequately answered by existing knowledge,” it is primarily research.

1.2 The engineering problem and the research problem

An engineering problem begins with a need, deficiency or opportunity. Examples include reducing energy consumption in a motor drive, improving the reliability of a sensor interface or developing a low-cost monitoring device. It is resolved through requirements, constraints, design decisions and verification.

A research problem begins with uncertainty, an incomplete explanation, an unresolved comparison or a methodological limitation. Examples include determining whether a control strategy improves transient performance under defined disturbances, or evaluating the robustness of a machine-learning fault classifier when training data are limited.

A practical test is to complete the following sentences:

• Engineering: “The system will be successful if it achieves these measurable requirements.”
• Research: “The investigation will be informative if it produces credible evidence that answers this question.”

Some projects require both sentences. In that case, the proposal should identify which claim is primary and ensure that both design verification and investigative analysis are adequately performed.

2. From an Initial Idea to a Defensible Project

A project idea is not yet a project definition. A defensible definition contains a context, problem, aim, objectives, boundaries, method and success criteria.

2.1 Context and problem statement

The context explains the technical and practical setting. It may identify an industrial process, power system, embedded platform, communication network or sustainability challenge. The problem statement then identifies a specific deficiency or unanswered question.

Weak problem statement: “Renewable energy is important, so a solar project will be developed.”

Stronger problem statement: “A laboratory photovoltaic demonstrator lacks a method for estimating energy yield under partial shading. The project will develop and evaluate an estimation method using measured irradiance and electrical output.”

The stronger version identifies the setting, deficiency, proposed direction and evidence needed. It is specific enough to guide work without prematurely prescribing every technical decision.

2.2 Aim and objectives

The aim is a concise statement of the overall purpose. Objectives are the major actions required to achieve it. Strong objectives are observable and assessable. Suitable verbs include define, model, design, implement, measure, compare, validate, analyse and evaluate.

A useful structure is:

1. Review relevant theory and prior solutions.
2. Derive requirements and constraints.
3. Develop or select a method.
4. Implement the design or investigation.
5. Verify or evaluate performance.
6. Interpret results and identify limitations.

Objectives should not be merely activities. “Attend meetings” and “write a report” are project activities, not technical objectives. Objectives should also be feasible within available time, equipment, skills and supervision.

2.3 Scope and boundaries

Scope defines what the project includes; boundaries define what it deliberately excludes. A boundary might exclude commercial certification, long-term field deployment, electromagnetic compatibility testing or a complete product enclosure. Explicit boundaries protect quality by preventing uncontrolled expansion.

Scope should address:

• system or population under investigation;
• operating conditions and test cases;
• hardware, software and simulation elements;
• performance measures;
• available resources and schedule;
• safety, regulatory and ethical constraints.

2.4 Requirements and success criteria

Requirements translate needs into testable statements. A requirement should identify a function or constraint, a measurable threshold where possible, and the method by which compliance will be checked.

For example, “the data logger shall record temperature every 10 s with a timestamp error below 1 s during a 24-hour test” is more useful than “the logger shall be accurate.” The first statement supports verification; the second does not define accuracy, conditions or evidence.

Requirements may be functional, performance-related, physical, economic, safety-related, environmental or regulatory. A requirements-traceability matrix links each requirement to a design element, verification method and result. This is valuable in both academic assessment and professional engineering practice.

3. Originality and Technical Contribution at Bachelor Level

Originality is frequently misunderstood. A bachelor project is not normally expected to create a completely new scientific theory or commercially revolutionary product. It is expected to demonstrate independent understanding and a defensible contribution appropriate to the project context.

Bachelor-level originality may include:

• applying an established method to a new device, dataset or operating condition;
• integrating known components into a system that addresses a defined need;
• reproducing a published result and testing its robustness;
• comparing established methods using a transparent evaluation framework;
• developing a practical implementation where previous work is mainly theoretical;
• producing a dataset, measurement procedure or open technical artefact;
• identifying limitations or failure conditions not previously documented in the local context.

Originality can therefore be contextual, methodological, integrative, empirical or analytical. The claim must be proportionate to the evidence. A project should not claim to have “solved” a general engineering problem when it has only demonstrated a prototype under laboratory conditions.

3.1 Contribution statements

A contribution statement should answer three questions:

1. What existed before the project?
2. What has the project added or clarified?
3. Who can use or learn from that addition?

For example: “This project contributes a reproducible comparison of two low-cost current-sensing arrangements under three load conditions, using a calibrated reference instrument. The results indicate which arrangement is more suitable for educational motor-drive laboratories, while the limited sample size prevents generalisation to industrial environments.”

This statement is credible because it identifies the object, comparison, evidence, audience and limitation.

3.2 Verification, validation and evaluation

These terms should be used precisely.

• Verification: checking whether an implementation conforms to its specified requirements. “Was the system built correctly?”
• Validation: checking whether the chosen system or model is suitable for its intended purpose. “Was the correct system built?”
• Evaluation: systematic judgement of performance, value or suitability against stated criteria.

A simulation can be verified by checking equations, code and numerical convergence. It may be validated by comparison with experimental measurements or a trusted reference model. A prototype may be verified against electrical requirements but still fail validation if it does not satisfy user needs.

4. A Framework for Project Planning and Execution

A robust project lifecycle is iterative rather than strictly linear.

Figure: An iterative capstone project lifecycle. Evaluation may lead to revised scope, methods or requirements.

4.1 Proposal stage

The proposal normally includes the background, problem statement, aim, objectives, preliminary literature review, proposed method, resources, risks, schedule, anticipated contribution and initial references. It should demonstrate that the project is both worthwhile and feasible.

A schedule should identify milestones rather than simply divide the calendar into broad phases. Examples include requirements approval, design review, safety approval, prototype integration, pilot test, data collection, analysis completion and draft submission.

Risk management should consider technical failure, unavailable components, software incompatibility, insufficient data, access restrictions, safety incidents and loss of project personnel. A mitigation plan may include substitute components, backup data, staged testing and a reduced-scope fallback outcome.

4.2 Literature and technical review

A review is not a list of summaries. It should establish what is known, how knowledge has been produced, where methods disagree, and how the proposed project is positioned. Sources should be selected for relevance, authority and currency. Peer-reviewed literature, standards, manufacturer documentation and authoritative technical reports may all be appropriate, but they serve different purposes.

A literature review for a design project should identify established architectures, constraints, standards and prior design choices. A research dissertation should additionally evaluate methods, assumptions, evidence quality and gaps. Students should distinguish a source’s claim from their own interpretation and cite all material that is not common knowledge.

4.3 Method and evidence

The method must be capable of answering the stated question or verifying the stated requirements. A method section should specify instruments, software versions, circuit configurations, sampling conditions, calibration, test cases, data-processing steps and criteria for comparison.

Reproducibility is a professional virtue. Another competent person should be able to understand how results were generated, even if exact replication is impossible. Configuration files, source code, test procedures and raw data should be archived where permitted.

4.4 Analysis and interpretation

Results should be separated from interpretation. Results report observations, measurements or calculated outputs. Interpretation explains their significance in relation to objectives, theory and prior work.

Electrical engineering evidence may include waveforms, frequency responses, efficiency measurements, error metrics, thermal observations, reliability results or user tests. Graphs should include units, labels, scales and uncertainty information where relevant. A single successful demonstration is rarely sufficient evidence of general performance; test conditions and repetitions matter.

Students must not remove inconvenient data without justification. Anomalies should be investigated, documented and either retained with explanation or excluded according to a pre-defined and defensible rule.

5. Deliverables and Assessment

Deliverables should reflect the project type. Common deliverables include:

• approved proposal and requirements specification;
• literature or technical review;
• design calculations, models, schematics and source code;
• prototype, simulation, dataset or experimental apparatus;
• test plan, risk assessment and verification records;
• final dissertation;
• poster, presentation or oral defence;
• archived technical files and user documentation.

The artefact is only one component of achievement. A technically impressive prototype with undocumented methods may be weaker academically than a modest but rigorously evaluated system.

5.1 Assessment dimensions

Although institutional rubrics differ, assessment commonly considers:

1. Problem definition: significance, clarity, scope and feasibility.
2. Technical knowledge: accurate use of engineering theory and tools.
3. Methodological rigour: suitability, transparency and control of variables.
4. Design quality: requirements, trade-offs, integration and safety.
5. Evidence and analysis: quality of testing, data handling and reasoning.
6. Originality and contribution: independent value appropriate to level.
7. Project management: planning, records, adaptation and resource use.
8. Communication: structure, technical writing, visual presentation and defence.
9. Professional conduct: ethics, integrity, teamwork and responsibility.

Assessment should reward justified decisions rather than merely expensive equipment or visually polished results. Negative results can be academically valuable when they are credible and properly interpreted.

5.2 A simple quality model

Project quality can be understood as the alignment of four elements: claim, method, evidence and conclusion. A conclusion is defensible when the method directly addresses the claim and the evidence supports the stated level of certainty. Overclaiming occurs when conclusions extend beyond the tested conditions, sample or model assumptions.

Students should use calibrated instruments where possible, record uncertainty or tolerance information, distinguish measured from estimated quantities, and report limitations honestly. Numerical precision should not exceed the accuracy justified by the measurement system.

6. Roles and Responsibilities

6.1 Student

The student is the project owner and primary decision-maker. Responsibilities include defining and refining the scope, preparing a schedule, maintaining records, obtaining approvals, conducting safe work, communicating progress, preserving data, acknowledging sources and producing an independent account of the work.

Independence does not mean working without advice. It means understanding and owning decisions. Students should arrive at supervision meetings with progress evidence, questions and proposed next actions.

6.2 Supervisor

The supervisor provides academic guidance, challenges assumptions, helps identify risks and supports methodological development. The supervisor is not normally the project’s operator or ghost writer. Supervision should encourage progressively greater student autonomy.

A supervisor may help refine a research question, recommend literature, review a test plan and identify technical hazards. The student remains responsible for checking sources, implementing decisions and presenting an accurate account.

6.3 Sponsor or industrial partner

A sponsor may provide a problem, data, equipment, funding, domain knowledge or access to a workplace. Sponsors can improve relevance but may also introduce confidentiality, intellectual-property or schedule constraints. The educational objectives and academic standards must remain clear.

A sponsor should not require results to be altered, suppress inconvenient findings or control academic judgement. Agreements should define access, ownership, publication, safety and confidentiality before sensitive work begins.

6.4 Examiner or assessment panel

Examiners judge the submitted evidence against published criteria. They assess the work, not the student’s personality or the prestige of the sponsor. They should consider the project’s scope, available resources and approved constraints.

During an oral defence, questions may test understanding, assumptions, alternatives, limitations and the student’s individual contribution. A defence is not intended to reward confident improvisation over technical substance; answers should be reasoned and evidence-based.

7. Ethics, Safety, Integrity and Governance

Electrical engineering projects can cause injury, equipment damage, data loss or environmental harm. A risk assessment should address electric shock, arc flash, stored energy, rotating machinery, batteries, lasers, high temperatures, chemicals, pressure systems and unprotected power electronics as applicable. Isolation, guarding, appropriate personal protective equipment, competent supervision and emergency procedures are essential.

Research involving human participants, personal data or sensitive organisational information may require formal ethics approval. Consent must be informed and voluntary. Data should be minimised, securely stored and retained only as required. Students must not collect personal data merely because it is technically possible.

Academic integrity includes accurate citation, honest reporting, proper authorship and transparent use of software or generative artificial intelligence. AI tools may assist brainstorming, coding support or language editing where institutional policy permits, but students remain responsible for factual accuracy, originality, confidentiality and verification. Generated material must not be presented as independently verified evidence. Proprietary designs, unpublished data and personal information should not be uploaded to external systems without permission.

Intellectual property should be discussed early. The student, university and sponsor may have different rights over code, circuit designs, data and inventions. A written agreement is preferable to assumptions.

8. Contemporary Practice and Employability

Modern electrical engineering projects increasingly combine embedded computing, cloud connectivity, power electronics, digital twins, data analytics and machine learning. These technologies do not eliminate the need for engineering fundamentals. A machine-learning classifier still requires representative data, defined performance measures, error analysis and awareness of failure modes. A digital simulation still depends on model assumptions and validation.

Employers value graduates who can move from an ambiguous need to a traceable engineering decision. Evidence of employability includes a clear portfolio, version-controlled code, readable schematics, test records, safety documentation, concise technical writing and the ability to explain trade-offs to technical and non-technical audiences.

Sustainability should be considered across the system lifecycle. Relevant issues may include energy use, material selection, repairability, battery disposal, electronic waste, supply-chain risks and the environmental cost of computation. A design that meets an immediate performance target may still be undesirable if it creates disproportionate lifecycle impacts.

9. Illustrative Case: A Low-Cost Motor-Temperature Monitor

This is an illustrative case, not a report of an actual project.

Background

A teaching laboratory operates small induction motors and wants early warning of overheating. Commercial monitoring equipment is too expensive for every laboratory bench. A student team proposes a low-cost sensor node using a temperature sensor, microcontroller and wireless communication.

Problem and project classification

The initial idea—“build an IoT motor monitor”—is too broad. The team defines the problem as follows: the laboratory lacks a repeatable, low-cost method for detecting abnormal temperature rise during controlled motor tests.

The work is primarily an engineering project with a design-study component. Its main claim will be that a specified sensor node can detect a defined temperature threshold under laboratory conditions. A secondary claim may compare two sensor placements.

Requirements

The team specifies a measurable temperature range, sampling interval, alarm threshold, acceptable communication delay, electrical isolation requirements and a maximum prototype cost. It also states that the project will not certify the system for industrial safety applications or continuous unattended operation.

Analysis and approach

The team reviews temperature-sensing methods, motor heat-transfer behaviour, wireless reliability and laboratory safety procedures. It designs two sensor-mounting arrangements, builds prototypes and uses a calibrated reference thermometer. Tests include normal operation, deliberately increased mechanical load under supervision and wireless interruption.

The evaluation plan defines detection delay, temperature difference from the reference instrument, communication success rate and false-alarm behaviour. The team records raw data and documents sensor calibration, ambient temperature and motor operating conditions.

Outcome

The prototype detects the chosen threshold in the tested conditions, but the surface-mounted sensor responds more slowly than the embedded reference sensor. Wireless communication also fails near a metal enclosure. The team therefore concludes that the prototype is suitable as an educational warning device, not as a protective shutdown system.

Learning points

The project’s value lies not only in building hardware. It lies in converting a broad idea into requirements, comparing alternatives, testing credible scenarios and limiting the conclusion to the evidence. The negative communication result is useful because it identifies a deployment constraint. The project demonstrates contextual originality through integration and evaluation rather than invention of a new sensor principle.

Challenges and Common Failure Modes

Several recurring problems weaken capstone projects:

• scope expands faster than time and resources;
• the project begins with a technology rather than a problem;
• objectives describe activities rather than outcomes;
• testing is designed after the prototype, making success criteria vague;
• simulation results are treated as experimental truth;
• literature is summarised without synthesis;
• data are collected without a reproducible method;
• limitations are hidden to make conclusions appear stronger;
• supervision is mistaken for delegation of responsibility;
• documentation is postponed until the final weeks.

These problems can be reduced through early requirements, staged demonstrations, version control, laboratory notebooks, risk reviews and regular alignment between objectives and evidence. A contingency plan should define what constitutes a valid reduced-scope outcome if hardware, access or data become unavailable.

Best-Practice Checklist

Before commencing, confirm that the project has a defined problem, feasible scope, approved risks and identifiable stakeholders. During implementation, maintain dated records, test subsystems before integration, protect raw data, document design changes and discuss deviations promptly. Before submission, check that every objective is addressed, every major claim has evidence, figures have units and captions, references are complete, limitations are explicit and the student’s individual contribution is clear.

Chapter Summary

A capstone project integrates engineering knowledge into an open-ended, professionally relevant task. Engineering projects focus on developing and verifying a useful solution; design studies focus on comparing alternatives and justifying a design decision; research dissertations focus on answering a question through systematic evidence. These forms may overlap, but the dominant claim should be explicit.

At bachelor level, originality usually means a defensible contextual, integrative, methodological, empirical or analytical contribution rather than a revolutionary invention. A credible project aligns its problem, aim, objectives, requirements, method, evidence and conclusions. Verification checks conformity with requirements, validation checks suitability for purpose, and evaluation judges performance against criteria.

Deliverables may include a proposal, review, design records, prototype or model, data, test results, dissertation and oral defence. Students own the work; supervisors guide without replacing student responsibility; sponsors provide context and resources without compromising academic integrity; and examiners assess evidence against published criteria. Safety, ethics, data protection, intellectual property, sustainability and responsible use of AI are integral to engineering practice. The strongest projects are feasible, traceable, honest about uncertainty and useful to a defined audience.

Key Terms

Capstone project: A substantial culminating academic engineering activity integrating programme knowledge.

Dissertation: A structured scholarly report presenting a project’s problem, method, evidence and conclusions.

Engineering project: Work focused primarily on developing and verifying a practical technical solution.

Design study: A systematic comparison and justification of design alternatives under requirements and constraints.

Research dissertation: An investigation intended to answer a defined question or address a knowledge gap.

Problem statement: A precise description of the need, deficiency or uncertainty motivating the work.

Aim: The overall purpose of a project.

Objective: An assessable action or outcome supporting the aim.

Scope: The work and conditions included in a project.

Boundary: An explicit limit on what the project will not address.

Requirement: A stated function, constraint or performance condition that can guide design or verification.

Originality: A new or independently developed contribution appropriate to the project’s context and level.

Technical contribution: The useful addition, clarification, artefact, evidence or analysis produced by the project.

Verification: Checking whether an implementation satisfies specified requirements.

Validation: Checking whether a system or model is suitable for its intended purpose.

Evaluation: Systematic judgement against defined criteria.

Reproducibility: The degree to which another competent person can understand and repeat the method.

Requirements traceability: Linking requirements to designs, tests and results.

Academic integrity: Honest, responsible and properly attributed scholarly work.

Oral defence: A formal presentation and questioning process used to assess understanding and ownership.

Review Questions

Short Answer Questions

1. What is the principal difference between an engineering project and a research dissertation?
2. Give two examples of originality appropriate to bachelor-level work.
3. Distinguish verification from validation.
4. Why should a project define explicit boundaries?
5. State two responsibilities of a student and two responsibilities of a supervisor.

Long Answer Questions

1. Explain how a broad engineering idea can be transformed into a feasible project definition. Include the roles of context, problem statement, aim, objectives, scope and success criteria.
2. Compare engineering projects, design studies and research dissertations using their questions, methods, evidence and expected contributions.
3. Discuss how requirements traceability improves both engineering quality and academic assessment.
4. Explain the meaning of originality at bachelor level and discuss why overclaiming is academically and professionally problematic.
5. Describe the ethical, safety, intellectual-property and data-governance issues that may arise in an electrical engineering capstone project.

Analytical / Application Questions

1. A student proposes to “use artificial intelligence to improve power-system reliability.” Analyse why this is inadequate as a project definition and develop a more defensible problem statement, aim, objectives and evaluation plan.
2. A prototype meets its voltage and current requirements in a laboratory test but fails when used by its intended operators. Determine whether the problem is primarily one of verification, validation or both, and justify your answer.
3. A sponsor asks a student to omit test results showing poor performance from the final dissertation. Analyse the request and propose an appropriate response that protects academic integrity, confidentiality and professional responsibility.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a design study from an engineering project?

A. A design study compares and justifies alternatives against requirements.

B. A design study never uses calculations or experiments.

C. An engineering project cannot include design decisions.

D. An engineering project is concerned only with literature review.

Correct Answer: A. A design study compares and justifies alternatives against requirements.

Question 2

Which is the strongest example of a bachelor-level contribution?

A. Claiming to solve all industrial motor faults permanently

B. Applying and evaluating an established method under a new, clearly defined laboratory condition

C. Copying a published circuit without testing it

D. Replacing evidence with a visually attractive prototype

Correct Answer: B. Applying and evaluating an established method under a new, clearly defined laboratory condition

Question 3

What does verification primarily ask?

A. Was the correct system built for the intended users?

B. Was the implementation built according to its specified requirements?

C. Was the project commercially profitable?

D. Was the literature review sufficiently long?

Correct Answer: B. Was the implementation built according to its specified requirements?

Question 4

Which item is a measurable requirement?

A. The device should be modern

B. The system should be user friendly

C. The logger shall record temperature every 10 s

D. The prototype should be innovative

Correct Answer: C. The logger shall record temperature every 10 s

Question 5

Who owns primary responsibility for making and documenting project decisions?

A. The sponsor

B. The examiner

C. The laboratory technician

D. The student

Correct Answer: D. The student

Question 6

Which practice best supports reproducibility?

A. Reporting only successful tests

B. Keeping undocumented changes until the final report

C. Recording instruments, configurations, procedures and data-processing steps

D. Removing anomalous results without explanation

Correct Answer: C. Recording instruments, configurations, procedures and data-processing steps

Question 7

A conclusion that applies laboratory results to all industrial environments without additional evidence is an example of what problem?

A. Overclaiming

B. Calibration

C. Requirements traceability

D. Scope control

Correct Answer: A. Overclaiming

Question 8

Which statement about a supervisor is most appropriate?

A. The supervisor should write the dissertation for the student

B. The supervisor provides guidance while the student retains ownership of the work

C. The supervisor replaces the need for safety approval

D. The supervisor determines results before testing begins

Correct Answer: B. The supervisor provides guidance while the student retains ownership of the work

Question 9

Why is a requirements-traceability matrix useful?

A. It links requirements to design elements, verification methods and results

B. It guarantees that a prototype will be commercially successful

C. It eliminates the need for testing

D. It replaces the literature review

Correct Answer: A. It links requirements to design elements, verification methods and results

Question 10

Which action is most consistent with academic integrity when a test produces poor performance?

A. Delete the result without record

B. Change the result to match the expected outcome

C. Report and interpret the result, including relevant limitations

D. Ask the sponsor to approve a revised result

Correct Answer: C. Report and interpret the result, including relevant limitations