Technical Feasibility

5. Where will it be hosted, and who will keep it running? On a team member's laptop only during demonstrations, on a college machine, or on a rented server? Chapter 5 asked who will maintain it. This question asks what they will maintain.

6. Must it work with any existing system? Integration with another system, such as a college's student records or a payment service, is often the hardest technical work of all, and frequently impossible for students, who cannot get access.

7. Can it handle the load? Estimate how many people will use it at its busiest moment, and check that the planned technology can serve them. For most student projects the answer is easily yes, but you must show the arithmetic.

8. Can the data be kept safe? What personal data will it hold, and can the team store and protect it properly?

9. What could go wrong technically? Collect the doubts from every question above into a list of risks, each with its likelihood, its impact and what you will do about it.

The skills matrix

A skills matrix answers question 2 at a glance: people down the side, technologies across the top, a rating in each cell. A simple scale is enough:

Any column with no 2 or 3 in it is a technology nobody on the team can yet use unaided. Either drop that technology or plan the learning time.

Estimating load: the arithmetic you must show

"Can it handle the load?" is answered with a short calculation, not a feeling. The method has four steps:

1. How many users a day, from your evidence.
2. When they arrive: spread over a day, or bunched into a short window?
3. The peak rate: users per minute at the busiest moment.
4. The work each user causes: how many requests one user's visit makes.

Multiply the peak rate by the requests per user and compare the result with what the technology can serve. Leave a wide safety margin, because your estimate is rough and real crowds bunch more tightly than averages suggest. Chapter 11 turns the result into a measurable requirement, and Chapter 63 tests it.

The worked project: technical feasibility

The worked team answered the nine questions in its third week.

Technology and skills

They considered three ways of building the system, each built on papers they had already passed:

Their skills matrix settled it:

Every column of the Node.js stack has a 2 or a 3. The one weak column is Linux server, and it became the first risk on their list. They chose Node.js with Express and MySQL, with plain pages that work on phones, tablets and laptops alike, and an Android app that wraps those same pages for students who want an app. Chapter 26 records this decision in full.

Hardware

Reaching the system

This was the question that nearly changed the project.

A server on a machine in the college lab sits on the college network. A phone connected to the college Wi-Fi can reach it; a phone using mobile data cannot, unless the college makes that machine reachable from the internet, which the IT in-charge would not do for a student project.

So the team checked two things at the canteen itself. First, whether the college Wi-Fi reached it: they walked the canteen with a phone and found a usable signal at every table and at the counter. Second, whether students could join it: every student with a college account could sign in to the Wi-Fi.

That made the system technically feasible on the college Wi-Fi. It became a recorded constraint: during the trial, students must be on the college Wi-Fi to order. The team noted that a public server, reachable from mobile data, is the way to lift that limit later, and Chapter 58 shows how it is done and what it costs.

Load

The busiest moment is before the break, when orders for the first slots close. The team's estimate:

1. Users a day: about 212 students, from their observation.
2. When they arrive: they assumed the worst plausible bunching, half of the day's orders in the last 15 minutes before the first cut-off, which is 106 orders in 15 minutes.
3. Peak rate: 106 divided by 15 is about 7 orders a minute.
4. Work per order: they counted the requests one student's visit makes, from signing in to seeing the order number, as roughly 10 requests.

So the peak is about 70 requests a minute, a little more than one a second. A single Node.js process on a modest machine serves far more than that. To leave a wide margin, they set the requirement at 100 students ordering in the same minute, about fourteen times the estimated peak, and planned to prove it with a load test.

Integration and data

The system needs no other system. It does not read the college's student records; instead, students register themselves with a college email address, and only that address's domain is accepted. It holds no personal data beyond a name, a college email address and each student's orders, and no money passes through it.

Technical risks

Verdict: technically feasible, on the college Wi-Fi, with the Node.js, Express and MySQL stack, on condition that the Linux deployment is practised early and that the ordering is made safe under concurrency.

Do this for your project

1. List at least two candidate stacks, each tied to papers your team has passed, with its for and against.
2. Build a skills matrix. Any column without a 2 or 3 is a risk to plan for or a technology to drop.
3. Check the hardware: development machines, the server, the users' devices.
4. Go to the place and check the network there. Decide where the server will be, and confirm every user can reach it.
5. Estimate the peak load in four steps, and set a target with a wide margin.
6. List what other systems you would need and whether you can get access; if not, redesign around it.
7. Write the risk table, and end with a verdict of the form "feasible, on condition that".

Mistakes that cost marks

"The project is technically feasible because the technology exists." Existence is not the question. Whether this team, with these skills and these machines, can build and run it, is.

No load arithmetic. Saying the system "can handle many users" proves nothing. Four lines of arithmetic do.

Forgetting the network. A server the users cannot reach is not a working system, however good the code.

Planning to learn the hardest thing last. Deployment learned in the final week is the most common cause of a failed demonstration.

A risk list with no mitigations. A risk you have written down but not planned for is a worry, not a risk assessment.

Quick revision

• A feasibility study decides whether the project should go ahead as proposed. MU names technical, economic, operational.
• Technical feasibility asks: technology, skills, hardware, network reach, hosting, integration, load, data safety, risks.
• A skills matrix rates each member on each technology; a column without a 2 or 3 is a risk.
• Load is estimated in four steps: users a day, their bunching, the peak rate, requests per user; then a wide margin.
• Every risk has a likelihood, an impact and a mitigation.
• The verdict is usually "feasible, on condition that...".

Questions you must be able to answer

1. What does technical feasibility assess? Whether the proposed system can be built and run with the technology, skills, hardware, network and hosting actually available to the team, within the time it has, and what technical risks stand in the way and how they will be handled.

2. What is a skills matrix, and what does a weak column tell you? A table rating each team member's skill in each technology the project needs. A column with nobody rated able to use the technology unaided shows a skill the team lacks, which must be learned early in the plan or avoided by choosing a different technology.

3. Show how the worked team estimated its peak load. About 212 students order in a day; assuming half of them order in the last 15 minutes before the first cut-off gives 106 orders in 15 minutes, about 7 a minute; at roughly 10 requests per order that is about 70 requests a minute. The target was then set at 100 students ordering in the same minute, about fourteen times the estimate, as a safety margin.

4. Why did hosting on a college machine make the college Wi-Fi a requirement? Because a machine on the college network can be reached only by devices on that network, and the college would not expose it to the internet. Students on mobile data could not reach it, so ordering was made feasible on the college Wi-Fi, after the team checked that the signal reached every part of the canteen.

5. What form should the conclusion of a technical feasibility study take? A verdict with its conditions, such as "feasible with this stack, on the college Wi-Fi, provided deployment is practised early and ordering is made safe under concurrency", followed by the risk table that supports it.