A piece of work where you do not just build something, you also prove something. A project alone shows that you can code. A research project shows that you found out something nobody had written down before, and then showed your working.

Yours does both. You proved a finding with statistics, and you built a system that comes from that finding. That combination is the whole point of your degree.

The document that records all of it. Chapters in a fixed order, so anyone can follow what you did and check you.

Yours is 165 pages, in 7 chapters plus 5 appendices at the back.

Short for viva voce, which is Latin for "by live voice". You present your work and then examiners ask you questions about it. They are not trying to catch you out. They are checking that you understand what is in your own document.

This whole guide exists for that conversation. The last page on this site is the viva page.

The thing you built. Not the thesis, the actual working product.

Yours is EVENTIA, the deployed web application. If an examiner says "what is your artefact", that is the answer.

Anything you measure that can be different from person to person. Age is a variable. How strongly someone agrees with a statement is a variable.

You have four. Three that you think are causes, and one that is the outcome.

The suspected cause. The thing you think is doing the pushing.

You have three: IV1 real-time event visibility, IV2 pre-booking and resource coordination, IV3 centralized information access.

The outcome. The thing you think is getting pushed. It is called dependent because it depends on the others.

Yours is Coordination Effectiveness, written as E0. It means: would centralised coordination actually make these events run better.

Something real that you cannot measure with a ruler. Trust is a construct. Satisfaction is a construct. You measure it indirectly, with several questions at once, and then combine them.

All four of your variables are constructs. That is why each one is measured with 4 or 5 survey questions instead of one.

Turning something abstract into something you can actually score. Deciding which questions measure it, on what scale, and how the answers combine into a single number.

Section 4.3 of your thesis is called this. It is where the faculty expects you to prove your measurements are legitimate before you show any result.

The 1 to 5 agreement scale. 1 is strongly disagree, 5 is strongly agree, and 3 sits in the middle. So a group average above 3 means that group leans towards agreeing.

Every scored question in both your surveys uses it. That is why every average in your thesis is a number out of 5.

The population is everybody you care about. The sample is the people you actually managed to ask.

Your organiser population is hotels across Sri Lanka that host social events. Your organiser sample is 40 of them. Your tourist sample is 64 travellers.

Purposive means you deliberately pick people who qualify, instead of picking at random. Convenience means you take whoever you can reach. Both are types of non-probability sampling, which just means not random.

Organisers were purposive, because only around 60 to 80 properties in the collection area host events at all, so random picking would be pointless. Tourists were convenience, with a screening question checking they had attended or planned to attend a hotel event.

A number between 0 and 1 that answers one question: do the several questions meant to measure one thing actually agree with each other? Above 0.70 is the usual bar. Between 0.60 and 0.70 is accepted for short scales in exploratory work.

Think of it like this. If you ask four questions that are all supposed to measure "hunger", a hungry person should answer all four in a hungry direction. If one of them does not follow the others, that question is measuring something else.

You check this first, before anything else. If the questions do not hang together, every result after them is meaningless. Two of your questions failed this check and were removed, which is normal and is reported openly.

How well one single question agrees with the rest of its own group, leaving itself out of the comparison. Below 0.30 means that question is not measuring what the others measure.

This is the exact rule that removed your two items. Question 20 came back at minus 0.622 among travellers, which means it did the opposite of what it should.

Removing the questions that fail the reliability check, then recalculating. Worst one first, one at a time, and never letting a group drop below 3 questions.

It rescued your organiser outcome scale from an unusable 0.159 to an acceptable 0.690. Your thesis shows both the before and the after, which is the honest way to do it.

How strongly two things move together, from minus 1 to plus 1. Close to 1 means when one goes up the other goes up. Close to 0 means no relationship.

The most important thing about correlation: it does not prove one thing causes the other. Ice cream sales and drowning both go up in summer. Ice cream does not cause drowning.

All three of your causes correlate strongly with the outcome, in exactly the same rank order in both groups. That looks like all three hypotheses working. The next step is what shows otherwise.

Testing all your suspected causes at once, to see what each one contributes after the others have been accounted for.

An example. Imagine height, weight and shoe size all correlate with how fast someone runs. Put all three in together and shoe size might contribute nothing of its own, because everything shoe size was explaining was really height explaining it.

This is the step that produced your finding. On their own, all three of your causes look strong. Together, only IV3 keeps its effect, because the other two were mostly explaining the same thing IV3 was.

Beta is the unique pull of one cause on the outcome, put on a common scale so all three can be compared fairly. Bigger means stronger.

p is the chance of seeing a result this strong if there were really no effect at all. Below 0.05 counts as significant, which just means "unlikely to be a fluke".

Your headline numbers. IV3 got a beta of 0.665 with p below 0.001 among travellers. The other two sat between 0.096 and 0.234 with p values between 0.138 and 0.368, which is nowhere near significant.

A check on whether a group of questions measures one single thing or several things mixed together. If you get one strong result out of it, the group measures one thing.

