Theory
Can you do it, and what exactly must it do?
With a clear problem in hand, two questions come next, and getting them right prevents most project disasters. First: can this project realistically be done with your time, skills, and resources? That is the feasibility study. Second: what exactly must the system do? That is requirement analysis.
Skipping these leads to the classic student trap, an over-ambitious project that runs out of time half-built, or a project where the team never agreed on what they were building. This lesson covers both checks, so you commit to something achievable and know precisely what 'done' means before you start.
Theory
Feasibility: is it realistic?
A feasibility study asks whether the project can actually be delivered, before you invest months in it. The common angles:
Technical: can it be built with available technology and your skills? Operational: will it work in practice and actually be used? Economic: is the cost worth the benefit, and affordable? Schedule: can it be finished in the time available (a semester)?
For a student project, time and skill feasibility matter most. The honest question is: can WE, with our current abilities, finish THIS in the semester we have? If the answer is no, scope it down to something you can complete and polish. A finished, modest project beats an ambitious unfinished one, every time.
Theory
Requirements: functional and non-functional
Requirement analysis defines what the system must do, in enough detail that everyone agrees and you can build and test against it. Requirements split into two kinds.
Functional requirements are specific features or behaviours: 'the system shall let a student register for an event', 'an organiser shall be able to view the attendee list'. They describe what the system does.
Non-functional requirements are qualities: performance ('a page loads in under 2 seconds'), security ('passwords are stored securely'), usability, reliability. They describe how well it does it.
Good requirements are clear, specific, and agreed by the team. They become your checklist for building and your criteria for testing.
Quiz
Which of these is a non-functional requirement (as opposed to a functional one)?
- The system shall let a student register for an event
- The system shall respond to each request within 2 seconds and store passwords securely
- The system shall let an organiser view the attendee list
- The system shall send a confirmation email on registration
Show the answer
The system shall respond to each request within 2 seconds and store passwords securely
Non-functional requirements describe QUALITIES, how well the system performs, rather than specific features. Option B (respond within 2 seconds, store passwords securely) is about performance and security, which are qualities, so it is non-functional. Options A, C, and D all describe specific FEATURES or behaviours the system must do (register for an event, view attendees, send a confirmation email), which are functional requirements. The distinction: functional requirements say WHAT the system does; non-functional requirements say HOW WELL it does it (speed, security, usability, reliability). Both matter, and both belong in your requirement analysis.
Think first
Why is scoping a project realistically the hardest, and most important, planning skill?
Why do so many student projects fail on scope, and why does honest feasibility matter so much? Then tap.
Show the answer
Because ambition is easy and finishing is hard, so the most common cause of failed student projects is taking on MORE than can realistically be completed in the time available, and honest feasibility, deliberately scoping down to what you can actually deliver, is what prevents that failure. It is genuinely tempting to plan a grand project: many features, cutting-edge technology, something to wow the panel. But a semester is short, your skills are still developing, and real development always takes longer than expected (bugs, integration problems, learning curves, life). So an over-scoped project runs out of time with core features half-built and nothing polished, which evaluators and users see immediately as unfinished, and which is deeply demoralising. The counter-intuitive truth is that a SMALL, COMPLETE, well-executed project is far more impressive and valuable than a large, broken one: it demonstrates that you can define, plan, build, test, and finish something real, which is the actual skill being assessed. Honest feasibility is how you get there: by asking realistically 'can WE finish THIS in the time we have?', and if not, cutting scope until the answer is yes, choosing a core set of features you can build well rather than a wish-list you cannot. This is hard because it requires resisting your own ambition and admitting limits, which feels like settling for less. But experienced developers know that scoping to reality is a mark of maturity, not weakness: it is the difference between a project that ships and one that collapses. You can always note extra features as 'future scope' to show ambition while keeping your actual build achievable. So realistic scoping, driven by an honest feasibility check, is the planning skill that most determines whether your project succeeds, precisely because the default human tendency is to over-promise. Scope to finish, and you will finish, which beats aiming high and falling short. Small and done beats big and broken.
Summary
Key takeaways
- After defining the problem, check feasibility (can it be done?) and analyse requirements (what must it do?).
- A feasibility study assesses whether the project is realistic: technical, operational, economic, and schedule feasibility.
- For a student project, time and skill feasibility matter most; scope down to what you can finish in the semester.
- Requirement analysis defines what the system must do, clearly enough to build and test against.
- Functional requirements are specific features/behaviours (what the system does); non-functional requirements are qualities (how well: performance, security, usability).
- Good requirements are clear, specific, and agreed; they become your build checklist and test criteria.
- Memory hook: check it is feasible (can we finish it?), then define functional (what) and non-functional (how well) requirements.