How to Write Chapter Four of a Final Year Project in Nigeria: Results, Implementation and Testing

Learn how to write Chapter Four for research and software projects, with examples of results, tables, screenshots, implementation details and test reports.

Mohammad Jamiu
Published on Oct 14, 2026
How to Write Chapter Four of a Final Year Project in Nigeria: Results, Implementation and Testing

Quick Summary

Chapter Four presents the outcomes of the work described in Chapter Three.

What you include depends on your project:

  • Survey research: Response details, descriptive statistics, answers to research questions and relevant hypothesis tests.
  • Qualitative research: Themes or other analytical findings supported by evidence from interviews, observations or documents.
  • Software projects: The implemented system, main screens, important workflows and testing results.
  • Experimental or prediction projects: Experimental outcomes, model performance, comparisons and evaluation results.

Follow your department’s structure. Some reports combine results and discussion in Chapter Four; others place the fuller discussion in Chapter Five.

Present actual findings. Clearly distinguish collected data, demonstration records, simulated features and tests that have not been completed.

What Is Chapter Four About?

Chapter Four shows what your project produced.

For a questionnaire study, this might mean the responses collected and the analysis addressing your research questions.

For a software project, it might mean the working application, how its features operate and the results of testing.

The chapter should connect three things:

  1. Your objectives: What you intended to investigate or develop.
  2. Your methods: How you carried out the work.
  3. Your evidence: What you found or produced.

A clear presentation cannot compensate for missing evidence. If an activity was not completed, report that limitation honestly.

Before writing, check that your methods are accurately described in Chapter Three.

Choose an Outline That Fits Your Project

Do not force every project into a questionnaire format.

A software application does not automatically need a demographic table. A qualitative study does not automatically need percentages or hypothesis tests.

Use the sections required to explain your work and follow your department’s handbook.

Chapter Four Outline for a Quantitative Research Study

A possible structure is:

  1. Introduction.
  2. Response details and data preparation.
  3. Relevant participant characteristics.
  4. Results organised by research question or objective.
  5. Hypothesis tests, where applicable.
  6. Discussion, if required in this chapter.
  7. Summary of findings.

1. Introduction

Briefly state what the chapter presents and how it is organised.

Writing pattern:

This chapter presents the results of the study on [topic]. It describes the responses included in the analysis and presents findings according to the research questions and hypotheses.

Replace the bracketed text with your actual details.

2. Response Details and Data Preparation

Explain how many responses or observations were available and which were included.

Distinguish between:

  • People invited or questionnaires distributed.
  • Responses received.
  • Responses excluded.
  • Responses included in the analysis.

Illustrative example only:

Of 150 questionnaires distributed, 126 were returned. Six were excluded because they did not meet the stated completeness criteria, leaving 120 for analysis.

In this example, the return rate is 84%, while the proportion of distributed questionnaires included in the analysis is 80%. Label the measure you report and explain its denominator.

Describe relevant treatment of missing answers, duplicate records or coding errors. Do not remove inconvenient responses simply because they weaken an expected finding.

3. Participant Characteristics

Present background information that helps readers understand the sample.

Relevant characteristics might include programme, level of study, age group or another variable connected to the research.

Include only what is useful and appropriate. Avoid identifying individuals through small or unusually specific groups.

Illustrative table using fictional figures:

Level of studyFrequencyPercentage
200 level3025.0%
300 level4235.0%
400 level4840.0%
Total120100.0%

A short explanation could state:

Final-year students formed the largest group, accounting for 40.0% of the analysed responses.

You do not need to repeat every number in the table.

4. Present Results by Research Question

Use headings that make the connection to your objectives clear.

For each question:

  1. State the question or objective.
  2. Present the relevant table, chart or analytical result.
  3. Explain the main pattern.
  4. Identify important exceptions or uncertainty.

If respondents report that social media distracts them, describe that as their reported experience. Their agreement alone does not establish that social media caused a change in academic performance.

Use wording that matches what your method can support.

5. Report Hypothesis Tests Where Applicable

Use the analysis specified and justified in your methodology. If the approach changed, explain the reason and update the methods section.

Depending on the test, report:

  • The hypothesis examined.
  • The statistical procedure.
  • Relevant sample size.
  • Test statistic and degrees of freedom, where applicable.
  • The p-value.
  • Effect size and confidence interval, where appropriate.
  • The conclusion in the context of the research question.

A writing pattern might be:

The association between [variable A] and [variable B] was examined using [test]. The result was [statistic and relevant details], with p = [actual value]. This provided [describe the evidence] regarding [hypothesis].

Do not treat a p-value as the probability that your hypothesis is true. Statistical significance also does not establish the size or practical importance of an effect. The American Statistical Association’s guidance explains these distinctions.