Every one of your purified groups passed this, so each construct can legitimately be averaged into one score. It also revealed that your outcome variable behaves as one thing, not the three sub-parts you defined it as in Chapter 3. That is honestly reported.

A method for turning written-out answers into counted themes. Read everything, tag recurring ideas, group the tags, name the groups, count them.

Your last two questions on each survey were free text. This method turned them into the four theme tables in Chapter 4. It is what lets you say the numbers and the words agree with each other.

Checking the same conclusion using more than one kind of evidence, so it does not rest on one method alone.

Your statistics said centralised information matters. Then 52.5 percent of travellers asked for exactly that, unprompted, in their own written words. Two different methods, one conclusion.

A position that says: there is a real world out there, but we can only ever measure it approximately, and researchers have biases. So measure carefully and report your error, instead of claiming perfect objectivity.

It justifies your approach. Using numbers and surveys, while still admitting the numbers are imperfect and the sample was limited.

Start from existing theory, write down what you expect before you look, then collect data to find out if you were right. The opposite is inductive, where you look first and build a theory from what you see.

Your three hypotheses were written in Chapter 3, before a single response came in. That ordering is what makes your result a real test and not a story fitted after the fact.

A specific, testable statement about what you expect. Not a hope. A claim precise enough that data can contradict it.

You had three, one per cause. Two were not supported. That is a legitimate and interesting result, not a failure.

A research strategy where you do not only study a problem, you build something that addresses it, then evaluate what you built.

It is why your thesis can contain both a statistics chapter and a software chapter without them looking like two unrelated projects stapled together.

The named process inside Design Science Research. Identify the problem, define objectives, design and develop, demonstrate, evaluate, communicate.

Table 3.1 in your thesis maps each phase onto a chapter. If asked how your research was structured, walk through those six words in order.

A classic theory saying people adopt a system for two reasons: they think it is useful, and they think it is easy. Both feed into their intention to use it.

It is the justification for how you measured your outcome. Because the system did not exist yet, you measured intention to adopt rather than a real measured improvement. TAM is what makes that a defensible choice rather than a shortcut.

A functional requirement is something the system must do. A non-functional requirement is how well it must do it. Speed, security, reliability, layout.

You have 14 functional and 9 non-functional. Each one traces back to a survey number or a cited source, so none of them are invented.

Every requirement can be followed backwards to the evidence that caused it, and forwards to the test that verifies it.

It is the chain that makes this research rather than a student project. Survey question, to beta coefficient, to database table, to test case. You can follow any thread all the way through.

A structured description of one task somebody does. Who does it, what has to be true first, the normal path, what happens when it goes wrong, and the state it leaves behind.

You have 11. Six are written out in full in Chapter 4 and the rest are in Appendix C. The one that matters is booking across several resources at once.

A working version built to prove an idea, not a finished commercial product. It does the important things properly and leaves out the rest.

Yours deliberately leaves out payment processing. Bookings are recorded as pending payment. That is stated as out of scope in Chapter 1, so it is a boundary you chose, not something you forgot.

A group of database changes that either all happen, or none of them happen. There is no halfway state.

Think of a bank transfer. Money leaving one account and arriving in the other must be one single act. If only half of it happened, money would vanish.

A booking in your system touches several inventory rows at once. Two tickets, a room, a parking slot. If it half-succeeded, somebody would be charged for a ticket with no room. Atomic means that cannot happen.

Two people do the same thing at the same instant. Both read "1 left", both decide it is fine, both write. Now two people have booked one thing.

This is the single bug your booking design exists to prevent, and test case TC-05 is the test that proves it cannot happen. On an event night with everyone booking at once, this is not a remote risk, it is the expected case.

Claiming specific rows in the database so nobody else can change them until you finish. It closes the gap between reading a number and writing it back.

It is the mechanism that makes your guarantee true rather than merely hoped for.

Access rules enforced by the database itself, row by row, rather than by the website hiding things. A guest can only read their own booking because the database refuses to hand over anyone else's, not because the page does not show a link to it.

Organisers named security in 46.7 percent of their adoption answers. Test case TC-09 checks these rules by calling the system directly and going around the interface, which is the only honest way to test them.

The database pushes a change out to every screen that is watching. The opposite is polling, where each screen keeps asking "anything new yet?"

It is what makes the traveller's page and the hotel's dashboard show the same number at the same moment. Measured at 265 milliseconds typically.

Sort every measurement from fastest to slowest. p50 is the one in the middle. p95 is the point that 95 percent of them are faster than.

p95 is quoted rather than the average, because the slow ones are what a user actually notices and complains about.

Every speed number in your Chapter 6 is a p95 from a real measured run, not an estimate.

A standard 10-question usability questionnaire that gives one score out of 100, run with real participants.

Learn this one, because it is the thing you did NOT do. It is the single named gap in your evaluation, and it is the most likely thing an examiner will ask about. The viva page has the answer.