How to Write Chapter Three (Methodology) of a Final Year Project in Nigeria

Quick Summary

Chapter Three explains how you will carry out your project, or how you carried it out in the completed report.

Its structure depends on your project:

• Survey studies: Research design, population, sampling, instruments, data collection and analysis.
• Qualitative studies: Research approach, participant selection, interviews or observations, analysis and trustworthiness.
• Software projects: Requirements gathering, system analysis, development approach, architecture, database design and testing methods.
• Experimental or prediction projects: Materials or datasets, procedures, experimental design and evaluation methods.

Use your department’s handbook and supervisor’s guidance to organise the chapter. Describe your actual methods and explain why they suit your objectives.

What Is Chapter Three About?

Chapter Three connects your project objectives to the procedures used to address them.

A reader should be able to understand:

• What you investigated or developed.
• Why you chose your approach.
• Where your information came from.
• How participants, records or datasets were selected.
• Which tools and procedures you used.
• How you analysed information or evaluated the system.
• What permissions and ethical considerations applied.

A strong methodology explains both what you did and why that approach was appropriate.

Do not copy a methodology simply because its topic resembles yours. Two projects with similar titles can use different data, participants, development methods or evaluation procedures.

Choose the Structure That Fits Your Project

There is no single Chapter Three outline that fits every Nigerian department.

For example, a questionnaire study may need a population and sample size. A software project may instead require analysis of an existing process, database design and a testing plan.

Some projects combine these approaches. You might interview staff to identify requirements, build an application and then evaluate it with users.

Explain how each method contributes to the project rather than adding sections that do not apply.

Chapter Three Outline for a Survey-Based Study

Adapt the following headings to your department’s format:

1. Introduction.
2. Research design.
3. Study setting or area.
4. Population of the study.
5. Sample size and sampling procedure.
6. Data collection instrument.
7. Validity evidence.
8. Reliability assessment.
9. Data collection procedure.
10. Data analysis methods.
11. Ethical considerations.

The examples below are writing patterns. Replace bracketed text with verified details from your own work.

1. Introduction

Briefly explain what the chapter covers.

Example:

This chapter explains the methods used to investigate [research problem]. It describes the research design, study population, sampling procedure, data collection instrument, analysis methods and ethical considerations.

Include only the sections that appear in your chapter.

2. Research Design

Name your design, describe how you applied it and justify its suitability.

Example:

The study used a cross-sectional survey design to collect information about [variables] from [participants] during [period]. This approach was selected because the study aimed to describe [specific characteristics or relationships] at that time.

Do not claim that a survey establishes cause and effect merely because two variables are associated.

3. Study Setting or Area

Identify where the study took place and explain why the setting matters.

Include relevant details such as the institution, department, organisation or community.

Avoid lengthy geographical descriptions that do not help the reader understand the study.

4. Population of the Study

Define the group to which your study relates.

State:

• Who was eligible.
• Any relevant inclusion or exclusion criteria.
• The population size, if known.
• The source and date of that figure.

Example:

The target population comprised [eligible group] at [institution]. The accessible population was [number], based on [record source and date].

Do not invent a population figure to make a sample-size calculation possible.

5. Sample Size and Sampling Procedure

Explain how many participants you selected and how you selected them.

Sample size and sampling procedure answer different questions:

• Sample size: How many participants or observations?
• Sampling procedure: How were they chosen?

Justify the sample size using an appropriate calculation, study design, practical rationale or approved approach. If you use a formula, explain its assumptions and inputs.

Example:

A sample of [number] participants was selected using [procedure]. This procedure was chosen because [reason]. The sample size was determined using [method], with [relevant assumptions].

Do not describe a convenience sample as random sampling.

If your study uses a census, explain which eligible members were approached and how many participated.

6. Data Collection Instrument

Describe what you used to collect information.

For a questionnaire, explain:

• Whether it was developed, adapted or adopted.
• Its sections and number of items.
• The response options.
• The concepts measured.
• Any scoring procedure.
• The source and permission requirements, where applicable.

Example:

The questionnaire contained [number] sections covering [topics]. Responses to [specified items] used a [describe response scale]. Higher scores represented [meaning].

Include the instrument in the appendix where required.

7. Validity Evidence

Explain the evidence supporting the instrument’s suitability for its intended use.

For example, you might describe how reviewers checked whether the questions covered your objectives and were understandable to the intended respondents.

Report:

• Who reviewed the instrument.
• What they assessed.
• What changes followed.

Avoid treating “my supervisor approved it” as a complete explanation of validity.