When a result does not meet your chosen significance threshold, avoid claiming that the null hypothesis has been proved.

Chapter Four for Qualitative Research

Qualitative findings need a clear analytical structure and supporting evidence.

Depending on your method, organise the chapter around themes, cases, categories or another justified framework.

For each finding:

  • Explain the pattern or interpretation.
  • Support it with relevant evidence.
  • Include differences or contradictory accounts.
  • Connect it to the research question.

Illustrative Theme Presentation

Theme: Difficulty Tracking Clearance Progress

Participants described uncertainty about which university units had processed their clearance requests. Some reported making repeated visits to obtain updates.

In your actual report, support this account with evidence from your interviews or other sources.

Use anonymised quotations where appropriate, following consent arrangements. Do not invent quotations or rewrite participants’ words as direct quotations.

Explain what the evidence means rather than presenting a long sequence of quotations without analysis.

Chapter Four for Software and Computer Science Projects

A system-development project may use Chapter Four to explain implementation and testing.

A possible outline is:

  1. Introduction.
  2. Implementation environment.
  3. Main modules and workflows.
  4. Screenshots and explanations.
  5. Testing results.
  6. User evaluation, if conducted.
  7. Limitations and summary.

Follow your department’s chapter arrangement if it differs.

1. Describe the Implementation Environment

State the tools and environment actually used.

Relevant details include:

  • Programming language and version.
  • Framework or major libraries.
  • Database.
  • Operating system.
  • Browser.
  • Relevant hardware specifications.
  • Installation or deployment arrangement.

Explain each tool’s role. Avoid listing software that was installed but not used.

For example:

The application uses Python and Flask to process requests and render pages. SQLite stores the application records. HTML templates and locally stored styles provide the user interface.

Use this wording only if it accurately describes your application.

2. Explain the Main Modules

Organise this section around the system’s functions.

For a student clearance system, modules might include:

  • Accounts and permissions.
  • Clearance applications.
  • Unit review and decisions.
  • Progress tracking.
  • Clearance-slip generation.
  • Administration and reporting.

Explain who uses each module, what they do and what happens to the records.

Describe implemented behaviour. Put unfinished features in the limitations section.

3. Present Screenshots With Useful Captions

Choose screenshots that demonstrate important requirements.

For each screenshot:

  1. Introduce the screen or workflow.
  2. Insert a readable image.
  3. Add a numbered caption.
  4. Explain the relevant behaviour.

Example caption:

Figure 4.2: Student dashboard showing the status of clearance decisions across university units.

Explain the decision rule as well as the appearance. For example, a clearance slip may remain unavailable until every required unit approves the request.

Use screenshots from your own build. Remove sensitive information and label sample records.

A screenshot demonstrates what was displayed at a particular moment. It does not, by itself, prove that permissions, calculations or other rules work correctly.

4. Report Actual Testing Results

Connect your tests to the requirements defined earlier.

A useful test record includes:

  • Test identifier.
  • Feature or requirement.
  • Starting conditions and inputs.
  • Action performed.
  • Expected result.
  • Actual result.
  • Status.

Example test plan — these tests have not been executed:

Test IDActionExpected resultActual resultStatus
T01Attempt login with an incorrect passwordLogin is rejectedNot yet recordedNot run
T02Submit a clearance request without a required fieldA validation message appears and no request is savedNot yet recordedNot run
T03Attempt to open another unit’s restricted requestAccess is deniedNot yet recordedNot run
T04Request a clearance slip while an approval is missingThe slip remains unavailableNot yet recordedNot run

For your completed Chapter Four, replace the final columns with observed outcomes from tests you actually ran.

Include important normal, invalid and boundary cases. Record failures, corrections and retests accurately. Keep test logs or other evidence where appropriate.

5. Separate Functional Tests From User Evaluation

These answer different questions:

  • Functional testing: Does the system behave according to its requirements?
  • User evaluation: How do intended users experience the system?

If users evaluated the application, describe who participated, what tasks they completed, how feedback was collected and what you found.

Do not claim that users were satisfied if no evaluation took place.

Likewise, successful tests do not establish that the application is fully secure, ready for production or suitable for every organisation.

6. Explain Limitations and Simulations

State what the implementation does and does not demonstrate.

Examples include:

  • Payment recording is simulated.
  • Notifications appear within the application rather than being sent by SMS.
  • Demonstration records are fictional.
  • Evaluation involved a limited group.
  • The application was tested locally but not deployed in a real organisation.

These details help readers assess the result accurately.

Connecting Your Source Code to Chapter Four

Your screenshots, feature descriptions, database explanations and tests should all describe the same build.

