The evidence at the back
Nearly 40 pages of raw material sitting behind the thesis. Knowing what is back there is useful, because it is where an examiner goes to check you.
Appendices are where the raw material sits. Nobody reads them cover to cover, but an examiner who wants to check a claim goes straight there.
So you do not need to memorise their contents. You need to know what is in each one, so that when someone asks "where is your evidence for that", you can say which appendix without hesitating.
Pages 127 to 165, nearly 40 pages.
The five appendices at a glance
| Appendix | What is in it | Pages |
|---|---|---|
| A Survey Instruments | Both questionnaires in full, every question exactly as respondents saw it | 127 to 136 |
| B Full Statistical Output | The complete statistical output for both samples, plus the thematic coding frequencies | 137 to 147 |
| C Remaining Use Cases | The 5 use case specifications not written out in Chapter 4 | 148 to 151 |
| D Remaining Tests and Measurements | The test cases not in the chapter body, and the full measurement output including every distribution | 152 to 156 |
| E Selected Source Code | The database schema, the booking function, and the access control policies | 157 to 165 |
Appendix A, the surveys
Both questionnaires, printed as respondents saw them. This is where an examiner goes if they want to check whether a question actually measures what you say it measures.
Questions 1 to 4 are profile, not scored. Questions 5 to 23 are the Likert items measuring the four constructs. Question 14 sits in the middle measuring how often the failure actually happens, and is reported as a frequency rather than scored. Questions 24 and 25 are free text.
Both surveys share this structure deliberately, so the same model could be tested twice on two different groups.
A few real questions, so you recognise them
| Item | Measures | The traveller wording |
|---|---|---|
| 5 | IV1 | More than once, I have heard about a great event in Mirissa or Matara only after it had already happened |
| 7 | IV1, reversed | It is usually easy for me to find out about hotel events happening nearby while I am in the area Removed |
| 11 | IV2 | Not being able to reserve a spot in advance has made me skip an event I was actually interested in |
| 15 | IV3 | I usually have to check a few different sources, like Instagram, a hotel's website, or asking staff at the desk, just to know the price and what is actually included |
| 17 | IV3 | Knowing everything about an event, including what is available, what it costs, and where it is, before I commit would help me decide faster |
| 22 | Outcome | I would recommend an app like this to other travelers visiting Mirissa or Matara |
| 20 | Outcome, reversed | I would be a little cautious trusting a new app with my booking or payment details unless it felt genuinely reliable Removed |
No question says "real-time visibility" or "centralized information access". The variable labels are hidden from respondents on purpose, so nobody can guess what is being measured and answer to please the researcher.
That was one of the changes made after the supervisor rejected the first draft. If asked about instrument design, this is a good detail to mention.
Appendix B, the full statistics
Everything the analysis produced, in three sections: the traveller sample, the organiser sample, and the thematic coding frequencies.
For each sample it carries the respondent profile frequencies, item-level means and standard deviations for all 19 scored items, the reliability output before and after purification with every corrected item-total correlation, the dimensionality check, the composite scale descriptives, the full correlation matrices with their p values, and the complete regression output with the collinearity and independence diagnostics.
Chapter 4 reports selected figures. Appendix B reports all of them.
That means if an examiner asks for a number that is not in the chapter, for example the standard deviation of a single item, it exists in the document. You do not have to know it. You have to know it is in Appendix B.
Appendix C, the remaining use cases
Chapter 4 specifies 6 use cases in full: publish event, manage inventory, discover events, book multiple resources, monitor the live dashboard, and validate a ticket at check-in.
The other 5 are here: account registration, authentication, profile management, property registration and booking history retrieval.
They are routine. They introduce no logic specific to this research, so putting them in the chapter body would dilute the six that carry the contribution.
Moving them rather than deleting them means the specification is still complete. That is the right answer if someone asks why login is not in Chapter 4.
Appendix D, the full measurements
Three things: the test cases covering routine paths that are not in Chapter 6, the complete non-functional measurement output with full distributions rather than just the headline percentiles, and the full transcripts of the concurrency test and the access control test.
They are raw output from scripts that ran against the real deployed database. Not a description of a test, the actual output of the test.
If an examiner doubts that 20 requests really ran at once, the transcript is there.
Appendix E, the source code
Three pieces of code, chosen because they are the three places where Chapter 5's claims can be checked directly.
E.1 The database schema
All six tables with their columns, keys and constraints. This is where you can see that tickets, rooms and add-ons really are one table.
E.2 The booking function
The complete source of create_booking. Chapter 5 prints it as simplified pseudocode. This is the real thing, including the row locking and the ordering.
E.3 The access control policies
Every row level security policy. This is what TC-09 actually tests, so the test and the thing it tests are both in the document.
It closes the last gap in the traceability chain. A claim in Chapter 5 can be checked against the code in Appendix E, which can be checked against the test in Chapter 6, which can be checked against the transcript in Appendix D.
Very few undergraduate theses can be audited end to end like that.
If they ask you
Where is the evidence for that number?
The safe general answer: chapter figures are summarised in the chapter tables, and the full output is in Appendix B for anything statistical, Appendix D for anything measured about the system.
If it is about the instrument, Appendix A. If it is about how something was implemented, Appendix E.
Why is registration and login not specified in Chapter 4?
Because those use cases are routine and introduce no logic specific to this research. They are fully specified in Appendix C, so the specification is complete, but keeping them out of the chapter body keeps the focus on the six use cases that carry the contribution.
The same logic applies in Chapter 5, where authentication and profile management are implemented with standard patterns and deliberately not documented.
Can I see the code for the booking transaction?
Yes, it is Appendix E.2, printed in full. Chapter 5 Section 5.4.3 shows it as pseudocode for readability, and the appendix carries the actual source, including the row locking with ascending identifier ordering and the capacity ceiling check.
Appendix E.1 has the schema it operates on and E.3 has the access control policies, so the three parts of the correctness argument are all in the document.
Appendix A has both survey instruments in full. Appendix B has the complete statistical output for both samples plus the thematic coding frequencies. Appendix C has the five remaining use case specifications that were kept out of the chapter body because they are routine. Appendix D has the remaining test cases and the full measurement output, including the raw transcripts of the concurrency and access control tests. Appendix E has the database schema, the booking function source and the row level security policies, so every claim in Chapter 5 can be checked against the actual code.