# Information systems capstone project scope: fit it into one semester

> **The short answer**: An information systems capstone project scope fits one semester when it covers one process in one organisation for one user group, and splits features into must, should and later. Tie each week to a visible output, get consent from participants, avoid sensitive real data and treat your supervisor as the authority on requirements.[^1]

**Key takeaways**

- One process and one user group are enough for a strong project.
- Split features into must, should and later, and build only the first.
- Every week produces something you can show your supervisor.
- When real people take part, ask for consent and collect the least data you can.[^2]
- Your supervisor and department handbook set the requirements, not this guide.

![Diagram: a large scope shrinking to one process](https://tiswa.app/assets/blog/information-systems-capstone-scope/information-systems-capstone-scope-cover-en.webp)

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.

> **tiswa's take**: What we see with students: an information systems project rarely fails because the idea is small. It fails because the team wrote the scope with enthusiasm in week one and never measured it against the calendar. Teams that ask on day one, "what is the smallest version we can test with a real user?", reach the demo with something that runs.

## 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?

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.

![Three columns: must, should, later](https://tiswa.app/assets/blog/information-systems-capstone-scope/information-systems-capstone-scope-inline-1-en.webp)


| 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 |

![Timeline: analyse, model, build, test, write](https://tiswa.app/assets/blog/information-systems-capstone-scope/information-systems-capstone-scope-inline-2-en.webp)


For starting ideas see [graduation project ideas](https://tiswa.app/en/blog/graduation-project-ideas/), and for a contrast with a pure software project read [the computer science graduation project](https://tiswa.app/en/blog/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](https://tiswa.app/en/blog/major-information-systems/) 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](https://tiswa.app/en/blog/github-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](https://tiswa.app/en/blog/google-forms-guide/), interview records in [research interview documentation](https://tiswa.app/en/blog/research-interview-documentation/), and sensitive data with AI tools in [privacy with AI tools](https://tiswa.app/en/blog/ai-privacy-for-students/).

## 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](https://tiswa.app/en/blog/graduation-project-abstract/). If you need software or subscriptions, browse [student deals](https://tiswa.app/en/deals/) and the [Student Discount Index](https://tiswa.app/en/deals/student-discount-index/). Working with your supervisor is covered in [the thesis supervisor guide](https://tiswa.app/en/blog/thesis-supervisor/).

Team tools can cost more than you expect. Before you pay for any software, browse the student deals. [Browse student deals](https://tiswa.app/en/join/)

## Questions

### How do I scope an information systems capstone project?

Pick one process and one user group, then split features into must, should and later and build only the must-haves. Tie each week to an output your supervisor can see, and decide how you will measure success before you build.

### Is a prototype enough for a capstone project?

It may be, but the rule belongs to your department and supervisor. Reference curricula stress analysis, design and evaluation more than build size, so ask for the assessment rubric before you set the scope.[^1]

### Do I need consent for a Google Forms survey in my capstone project?

Always get participants’ consent, and ask your department whether the project needs the university’s research ethics committee, because the answer varies by university and type of study.

### How do I make a Google Forms anonymous survey?

Leave email collection off and do not ask for names or ID numbers. Email addresses are recorded only when that setting is turned on.[^2]

### Is a Google Forms survey enough evidence for my capstone?

Rarely on its own. Pair it with a before and after measure from the prototype, such as time to complete a request, and keep the survey short.

### What if the organisation is slow to reply to my project?

Switch to test data you create yourself and tell your supervisor straight away; do not wait two weeks. A written fallback plan from the start protects you here.


## Sources

[^1]: ACM and AIS: IS2020 competency model for undergraduate information systems programs, https://www.acm.org/binaries/content/assets/education/curricula-recommendations/is2020.pdf
[^2]: Google Docs Help: Google Forms response settings, https://support.google.com/docs/answer/2839588