20 Final Year Project Defence Questions and Answers in Nigeria (2026)

Quick Summary

Prepare to explain your project’s problem, objectives, methods, findings, contribution and limitations.

For software projects, also prepare to demonstrate the application and explain its architecture, database, code and test results.

The answer examples below are patterns to adapt. Replace every placeholder with accurate details from your own work.

Do not memorise answers that describe methods, results or features you cannot demonstrate.

How to Answer Project Defence Questions

A useful answer has three parts:

1. Answer the question directly.
2. Support it with evidence from your project.
3. Explain the connection to your objective or design decision.

For example, if asked why you chose a database, name it, explain the requirement it served and acknowledge any relevant trade-off.

Keep your initial answer focused. Add detail when the panel asks.

If a question is unclear, ask for clarification before answering.

Questions About Your Topic and Problem

1. What Is Your Project About?

Explain the problem, your approach and the main outcome.

Research-project pattern:

My project investigated [specific issue] among [group or setting]. I used [method] to examine [research question]. The main finding was [actual finding].

Software-project pattern:

My project developed a student clearance system for [defined context]. Students submit requests, unit officers record decisions, and students track their progress. The implementation was evaluated using [actual tests or evaluation].

Avoid describing an entire field when the panel asks about your particular project.

2. Why Did You Choose This Topic?

Connect your choice to an identified problem and a realistic scope.

Answer pattern:

I chose this topic because [problem and supporting observation or source]. It was feasible within the available time because [access, skills or resources]. The project focused on [specific boundary].

Interest can be part of your explanation, but show why the work was worth undertaking.

3. What Problem Does Your Project Address?

Explain the difficulty and who experiences it.

Software-project pattern:

The existing process records clearance decisions in separate locations, making progress difficult to track. My project investigated a system that brings the request and unit decisions into one workflow.

Use this example only if it reflects your investigation. Do not claim that a process is slow, costly or inaccurate without supporting evidence.

4. What Are Your Aim and Objectives?

State the overall purpose, followed by the main steps.

Software-project pattern:

The aim was to develop [system]. The objectives were to analyse the requirements, design the application and database, implement the core functions, and evaluate them against defined requirements.

Your answer should match the final report. Be ready to identify the evidence addressing each objective.

5. Who Benefits From the Project?

Identify the intended users or beneficiaries and explain the potential value.

Answer pattern:

The intended users are [groups]. The system provides [specific function] to support [task]. My evaluation established [what was actually checked], while [wider benefit] would require further investigation.

Distinguish intended benefits from improvements you measured.

Questions About Literature and Contribution

6. What Did Previous Studies or Existing Systems Show?

Summarise the findings relevant to your project.

Answer pattern:

I reviewed [relevant studies or systems]. They addressed [problem] using [approaches]. The aspects most relevant to my work were [findings, features or limitations], which informed [specific decision].

Prepare to discuss a few important sources in detail rather than reciting author names.

7. What Gap Does Your Project Address?

Explain your contribution without exaggerating its novelty.

Answer pattern:

The reviewed work addressed [existing knowledge or capability]. My project focused on [specific context, requirement, comparison or evaluation]. Its contribution is [supported contribution].

A new location or case-study name alone does not establish a research gap. Explain why that context changes the requirements or question being investigated.

8. What Theory, Framework or Design Approach Guided Your Work?

Describe the framework you actually used and how it influenced the work.

Research-project pattern:

I used [theory or framework] because it explains [relevant concept]. It informed [variables, questions or interpretation].

Software-project pattern:

The design separates [components or responsibilities]. This supported [requirement], and it is reflected in [diagram or implementation].

Do not invent a theory to answer the question. Follow the type of explanation appropriate to your project.

See Conceptual Framework vs Theoretical Framework.

Questions About Your Methods

9. What Methodology Did You Use, and Why?

Explain your actual process.

Research-project pattern:

I used [research design] because the study aimed to [objective]. Data were collected through [method] and analysed using [procedure].

Software-project pattern:

I gathered requirements through [actual sources], designed [components], and implemented the system in [actual stages]. I tested each stage using [procedure] and revised [example] after [feedback or failure].

Naming “Agile” or “Waterfall” is not enough. Explain what happened during your project.

10. What Was Your Population or Data Source?

Identify the source of your evidence.

Research-project pattern:

The target population was [group]. The population figure came from [source and date], and participants were selected using [procedure].

Software-project pattern:

Requirements came from [interviews, observation, documents or literature]. Demonstration records were [fictional, public or authorised records], and evaluation used [actual test data or participants].

