Category: Research Methodology

  • SSADM vs Waterfall vs Agile vs Prototyping: Which Methodology for Your Computer Science Project? (2026)

    SSADM vs Waterfall vs Agile vs Prototyping: Which Methodology for Your Computer Science Project? (2026)

    A computer science project in a Nigerian university is judged on two things at once: the system you built, and the methodology you claim you followed to build it. Most students build first and pick a methodology afterwards, then spend the night before submission trying to reverse-engineer a data flow diagram out of code they already wrote. It shows, and panels notice.

    Here is the comparison first, then the reasoning.

    The four methodologies compared

    Criterion SSADM Waterfall Agile / Scrum Prototyping / RAD
    Accepted by Nigerian CS departments Yes — the default Yes Sometimes, needs justification Yes, common for web and mobile
    Diagrams it obliges you to produce DFD, ERD, LDS, entity life histories Whatever you choose, usually UML User stories, backlog, sprint boards Wireframes, iteration screenshots
    Fills Chapter Three easily Very easily Easily Awkwardly Moderately
    Handles a changing requirement Badly Badly Very well Very well
    Needs a real external user Preferably No Yes, genuinely Yes, genuinely
    Evidence a panel can inspect Design documents Design documents Sprint logs, commit history Successive screenshots
    Risk if you are behind schedule Low Low High Medium
    Best fit Records systems replacing a manual process Fully specified, unchanging scope Team projects with a live client Web and mobile apps with UI at the centre

    The recommendation: for a solo undergraduate project that computerises an existing manual system — the most common shape of Nigerian CS project — choose SSADM. The runner-up, for a web or mobile application where the interface is the contribution, choose prototyping. Choose Agile only if you can produce real sprint evidence, and choose plain waterfall only if your department explicitly asks for it.

    Why SSADM still wins in Nigerian departments

    SSADM — Structured Systems Analysis and Design Methodology — was developed for UK government projects in the 1980s and has been quietly retired almost everywhere in industry. Nigerian computer science departments kept it, and the reason is pedagogical rather than nostalgic: SSADM forces you to produce exactly the artefacts a project examiner wants to mark.

    Follow it and Chapter Three writes itself, because the methodology names its own sections:

    1. Analysis of the existing system — how the records are kept now, gathered from interviews and observation at your case study organisation
    2. Problems of the existing system — a numbered list, each of which your new system will address
    3. Analysis of the proposed system — with its advantages stated against the numbered problems
    4. High-level model — the top-level data flow diagram
    5. Data flow diagrams — context diagram, then level 0, then level 1 for each major process
    6. Entity relationship diagram and database design — with the normalised table structures
    7. System specification — input design, output design, hardware and software requirements

    That is a complete chapter, and every item is a figure or a table rather than paragraphs of theory. It is the single most efficient methodology choice available to a student who is short of time.

    The one thing SSADM demands that students skip is the case study. SSADM assumes a real existing system somewhere — a school bursary that keeps fee records in a ledger, a clinic that files patient cards, a cooperative society that tracks contributions in an exercise book. You are expected to visit, interview staff and collect samples of their current forms. Those forms become your input design and belong in your appendix. Without them, your analysis of the existing system is invented, and a panel member who has supervised twenty of these projects will ask where your data came from.

    When the waterfall model is the honest answer

    Waterfall is the linear sequence: requirements, design, implementation, testing, deployment, maintenance. It is not the same thing as SSADM, though students often present them interchangeably. SSADM is a method with prescribed deliverables; waterfall is a lifecycle shape.

    Choose waterfall when your requirements genuinely were fixed at the start and never changed — a simulation, an algorithm implementation, an embedded controller, anything where the specification came from a standard or from your supervisor rather than from a user. Its Chapter Three is thinner than SSADM’s, so you carry more of the weight with UML: use case diagram, class diagram, sequence diagrams for the two or three most important interactions, and an activity diagram for the main workflow.

    Waterfall’s weakness in a project context is that it invites an obvious question at defence: “Your requirements never changed at all?” Have an answer ready. The strong version is that your scope was defined by a published specification or a supervisor brief and deliberately frozen so that testing could be exhaustive.

    Agile: powerful, and usually a trap for a solo student

    Agile is the honest description of how most students actually work — build a bit, show the supervisor, change it, build more. The trouble is that Agile is a team methodology with named ceremonies, and a panel that knows this will ask who your product owner was, how long your sprints were, and where the retrospective notes are.

    You can defend Agile in an undergraduate project, but only with evidence:

    • A product backlog written as user stories, in the “As a [role], I want [feature], so that [benefit]” format
    • Sprints of a stated length — two weeks is standard — with the goal of each sprint recorded
    • A git commit history whose dates line up with your sprint boundaries
    • A named stakeholder who reviewed at least two increments, usually your supervisor or a staff member at the case organisation, with dates
    • Screenshots of the system at the end of each sprint, showing genuine change

    If you can produce all five, Agile makes an excellent project and your Chapter Three becomes a sprint-by-sprint narrative. If you are assembling that evidence retrospectively three weeks before submission, do not claim Agile. Claim prototyping instead, which is true and much easier to support.

    Prototyping and RAD: the right choice for an app

    Prototyping — building a working mock, showing it to users, refining, repeating — is legitimate, well documented in the literature, and a natural fit when the contribution of your project is the interface and the user experience rather than the data model.

    It is the strongest choice for a mobile app, an e-commerce platform, a student portal, or anything where you iterated on screens. Your Chapter Three describes the iterations: what the first prototype contained, who reviewed it, what feedback it produced, what changed in the second, and so on, with a screenshot of each version. Three iterations is the usual minimum for a credible account.

    Prototyping also handles the situation most students are genuinely in, which is not knowing exactly what the system should do until they have built something and shown it to someone. Distinguish clearly in your write-up between throwaway prototyping, where the mock is discarded and the real system built afterwards, and evolutionary prototyping, where the prototype becomes the system. Undergraduate projects are almost always the second, and saying so precisely is the kind of detail that impresses a panel.

    Whichever you choose, Chapter Three still needs these

    Methodology choice does not exempt you from the standard structure your department expects. Whatever you pick, Chapter Three must state the methodology and justify it against alternatives, describe your data-gathering for the analysis phase, present the system design artefacts, and specify the development environment — language, framework, database, and the hardware you tested on.

    It also needs a testing subsection, and this is where computer science projects most often lose marks. Unit testing, integration testing and user acceptance testing should each be described, with a test case table showing the input, expected output, actual output and pass or fail for at least ten cases. Panels ask for this table by name.

    The surrounding structure — research design, sources of data, system analysis, the sequence of subsections — follows the same conventions as any Nigerian project, set out in the guide to writing Chapter Three section by section. Software projects diverge in content, not in shape.

    What goes in Chapter Four when you built a system

    A software project has no questionnaire and no chi-square, so Chapter Four cannot be tables of respondent means. It becomes system implementation and results: the implementation environment, screenshots of each major module with an explanation of what the user does on each screen, the database tables as implemented, your test case results, and a performance discussion covering response times or query performance where relevant.

    This is the same problem faced by engineering students whose data comes from a laboratory rather than a survey, and the structure that works for both is set out in the guide to writing Chapter Four when your project has no questionnaire. The generic template for survey-based Chapter Fours is in the pillar on data presentation, analysis and interpretation, which is worth reading for the interpretation style even though your tables will look different.

    The methodology questions the panel will ask

    Three of them come up in almost every computer science defence:

    1. “Why did you choose this methodology?” Answer with a property of your project, not a property of the methodology. “Because my system replaces an existing manual record system whose current processes had to be analysed before they could be automated” beats “because SSADM is structured and reliable.”
    2. “What were the alternatives and why did you reject them?” Name two, and reject each for a concrete reason. Agile rejected because you worked alone without a product owner; waterfall rejected because your requirements changed after the first user review.
    3. “Show me where your methodology appears in your work.” Point to the artefact. The DFD for SSADM, the sprint log for Agile, the successive screenshots for prototyping. A methodology with no visible artefact was never actually used.

    The full inventory of what panels ask, and how to answer each one, is in the guide to project defence questions in Nigeria.

    Write the chapter around the system you actually built

    The gap in most computer science projects is not the code. It is the twenty thousand words of documentation that must surround the code, written in departmental prose, consistent from chapter to chapter, and revised every time your supervisor returns a page.

    Tesify drafts those chapters against your own topic, methodology and system design, keeps terminology and references consistent as the draft grows, and lets you rewrite a section after corrections without starting again. Your system stays yours; the documentation stops being the bottleneck.

    Start your project on Tesify for free and build Chapter Three around the methodology you have chosen.

    Frequently asked questions

    Is SSADM outdated for a 2026 computer science project?

    It is outdated in industry but still standard in Nigerian computer science departments, and it remains a defensible academic choice because it produces the analysis and design artefacts a project examiner marks. If your department’s project guidelines name SSADM, use it. If they do not, you may choose a modern alternative provided you justify it and can show its artefacts.

    Can I use Agile for a solo final year project?

    Yes, but only if you can evidence it: a written backlog of user stories, sprints of a stated length, a commit history matching your sprint dates, and a named stakeholder who reviewed at least two increments. Without that evidence, a panel will treat the claim as decoration. Prototyping is usually the more honest label for solo iterative work.

    What is the difference between SSADM and the waterfall model?

    Waterfall is a lifecycle shape — a linear sequence of phases with no return to an earlier one. SSADM is a full methodology that specifies which techniques and deliverables belong in each phase, including data flow diagrams, logical data structures and entity life histories. SSADM is normally executed in a waterfall sequence, which is why the two get confused.

    Do I need a case study organisation for a computer science project?

    If your methodology involves analysing an existing system, yes — SSADM in particular assumes one. You need a real organisation whose current process you can observe, staff you can interview, and sample forms or records you can reproduce in your appendix. Projects that build a general-purpose tool rather than replacing a specific manual process can avoid a case study, but should say so explicitly in Chapter Three.

    How many data flow diagrams should my project contain?

    At minimum a context diagram showing the system as a single process with its external entities, and a level 0 diagram decomposing it into its major processes. Level 1 diagrams are expanded only for processes complex enough to need them — typically two or three. Every data store on a diagram must correspond to a table in your database design, and examiners check this correspondence.

    Can I change methodology after I have started building?

    You can, and it is far better than defending a methodology you did not follow. Tell your supervisor, then rewrite Chapter Three around what you genuinely did. A student who says the project moved from waterfall to prototyping because the first user review changed the requirements is describing real software engineering, and panels respond well to it.

    Does a computer science project need hypotheses?

    Usually not. A system development project states objectives and a system specification rather than testable hypotheses, because there is no statistical population being sampled. Some departments still require them, so check your guidelines — where hypotheses are demanded for a build project, they normally concern measurable performance of the new system against the manual one.

  • How to Design and Validate a Questionnaire for a Public Health Project in Nigeria (2026)

    How to Design and Validate a Questionnaire for a Public Health Project in Nigeria (2026)

    Most public health final year projects in Nigeria stand or fall on one document: the questionnaire in Appendix A. Your supervisor will skim Chapter One. The defence panel will read Chapter Four. But the external examiner will turn to the back, read your instrument item by item, and decide within four minutes whether your findings mean anything at all.

    The problem is that almost nobody teaches you how to build one. You are told to “design a structured questionnaire” and left to it. So you open a laptop, write forty statements beginning with “Do you agree that…”, print two hundred copies, and only discover at the defence that half your items measured nothing you claimed to measure.

    This guide takes you from an approved topic to a validated instrument in ten steps, with the actual text you would write at each stage. It assumes the standard Nigerian arrangement: a departmental project in Public Health, Community Health, Environmental Health or Nursing, a cross-sectional descriptive design, a supervisor with limited time, and a five-chapter format. Confirm the fine details with your own department, because instrument requirements vary between UNILAG, the University of Ibadan, ABU Zaria and OAU.

    Step 1: Turn every research question into a numbered questionnaire section

    Do not start by writing items. Start by writing the map. Take your research questions from Chapter One exactly as they were approved and lay them out as sections.

    Suppose your topic is knowledge and practice of exclusive breastfeeding among nursing mothers attending a primary health centre. Your research questions might be:

    1. What is the level of knowledge of exclusive breastfeeding among nursing mothers attending the centre?
    2. What is the level of practice of exclusive breastfeeding among the respondents?
    3. What factors are associated with non-practice of exclusive breastfeeding?
    4. Is there a significant relationship between maternal knowledge and practice of exclusive breastfeeding?

    That produces a questionnaire with exactly four content sections plus a demographic section:

    • Section A — Socio-demographic characteristics
    • Section B — Knowledge of exclusive breastfeeding (answers research question 1)
    • Section C — Practice of exclusive breastfeeding (answers research question 2)
    • Section D — Factors associated with non-practice (answers research question 3)

    Research question 4 needs no section of its own. It is answered by cross-tabulating Section B against Section C, which is a statistical operation, not an instrument.

    Write this map on one page and show it to your supervisor before you write a single item. It is the cheapest correction you will ever receive. Every item you later write must belong to a section, and every section must trace back to a research question. If an item does not fit anywhere, it does not go in the questionnaire, however interesting it is.

    Step 2: Match the item type to the variable, not to habit

    The single most common failure in Nigerian public health projects is putting everything on a four-point agreement scale. Knowledge is not an opinion. You cannot ask a mother whether she agrees that exclusive breastfeeding lasts six months — she either knows the recommended duration or she does not.

    The KAP structure — knowledge, attitude, practice — gives you three different item types, and mixing them up destroys your analysis:

    • Knowledge items take a correct answer. Use True/False/Don’t know, or multiple choice with one right option. These are scored: one mark for correct, zero for wrong or don’t know.
    • Attitude items take an agreement scale. A four-point Likert scale — Strongly Agree, Agree, Disagree, Strongly Disagree — is the Nigerian default because it forces a direction and gives you the familiar 2.50 decision criterion.
    • Practice items take a frequency or a yes/no behavioural report. “How many times in the last week did you…”, not “Do you agree that you should…”.

    Write the item type beside every row of your section map before drafting. If you are unsure which analysis your item types will permit later, work backwards from the test you intend to run — the guide on choosing the right statistical test for your project shows which question shapes require which test, and therefore which item format you must collect.

    Step 3: Write Section A so it earns its place

    Section A is not filler. Every demographic variable you collect should be one you intend to cross-tabulate. Panels ask a brutal question about this: “You collected religion. Where does religion appear in Chapter Four?” If the answer is nowhere, you wasted the respondent’s time and your printing budget.

    For a public health study, the defensible core is usually:

    1. Age (in completed years, or in bands you will actually use)
    2. Sex
    3. Marital status
    4. Highest level of education completed
    5. Occupation
    6. Monthly income band, if income is in your objectives
    7. Parity or number of living children, for maternal health topics
    8. Residence — urban, semi-urban, rural — if your sampling crosses settlements

    One rule that saves a lot of pain: collect age as a number, not as a band, whenever you can. You can always collapse numbers into bands during analysis, but you can never recover the number from a band. The same logic applies to number of children and years of experience.

    Step 4: Write knowledge items with a defensible correct answer

    Every knowledge item needs a source you can name. If a panel member asks “Who says that is the correct answer?”, the answer must be a guideline, not your opinion. For public health topics, the usual authorities are the World Health Organization, the Nigeria Centre for Disease Control and Prevention, the Federal Ministry of Health, or the National Primary Health Care Development Agency.

    Worked examples for the breastfeeding study:

    • Exclusive breastfeeding means giving the baby only breast milk, with no water, for the first six months. [True / False / Don’t know]
    • A baby on exclusive breastfeeding should be given water during hot weather. [True / False / Don’t know]
    • Breastfeeding should begin within one hour of delivery. [True / False / Don’t know]

    Notice the second item is deliberately false. A knowledge section made entirely of true statements can be passed by any respondent who simply ticks “True” all the way down, and your panel will spot that. Aim for roughly a third of your knowledge items to be false statements.

    Then decide your scoring rule in advance and write it into Chapter Three. A common and defensible rule: fifteen knowledge items, one mark each, with 0–7 classified as poor knowledge, 8–11 as fair, and 12–15 as good. State that the cut-offs follow Bloom’s original criteria of below 50 per cent, 50–74 per cent and 75 per cent and above, and cite a published Nigerian study that used the same cut-offs. Never invent cut-offs after seeing your data — that is the fastest route to a correction.

    Step 5: Write attitude and practice items that cannot be misread

    Six drafting rules, each of which fixes a mistake that appears in almost every first draft:

    1. One idea per item. “Exclusive breastfeeding is healthy and convenient” is two items. A mother who finds it healthy but inconvenient cannot answer.
    2. No negatives in the stem. “I do not believe formula is unnecessary” is unanswerable. Disagreeing with a double negative is guesswork.
    3. No leading language. “Do you agree that exclusive breastfeeding is the best choice for your baby?” tells the respondent what to say.
    4. No technical vocabulary. Replace “complementary feeding” with “giving other food alongside breast milk” unless your respondents are health workers.
    5. Anchor the recall period. “In the last seven days” or “since your last child was born” — never a bare “usually”.
    6. Include two or three reverse-scored items so you can detect straight-lining, and remember to recode them before analysis.

    Keep the whole instrument to a length a real respondent will finish. For a community sample, forty to fifty items across all sections is the practical ceiling. Fifteen minutes is the limit at a busy primary health centre, and a mother holding a baby in a queue will abandon anything longer.

    Step 6: Adapt a validated instrument rather than inventing one

    This is the step that separates a strong project from an average one, and it takes an afternoon. For most public health topics, someone has already built and validated an instrument.

    Search Google Scholar and AJOL for your construct plus “questionnaire” or “scale”, restricted to studies in Nigeria or West Africa. When you find an instrument in a published article, three things follow. You can state its origin in Chapter Three. You can quote its reported reliability coefficient. And you can defend your items by pointing to prior use rather than to your own judgement.

    Adapting is legitimate and expected — you change wording for your setting, drop irrelevant subscales, and add items for your local context. What is not legitimate is copying an instrument and presenting it as your own design. Cite the original authors in your instrument paragraph and in your reference list, following the referencing style your Nigerian university actually requires. Adaptation without attribution is a plagiarism finding waiting to happen.

    Before you commit to a construct, it is also worth checking how heavily it has already been studied in Nigeria; the method in counting existing Nigerian studies on your topic tells you within an hour whether validated instruments exist for it.

    Step 7: Establish content validity with three lecturers

    Nigerian departments overwhelmingly expect face and content validity established by expert review, and the standard is three experts: your supervisor plus two other lecturers, ideally one from measurement or biostatistics.

    Do it properly rather than by informal chat. Give each reviewer a copy of the instrument with your research questions and objectives attached, and a rating column asking them to mark every item as Relevant or Not relevant. Then compute the Content Validity Index: for each item, the proportion of reviewers who rated it relevant. Items scoring 1.00 with three reviewers stay. Items where two of three agreed are revised. Items where only one agreed are dropped. The scale-level index is the average across retained items, and anything from 0.80 upwards is comfortable to report.

    Keep the signed rating sheets. Several departments require them as an appendix, and even where they do not, a panel member who asks how validity was determined is answered instantly by producing them.

    Step 8: Pilot on ten per cent and compute Cronbach’s alpha

    Pilot on a group similar to your respondents but not part of your final sample — a different ward, a different health centre in the same LGA. Ten per cent of your calculated sample size is the conventional Nigerian pilot, so a sample of 300 means about 30 pilot respondents.

    The pilot does three jobs. It tells you how long the instrument takes. It surfaces items respondents misunderstand, which you catch by watching where they hesitate or ask questions. And it gives you the data for your reliability coefficient.

    Compute Cronbach’s alpha separately for each Likert-scaled section, not for the whole questionnaire at once. Alpha across sections measuring different constructs is meaningless. Knowledge sections scored right/wrong technically call for the Kuder-Richardson formula, though many Nigerian departments accept alpha as an approximation — ask your supervisor which your department expects. If a coefficient comes back low, the diagnosis and the repair are set out in the guide to what counts as a good Cronbach’s alpha, and the fix is almost always deleting one or two bad items rather than rewriting the section.

    Step 9: Write consent, and get ethical clearance before you distribute

    Health research on human subjects in Nigeria requires ethical clearance, usually from your institution’s Health Research Ethics Committee or from the State Ministry of Health where you are collecting data. Students routinely underestimate how long this takes — two to six weeks is normal, and it must happen before distribution, never after.

    Your instrument needs a consent page carrying the study title, your name and department, the purpose in plain language, the expected duration, a statement that participation is voluntary and can be withdrawn at any time, an assurance of anonymity, and a contact. Because you are handling personal data, the Nigeria Data Protection Act 2023 applies to you: collect only what you need, do not put names on questionnaires, and keep completed copies secure.

    The delivery decision matters here too. A paper instrument administered at a health facility reaches a different population from an online link, and the trade-offs are compared in the piece on collecting project data with Google Forms, KoboToolbox or paper. For clinic-based public health samples, paper administered on site almost always yields the better response rate.

    Step 10: Write the instrument paragraph for Chapter Three

    Here is the paragraph, ready to adapt. Substitute your own numbers and sources:

    Data were collected using a structured, self-administered questionnaire adapted from Adeyemi and Okafor (2022) and modified to suit the study setting. The instrument comprised four sections. Section A collected socio-demographic data across eight items. Section B measured knowledge of exclusive breastfeeding through fifteen items scored as True, False or Don’t know, with one mark awarded for each correct response, giving a maximum score of 15; scores were classified as poor (0–7), fair (8–11) and good (12–15) following Bloom’s criteria. Section C measured practice through twelve items on a four-point Likert scale ranging from Strongly Agree (4) to Strongly Disagree (1), with a decision criterion of 2.50. Section D contained ten items on factors associated with non-practice. Content validity was established by three experts in the Department of Public Health, yielding a scale-level Content Validity Index of 0.89. The instrument was pilot-tested on thirty nursing mothers at a comparable primary health centre who did not form part of the main study, and reliability coefficients of 0.81 for Section C and 0.78 for Section D were obtained using Cronbach’s alpha, indicating acceptable internal consistency. Ethical approval was obtained from the Health Research Ethics Committee, and written informed consent was obtained from every respondent.

    That paragraph answers, in advance, every instrument question a panel is likely to ask. It belongs in the instrumentation subsection of Chapter Three, and it sits inside the wider structure explained in the guide to writing Chapter Three section by section.

    Four mistakes that cost marks at defence

    1. Items that do not map to any research question. The panel checks this. Every orphan item invites the question of why you collected it.
    2. Reporting one alpha for the entire questionnaire. It signals that you ran the analysis without understanding it.
    3. Piloting on people who are also in the main sample. It contaminates your data and an alert examiner will catch it.
    4. Changing the instrument after data collection has started. Responses to two different versions of an item cannot be pooled. If the pilot showed a problem, fix it before, not during.

    Turn your validated instrument into a finished Chapter Three

    Once your items are written, your experts have rated them and your pilot has produced a coefficient, the remaining work is drafting — turning decisions you have already made into the formal prose your department expects, then keeping it consistent as your supervisor sends corrections back.

    Tesify was built for exactly that stage. It drafts your chapters against your own approved topic, objectives and instrument, keeps your citations and bibliography consistent as the draft moves, and lets you rework a section after supervisor comments without restarting the chapter. It is a way to write your own project faster, not a way to submit someone else’s.

    Start your project on Tesify for free and draft Chapter Three around the instrument you have just built.

    Frequently asked questions

    How many items should a public health project questionnaire have?

    Forty to fifty items in total across all sections is the practical ceiling for a community or clinic sample, taking about twelve to fifteen minutes to complete. Each content section usually needs ten to fifteen items so that a reliability coefficient is meaningful — a section of four items rarely produces a stable Cronbach’s alpha.

    Can I use a questionnaire from another student’s project?

    You can adapt a published instrument if you cite the original authors in Chapter Three and in your reference list, and state what you modified. Copying another undergraduate’s unpublished questionnaire without attribution is plagiarism, and it carries the added risk that the original was never validated in the first place.

    Do I need ethical clearance for an undergraduate public health project in Nigeria?

    Almost always, yes, where you are collecting data from human respondents. Clearance normally comes from your institution’s Health Research Ethics Committee, and data collection in a public facility may additionally require permission from the State Ministry of Health or the facility’s medical officer. Allow two to six weeks and apply before you print your questionnaires.

    Should knowledge questions use a Likert scale?

    No. Knowledge has a correct answer, so it should be measured with True/False/Don’t know or multiple choice and scored as right or wrong. A Likert scale measures agreement, which is an attitude. Putting knowledge on an agreement scale is one of the most common reasons a public health instrument is sent back for revision.

    How many people should I use for the pilot study?

    Ten per cent of your calculated sample size is the standard Nigerian convention, with a practical minimum of about twenty to thirty respondents for a stable reliability coefficient. Pilot respondents must resemble your target population but must not be included in your main sample.

    What Cronbach’s alpha value will my department accept?

    Most Nigerian departments accept 0.70 and above as adequate internal consistency, with 0.80 and above considered good. Report the coefficient for each Likert-scaled section separately rather than a single figure for the whole instrument, and state the number of items each coefficient was computed on.

    What is the difference between face validity and content validity?

    Face validity is the judgement that the instrument looks appropriate — that the items appear to measure what they claim. Content validity is stronger: it asks whether the items cover the full range of the construct, and it is quantified using a Content Validity Index computed from expert relevance ratings. Nigerian departments often ask for both, established by the same panel of three experts.

    Where does the questionnaire go in the finished project?

    The full instrument goes in the appendices, normally as Appendix A, immediately after the references and usually preceded by the consent form and the letter of introduction from your department. Chapter Three describes it in prose and refers the reader to the appendix; it never reproduces the items in full.