MonoEd Project Source Code provides systems built around students’ topics, with software options in Python or PHP. Packages include source code, screenshots, setup instructions, an explanatory guide and defence questions.

You can explore the Student Clearance Management System example to see how a project is presented.

Use supplied materials as a starting point. Run your copy, verify its behaviour and update the documentation after changes. Follow your department’s rules on assistance and disclosure.

Reporting Machine Learning or Prediction Results

If your project evaluates a model, include details needed to understand its performance:

  • The task and dataset.
  • How training, validation and test data were separated.
  • Any baseline used for comparison.
  • Metrics appropriate to the task.
  • Important errors and limitations.

For a classification task, accuracy alone may hide poor performance on a less common class. Explain why your chosen metrics suit the problem.

Do not present performance on training data as independent evidence of performance on new data.

Label synthetic or sample datasets and avoid claiming real-world effectiveness beyond what your evaluation supports.

How to Present Tables, Charts and SPSS Output

Use tables for exact values and charts where they make a pattern easier to understand.

For each table or figure:

  • Follow your department’s numbering convention.
  • Give it a descriptive title or caption.
  • Label variables, units and abbreviations.
  • Identify the source where required.
  • Refer to it in the text.
  • Explain the relevant finding without repeating every value.

For SPSS or other statistical software, present the results needed to answer your questions in a readable format. Keep detailed output in the appendix if your department requires it.

There is no universal rule that all SPSS output must appear in the appendix. Preserve the statistics needed to assess your analysis and follow the required reporting style.

Does Discussion Belong in Chapter Four or Chapter Five?

Check your approved structure.

In a results-only chapter, present the findings and the explanation necessary to understand them. Place the fuller discussion in the designated chapter.

In a combined results-and-discussion chapter, interpret findings, relate them to your objectives and compare them with relevant literature.

Do not move all explanation to Chapter Five if your department expects discussion alongside the results.

Whichever structure you use, distinguish an observed result from a possible explanation.

Common Chapter Four Mistakes

  • Presenting invented responses, quotations, screenshots or test results.
  • Using a questionnaire structure for a software project.
  • Reporting percentages without clear totals.
  • Ignoring missing data or exclusions.
  • Selecting only favourable findings.
  • Copying software output without explaining it.
  • Claiming causation from a method that only examines association.
  • Describing simulated features as live integrations.
  • Claiming user satisfaction without user evaluation.
  • Showing screens that do not match the documented system.
  • Drawing conclusions that go beyond the evidence.

How to End Chapter Four

Summarise the main outcomes in the order of your objectives.

For a research study, identify the principal findings without introducing new analysis.

For a software project, summarise the implemented functions, verified test outcomes and remaining limitations.

Writing pattern:

This chapter presented [findings or implemented functions] and the results of [analysis or testing]. The main outcomes were [brief summary]. The following chapter discusses [content required by your department].

Replace every placeholder with an accurate account of your work.

MonoEd FYP Report Generator can support drafting and organisation. Supply your actual evidence and check that generated text does not introduce unsupported findings.

Frequently Asked Questions (FAQs)

What should Chapter Four contain?

The outcomes of your project, organised according to your objectives and departmental structure. These may be research findings, experimental results, software implementation or testing evidence.

Must Chapter Four include hypothesis testing?

No. Include hypothesis tests only when they fit your research questions and methods. Qualitative studies and software projects may use other forms of analysis and evaluation.

Can I discuss findings in Chapter Four?

Yes, if your department uses a combined results-and-discussion structure. Follow the approved format.

Should SPSS output appear in Chapter Four?

Include the relevant results in a readable form. The placement of detailed output depends on departmental guidance.

How many software screenshots should I include?

Use enough to explain the important workflows and requirements without repeating similar screens. Follow any departmental limit.

Can I use sample data in software screenshots?

Yes, where appropriate for demonstration, but label it clearly. Sample records are not evidence that real users participated or that field research occurred.

What if some software tests fail?

Report the outcomes, correct issues where possible and record retests. Explain unresolved failures and their implications.

How long should Chapter Four be?

Follow your department’s requirements. Its length should reflect the evidence needed to answer your objectives clearly.

What should I write after Chapter Four?

Follow your approved structure for discussion, conclusions and recommendations. See How to Write Chapter Five of a Final Year Project.

About the Author

Mohammad-Jamiu B. Balogun, GMNSE

Mohammad-Jamiu B. Balogun, GMNSE

AI Security Researcher · Founder, MonoEd Africa

Mohammad-Jamiu is a First-Class Telecommunications Engineer and Best Graduating Student, BUK '24, and an AI security researcher. He founded MonoEd Africa to give Nigerian students AI-powered academic tools — from SIWES logbooks to final year projects. His work has reached over 10,000 students across Nigeria.

Share this article