A software project does not automatically require a survey population.

11. How Did You Determine Your Sample Size or Select Your Data?

Explain the reasoning and assumptions.

Research-project pattern:

The sample size was determined using [method and assumptions]. Participants were selected through [procedure], and [actual number] responses were included in the analysis.

Dataset-project pattern:

Records were included when they met [criteria]. I excluded [records and reasons] and used [procedure] to separate the data for development and evaluation.

Do not name a formula or selection method you did not use.

12. What Instrument or Procedure Did You Use?

Explain how information was collected or requirements were investigated.

Answer pattern:

I used [questionnaire, interview guide, observation procedure or document-review process]. It covered [topics], and the information was recorded through [actual procedure].

If you used an existing instrument, identify its source and explain any adaptations.

13. How Did You Check the Quality of Your Evidence?

Answer according to the project type.

Questionnaire-study pattern:

I assessed [relevant validity evidence] through [actual review procedure]. Reliability was examined using [assessment and actual result], where applicable.

Software-project pattern:

I translated the requirements into test cases, including normal inputs, invalid inputs and permission checks. I recorded the observed outcomes and repeated relevant tests after corrections.

Supervisor approval alone is not a reliability assessment. A pilot study should also be explained rather than presented as automatic proof of quality.

14. How Did You Analyse or Evaluate the Work?

Name the procedure and explain why it matched the objective.

Research-project pattern:

I used [method] to address [question]. It was appropriate because [reason connected to the data and design].

Software-project pattern:

I evaluated whether the application met [requirements] using [tests]. I also conducted [user evaluation or performance assessment] where applicable.

Do not present a software package’s name as the complete analysis method.

For further preparation, review How to Write Chapter Three.

Questions About Outcomes and Limitations

15. What Was Your Main Finding or Outcome?

Choose the most important supported result.

Research-project pattern:

The main finding was [actual result]. It addressed [objective], within the limits of [design or sample].

Software-project pattern:

The main outcome was an application supporting [core workflow]. Testing showed [actual outcome], while [limitation] remains unresolved.

Avoid “the system worked perfectly.” Explain what was checked.

16. Did You Achieve Your Objectives?

Map objectives to evidence.

Answer pattern:

Objective one was addressed through [evidence]. Objective two was addressed through [evidence]. Objective three was [completed, partly completed or not completed] because [reason].

Partial completion should be explained honestly. Do not claim that every objective was achieved simply because the report is finished.

17. What Conclusion Did You Reach?

State what the evidence supports.

Answer pattern:

The project supports the conclusion that [bounded conclusion]. This applies to [scope or conditions]. Further work is needed before claiming [broader outcome].

For software, distinguish successful implementation from proven organisational impact.

18. What Recommendations Did You Make?

Connect recommendations to findings or limitations.

Answer pattern:

Based on [finding or limitation], I recommend [action] by [relevant person or group]. Before wider use, the system would require [specific additional work].

Avoid recommendations unrelated to the work.

19. What Are the Limitations?

Identify meaningful boundaries and their implications.

Answer pattern:

The project was limited by [specific constraint]. This means the results do not establish [claim outside the evidence]. A next step would be [realistic improvement].

Examples include restricted datasets, limited user evaluation, simulated integrations or a local-only deployment.

20. What Was Your Own Contribution?

Explain the work you performed and the assistance you used.

Answer pattern:

I was responsible for [specific activities]. I used [sources, libraries, tools or assistance] for [purpose]. I verified the result by [checks], and my contribution included [design, implementation, analysis or evaluation].

Acknowledge collaboration and existing components accurately. Be ready to demonstrate your understanding.

Additional Software and Computer Science Defence Questions

A panel may ask you to move from a general explanation into the implementation.

Why Did You Choose This Language and Database?

Explain their roles and the requirements they served.

For example, a local database may simplify installation for a single-machine demonstration. Describe the limitations as well as the benefit.

How Do Your Database Tables Connect?

Use your actual ER diagram and schema.

Identify primary keys, foreign keys and important relationships. Explain how the design represents the workflow.

For a clearance system, you might trace how a request connects to a student and several unit decisions—if that matches your implementation.

Can You Trace One Action Through the Code?

Practise following:

Screen → request → route or controller → validation → database operation → response.

Use actual file and function names. Choose an important action such as submitting a request, issuing a book or allocating a room.

What Prevents Unauthorised Access?

Identify where permissions are checked.

