Problem Justification and Scope Definition

Surveys: what they can and cannot show

A survey is the most popular kind of evidence in student projects and the most often misused. Keep three things in mind.

Report the numbers, not only the percentages. "72.8 per cent" hides whether you asked 11 people or 1,100. Write "131 of 180 (72.8 per cent)".

Say how the people were chosen. If you shared a form in your class groups, those who replied are the ones who saw it and cared to answer. That is called a convenience sample, and it is not a random sample of all students. It is still useful, but its results describe the people who replied, and your report should say so.

Ask about behaviour, not about your solution. "Were you late for a lecture because of the queue last week?" produces evidence. "Would you use a great app to order food?" produces politeness. People say yes to hypothetical products they will never use.

Consider the alternatives honestly

Software is not the answer to every problem, and a justification that pretends otherwise is weak. List the other ways the problem could be tackled, and say why each is or is not better.

Examiners respect a team that considered cheaper alternatives and can explain why they chose software. They distrust one that never thought of any.

The problem statement

The justification is summarised in a problem statement: a short paragraph that says who has the problem, what it is, where and when it happens, how big it is, and what it causes. It does not describe the solution.

A dependable shape for it:

1. Who is affected, and how many.
2. What the difficulty is, in their terms.
3. Where and when it happens.
4. How much, with your evidence.
5. So what: the consequence for them, and for anyone else.

Keep it to a paragraph. If it needs a page, the problem is not yet understood.

Defining the scope

Scope is the boundary of your project. Inside it is everything the project promises to deliver. Outside it is everything it does not, however related or desirable.

A scope statement has four parts.

The objectives. What the project must achieve, stated so that someone can later check whether it did. The usual test for a well-made objective is that it is specific, measurable, achievable, relevant to the problem, and tied to a time. For a student project the time is the semester.

In scope. The capabilities the system will have, at the level of a list, not yet as detailed requirements. The detail comes in the SRS.

Out of scope. The capabilities it will deliberately not have, each with a one-line reason. This list is not an admission of weakness. It is the most useful list in the document, because it tells everyone, including your future selves, what not to spend time on.

The first release. If the in-scope list is still too long for your hours, mark which parts make the first release, sometimes called the minimum viable product: the smallest version that solves enough of the problem to be worth using. Chapter 13 does this properly with priorities.

Scope creep, and how a written scope stops it

Scope creep is the slow, unplanned growth of a project's scope, one reasonable-sounding addition at a time. "Could it also send an SMS?" "Could students rate the food?" "Could the owner see last month's sales too?" Each is small. Together they eat the testing and documentation weeks, and the project ends half-built.

A written scope turns each such idea into a decision instead of a drift. When someone suggests an addition, you ask three questions: does it serve the objectives, can we afford the hours, and what will we drop to make room? Most ideas are then written into the out-of-scope list as "a later release", which is honest and costs nothing.

The worked project: justification

After the week of observation in Chapter 3, the worked team gathered three more kinds of evidence.

A survey. A short form, shared in the class groups of several years, with no names asked. 180 students replied in the week of 3 August 2026:

The report says plainly that this is a convenience sample of students in those groups. The first question matters more than it looks: if few students had phones with internet, a phone-based solution would fail, and 176 of 180 settles it.

An interview with the owner, Lata Pawar, on 10 August 2026. She put the average lunch bill at Rs 68 and estimated that about Rs 600 of food is thrown away on an ordinary day, because the cooks guess each morning how much of each dish to make. The team recorded both figures as her estimates.

The alternatives, as they wrote them down:

The problem statement they submitted:

Students at our college have a 40-minute lunch break, from 12:30 to 13:10, and one canteen counter where they must both order and wait for their food. Over five days of observation we counted an average of 212 students served and 31.2 leaving the queue without buying each day, and timed waits averaging 16 minutes and reaching 27 minutes. In our survey, 131 of 180 students said the queue makes them late for the 13:10 lecture at least once a week, and 49 of 180 skip lunch at least twice a week because of it. The canteen loses sales it could have made, and, by the owner's estimate, throws away about Rs 600 of food a day because the kitchen cannot know in advance what will be ordered.

