By the tiswa editorial team, from the official sources listed at the end of this guide. How we write our guides
Three students in their final term write on the whiteboard: a complete hospital management system. Appointments, pharmacy, lab, billing, reports, a dashboard and a mobile app. They have one semester, and no access to any hospital. A month later they own a beautiful architecture diagram and two screens that work, and nothing they can show a committee.
What does an information systems capstone have to prove?
Information systems programmes usually sit between business schools, computing schools and information-management schools, and reference curricula such as the ACM and AIS IS2020 report are built on competencies: analyse a problem in an organisation, design an information solution, build it or prototype it, and evaluate the effect.1 Your project is therefore not measured by the number of screens but by whether you can show that whole loop: a real problem, then analysis, design, a working prototype and evidence that it helps.
That changes the question. Instead of "how many features can we add?", ask "what evidence will show that the process improved?" Formats and requirements differ between departments, so ask your supervisor for the assessment rubric before you lock the scope.
How do you cut an information systems project down to one semester?
- Pick one process
Write down a process with a start and an end: requesting leave, receiving lost items, booking a room. "University management" is not a process, but "booking study rooms" is.
- Pick one user group
Who will actually press the buttons? Female students only, or the staff of one department. Every extra group brings more screens, permissions and tests.
- Sort features into must, should and later
Must means the process stops working without it. Put the rest under "later" and list it in a future-work section; that shows judgement, not a gap.
- Define success before you build
One measure is enough: time to complete a request, number of errors, satisfaction of five users. You cannot evaluate what you did not measure before the change.
- Tie every week to an output
If your term has about fourteen weeks (check your university calendar), spread them across analysis, design, build, test and writing, and put a file or screen in each week that you can show your supervisor.
| Question | Sign the scope is too big | Sign it fits |
|---|---|---|
| How many processes? | More than one in the system | One process with known steps |
| How many user groups? | Staff, students, management and customers | One or two at most |
| Is there access to data or an organisation? | Waiting on an organisation you have not contacted | One organisation agreed, or test data you create |
| How many external integrations? | Payment, notifications and national ID together | None, or one you can simulate |
| Could you demo in two weeks? | Nothing works until the end | A simple prototype runs early |
For starting ideas see graduation project ideas, and for a contrast with a pure software project read the computer science graduation project. The core difference is that an information systems project is judged on how well the solution fits the process and the organisation, not on code complexity. If you are still unsure about the major, the information systems major guide gives background.
Which resources really set the size of the project?
Four, and their effect shows late: team size and skills, access to a real organisation, data, and hosting. A team of three with one person who knows databases cannot promise a committee three data stores. An organisation that takes two weeks to answer eats a seventh of the term. And real data without consent cannot be used.
Write a four-line risk table before you lock the scope: the risk, who watches it, and the fallback. A ready fallback means test data you generate yourselves if the organisation is slow, and a build that runs on your supervisor’s machine if hosting fails. For code management inside the team, the GitHub guide for beginners helps.
How do you run a Google Forms anonymous survey and handle research ethics?
If you run interviews or a survey, or test the system with users, you are collecting data about people. The working rule: explain your purpose to the participant, ask for consent before they begin, collect the least you need, and do not ask for a name or national ID you do not need. Ask your supervisor and department whether the project goes through the university’s research ethics committee, because the answer depends on the university and the kind of study, and it sits with them, not with us.
For Google Forms surveys, watch two settings: respondents’ email addresses are recorded only if you turn on the setting that collects them, and limiting a form to one response requires respondents to sign in with a Google account.2 If you want an anonymous survey, leave email collection off and say so at the top of the form. The form-building details are in the Google Forms guide, interview records in research interview documentation, and sensitive data with AI tools in privacy with AI tools.
What does a realistic graduation project plan look like?
Here is an example for illustration, not a suggested project and not a department requirement: a lost-and-found request tracker for a single college. A student logs what they lost, a staff member logs what was found, and the system matches them. One process, two user groups and three must-have features: logging a request, searching and matching, and changing status. Notifications, statistical reports and a mobile app go under "later".
| Weeks | Output | What the supervisor sees |
|---|---|---|
| 1 to 3 | Current process described, users interviewed | Process map and interview notes |
| 4 to 5 | Requirements and data model | Must and later list, table diagram |
| 6 to 9 | Three features built | Prototype running on test data |
| 10 to 11 | Test with five users | Before and after measurements |
| 12 to 14 | Report written, presentation prepared | Full draft, then the final version |
When do you cut scope, and when do you add?
Cut when two weeks pass without an output, when access to the organisation slips, or when a "must" feature turns out to need another system. Add only when you are ahead of schedule, and remember that whatever you add also needs testing and documentation. Make the call in a short meeting with your supervisor, not in a side chat.
Once the scope settles, draft the project abstract early because it exposes vagueness; see the graduation project abstract. If you need software or subscriptions, browse student deals and the Student Discount Index. Working with your supervisor is covered in the thesis supervisor guide.