8. Reliability Assessment

Reliability concerns the consistency of measurement. Depending on the instrument, relevant approaches may include internal consistency, test-retest assessment or agreement between observers. OpenStax explains these distinctions.

Describe the assessment you actually conducted, including:

• The participants or observations involved.
• The procedure.
• The measure calculated.
• The result and its interpretation.
• Any changes made afterwards.

Example:

Internal consistency was assessed for the [named scale] using responses from [pilot group]. The calculated coefficient was [actual result]. This was interpreted in relation to [appropriate methodological guidance].

Supervisor approval does not replace reliability assessment. If no assessment was conducted, explain that honestly and discuss its implications with your supervisor.

Do not invent a coefficient or apply Cronbach’s alpha automatically to every questionnaire.

9. Data Collection Procedure

Explain the sequence of activities clearly enough for another researcher to understand what happened.

Include relevant details about:

• Recruitment.
• Permissions and consent.
• Administration dates and mode.
• Instructions given to participants.
• Follow-up procedures.
• Handling incomplete responses.
• Data storage.

Distinguish the number invited from the number who responded.

10. Data Analysis Methods

Connect each analysis method to a research question or objective.

For example:

• Frequencies and percentages can summarise categories.
• Suitable numerical summaries can describe measured variables.
• Statistical tests should match the question, data and assumptions.

Naming SPSS, Excel or Python is not enough. Explain what you did with the software.

Example:

Responses to Research Question 1 were summarised using frequencies and percentages. The relationship specified in Hypothesis 1 was examined using [test], after checking [relevant assumptions].

Report your actual decisions. Do not add statistical tests simply to make the chapter appear more technical.

How Chapter Three Differs for Qualitative Research

A qualitative study may use interviews, observation, documents or other sources to explore experiences and processes.

Its methodology should explain:

• The research approach and its justification.
• The setting and participant selection.
• Recruitment and consent.
• How interviews or observations were conducted.
• Recording and transcription procedures.
• How the material was analysed.
• The researcher’s role and relevant assumptions.
• Steps taken to support a credible and transparent interpretation.

For example, do not stop at “thematic analysis was used.” Explain how you became familiar with the material, developed codes, examined patterns and refined your interpretation.

Do not add questionnaire reliability statistics unless they apply to an instrument actually used.

Chapter Three Outline for a Software or Computer Science Project

For a system-development project, an outline might include:

1. Introduction.
2. Requirements gathering.
3. Analysis of the existing system.
4. Requirements of the proposed system.
5. Development approach.
6. System architecture.
7. Database design.
8. Process and interface design.
9. Security and data handling.
10. Testing and evaluation methods.

Your department may place some design or implementation details in another chapter. Follow its required structure.

1. Requirements Gathering

Explain how you identified what the system should do.

Possible sources include:

• Interviews with intended users.
• Observation of an existing workflow.
• Review of forms and records.
• Relevant literature.
• Analysis of existing applications.

State which methods you actually used.

If requirements came from a project brief and literature rather than fieldwork, say so. Do not invent staff interviews or organisational visits.

2. Analysis of the Existing System

Describe the current process and the limitations supported by your investigation.

For a student clearance project, explain how requests move between units, how decisions are recorded and how students check progress.

Separate observed problems from assumptions that still need verification.

3. Requirements of the Proposed System

Describe the intended users and what each should be able to do.

For example:

• Student: Submit a clearance request and view progress.
• Unit officer: Review requests assigned to their unit.
• Administrator: Manage accounts and view reports.

Also describe requirements such as access restrictions, installation conditions and handling invalid inputs.

Make these requirements specific enough to test.

4. Development Approach

Explain how the work was organised.

A development lifecycle connects requirements, design, implementation and testing. Different approaches organise and revisit these activities differently. IBM provides an overview of the software development lifecycle.

Describe the process you followed and why it suited the project.

Example:

The application was developed incrementally. User accounts and clearance requests were implemented first, followed by unit decisions and reporting. Each increment was tested before the next was added.

Do not label the work “Agile” or “Waterfall” without explaining what that meant in practice.

5. System Architecture

Explain the main components and how they communicate.

A small web application might contain:

• A browser interface.
• Application routes and business rules.
• A database.
• Locally stored assets or uploaded files.

Name the actual technologies and justify their roles.

For example, explain why a local database and server-rendered pages suited your installation requirements.

6. Database Design

Describe the tables, fields, keys and relationships supporting the requirements.

For a clearance system, possible records include users, units, clearance requests and unit decisions. Your final design must match the implementation.

