Chapter 15: Problem Scoping in AI Project Framework
Every afternoon the queue outside the school canteen stretches past the staircase. Some days the samosas are finished by half past twelve and a whole section goes back to class hungry. On other days a full tray is left over and thrown away.
The canteen in-charge mentions this in the staff room. A teacher says, “Why not use AI to predict how much food to cook?” Everyone nods. It sounds like a sensible idea.
Then the class representative asks a harder question: predict it from what?
Nobody has an answer. No one has written down how much food is cooked each day, or how much is left over. No one has checked whether the real trouble is the cooking or the length of the queue. No one is sure who would even use the prediction — the cook, the students, or the school office.
The idea is not wrong. It is simply unscoped. Before a single line of code is written, somebody has to describe the problem properly: who it affects, what exactly is going wrong, where it happens, and why it is worth solving at all.
Fig. 15.0-1 shows that same canteen scene, with the four questions nobody had asked yet.
Diagram
Fig. 15.0-1 – a school canteen counter with a long queue of students; above the scene, four empty thought bubbles labelled WHO, WHAT, WHERE and WHY, drawn as unanswered questions floating over the crowd
This chapter answers all five of these questions.
15.1 What Is an AI Project Framework?
Think about a family building a house. Nobody starts by buying bricks. First they decide how many rooms they need, where the water pipes will run, and how much they can spend. Only then does the building begin. If they skip that stage, they may end up with a beautiful house and no place for the water tank.
Building a computer system that learns from data works the same way. Artificial intelligence (AI) is the branch of computing that builds systems able to carry out tasks that normally need human judgement, such as recognising a face or sorting fruit by ripeness. An AI system is not built in one step. Data has to be collected, a program has to be trained on that data, and the finished system has to be put to work and watched over.
Each of those steps depends on the one before it. Collect the wrong data and the training is wasted. Train on good data but never check the result, and nobody knows whether the system helps or harms. So teams follow an agreed order of stages instead of working in whatever order feels convenient. That agreed order is called an AI project framework.
Here, deployment means putting the finished system into real use — installing it on the shop’s billing counter, or on the phone in a farmer’s hand — rather than leaving it running only on the developer’s computer.
What the framework covers
A typical AI project framework moves through these stages:
- Defining the problem clearly.
- Collecting and preparing the data.
- Choosing and training the software that will do the work.
- Deploying the system and monitoring it after it goes live.
The last stage matters more than students usually expect. A system that worked well in June may work badly in December, because the world it was trained on has changed. Monitoring means checking on it regularly and retraining it when its answers start slipping.
Why teams bother with it
Working to a framework does three useful things. It reduces the risk of building the wrong thing, because the problem is settled before any money is spent. It uses time and equipment sensibly, because everyone knows what comes next. And it keeps the practical questions in view alongside the technical ones — whether the system can be scaled up to more users, whether it treats people fairly, and whether it follows the law.
In the rest of this chapter you will look closely at the very first stage — deciding exactly what problem is being solved.
15.2 The Phases of an AI Project Cycle
Think about cooking a meal for guests. You first decide what dish you are making. Then you buy the ingredients. Then you spread them on the counter and see what you actually have — perhaps the tomatoes are not ripe. Then you cook, and finally you taste before serving. Skip the tasting and you find out about the salt only when your guest does.
An AI project runs through a very similar set of stages, always in the same order. This ordered set of stages is called the AI project cycle.
The cycle has four phases. Fig. 15.2-1 shows them arranged in a ring.
Diagram
Fig. 15.2-1 – four boxes arranged in a ring joined by curved arrows running clockwise, labelled in order: Problem Scoping, Data Acquisition, Data Exploration, Modelling and Evaluation; a dashed arrow runs from the last box back to the first, labelled “if the result is not good enough, scope again”
The four phases
Problem scoping is the first phase. Here the team works out exactly what problem is being solved, who it affects and what a good result would look like. Nothing is built yet. This is the phase the rest of this chapter is about.
Data acquisition comes next. The team collects the data the system will learn from, and checks that it comes from a reliable source. A system meant to sort mangoes needs pictures of mangoes — good ones and bad ones — not a general collection of fruit photographs.
Data exploration follows. The collected data is drawn out as graphs and charts so that patterns and gaps become visible. A number written in a table is easy to miss. The same number drawn as a bar sticking out above the rest is not.
Modelling and evaluation is the last phase. A model is the piece of software that has been fitted to the data so that it can produce an answer for a new case it has not seen before. Modelling is the work of building and training that model, and evaluation is the work of testing it to find out how well it actually performs.
Why it is drawn as a ring
Evaluation rarely ends the story. If the testing shows the model is not good enough, the team goes back — sometimes to collect better data, sometimes all the way back to problem scoping, because the problem itself was described badly. That is why the phases are drawn as a cycle rather than a straight line.
The other three phases are taken up in later chapters. The rest of this chapter stays with the first one.
15.3 Problem Scoping
A plumber is called to a house and told, “There is a problem with the water.” That sentence is not enough to work with. Is the tap leaking, is the tank empty, or has the motor stopped? Until the plumber walks around the house and narrows it down, any repair he attempts is a guess.
An AI team starts in exactly the same position. Somebody says, “Our canteen wastes food, can AI fix it?” That is a complaint, not a problem the team can build for. The work of turning a loose complaint into a clear, workable description of what has to be solved is called problem scoping.
What this phase settles
Problem scoping acts as the blueprint for everything that follows. By the end of it, the team should be able to state four things:
- The core problem — the one thing that is actually going wrong, separated from everything else people are complaining about.
- The goal — what a successful result would look like, stated clearly enough that anybody can check it later.
- The needs of the people involved — what the users of the system actually want from it, which is not always what the team assumes.
- The constraints — the limits the project has to work inside, such as the time available, the money available, or the fact that the required data simply does not exist yet.
That last one is easy to skip and expensive to skip. A team can spend a month designing a system that predicts canteen demand and only then discover that nobody has ever recorded how much food was cooked on any day.
What problem scoping cannot do
Scoping does not tell you whether the AI solution will work. It only makes sure you are aiming at the right target. A perfectly scoped problem can still fail at the modelling phase because the data turns out to be too noisy or too small. And a scope decided in January may stop matching reality by July, which is one reason the project cycle loops back.
The next three sub-sections look at the three main pieces of this work: understanding the problem, defining the goal, and making that goal SMART.
15.3.1 Understanding the Problem and the Factors That Affect It
A ceiling fan stops turning. “The fan is broken” is what everyone says, but it is not yet a diagnosis. The switch may be faulty, the regulator may have failed, a wire may have come loose, or the power may simply be off. Each of these needs a different repair. The complaint is the same in all four cases.
The first job in problem scoping is exactly this: separate what people are complaining about from what is actually going wrong.
Symptom and cause are not the same
In the canteen, the complaint is that students go hungry on some days and food is thrown away on others. That is the symptom — the thing people notice. The problem underneath it is that the amount of food cooked each morning does not match the number of students who will eat that day.
Writing the symptom as though it were the problem sends the whole project in the wrong direction. A team that scopes the problem as “students are unhappy” might end up building a feedback app, which would collect complaints beautifully and change nothing about the cooking.
Finding the factors
Once the problem is stated, the next step is to ask what affects it. A factor is anything that changes the size or the behaviour of the problem. Some factors are obvious, some are not, and the only way to find the hidden ones is to talk to the people who live with the problem every day — in this case the cook, the students and the office.
Fig. 15.3-1 shows the factors the team gathered for the canteen problem.
Diagram
Fig. 15.3-1 – a fishbone-style sketch with the problem written in a box on the right (“food cooked does not match the number who will eat”) and slanting branches feeding into it from the left, each labelled with one factor: number of students present, day of the week, exam or holiday schedule, weather, price of the item, and what is on the menu
Listing factors is not the end of it. Each one has to be checked against a hard practical question: can it be measured and recorded? A factor that nobody records cannot be used later, however important it feels. Table 15.1 sets out the same six factors against that test.
The table makes the gap visible straight away. Two of the six factors are not being recorded at all. That is not a reason to give up on them; it is a reason to start recording them now, before the data acquisition phase begins.
15.3.2 Defining the Goal of the Project
A bus without a destination board can still be driven. It just cannot be judged. Nobody can say whether it arrived, because nobody said where it was going.
Knowing the problem tells the team what is wrong. It does not yet tell them what “finished” looks like. That is the job of the goal.
Problem and goal are different sentences
The problem describes the present. The goal describes the situation the team is trying to reach.
For the canteen, the problem is that the quantity cooked each morning does not match the number of students who will eat that day. A goal built on it might be: to give the cook, before eight in the morning, an estimate of how many portions of each item will be needed that day, so that the canteen neither runs out during the lunch break nor is left with unsold trays.
Notice what the goal contains. It says who receives the result (the cook), when (before eight), what the result is (an estimate of portions per item), and what a good outcome means (no running out, no unsold trays). Every one of those can be checked later by someone who was not in the room today.
A goal has to be checkable
The point of writing a goal down is that it can settle an argument six months from now. This is why teams also agree, at scoping time, on the success criteria — the specific things that will be looked at afterwards to decide whether the goal was met. If the criteria are only decided at the end, everybody quietly picks the criteria that make their own work look good.
Table 15.2 puts a loose aim next to a defined goal for the same project.
The left-hand column is not a bad idea. It is an unfinished one. Turning it into the right-hand column is the whole point of this part of scoping.
Keep the goal tied to what the school actually wants
A goal also has to be worth reaching. The school’s real concern is wasted food and hungry students, so a goal aimed at reducing both fits. A goal aimed at, say, making the canteen queue move in alphabetical order would be perfectly checkable and completely beside the point.
A goal like the canteen one is a good start, but it is still missing something: a deadline, and a measurable target. The next sub-section shows how teams tighten a goal until it has both.
15.3.3 Making a Goal SMART
“I want to do better in mathematics this year” is a sentence every teacher has heard. It is sincere, and it is useless as a plan. Better by how much? By when? Compared with what?
Project goals fail in the same way. A goal can sound firm and still leave everyone free to decide afterwards whether it was reached. To avoid that, teams check their goal against five tests, known together as SMART — Specific, Measurable, Achievable, Relevant and Time-bound. Fig. 15.3-2 shows the five tests arranged around the goal they are applied to.
Diagram
Fig. 15.3-2 – a circle divided into five coloured segments arranged around a centre labelled “SMART goal”; the segments are labelled clockwise Specific, Measurable, Achievable, Relevant and Time-bound
The five tests
Specific means the goal names one clear outcome, not a general direction. “Improve the canteen” is a direction. “Give the cook a daily estimate of portions needed for each item” is specific.
Measurable means somebody can put a number to it and check it. This forces the team to name what will be counted — here, the number of school days on which an item runs out before the lunch break ends.
Achievable means the goal can actually be reached with the time, people and data available. “The canteen never runs out of anything, ever” would fail this test. Attendance changes, deliveries fail, and no estimate is right every single day.
Relevant means the goal serves what the school is actually trying to do. Reducing waste and hunger is relevant. Sorting the queue alphabetically is not.
Time-bound means a deadline is attached, so progress can be judged at a fixed point instead of drifting.
Writing the canteen goal as a SMART goal
Putting the five together gives something like this:
Within four months of the estimate going into daily use, reduce the number of school days on which any canteen item runs out before the lunch break ends to at most one day in every ten, measured across a full term.
Before this goal can be judged, the school has to know where it is starting from. Nobody at the school has been recording leftovers or run-outs, so the first weeks of the project are spent simply writing those figures down each day. Without that record there is nothing to compare the later result against.
That single number is what makes the goal measurable. At the end of the term the school counts the run-out days. Six or fewer, and the goal was met. Seven, and it was not — and no argument about it is possible.
What SMART does not guarantee
A goal can pass all five tests and still be the wrong goal. SMART checks how a goal is written, not whether it was worth writing. That judgement comes from the work in the previous sub-sections — understanding the real problem and the people it affects.
15.4 The 4Ws of Problem Scoping
A reporter sent to cover a road accident does not decide what to write and then look for facts to fit. She asks a fixed set of questions first — who was involved, what happened, where, and why. The questions are always the same, which is precisely why nothing important gets left out.
Problem scoping uses a very similar checklist, called the 4Ws: Who, What, Where and Why. SMART, from the last sub-section, tightens a goal after you have one. The 4Ws come earlier — they are how a team makes sure it understood the problem from every side before writing that goal at all.
The four questions are:
- Who are you solving this for?
- What is the problem?
- Where does the problem exist?
- Why are you solving it?
Teams usually write the four answers side by side on a single sheet, so that all of them can be read at once. That sheet is called the 4W canvas, and Fig. 15.4-1 shows its layout.
Diagram
Fig. 15.4-1 – a sheet divided into four labelled blocks stacked one below the other, WHO, WHAT, WHERE and WHY, joined by a curved arrow running from the top block down to the bottom; to the right of the blocks, the four questions are listed: “Who are you solving for?”, “What is the problem?”, “Where does the problem exist?”, “Why are you solving it?”
Why all four, and why in that order
Each answer sets up the next one. Until you know who is affected, you cannot say what counts as a problem for them. Until you know what the problem is, you cannot look for where the data about it lives. And until you know where the solution will run, you cannot judge whether the whole thing is worth the effort — which is the last question.
The order also protects the team from a common trap: answering “why” first. A team that begins with “because AI is exciting” will find a problem to attach it to, and that problem is rarely the one worth solving.
The four answers are also not permanent. As the team talks to more people, an answer often changes — and when the “who” changes, the “what” usually changes with it.
The four sub-sections that follow take each W in turn.
15.4.1 WHO (Identifying the stakeholders and users)
A school plans a trip to a science centre. The obvious people are the students going. But the bus driver has to know the route, the parents have to agree, the class teacher has to arrange leave, and the principal has to sign the permission. Plan around the students alone and the trip stalls at the first signature.
The WHO question asks the same thing of an AI project: who is involved in it, and who will feel its effects.
Three kinds of stakeholder
Primary users are the people who will actually work with the system. They open it, read its output and act on it. In the canteen project the primary user is the cook, because it is the cook who receives the daily estimate and decides how much to prepare.
Secondary users are affected by the system without touching it. The students eating in the canteen are secondary users — the estimate changes what is on the counter at lunch, but no student ever opens the system. So are the office staff who pay the canteen’s bills.
Decision makers are the people with the authority to approve the project, pay for it, or stop it. Here that is the principal and the canteen contractor. They may never use the system at all, but nothing happens without their agreement.
Table 15.3 sets out the canteen project’s stakeholders and what each one actually wants from it.
Reading down that last column shows why the WHO question is asked so early. The cook wants something short. The staff want nothing extra to fill in. If the team designs a detailed form to be completed every morning, it satisfies neither, and the system quietly stops being used within a fortnight.
Talking to them early
Stakeholders are not a list to be filed away. Their needs, worries and expectations shape what gets built, and those things are only learned by asking. A ten-minute conversation with the cook in week one is worth more than a month of guessing in the team’s own classroom.
15.4.2 WHAT (Defining the problem and objectives)
A shopkeeper says business is bad. That could mean several different things. Fewer customers are walking in. Or the same customers are buying less. Or the popular items keep running out while the slow ones fill the shelves. Each of these is a different problem, and each needs a different fix.
The WHAT question forces that choice to be made. It asks the team to name the one problem the project will address, and then to say what solving it should achieve.
Pinning the problem down
Three questions turn a loose description into a definite one:
- Scope — how much of the situation does this problem cover? The canteen project deals with the quantity of food prepared each morning. It does not deal with the price of items, the speed of the queue, or the taste of the food, even though people complain about all three.
- Scale — how big is it? Does it affect one counter or every counter, one class or the whole school, one day a week or every day?
- Impact — what does it cost? Wasted food is money the school has already spent. Students who miss lunch sit through the afternoon hungry.
Answering these keeps the project honest in both directions. A problem drawn too narrowly — “estimate how many samosas are needed on Fridays” — solves a sliver and leaves the rest untouched. A problem drawn too widely — “fix the canteen” — cannot be built at all.
From problem to objectives
Once the problem is fixed, the team writes the objectives: the specific results the finished system has to produce, stated so they can be checked. Objectives are narrower than the goal. The goal says where the project is going; the objectives say what must be true for it to have got there.
For the canteen problem, the objectives might be:
- Produce a daily estimate of the portions needed for each item on the menu.
- Deliver that estimate to the cook before preparation starts in the morning.
- Present it in a form the cook can read and act on without training.
Objective (c) is the one teams forget. A correct estimate that arrives as a page of figures nobody has time to read has not met the objective, however good the software behind it is.
Objectives also have to serve what the organisation actually cares about. The school’s concern is waste and hungry students, so objectives about portions and timing fit. An objective about, say, producing a monthly report of canteen statistics would be easy to build and would serve nobody in particular.
Notice that none of the objectives above mentions software, data or AI. That is deliberate. The WHAT question settles what has to be achieved; how it will be achieved is decided much later, in the modelling phase.
15.4.3 WHERE (Determining the context and environment)
A ceiling fan and a table fan do the same job, but you would not fit a ceiling fan in a cycle-rickshaw. Where a thing has to work decides a great deal about what it can be.
The WHERE question asks two separate things about an AI project: where the data is going to come from, and where the finished system is going to run.
The data environment
The data environment is everything about where the project’s data lives — which records exist, who holds them, how the team may get at them, and what condition they are in.
For the canteen project the data environment looks like this. Daily attendance is held by the school office. The calendar of exams and holidays is on the school notice board. Canteen prices are on the price list. Records of how much was cooked and how much was left over do not exist anywhere, because nobody has been writing them down.
Three practical limits show up in almost every data environment:
- Availability — does the record exist at all? Here, half of what the project needs does not.
- Quality — can it be trusted? Attendance filled in properly every morning is useful; attendance marked from memory on Friday evening is much less so.
- Format — what shape is it in? A register written by hand has to be typed in by somebody before any program can use it.
None of these is a reason to abandon the project. They are reasons to know, at scoping time, how much work the data will cost — because that work always turns out to be larger than the team expects.
The deployment environment
The deployment environment is where the finished system will actually run and where its output will appear. It might sit on the school’s own computer, or on a company’s computers reached over the internet, or be built into a small device.
This choice is not a detail to settle later. The canteen kitchen has no computer, no reliable place to keep one, and a cook whose hands are wet and floury from seven in the morning. A system that expects him to log in and read a screen will not be used. A printed sheet pinned above the counter, produced by the office computer at ten to eight, fits the actual room. Fig. 15.4-2 shows the two ends of the project side by side.
Diagram
Fig. 15.4-2 – on the left, three labelled sources of data (attendance register in the school office, school calendar, canteen’s own daily record) with arrows feeding into a central box labelled “the system”; on the right, an arrow leaving the box to a sheet of paper pinned above the kitchen counter, labelled “deployment environment”
Table 15.4 sets the two environments against each other.
15.4.4 WHY (Understanding the purpose and values)
Every project costs something — somebody’s time, somebody’s money, and the attention of people who could have been doing other work. The WHY question asks whether that cost is worth paying, and it is asked before the spending starts, not after.
What the project is worth
The answer to WHY is stated as the benefits the project is expected to bring. For an organisation these are usually of a few kinds: money saved, money earned, time saved, or a service that people are happier with.
For the canteen, the benefits are plain enough. Food that is cooked and then thrown away is money the school has already spent for nothing, so less waste means lower cost. Students who reach the counter and find their item finished go back to class hungry, so fewer run-outs means a lunch break that does what it is meant to do. Both benefits point back at the same problem, which is a sign the scoping has held together.
The success criteria agreed earlier are what turn this from a hope into a claim that can be checked. Without them, “the canteen improved” is only an opinion.
Why solve it with AI at all
The WHY question has a second half that is easy to skip: why does this problem need an AI solution rather than a simpler one?
There are honest reasons. The problem may depend on many factors changing together, so no single fixed rule fits. It may involve more records than a person could look through by hand. It may contain patterns that only show up across months of data. The canteen problem has some of this character — attendance, the day of the week, the exam calendar and the menu all pull on the answer at once.
But there are also cases where the honest answer is that AI is not needed. If the cook could get most of the way there by simply reading the morning’s attendance figure and adjusting last week’s quantities, then that is the solution, and it can start tomorrow.
With all four Ws answered, the team has everything it needs to write the problem down in a single agreed form. That is the subject of the next section.
15.5 The Problem Statement
By now the team has a good deal on paper: the factors behind the problem, a SMART goal, a list of stakeholders, two environments and a reason for doing any of it. That is a lot of sheets. Six months later, when somebody new joins the project, nobody is going to read all of them.
So the last act of problem scoping is to compress everything into a few sentences that everyone signs up to. That is the problem statement.
The usual template
Teams commonly write it against a fixed template with four blanks, one for each of the 4Ws. Table 15.5 shows the blanks and where each one comes from.
Filled in for the canteen project, the four blocks read:
Our canteen cook has a problem that the quantity of food he prepares each morning does not match the number of students who will eat that day, when he has to decide those quantities before attendance for the day is known. An ideal solution would give him a portion estimate for each item before preparation begins, so that fewer students find their item finished and less cooked food is thrown away.
What makes it a good one
A problem statement earns its place by being short and by leaving nothing important out. Three things are worth checking before it is accepted.
It should describe one problem. If the sentence contains an “and also”, the project has probably taken on two problems and will do neither well.
It should not name any technology. Read the canteen statement again — there is no mention of AI, of a model, or of a programming language. That is correct. The statement says what has to be true; the modelling phase decides how.
It should be checkable by an outsider. Somebody who was not part of the scoping should be able to read it and say whether the finished system did what it promised.
And then the next phase begins
Once the problem statement is agreed, problem scoping is over. The team knows what it is solving, for whom, in what setting, and why it matters. What it does not yet have is any data.
That is where the AI project cycle turns to its second phase, data acquisition, which the next chapter takes up.
15.6 Summary
- An AI project framework is a structured method that guides the development, deployment and maintenance of an AI system through a fixed order of stages.
- Deployment means putting a finished system into real use, rather than leaving it running only on the developer’s computer.
- The AI project cycle has four phases: problem scoping, data acquisition, data exploration, and modelling and evaluation. It is drawn as a ring because a poor result sends the team back to an earlier phase.
- Problem scoping is the first phase. It defines and understands the exact problem the AI solution will address, before any data is collected or any software is built.
- Scoping settles four things: the core problem, the goal, the needs of the people involved, and the constraints the project must work within.
- The complaint people make is the symptom; the problem is what would have to change for the complaint to stop.
- A factor is anything that changes the size or behaviour of the problem. Each factor should be checked to see whether it can actually be measured and recorded.
- The goal states what a successful result would look like, and the success criteria state what will be checked afterwards to decide whether it was reached.
- SMART is a five-part test for a goal: Specific, Measurable, Achievable, Relevant and Time-bound. A goal can pass all five tests and still be the wrong goal.
- The 4Ws are Who, What, Where and Why. Written side by side on one sheet, they form the 4W canvas.
- WHO identifies the stakeholders: primary users who work with the system, secondary users affected by it without touching it, and decision makers who can approve or stop the project.
- WHAT fixes the problem’s scope, scale and impact, and turns it into objectives — the specific results the finished system must produce.
- WHERE covers two settings: the data environment, which is where the data lives and what condition it is in, and the deployment environment, which is where the finished system will run and its output appear.
- WHY states the value the project is expected to bring, and asks honestly whether the problem needs an AI solution at all.
- The problem statement compresses all of this into a few agreed sentences. A good one describes a single problem, names no technology, and can be checked later by an outsider.
15.7 Key Terms
4W canvas — a single sheet on which the answers to the four Ws are written side by side, so that all of them can be read at once.
4Ws — the four scoping questions Who, What, Where and Why, asked in that order.
AI project cycle — the ordered set of phases an artificial intelligence project passes through: problem scoping, data acquisition, data exploration, and modelling and evaluation.
AI project framework — a structured method that guides the development, deployment and maintenance of an artificial intelligence system through a fixed order of stages.
Artificial intelligence (AI) — the branch of computing that builds systems able to carry out tasks that normally need human judgement.
Constraint — a limit the project must work inside, such as the time available, the money available, or data that does not exist.
Data acquisition — the phase in which the data the system will learn from is collected from reliable sources.
Data environment — everything about where a project’s data lives: which records exist, who holds them, how they may be accessed, and what condition they are in.
Data exploration — the phase in which collected data is drawn out as graphs and charts so that patterns and gaps become visible.
Decision makers — the stakeholders with the authority to approve, fund or stop the project.
Deployment — putting a finished system into real use, rather than leaving it running only on the developer’s computer.
Deployment environment — where the finished system will run and where its output will appear.
Evaluation — the work of testing a trained model to find out how well it actually performs.
Factor — anything that changes the size or the behaviour of the problem being scoped.
Model — the piece of software that has been fitted to data so that it can produce an answer for a new case it has not seen before.
Modelling — the work of building and training a model.
Objectives — the specific results the finished system must produce, stated so that they can be checked.
Primary users — the stakeholders who will actually work with the system, reading its output and acting on it.
Problem scoping — the first phase of an AI project, in which the team defines and understands the exact problem the solution will address, before any data is collected or software built.
Problem statement — a short written summary of the scoped problem, naming who is affected, what the problem is, where or when it occurs, and what an ideal solution would achieve.
Secondary users — the stakeholders affected by the system without ever using it themselves.
SMART — a five-part test for a goal: Specific, Measurable, Achievable, Relevant and Time-bound.
Stakeholder — any person or group involved in an AI project or affected by it, whether or not they use the system.
Success criteria — the specific things that will be looked at after the project to decide whether the goal was met.
15.8 Objective Questions
- In an AI project, problem scoping is carried out mainly in order to:
- collect and clean the data the system will use
- decide which programming language the team will write in
- define the problem clearly and set a goal for the project
- train the software on records from past years
- Fill in the blanks.
- The first phase of the AI project cycle is ______.
- The ______ environment describes where the finished system will run and where its output will appear.
- State whether each of the following is true or false.
- A goal that passes all five SMART tests is certain to be the right goal for the project.
- A factor that nobody has been recording can still be used by the system straight away.
- A decision maker may never use the finished system.
- Which of the following is not one of the five SMART tests?
- Specific
- Repeatable
- Achievable
- Time-bound
- A parent whose child’s bus timing changes because of a school’s new route-planning system, but who never opens that system, is best described as:
- a primary user
- a secondary user
- a decision maker
- not a stakeholder at all
- Match each W in Column A with the question it asks in Column B.
| Column A | Column B |
|---|---|
| a. WHO | i. Where does the problem exist? |
| b. WHAT | ii. Why are you solving it? |
| c. WHERE | iii. Who are you solving for? |
| d. WHY | iv. What is the problem? |
- Name the four phases of the AI project cycle in the order in which they occur.
15.9 Concept Questions
Define problem scoping, and state why it is placed first in the AI project cycle.
Explain the difference between the symptom of a problem and the problem itself. Give one example of your own, not taken from the chapter.
While scoping a problem, why must each factor be checked to see whether it can actually be measured and recorded?
Distinguish between the data environment and the deployment environment of an AI project, giving one example of each.
A team writes its goal as “Make the school library better.” Rewrite this as a SMART goal, and explain briefly how your version satisfies each of the five tests.
A school term has 80 school days. A project sets a target that an item may run out on at most one school day in every ten. Work out the largest number of run-out days that still meets the target, showing your working.
What would happen to a project if the team answered the WHY question first, before WHO, WHAT and WHERE? Explain with a reason.
15.10 Case-Based Questions
- A stationery shop beside a school finds that its most popular notebooks are sold out by the middle of every month, while several other designs sit unsold on the shelf for months. The owner wonders whether an AI system could tell her how many of each notebook to order. She lists the factors she thinks matter, and whether her shop records them at present.
- Identify one primary user and one secondary user of the proposed system.
- Which factor in the table must the shop begin recording before this project can go ahead, and why?
- Write a problem statement for the shop, using the four-block template.
- A school librarian keeps a handwritten register of every book issued and returned. She would like a system that suggests, at the start of each term, which subjects the school should buy more books in. The school office has one computer. The library itself has none, and the librarian is at the issue desk for the whole school day.
- Describe the data environment and the deployment environment for this project.
- State one constraint the team should write down during problem scoping, and explain why it matters.
- Instead of an AI system, the librarian could simply count the ten most-issued books at the end of each term. Give one reason why this simpler method might be enough, and one reason why it might not be.