Show a relevant test, such as a student attempting to open an administrator’s page. Hiding a menu item alone does not demonstrate that access is restricted.

What Happens When an Input Is Invalid?

Demonstrate a missing field, duplicate record, conflicting booking or another important rule.

Explain whether the operation is rejected, what the user sees and whether the database remains consistent.

How Are Passwords Handled?

Explain the actual password-storage and verification process.

If the application uses password hashing, identify the relevant library or function. Do not describe hashing as decrypting a password.

Does Every Feature Work Without Internet?

Identify which components run locally and which depend on external services.

Clearly distinguish live integrations from simulations.

How Did You Test the System?

Prepare to show a test case with:

• Starting conditions.
• Input or action.
• Expected result.
• Observed result.
• Status.
• Any correction and retest.

See How to Present Implementation and Testing in Chapter Four.

How to Prepare a Short Software Demonstration

Choose one complete workflow that addresses a core objective.

For a student clearance application, an illustrative sequence is:

1. Sign in as a student.
2. Submit a request.
3. Sign in as an authorised officer.
4. Record a unit decision.
5. Return to the student view.
6. Explain the updated status and remaining approval conditions.

Adapt the sequence to your actual system.

Before the defence:

• Start the application from a fresh launch.
• Confirm the database and required services are available.
• Prepare clearly labelled demonstration records.
• Check each account and permission.
• Rehearse one invalid-input or access-control example.
• Keep permitted backup materials available.
• Practise within the presentation time.

Use screenshots as supporting material. If a live demonstration fails, explain the issue accurately rather than presenting a screenshot as proof that it is currently working.

Preparing With MonoEd

If you have an approved software topic, MonoEd Project Source Code provides systems built around students’ topics, with software options in Python or PHP.

Packages include source code, an explanatory guide, setup instructions, screenshots and defence questions based on the build.

Use these materials to study:

• Run each core workflow.
• Read the relevant code and database queries.
• Repeat important tests.
• Make a small change and explain its effect.
• Update your report after modifications.

Follow your department’s rules on assistance and disclosure.

For the written report, MonoEd FYP Report Generator can support drafting and organisation. Verify that the text matches your evidence and final implementation.

What If You Do Not Know an Answer?

Pause and identify what the panel is asking.

If needed, say:

Could you clarify whether you mean [interpretation A] or [interpretation B]?

If the question is outside your work:

I did not evaluate that within this project. What I can establish from my work is [supported point]. Investigating the wider question would require [relevant next step].

If the panel identifies an error, acknowledge it and explain the correction you understand.

Avoid inventing an answer or making promises about results you have not obtained.

What If You Are Asked About AI or External Assistance?

Answer truthfully and follow your institution’s requirements.

Describe:

• What assistance you used.
• Which tasks it supported.
• What you checked or changed.
• Which decisions and activities were your responsibility.

Understanding and editing assisted work do not remove disclosure requirements.

Likewise, a tool-generated reference, test result or explanation should not be presented as verified evidence unless you checked it appropriately.

Your One-Page Defence Preparation Sheet

Prepare brief notes covering:

• Project title and problem.
• Aim and objectives.
• Important sources or existing systems.
• Methods and reasons for choosing them.
• Main findings or implemented functions.
• Evidence supporting each objective.
• Contribution and assistance used.
• Limitations and recommendations.

For software projects, add:

• Architecture and database relationships.
• Main file and function names.
• Demonstration sequence.
• Important test outcomes.
• Installation and connectivity requirements.

Check that your slides match the final report. See the Project Defence PowerPoint Guide.

Frequently Asked Questions (FAQs)

Should I memorise these answers?

No. Practise explaining the points using your own evidence. The panel may ask the same question in a different way or request a demonstration.

How long should each answer be?

Start with a direct, focused answer. Provide supporting detail when necessary or requested. Follow any presentation-time guidance from your department.

Must I demonstrate my software?

Check your department’s requirements. Prepare to explain and demonstrate the core functions if your project includes a working system.

Should I study every line of code?

Understand the overall structure and be able to trace important workflows, database operations, permissions and error handling. Do not claim authorship or understanding you cannot demonstrate.

What if the software fails during the defence?

Explain what happened, attempt a reasonable recovery and use permitted backup materials. Distinguish earlier test evidence from the application’s current state.

Can I bring notes?

Follow your department’s rules. A short printed outline may be useful if notes are permitted.

What is the best preparation?

Review your evidence, rehearse aloud and practise answering follow-up questions. For software, run the system from a fresh start and explain one complete workflow through the interface, code and database.