Chapter 4 of a development-based computer science FYP contains implementation and evaluation, not statistical hypothesis testing. It presents the built system module by module with interface figures, then reports evidence that it works: a test case table with expected and actual outcomes, functional and non-functional testing results, and a user acceptance or model performance evaluation.
The confusion is understandable. Chapter 4 in most Malaysian FYP handbooks is titled “Results and Discussion”, and almost every example your seniors leave behind is a survey study full of SPSS output. You built a mobile attendance system, a machine learning classifier or a web-based inventory platform. There is no t-test to run. This article answers the specific questions development students ask, in the order they ask them.
What is the actual difference between Chapter 3 and Chapter 4 in a development FYP?
Chapter 3 is the plan and the design. Chapter 4 is the artefact and the evidence.
Chapter 3 holds your chosen software development methodology and its justification — waterfall, iterative prototyping, agile or a hybrid — plus requirements analysis, use case diagrams, sequence diagrams, entity relationship diagrams, system architecture, and your planned testing strategy. Chapter 4 holds the working system, the code-level implementation decisions you actually made, the interface screens, and the results of executing the testing strategy you promised.
The clean dividing line: if a diagram describes what you intended to build, it belongs in Chapter 3. If a figure shows what exists and runs, it belongs in Chapter 4. Students who blur this end up with a Chapter 4 that repeats their design chapter and contains no evidence at all, which is the single most common reason a development FYP scores poorly. Engineering students in the same faculty face the mirror image of this problem, and comparing how an engineering lab FYP structures its methodology makes the boundary clearer: their Chapter 3 promises a test matrix, and their Chapter 4 fills it in. Yours promises test cases, and Chapter 4 fills those in.
How should the implementation section be organised?
Organise by module or by functional requirement, never by file or by the chronological order in which you happened to code things. For each module, give the reader four things in a consistent pattern:
- Purpose. One or two sentences on what the module does and which requirement from Chapter 3 it satisfies. Reference the requirement identifier explicitly, so the examiner can trace it.
- Interface figure. A screenshot of the working screen, numbered as Figure 4.x with a caption, referred to in the text.
- Implementation detail. The technical decisions that matter — how authentication was handled, how the database query was structured, which library performed a task, how a specific constraint was enforced.
- A short code excerpt where it genuinely explains something. Ten to twenty lines of the algorithm or query that is central to the module, formatted as a numbered listing. Full source code goes to the appendix.
Keep the environment specification in one place: languages and versions, framework, database, IDE, hosting or deployment target, and the hardware you developed and tested on. Examiners ask about versions because a system that only runs on your laptop is a real weakness.
How many screenshots is too many?
A screenshot must do work. Include one per significant screen or state — the login flow, the main dashboard, each core transaction screen, an error or validation state, and any admin view. Cropped, readable, and captioned.
What you should not do is paste twenty near-identical screens showing a list with one extra row. Malaysian FYP examiners have seen the padded report before, and a Chapter 4 that is 80 percent images with three sentences between them reads as thin. If you have many similar screens, group them into one figure with labelled panels.
What testing evidence does an examiner actually want to see?
A test case table is the backbone of Chapter 4, and it is what distinguishes a report about a system from a report that merely shows one. Build a table with these columns: test case ID, module, test description, input data, expected result, actual result, and status marked pass or fail.
Cover the layers your Chapter 3 promised. Unit testing checks individual functions. Integration testing checks that modules exchange data correctly. System testing checks complete workflows end to end. User acceptance testing checks that real users can achieve real tasks. Include boundary and negative cases — an empty field, an invalid date, a duplicate record, a wrong password, a very large upload — because a table showing only successful happy paths tells an examiner you tested nothing difficult.
Report failures honestly. A test case that failed, followed by the diagnosis and the fix and a re-test that passed, is stronger evidence of engineering competence than a table with a hundred consecutive passes. Examiners are suspicious of perfection.
How do I evaluate a system when there is no experiment to run?
Choose the evaluation type that matches what you built, and state it in Chapter 3 so Chapter 4 delivers on a promise rather than improvising.
- Usability evaluation. Recruit a small group of representative users, give them defined tasks, and measure completion and satisfaction. The System Usability Scale is the standard instrument here: ten alternating positive and negative statements answered on a five-point scale, converted to a single score out of 100. It is widely used precisely because it is short and comparable across systems.
- Functional acceptance. Users or your client sign off that each requirement is met, recorded against your requirements list.
- Performance benchmarking. Response time per operation, page load time, query execution time, concurrent user handling, memory footprint. Report as a table with the test conditions stated.
- Model performance, for machine learning FYPs. See the next section.
Usability and acceptance evaluations involve human participants, which means the design of your evaluation questionnaire and the number of users you recruit both become defensible or indefensible choices. Our guidance on how many respondents an evaluation study needs applies to this section, with one important caveat: usability testing conventions accept much smaller groups than survey research does, and you should justify your number on usability grounds rather than by quoting a sample size table meant for population surveys.
What if my FYP is a machine learning or data science project?
Then Chapter 4 is closer to a conventional results chapter, and it should contain:
- Dataset description as used. Final record counts after cleaning, class distribution, and the train, validation and test split with proportions and whether the split was stratified.
- Training configuration. Hyperparameters, epochs, learning rate, and how you selected them.
- Performance metrics. Accuracy alone is not enough, particularly with imbalanced classes. Report precision, recall and F1 per class, with a confusion matrix. For regression, report error metrics such as RMSE and MAE with the units of your target variable.
- Baseline comparison. Compare against at least one simpler model or against the published result you cited in your literature review. A model with no comparison point has no interpretable performance.
- Discussion of errors. Which cases the model gets wrong and a plausible explanation. This paragraph is often what separates a good FYP from an average one.
If you compare several models across multiple runs and want to claim one is genuinely better rather than luckier, a significance test may be appropriate; our walkthrough of choosing a statistical test for FYP data covers how to pick one. For most undergraduate projects, a clearly presented metrics table with a stated baseline is sufficient.
Do I need SPSS anywhere in a development FYP?
Usually not. If your only quantitative data is a ten-user usability questionnaire, descriptive statistics computed in Excel — mean, standard deviation and the aggregate score — are appropriate and honest. Running inferential tests on ten respondents in order to look rigorous has the opposite effect, because the first question in your viva will be about your statistical power. Match the analysis to the evidence you actually have.
What if my system is not finished?
Report the working scope precisely and place the rest in future work. Write which modules are complete and tested, which are partially implemented, and which were descoped, with the reason — an API that required paid access, a hardware component that did not arrive, a semester that ran out.
An incomplete but honestly documented system with solid testing of what exists is graded far more kindly than a claimed complete system that visibly fails during the demonstration. Malaysian FYP assessments almost always include a live demonstration, and your Chapter 4 claims will be checked against a running system in front of you.
How does Chapter 4 differ between an undergraduate FYP and a postgraduate thesis?
An undergraduate FYP is assessed largely on whether you can build and validate a working artefact. A master’s or doctoral thesis must additionally contribute something novel and situate the result against existing literature in depth. The scope, the depth of evaluation and the expected literature engagement all step up, which is why the terms are not interchangeable — the distinctions are set out in our explainer on how FYP, thesis and dissertation differ in Malaysia. The reporting conventions for tables, figures and numerical results are shared across both, and are covered in our guide to the standard results chapter conventions.
Get the chapter drafted while the system is still fresh
The practical difficulty with a development FYP is that you finish coding in week eleven and then have to convert commit messages, WhatsApp screenshots and a folder of test notes into formal academic English before submission. Tesify builds a structured Chapter 4 draft around your modules, test cases and evaluation results, in the order Malaysian FYP handbooks expect, so your remaining time goes into verifying that every claim matches the system you will demonstrate. You stay the author, and every result in the chapter remains yours to defend.
Draft your Chapter 4 with Tesify
Frequently asked questions
Should Chapter 4 be called Results or Implementation in a computer science FYP?
Follow your faculty handbook. Many Malaysian computer science departments allow “Implementation and Testing” or “System Implementation and Evaluation” for development projects even where the generic template says “Results and Discussion”. Confirm with your supervisor before renaming, and keep the numbering consistent with the rest of the report.
How many users do I need for a usability test?
Usability testing conventions accept far smaller groups than survey research, and undergraduate FYPs commonly evaluate with somewhere between five and thirty representative users depending on the instrument used. What matters is that participants resemble the intended users, that the tasks are defined in advance, and that you justify the number on usability grounds rather than quoting a population sampling table.
Do I put my full source code in Chapter 4?
No. Chapter 4 carries short excerpts of algorithms or queries that explain a design decision, typically ten to twenty lines each. Full listings belong in an appendix or a linked repository. A chapter padded with hundreds of lines of code reads as an attempt to fill pages rather than as evidence.
Can I include failed test cases?
You should. A failure, its diagnosis, the fix and a passing re-test demonstrates a real testing process. Tables showing only passes suggest the test cases were written after the fact to match working behaviour, which examiners notice and probe during the viva.
Where do use case and sequence diagrams belong?
In Chapter 3, with the system design. Chapter 4 shows what was built. Repeating your design diagrams in Chapter 4 wastes space that should carry implementation and testing evidence, and it inflates your similarity index against your own proposal.
My FYP is a hardware and IoT project. Does this structure still apply?
Broadly yes, with additions. Include the assembled prototype photograph, the circuit or wiring configuration as built, sensor calibration results, and measurement accuracy against a reference instrument. Your test case table should include hardware conditions such as sensor range limits, power interruption and connectivity loss.
Should discussion be inside Chapter 4 or in Chapter 5?
Handbooks vary. Where Chapter 4 is titled “Results and Discussion”, interpret each result briefly as you present it and reserve Chapter 5 for conclusions, contributions, limitations and future work. Where the chapters are separated, keep Chapter 4 to evidence only. Ask your supervisor and follow one convention consistently throughout.
How do I report response time results credibly?
State the test conditions before the numbers: device specification, network type, dataset size and number of repetitions. Report the mean across repeated runs rather than a single measurement, and note the variation. A single stopwatch reading from one run on your own laptop is not a benchmark.
Does using AI coding assistants need to be disclosed?
Malaysian universities are increasingly issuing their own AI use policies, and several faculties now require a declaration of AI assistance in coursework and final year reports. Check your current faculty circular rather than assuming, disclose what you used and how, and be ready to explain any code in your submission during the demonstration, because you remain accountable for all of it.
How long should Chapter 4 be?
Commonly 20 to 35 pages for a development FYP including figures and tables, which reflects the space that interface figures and test case tables consume. Your handbook takes precedence. Judge sufficiency by coverage rather than page count: every requirement traced, every module shown, every test layer evidenced.