Notice what the statement does. It names who, what, where and when; it gives numbers and says where they came from; it states the consequences for students, for teachers and for the canteen; and it does not mention an app.

The worked project: scope

Objectives. By the end of the semester, the project will deliver a system that:

• O-1 lets a student order lunch before the break and collect it within five minutes of a chosen pickup time;
• O-2 is expected to halve the number of students who leave the queue without buying, from 31.2 a day, when the canteen uses it;
• O-3 tells the kitchen, by 12:20 each day, how many of each dish to prepare for each pickup slot;
• O-4 shows the owner the day's sales without counting slips.

In scope:

• student accounts, created by the students themselves with their college email address;
• today's menu, with prices, a vegetarian mark and what is still available;
• ordering for one of four ten-minute pickup slots, with a stock limit on every dish;
• a number for each order, and its status visible to the student;
• cancelling an order that has not started being prepared;
• a counter screen of the day's orders by slot, on which staff move each order from placed to collected;
• a kitchen list of what is still to be made for each slot;
• the owner's pages for the menu, the day's stock, the daily report and staff accounts;
• a web application for phones and laptops, and an Android app.

Out of scope, with reasons:

Every item in the out-of-scope table came up in a conversation during the first weeks. Writing it down with its reason ended the discussion of each, and when the owner asked again in week eight about online payment, the team pointed to the table and to the proposal she had signed.

Do this for your project

1. Gather at least two kinds of evidence beyond your own observation: records, an interview, a survey.
2. If you run a survey, keep it short, ask about behaviour, ask no names, and report numbers with their totals and how people were reached.
3. List the alternatives to software, and one honest line on each.
4. Write your problem statement in one paragraph: who, what, where and when, how much, so what. No mention of software.
5. Write three to five objectives that someone could check at the end of the semester.
6. Write the in-scope list and the out-of-scope list, each item of the second with its reason. Show both to the person in charge of the place, and to your guide.

Mistakes that cost marks

Justifying with adjectives. "Huge", "serious", "many" persuade nobody. Numbers with sources do.

Percentages without totals. "80 per cent of students agree" invites the question "80 per cent of how many?".

A survey about the solution. "Would you like an app?" measures politeness, not need.

No alternatives considered. It suggests the solution was chosen before the problem was understood.

An empty out-of-scope list. It means the scope has no boundary, and nobody believes a student project will build everything.

Objectives nobody can check. "To make the canteen efficient" cannot be tested; "collect within five minutes of the pickup time" can.

Quick revision

• Justification: evidence of how many, how often, how costly, what if nothing is done, and why current ways fall short.
• Evidence ranks: your own measurements, then records, then interviews, then surveys; general statements count for nothing.
• Report survey results as counts with totals and say how people were reached; a convenience sample describes those who replied.
• The problem statement: who, what, where and when, how much, so what, and no solution.
• Scope: objectives, in scope, out of scope with reasons, and the first release.
• Scope creep is unplanned growth; a written scope turns each addition into a decision.

Questions you must be able to answer

1. What is the difference between identifying a problem and justifying it? Identifying it establishes that a difficulty exists and describes it. Justifying it shows with evidence that it is significant enough to be worth solving, by how many people it affects, how often, at what cost, and why the existing ways of coping are inadequate.

2. What makes survey evidence weak, and how do you report it honestly? It is weak when the sample is small or self-selected, when it asks about a hypothetical solution rather than actual behaviour, or when only percentages are reported. Report the counts with their totals, say how respondents were reached, and ask about what people actually do.

3. What is scope creep, and how does a written scope prevent it? Scope creep is the unplanned growth of a project through a series of small additions, which consumes the time needed for testing and documentation. A written scope, with an out-of-scope list and objectives, makes each proposed addition a decision to be justified against the objectives and the hours available.

4. Why did the worked team leave online payment out of scope? Because accepting payments online requires a payment gateway merchant account and business verification that a student team cannot obtain, and because paying at the counter is what students already do and what 124 of the 180 surveyed preferred.

5. Write an objective for the worked project that can be checked, and one that cannot. Checkable: a student who pre-orders collects the food within five minutes of the chosen pickup time. Not checkable: the canteen becomes more efficient, because nothing says how efficiency would be measured or what counts as success.