Include an ER diagram where required and explain important relationships.

See ER Diagrams for Final Year Projects.

7. Process and Interface Design

Show how users complete important activities.

For example:

1. A student submits a request.
2. The system records it.
3. An authorised officer reviews it.
4. The officer’s decision updates the student’s progress.
5. The system releases the clearance slip when the required conditions are met.

Use diagrams that help explain these steps. Keep the terminology consistent with your screens and database.

8. Security and Data Handling

Describe controls implemented or planned, depending on the stage of the report.

Relevant controls may include:

• Password hashing.
• Server-side permission checks.
• Input validation.
• Parameterised database queries.
• Restrictions on uploaded files.
• Protection of personal information.

Explain what each control does in your application. Avoid describing the system as completely secure.

9. Testing and Evaluation Methods

Explain how you will check the requirements.

For each important feature, define:

• The starting condition.
• The action or input.
• The expected result.
• How the actual result will be recorded.

For a clearance system, test whether an officer can access another unit’s requests and whether a clearance slip remains unavailable while a required approval is missing.

Separate software tests from user evaluation. A feature passing a test does not establish that users found it useful.

Report completed outcomes in the chapter required by your department. Never present planned tests as completed tests.

Building the System Your Methodology Describes

Your report, diagrams and software should describe the same project.

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.

You can examine the Student Clearance Management System example to see how users, features and records connect.

Check the supported scope and follow your department’s rules on assistance and disclosure. Describe the requirements, development work and checks you actually carried out.

Ethical Considerations

Explain the requirements applying to your own study.

Where relevant, cover:

• Institutional or organisational permission.
• Ethics review.
• Informed consent.
• Voluntary participation.
• Confidentiality and access controls.
• Storage, retention and deletion of information.
• Handling sensitive records.
• Disclosure of relevant assistance.

Do not claim approval or consent that was never obtained.

For software projects, clearly label fictional or sample records. They should not be presented as real participants, field data or evidence of deployment.

Should Chapter Three Use Past or Future Tense?

Match the wording to the stage of the work.

In a proposal:

Interviews will be conducted to identify the reporting requirements.

In a completed report:

Interviews were conducted to identify the reporting requirements.

Use present tense where appropriate for established descriptions. The key is to distinguish planned activities from completed activities and follow your department’s style.

Common Chapter Three Mistakes

• Using a survey outline for a project that develops software.
• Listing methods without explaining why they fit the objectives.
• Confusing population size, sample size and response count.
• Claiming random sampling without using a random procedure.
• Inventing interviews, permissions, pilot studies or reliability results.
• Treating software names as analysis methods.
• Including diagrams that contradict the database or application.
• Claiming a development approach that does not describe the work.
• Reporting planned tests as completed results.
• Copying another project’s methodology without adapting and verifying it.

Chapter Three Checklist

Before submitting, confirm that:

• Each objective connects to a method or development activity.
• The structure follows your department’s guidance.
• Sources of data and requirements are identified.
• Numbers and procedural details are accurate.
• Planned and completed activities are clearly distinguished.
• Instruments and diagrams appear in the appropriate sections or appendices.
• The analysis or evaluation approach is explained.
• Limitations and ethical requirements are addressed.
• The chapter matches the work you can demonstrate.

MonoEd FYP Report Generator can support drafting and organisation. Supply accurate project details and verify that every statement reflects your methods and evidence.

Frequently Asked Questions (FAQs)

Is Chapter Three the same for every department?

No. Survey research, qualitative studies, experiments and software projects can require substantially different sections. Use your department’s handbook.

Does every project need a population and sample size?

No. These sections apply when your study involves a relevant population and selection process. A software project may still need participant selection details if you interview or evaluate with users.

Does supervisor approval establish reliability?

No. Report the assessment appropriate to your instrument. Approval and reliability evidence serve different purposes.

Can I write Chapter Three before collecting data or building the system?

Yes, as a description of the proposed methods. Revise the completed report to reflect what actually happened.

Where should software test results appear?

Follow your department’s structure. Chapter Three can explain the testing method, while completed results may belong in an implementation or results chapter.

How long should Chapter Three be?

Use any departmental limit. Include enough detail to explain and justify the work without repeating unrelated theory.

Can I use AI to help write Chapter Three?

Follow your institution’s rules. Verify the draft and disclose assistance as required. AI output must not introduce methods, participants, results or approvals that do not exist.

What should I write next?

Follow your approved structure. For guidance on presenting outcomes, read How to Write Chapter Four of a Final Year Project.