Mini Project I (Real-World Application Development) Notes | B.Sc. (Computer Science) Semester 5 | Mumbai University | munotes

The fifty marks in one table

MU prints the marks of this paper in the EVALUATION SCHEME at the back of the syllabus, under section C, "Evaluation for Mini Project (2 Credit Courses)". There are eight components, four for each assessor.

Internal evaluation, to be assessed by the Project Guide:

External evaluation, to be assessed by the External Examiner:

The component names above are MU's own, copied as printed, ampersands included. When your guide or examiner uses one of these names, this is what they are referring to.

Look at where the weight falls. Twenty of the fifty marks, 40 per cent, are the working application and its technical design and implementation. A project that is well documented but does not run, or runs but was never really designed, cannot score well however good the report is. Equally, the four internal components are each worth as much as the report: the guide's marks are not a formality.

Who awards them, and when

The Project Guide is the teacher your college assigns to supervise your project. MU gives them all 20 internal marks. They see your work throughout the semester, which is why their four components are about the stages of the work: the problem and the proposal, the design, the progress of the code, and a presentation.

The External Examiner is a teacher from outside your college, appointed for the examination, who sees your project once, at the end. MU gives them all 30 external marks, for what can be judged at that one meeting: the application running, its design and code, the report, and your answers.

MU does not print the dates on which each internal component is assessed. It prints only what they are. So the timing is your college's, and in practice it follows the work:

Ask your guide in the first week when they will assess each of the four. Write the dates in your project plan. Chapter 17 shows how.

Passing: each half on its own

This is the rule that catches students out. The scheme page of MU's syllabus, which applies to every course of this programme, prints the scheme of examination in three lines, "40% Internal", "60% External, Semester End Examination" and "Individual Passing in Internal and External Examination", and the standard of passing as "40% in each component".

Individual passing means the internal marks and the external marks are passed separately. It is not enough for the total to reach 40 per cent. For this paper:

• 40 per cent of the internal 20 marks is 8. You need at least 8 of 20.
• 40 per cent of the external 30 marks is 12. You need at least 12 of 30.

A worked example makes the trap plain. Three students of one college finish the paper with these marks:

Rohit has 28 of 50, which is 56 per cent, and has not passed, because his external marks are one short of 12. Sana has 66 per cent and has not passed either, because her internal marks are one short of 8. Irfan has only 44 per cent and has passed, because each half cleared its own bar. Guard both halves. A strong external day cannot rescue internal marks you let slip during the semester.

From marks to a grade

The same appendix prints how a percentage becomes a letter grade and a grade point. Your result in this paper is the percentage of 50 that your two halves add up to:

So a student with 18 internal and 24 external has 42 of 50. 42 divided by 50 is 0.84, which is 84 per cent, which is A+ (Excellent) with 9 grade points. Each mark on a 50-mark paper is worth 2 per cent, so the difference between A and A+ can be a single mark.

What does not apply to this paper

The other practical papers of your semester, such as Computer Science Practical 5, are assessed under section B of the same appendix. It is printed with its own heading, "Evaluation for Practical Courses (2 Credit Courses)", and immediately under it, "(other than Mini Project)".

So none of section B's rules is a rule of this paper:

• There is no certified journal requirement for appearing.
• There is no rule that 80 per cent of the practicals must be completed, because this paper has no list of practicals.
• There is no two-hour practical examination with a question on each module.
• There is no mid-term practical examination.

Students who have heard these rules from seniors doing the practical papers sometimes carry them over. Do not. The documents that matter here are the ones this book walks you through: the proposal, the SRS, the UML set, the architecture document, the report and the user manual.

What MU does not print, and who decides it

MU's scheme is short. Several things a student wants to know are simply not in it. When something is not printed, it is decided by your college and your guide, and you should ask rather than assume.

One thing MU does print firmly is in Module 2: "Version control using GitHub (Mandatory)". That word is not in brackets for decoration. Whatever else your college allows, your code must be in a GitHub repository. Chapters 61 and 62 teach it, and Chapter 39 makes the first commit.

In the first week, take this list of questions to your guide and write down the answers. Every answer is a rule you will be held to, and a guess is a rule you might break.

Each of the eight components, and what earns it

MU prints the name of each component and its marks, and nothing about what earns them. The column "what you show" below is our reading of each name, based on what that name can sensibly mean for a project; your guide's and examiner's own expectations, if they give you any, come first.

Problem Identification & Project Proposal (5, guide). You show a real problem, evidence that it is real, and a proposal that says what you will build, for whom, why it is worth building and whether it can be built. Chapters 3 to 8 and 33.

System Design (SRS, UML Diagrams, Architecture) (5, guide). MU names the three documents inside the brackets, so those are what is judged: the software requirements specification, the complete set of UML diagrams, and the architecture design document. Chapters 9 to 36.

Development Progress & Code Review (5, guide). Progress is judged over time, so show it over time: commits spread across the weeks, not all on the last night; issues opened and closed; a running build at each meeting. A code review means your guide reads your code and asks you about it, so be ready to explain any line you wrote. Chapter 49.

Internal Presentation / Review (5, guide). A presentation of the project to your guide, or to a panel your college forms, before the external examination. Treat it as the dress rehearsal for the external day. Chapter 74.

Working Application Demonstration (10, examiner). The application must run in front of the examiner and do what your SRS says it does, including refusing bad input and recovering from errors. Chapters 71 and 74.

Technical Design & Implementation (10, examiner). The quality of the design and of the code that implements it, and how faithfully the one follows the other. An examiner can open your repository, your diagrams and your code side by side. Chapters 19 to 31 and 38 to 49.

Project Report Evaluation (5, examiner). The final report, judged as a document: complete, correct, organised and readable. Chapters 66 and 73.

Viva Voce (5, examiner). Questions put to you in person about your project and the ideas behind it. "Viva voce" is Latin for "with the living voice", meaning an oral examination. Chapter 76 collects the questions examiners ask, with answers.

Why a copied project fails

Every year some students download a finished project from a website and submit it. This paper is built, perhaps by design, so that this fails at three separate points.

The code review. Your guide reads your code during the semester and asks you about it. A student who did not write it cannot explain why a function is written the way it is, or what happens if a line is removed.

The GitHub history. Git records who made every change and when. A repository with one enormous commit on the last day, or with commits by strangers, tells its own story before anyone asks a question.

The demonstration and the viva. An examiner who suspects a project was not built by the student asks for a small change, made live: add a field, change a validation rule, show where a particular request is handled. Only the person who built it can do that in five minutes.

The worked project in this book is complete, and you may read every line of it. It is an example of the method, not a project to submit. Chapter 2 explains how to use it.

How this book follows the marks

What it does not mean

"Practical" does not mean a practical examination. The type is Practical because the credits are practical hours. There is no timed practical paper for this course.

The internal marks are not given for attendance. Each of the four is named after something you produce or do. A student who attends every meeting and brings nothing earns nothing under those names.

A good total does not guarantee a pass. Individual passing means 8 of 20 and 12 of 30, separately.

"No text book" does not mean "no preparation". The external examiner judges design and implementation, and asks questions in the viva. Both require you to understand the ideas this book teaches, not only to have built something.

Quick revision

• No written examination. Internal 20 by the Project Guide, external 30 by the External Examiner.
• Internal: Problem Identification & Project Proposal 5; System Design (SRS, UML Diagrams, Architecture) 5; Development Progress & Code Review 5; Internal Presentation / Review 5.
• External: Working Application Demonstration 10; Technical Design & Implementation 10; Project Report Evaluation 5; Viva Voce 5.
• Individual passing, 40 per cent in each: at least 8 of 20 and at least 12 of 30.
• Section B's certified journal and 80 per cent rule are printed "(other than Mini Project)": they do not apply.
• MU does not print group size, report format or dates: ask your guide in week one.
• GitHub is printed as Mandatory.

Questions you must be able to answer

1. How is Mini Project I assessed? By two assessors and no written paper. The project guide awards 20 internal marks for the problem and proposal, the system design, the development progress and code review, and an internal presentation, 5 marks each. An external examiner awards 30 marks for the working application demonstration (10), the technical design and implementation (10), the project report (5) and the viva voce (5).

2. A student has 19 internal and 11 external marks. Have they passed? No. MU's scheme requires individual passing at 40 per cent in each component, which is 12 of 30 in the external. Eleven is one short, so the student has not passed the paper, although the total of 30 is 60 per cent.

3. Does a student need a certified journal to appear for the Mini Project examination? No. The certified journal rule is in section B of the evaluation scheme, which is printed as applying to practical courses "other than Mini Project".

4. What does "Development Progress & Code Review" require you to show? MU prints only the name and the 5 marks. Read plainly, it asks for progress that can be seen over time, such as commits spread across the weeks and issues closed, and for code the guide can read and the student can explain line by line when asked.

5. What percentage and grade does 38 out of 50 give? 38 divided by 50 is 0.76, which is 76 per cent, and that falls in 70.0 to below 80.0, which is grade A (Very Good) with 8 grade points.

6. Your college has not said how many students may be in a group. What do you do? Ask the guide. MU's scheme for this paper does not print a group size, so the college's rule is the one that applies, and it should be confirmed in writing in the first week, along with the report format and the assessment dates.

And the deliverables, printed as "Documentation Deliverables at the End of Module 1":

How the five rows become four documents

The rows are not five separate jobs. Each one feeds a document, and the documents build on each other in a fixed order, because each needs the one before it.

1. The problem and its feasibility become the heart of the project proposal. You cannot propose a solution to a problem you have not established.
2. The requirements become the SRS. You cannot specify requirements for a problem that has not been scoped.
3. The SDLC plan goes into the proposal, as its plan of work, and stays with you as the project plan you track for the rest of the semester.
4. The UML diagrams turn the SRS into pictures of the system: who uses it, what it holds, how it behaves. They make up the complete UML set, and the use case diagram also appears in the SRS.
5. The architecture decides how the specified system will actually be built, and becomes the architecture design document.

Put as a chain: problem, then proposal, then SRS, then UML, then architecture. A guide who reads them in that order should find that each document answers the questions the one before it raised.

The thirty hours

MU allots 30 hours to Module 1. That is 30 hours for each student, because every student earns the 2 credits. A team of four has 120 hours for the design phase between them, and another 120 for the build.

Thirty hours sounds like a lot until it is spread over a semester of other papers. The worked team's plan, which Chapter 17 computes, finishes the four documents in the seventh week and holds its design review on the last day of it. Thirty hours in seven weeks is a little over four hours a week for each member, every week, and Chapter 18 shows that some weeks need more.

Two warnings from how students actually spend this time:

• The first two weeks decide the project. A problem chosen in a hurry in week one is defended for the rest of the semester. Chapter 3 is about choosing well.
• Documents take longer than they look. An SRS is not typed in an evening. It needs interviews first, and then several drafts, each read by someone else.

The worked project in this book

Every chapter of this book teaches an idea and then does it, on one complete project, so that you see the finished article and not only a description of it. The project runs from the first chapter on problems to the last question of the viva. Here it is.

The problem. At a degree college, the canteen serves lunch through one counter during a 40-minute break, from 12:30 to 13:10. Students queue to order and pay, then wait again while the food is prepared. Some give up and leave the queue without eating. Others eat and arrive late for the 13:10 lecture.

The team. Four TY B.Sc. (Computer Science) students: Aditi Kulkarni, who leads the team and owns the requirements and the documents; Farhan Shaikh, who owns the backend and the database; Sneha Nair, who owns the pages and how they look; and Rohan D'Souza, who owns testing, deployment and the Android build. Their guide is Prof. S. Iyer. The canteen is run on contract by its owner, Lata Pawar, and its counter by Ganesh More.

The solution they arrive at. An application called Canteen Pre-order. Students order lunch from their phones before the break and choose a ten-minute pickup slot. The counter sees the orders slot by slot and moves each one through placed, being prepared, ready and collected. Students pay at the counter when they collect. The owner manages the menu, sets each day's stock, and reads the day's sales.

How it is built. With Node.js and the Express framework on the server, a MySQL database, and plain HTML, CSS and JavaScript in the browser, which is the stack MU's own earlier papers taught: Web Technologies, MEAN Stack Development and the database papers. An Android app wraps the same pages for students who prefer an app. Chapter 26 explains why each choice was made, and what would change for a project built in PHP, Django, the MERN stack or native Android.

How much of it the book shows. All of it. Every document is written out in Module 1's chapters. Every file of the application, every test, every configuration file, is printed in full in Module 2's chapters, and every terminal session printed in this book was run on a real Ubuntu machine against that exact code, with its output copied from the screen.

The story is fictional. The people, the college and the canteen are invented. The numbers about the canteen, such as how many students left the queue each day, are the worked team's observations within the story, and the book never presents them as facts about any real college.

The one rule for using the worked project

Copy the method, never the project.

The worked project exists so that every idea in this book has a concrete, finished example. It is not a project for you to submit, and submitting it would fail in the ways Chapter 1 describes: at the code review, in the GitHub history, and at the demonstration, where an examiner can ask for a change made live.

Use it this way instead:

1. Read the idea in each chapter.
2. Read what the team did with it, and notice the decisions they made and why.
3. Do the same step for your own problem, using the task list at the end of the chapter.
4. Compare your version with theirs, and ask whether yours answers the same questions.

Your problem will be different from a canteen queue, and so will your requirements, your diagrams and your code. The questions each step asks will be exactly the same.

Working as a team

MU does not print a group size for this paper; your college decides it (Chapter 1). Most projects are done in small groups, and a group needs two things settled in the first week.

Who owns what. Ownership means one person is answerable for a piece of work being done and done well, not that they do it alone. The worked team split ownership by area, as above, and every member still wrote code and every member took part in every document review. Chapter 18 writes this down properly as a responsibility matrix.

Everyone must be able to explain everything. An examiner may ask any member about any part of the project. "Farhan did the database" is not an answer in a viva. Plan time for each member to walk the others through their part.

Do this for your project

1. Settle your group with your guide, and get the answers to Chapter 1's list of questions: group size, report format, assessment dates.
2. Agree who owns which area. Write it down.
3. Create a shared folder for your documents, and name every file with the document and its version, for example srs-v0.3.docx. Chapter 32 sets out the conventions.
4. Block about four hours a week, per person, for the next seven weeks, and expect some weeks to need more. Put them in your calendars now.
5. Read Chapter 3 before you choose a problem.

What it does not mean

The design phase is not "documentation for the sake of marks". Each document answers questions the builders would otherwise answer by guessing, one at a time, in code.

Module 1 is not finished when the documents are submitted. Requirements change as you build. The documents are updated when they do, and the version history in each shows it.

Following the worked project's stack is not required. It is one reasonable choice, explained in Chapter 26. Choose yours by the same reasoning.

Quick revision

• Module 1 is the design phase: MU's heading is "Problem Identification, Requirement Engineering & System Design Phase".
• Five topic rows: problem identification and feasibility; requirement engineering; SDLC planning; UML modelling; architecture design.
• Four deliverables: project proposal, SRS document, complete UML set, architecture design document.
• The documents build in order: problem, proposal, SRS, UML, architecture.
• 30 hours per student; a team of four has 120 hours for the design phase.
• The worked project, Canteen Pre-order, is fictional, complete, and printed in full. Copy the method, never the project.

Questions you must be able to answer

1. Why does Mini Project I begin with a design phase instead of with programming? Because a mistake in a document costs minutes to fix and the same mistake built into code, database and tests costs days. The design phase makes the expensive decisions while they are cheap, and gets them checked by people who know the problem, before anything is built on them.

2. Name the five topics of Module 1 and the four documents it ends in. Problem identification and feasibility study; requirement engineering; SDLC planning; system modelling using UML; system architecture design. The documents are the project proposal, the SRS document, the complete UML set and the architecture design document.

3. In what order are the Module 1 documents written, and why that order? Proposal, then SRS, then the UML set, then the architecture document, because each needs the one before it: requirements cannot be specified for an unscoped problem, the diagrams draw the specified requirements, and the architecture decides how the specified and modelled system is built.

4. Which internal marks depend on Module 1 alone? Problem Identification & Project Proposal, and System Design (SRS, UML Diagrams, Architecture): 10 of the guide's 20 marks.

5. Your group copies its design from a finished project online. What goes wrong? The design does not match the group's own problem, so the guide's questions about the problem and its stakeholders cannot be answered; and later the code review, the Git history and the live demonstration all expose work the group did not do.

Examples of the kind:

• A tuition class tracks fees in a notebook and cannot tell which students owe money until the month's end.
• A small clinic books appointments by phone, patients arrive together, and the waiting room overflows while the afternoon is empty.
• A print shop takes orders on WhatsApp, loses files in the chat, and prints the wrong version.
• A two-wheeler service centre writes job cards by hand, and customers phone repeatedly to ask whether the bike is ready.

Social

A social problem belongs to a community rather than to a business: a housing society, a neighbourhood, a group of volunteers, a public service. Nobody profits directly from solving it, which makes the people who have it glad of help and slow to fund it.

Examples of the kind:

• A housing society's water tanker bookings and maintenance complaints are managed through one overloaded WhatsApp group.
• A blood donors' group keeps donors in a spreadsheet and cannot quickly find who is eligible to donate again.
• A volunteer group teaching children on weekends schedules volunteers by phone and ends up with too many one week and none the next.
• A local library for senior citizens lends books through a register and cannot tell which books are overdue.

Institutional

An institutional problem belongs to an organisation such as a college, a school, a hospital's administration or a government office. For a student this is the most reachable kind of all, because you are inside an institution already: your own college.

Examples of the kind:

• Students queue at the college canteen for most of the lunch break.
• Computer lab slots for projects are booked on a paper sheet pinned to a door.
• Library reading-room seats are taken early and held all day with a bag.
• Lost items handed to the office sit in a drawer, and their owners never find out.
• Placement drives are announced on notice boards, and students miss the registration deadlines.

Where problems hide

Three signs point at a problem worth investigating, and you can look for them anywhere.

A register. Wherever people write information into a book by hand, somebody later has to search it, total it or copy it. Registers are slow to search and cannot remind anyone of anything.

A queue. Wherever people wait in line, time is being lost, usually because a request and its fulfilment happen at the same place at the same moment. Separating the two is often exactly what software does well.

A group chat carrying work. Wherever a WhatsApp group is being used as a booking system, a complaints desk or a task list, information is scrolling out of sight and nobody can see the current state of anything.

To find these signs, use your eyes and your questions:

• Observe. Go and watch a place at its busiest time for half an hour. Note what people wait for, what they write down, what they ask for twice.
• Ask one question. "What part of your day takes longer than it should?" asked of a shopkeeper, a clerk or a lab assistant will produce more real problems than an hour of browsing.
• Shadow. Follow one person through one task, from start to finish, and write down every step.
• Look at the paperwork. The forms, slips and registers a place uses tell you what information matters to it, and where it is copied by hand.

Is it the right size and shape for this paper?

Not every real problem suits a 60-hour project. Test each candidate against these questions before you commit to it.

A problem that fails one of these can sometimes be reshaped. A clinic problem that needs medical records can become an appointment problem that needs only names, times and phone numbers. A payment problem can become an ordering problem where payment stays at the counter. Reshaping a problem to fit the paper is good judgement, provided you say so honestly in your scope (Chapter 4).

A problem is not a solution

The commonest mistake at this stage is to start with an answer.

"We want to build an app for the canteen" is a solution. It says nothing about what is wrong. "Students spend most of their 40-minute lunch break queuing at the canteen counter" is a problem. It says who suffers, what the difficulty is, and it can be checked by going to look.

Keep the two apart for as long as you can, for two reasons. The first is that the problem, once stated properly, may suggest a better solution than the one you started with. The second is that your examiner will judge the solution against the problem, and a problem that was really a solution in disguise gives them nothing to judge it against.

What to leave alone

Some choices look attractive and go badly, and it is kinder to say so now.

A clone of a famous product. "An Amazon clone" or "a food delivery app like Swiggy" has no users you can reach and no problem you can observe. It also invites comparison with a product built by thousands of engineers.

A problem only you have. A project whose only user is its builder cannot be accepted by anyone else.

Anything that needs sensitive personal data. Health records, identity numbers and bank details carry legal duties you cannot meet as a student project, and your guide will rightly refuse them.

Anything that moves real money. Taking payments online needs a payment gateway account, and opening one needs business verification a student team does not have. Keep payment outside the system, as the worked project does.

A title from a list. Lists of project titles circulate every year. A title is not a problem, and the student who picks one has to invent every requirement.

Doing it properly: the ethics of looking

Watching people and asking them questions is research, and it carries simple duties.

• Ask before you observe or photograph in a place that is not public: the canteen owner, the librarian, the lab in-charge. Say it is a college project.
• Do not record who people are unless you must. Count people, time them, but do not write down names. A survey should not ask for names unless you need them.
• Tell people what it is for and that they can decline.
• Keep what you collect to what you need, and keep it private.

These duties also make your evidence better. People who know what you are doing and trust you give you straighter answers.

The worked project: how the team found its problem

In their first week, the four members of the worked team each listed problems they had seen, and then scored the list together against the table above. Nine candidates came out of it:

They then spent an hour at each shortlisted place, at its busiest time. The lab bookings turned out to be a nuisance, not a problem: the sheet on the door worked, and the lab assistant was content with it. The librarian did not want the reading room's rules changed. The canteen at lunch was plainly a problem, it happened every day, and the owner, Lata Pawar, was willing to talk.

So they observed it properly. For five days, Monday 3 to Friday 7 August 2026, one of them stood near the counter from 12:30 to 13:10 and counted two things: the students served, and the students who joined the queue and left it without buying anything.

That is 212 students served on an average day, and 31.2 walking away. They also timed 20 students a day, 100 in all, from the moment each joined the queue to the moment they had food in hand: the mean wait was 16 minutes, the median 15, the longest 27 minutes, which is two thirds of a 40-minute break.

They asked the owner's permission before they began, counted people without recording who they were, and did not photograph anyone.

At the end of the week they wrote the problem down in one paragraph, and deliberately did not mention software:

At our college canteen, students have a 40-minute lunch break and one counter serves them all. Students queue to order and pay, then wait again for the food. Over five days we counted 212 students served and 31 leaving the queue without buying on an average day, and timed waits of 16 minutes on average and up to 27 minutes. Students who stay are often late for the 13:10 lecture; students who leave go without lunch.

That paragraph is the seed of their problem statement, which Chapter 4 develops and justifies.

Do this for your project

1. Each member writes down five difficulties they have seen this month, in any of the three kinds. Aim for fifteen or more candidates as a group.
2. Score every candidate against the size-and-shape table. Reject honestly.
3. Shortlist three. Spend an hour at each, at its busiest time, and talk to the person in charge.
4. Choose one. Ask permission from the person in charge before you study it further.
5. Measure it for a few days: count, time, or tally whatever the difficulty costs.
6. Write it down in one paragraph that describes the problem and its evidence, and does not mention software.

Mistakes that cost marks

Choosing from a list of titles. The guide's first questions about users and evidence have no answers, and the proposal mark suffers at once.

Describing a solution as the problem. "The college needs an app" cannot be justified, only asserted.

No evidence. "Students face a lot of problems" is an opinion. "31.2 students a day left the queue without buying" is evidence.

Too big. A problem needing a dozen user types and months of work leads to a half-built project, and a half-built project scores worse than a small complete one.

Nobody to accept it. Without a real person who will say whether it works, acceptance testing (Chapter 54) cannot be done.

Quick revision

• A real-world problem: somebody has it now, somewhere you can go, it can be measured, and software can reduce it.
• MU's three kinds: industry (a business), social (a community), institutional (an organisation such as your college).
• Signs of a problem: a register, a queue, a group chat carrying work.
• Find problems by observing, asking, shadowing and reading the paperwork, not from lists of titles.
• Test for size and shape: reachable users, fits 60 hours, needs frontend, backend and database, data you may use, nothing unobtainable, someone to accept it.
• A problem is not a solution. State the difficulty first, without naming software.
• Ask permission, record no names you do not need, keep what you collect private.

Questions you must be able to answer

1. What is a real-world problem, in the sense this paper uses? A difficulty that real, identifiable people have now, in a setting the students can visit, which can be observed and measured, and which software can reduce by recording, calculating, sharing or checking information.

2. Distinguish industry, social and institutional problems, with an example of each. An industry problem belongs to a business and is usually measured in money or time, such as a clinic's phone bookings. A social problem belongs to a community, such as a housing society's complaints lost in a group chat. An institutional problem belongs to an organisation such as a college, such as students losing their lunch break in the canteen queue.

3. Why is "we will build a canteen app" not a problem statement? Because it names a solution and says nothing about what is wrong, for whom, or how much. The problem is the difficulty itself, such as students losing most of their break in the queue, and a solution can only be judged against a problem stated that way.

4. How did the worked team know their problem was real? They observed it on five consecutive days and measured it: an average of 212 students served and 31.2 leaving the queue without buying each day, and waits averaging 16 minutes and reaching 27 minutes in a 40-minute break.

5. Why did the worked team reject the tuition-class fees problem? Because it involved money and the personal data of minors, and they could reach only one class to test with. A student project cannot take on those legal duties, and one class gives too little to test against.

6. What ethical duties apply when you observe a problem? Ask permission before observing or photographing in a place that is not public, explain that it is a college project, record no personal details you do not need, and keep what you collect private.

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.

The affected parties. People who never log in can still be helped or harmed. In the worked project, the teachers of the 13:10 lectures never touch the system, and they are exactly the people who notice when students stop arriving late.

System stakeholders and project stakeholders

There is a second list, and it should be kept separate from the first.

The system's stakeholders are the people above: those with an interest in the software once it exists.

The project's stakeholders are those with an interest in the project as a piece of work: your team, your project guide, and the external examiner. They care about the process, the documents and the marks, not about using the system.

Both lists matter, but they matter differently. Requirements come only from the system's stakeholders. Your guide is not a canteen user, and a requirement that exists only because "the guide wanted it" should be questioned. The project's stakeholders shape how you work: the deadlines, the documents and the standard of evidence.

How to find them

Five ways to find stakeholders you would otherwise miss:

Follow the process. Write down every step from the beginning of the task to its end, and ask who does each step. Every name is a stakeholder.

Follow the data. For each piece of information the system will hold, ask who provides it, who reads it, and whose information it is.

Follow the money. Who pays for anything the system needs? Who earns more or loses less because of it?

Follow the approvals. Whose permission is needed to install it, to use the college's machines, to put a notice on the board, to use student email addresses?

Ask every stakeholder, "Who else should we talk to?" Each conversation ends with this question, and it is the one that finds the people you did not know existed.

The stakeholder register

The findings go into a stakeholder register: a table, kept up to date for the life of the project, with one row per stakeholder.

Name real people wherever you can. "Canteen staff" is a group; "Ganesh More, who runs the counter" is someone you can phone.

The power and interest grid

Stakeholders differ in how much they care and how much they can do about it, and they need different treatment. A common way to sort them is a grid of power, meaning their ability to decide or block, against interest, meaning how much the system affects them.

The grid is a tool for deciding how to involve people, not a ranking of whether they matter. The low-power, high-interest group is where most of your users live, and they decide whether the system is actually used.

The worked project: the stakeholder register

The worked team built its first register in the second week, following the process of a canteen lunch from the kitchen to the counter.

And, kept separate, the project's own stakeholders:

Placed on the grid:

The stakeholder they nearly missed

The team's first list had no kitchen on it. They had followed the process from the student's side: order, pay, wait, collect. The cooks were behind a wall and never met a student.

It was the question "Who else should we talk to?", put to Ganesh at the end of his interview, that found them. "Ask the cooks," he said. "They are the ones who run out."

The head cook's interview changed the design. Every morning the kitchen guessed how much of each dish to make, and the guess was often wrong in both directions: popular dishes ran out by 12:45, and the rest were thrown away. What the kitchen needed was not an app for students at all. It was a list, before the rush, of how many of each dish had been ordered for each pickup slot. That became a requirement of its own, the kitchen list (FR-16 in Chapter 10), and it is also what makes the owner's hope of less waste, from Chapter 4, possible.

A team that never talked to the kitchen would have built a system that reduced the queue and did nothing for the waste, and would not have known what it had missed.

Knowing your users: user classes

For the primary and secondary users, it helps to write a short description of each user class: a group of users who use the system in the same way and need the same things. These descriptions go straight into the SRS (Chapter 34), under "user classes and characteristics".

Notice how much design follows from this table before any design has been done. The counter screen must work without typing. The student pages must work on a phone on mobile data. The owner's pages can be denser, because the owner uses them at a quiet time.

Do this for your project

1. Walk through the process from start to end and list who does each step.
2. Follow the data, the money and the approvals, and add everyone you find.
3. Check the two forgotten groups: who will maintain it, and who is affected without using it.
4. Build the stakeholder register, with a named contact for each row.
5. Place each stakeholder on the power and interest grid, and write down how you will involve each one.
6. Write a user class table for your primary and secondary users.
7. End every interview with "Who else should we talk to?", and add whoever it names.

Mistakes that cost marks

Listing only "users" and "admin". Real systems have owners, approvers, maintainers and affected parties, and a guide will ask about each.

Mixing up the two lists. The guide and the examiner are stakeholders of the project, not of the system, and requirements do not come from them.

Groups with no names. "Staff" cannot be interviewed. A named contact can.

A register that is never used. The register is the plan for your interviews and your acceptance tests. If no row leads to an interview, a review or a test, it was written for decoration.

Quick revision

• A stakeholder is anyone who uses, runs, pays for, approves, maintains or is affected by the system.
• Kinds: primary users, secondary users, operators, owners, approvers, maintainers, affected parties.
• Keep the system's stakeholders separate from the project's (team, guide, examiner): requirements come only from the first.
• Find them by following the process, the data, the money and the approvals, and by asking "Who else should we talk to?"
• Record them in a stakeholder register; sort them on a power and interest grid to decide how to involve each.
• Describe each user class: how many, what they know, how and where they will use the system, what matters most.

Questions you must be able to answer

1. Define a stakeholder, and give four kinds with an example of each from a canteen system. A stakeholder is anyone with an interest in, influence over, or who is affected by the system. Primary users, the students who order; operators, the counter staff who run the day's orders; owners, the canteen owner who decides whether it is used; affected parties, the teachers whose students arrive on time.

2. Why keep the project guide off the system's stakeholder list? Because the guide's interest is in the project as a piece of academic work, not in using the system. Requirements must come from the people who will use, run or be affected by the software; a feature added only because the guide wanted it is not a requirement of the system.

3. What is a power and interest grid, and how is it used? A two-by-two grid placing each stakeholder by their power to decide or block and by how much the system affects them. It decides how each is involved: manage closely, keep satisfied, keep informed, or monitor. It does not decide whose needs matter.

4. How did the worked team find the kitchen staff, and what difference did it make? By asking the counter staff "Who else should we talk to?" at the end of his interview. The head cook's interview showed that the kitchen needed the number of each dish ordered for each pickup slot, which became the kitchen list requirement and made the reduction of wasted food possible.

5. What is a user class, and where is it written down? A group of users who use the system in the same way and have the same needs, described by how many there are, what they know, how and where they use the system and what matters most to them. User classes are written in the SRS under user classes and characteristics.

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.

Intangible benefits are real but cannot honestly be priced: time returned to people, less stress, better service, fewer mistakes, a better reputation. Measure them in their own units, such as hours or complaints, and do not force a rupee value on them.

Revenue is not benefit

This is the mistake to avoid. When a system helps a business sell more, the business does not gain the full price of each extra sale. It gains the profit on it: the price minus what the sale cost to make. A canteen that sells one more Rs 68 lunch has spent something on the ingredients, the gas and the cook's time, and gains only what is left.

Counting revenue as benefit makes every payback look several times faster than it is. The worked example below shows the mistake and then the corrected figure.

The measures

Cost-benefit analysis

Put the costs and the benefits side by side, over the same period, and compare. If benefits exceed costs over a period the owner cares about, the project is economically feasible.

Payback period

The payback period is the time the benefits take to repay the one-time cost:

It is the most useful single measure for a small system, because it answers the owner's real question: "how long before this has paid for itself?"

Return on investment, and money over time

For large projects running over years, analysts also compute the return on investment, the net gain as a percentage of the cost, and the net present value, which discounts money received in future years because a rupee next year is worth less than a rupee today. Both matter when payback takes years. When payback takes weeks, as it usually does for a well-chosen student project, they add little, and it is enough to say so.

Sensitivity: what if you are wrong?

Every benefit figure is an estimate. A careful analysis asks how the conclusion changes if the estimate is too optimistic, for example if only half the hoped-for benefit arrives. If the project is still worth doing under the pessimistic figure, the conclusion is robust. This is called sensitivity analysis, and one extra line of it makes a feasibility study far more convincing.

The worked project: economic feasibility

What the owner told them

In her interview (Chapter 4), the owner, Lata Pawar, gave the team four figures, all recorded as her estimates:

• the average lunch bill is Rs 68;
• her margin is about 25 per cent of the bill;
• about Rs 600 of food is thrown away on an ordinary day, measured at what it cost her to make;
• the canteen is open about 180 college days a year.

One-time costs

The development effort is recorded separately, in hours: 240 person-hours, 60 for each of the four members, as MU allots.

Running costs

Benefits: the first attempt, and what was wrong with it

Aditi's first draft of the benefits looked like this:

It gave a payback of 9,500 divided by 1,260.80, which is about 7.5 days. Farhan questioned the first line: the canteen does not keep Rs 68 from a sale, it keeps its margin. The first line was revenue, and the benefit is the profit.

Benefits: corrected

Half of the 31.2 students is 15.6 students a day. Each sale of Rs 68 at a 25 per cent margin leaves Rs 17 of profit.

The waste line was already right, because the Rs 600 was measured at cost: food not thrown away is money not spent.

Payback, and a year

So the tablet pays for itself within the 21st college day, a little over four weeks of college. Over a year of 180 college days, the benefit is 180 multiplied by 465.20, which is Rs 83,736, against a one-time cost of Rs 9,500.

The corrected payback is nearly three times longer than the first draft's, and it is still short. That is the honest conclusion, and it is the one that survives an examiner's question about margins.

Sensitivity

The team asked what happens if they are wrong about the recovered sales, and only a quarter of the students who leave today come back instead of half.

A quarter of 31.2 is 7.8 students a day, at Rs 17 of profit each, which is Rs 132.60. With the Rs 200 saved on waste, the benefit is Rs 332.60 a day, and the payback is 9,500 divided by 332.60, about 28.6 days. Still within six weeks of college. The conclusion does not depend on the optimistic figure.

Intangible benefits

The team left all four unpriced. Thirty-six hours of students' time a day is a striking number without a rupee sign beside it.

Verdict: economically feasible. For a one-time cost of Rs 9,500 and no running cost, the canteen gains an estimated Rs 465.20 a day, paying back within about four weeks of college days, and within six weeks even if only a quarter of the lost sales return.

Do this for your project

1. Ask the owner of the problem for the figures you need, and record each as their estimate: prices, margins, volumes, days of operation, what the problem costs them now.
2. List one-time costs and running costs, each with a note of where the figure came from.
3. Record the development effort in hours; do not invent a rate for it.
4. List tangible benefits in rupees, as profit or saving, never as revenue, and intangible benefits in their own units.
5. Compute the payback period, and a year's benefit.
6. Redo the payback with a pessimistic benefit, and say whether the verdict survives.
7. End with a one-sentence verdict that states its conditions.

Mistakes that cost marks

"Economically feasible because the software is free." It answers whether the students can afford to build it, not whether the owner should adopt it.

Revenue counted as benefit. The most common arithmetic error in feasibility studies, and an examiner who spots it will doubt every other figure.

Invented figures. A cost or rate with no source, dropped in to make a table look complete, weakens the real figures around it.

Intangibles given a price. "Student satisfaction worth Rs 50,000" is a guess dressed as a number.

No pessimistic case. A conclusion that depends on everything going well is a hope.

Quick revision

• Economic feasibility compares costs with benefits.
• Costs: one-time (development, hardware, software, setup, training) and running (hosting, network, maintenance, paid services).
• Record student effort in hours; do not invent a rate.
• Benefits: tangible in rupees, intangible in their own units.
• Revenue is not benefit: count the profit on extra sales, and savings at cost.
• Payback period = one-time cost divided by benefit per period.
• Sensitivity analysis: redo it with a pessimistic benefit; a robust verdict survives.

Questions you must be able to answer

1. Distinguish one-time costs from running costs, with an example of each for a canteen system. One-time costs are paid once to bring the system into use, such as a tablet bought for the counter; running costs are paid for as long as it is used, such as rented hosting or paid SMS messages.

2. Why is the price of a recovered sale not the benefit of recovering it? Because the business spent money to make what it sold. Its gain is the profit, the price less the cost of making the sale. Counting the full price overstates the benefit and makes the payback look far quicker than it is.

3. Compute the worked project's payback period, and explain each figure. The one-time cost is Rs 9,500 for the counter tablet. The daily benefit is Rs 265.20 of profit on 15.6 recovered sales, at Rs 17 each, plus Rs 200 of food no longer wasted, a total of Rs 465.20. Payback is 9,500 divided by 465.20, about 20.4 days.

4. What is sensitivity analysis, and what did it show for the worked project? Recomputing the result with a less favourable estimate to see whether the conclusion still holds. With only a quarter of the lost sales recovered, the benefit falls to Rs 332.60 a day and the payback rises to about 28.6 days, so the project remains worthwhile.

5. Why did the worked team not put a rupee value on the time returned to students? Because there is no honest price for a student's time, and a guessed figure would be a false precision that weakens the real figures. They measured it in its own unit instead: about 36 hours of students' time a day.

Before and after: the most useful table in the study

The clearest way to answer question 1 is a table of the process before and after.

For the worked project:

Two decisions are visible in the table, and both came from studying operations rather than technology.

Walk-in sales continue. Four of the 180 students surveyed had no smartphone with internet, and some students will not be on the college Wi-Fi. The system does not replace the counter; it takes pre-ordered lunches out of the queue, which shortens the queue for everyone else too.

The stock in the system is the owner's allocation for pre-orders. The kitchen cooks for walk-in customers as well. So each morning the owner decides how many portions of each dish to offer for pre-order, and enters that number as the day's stock. When it is gone, the dish shows as sold out in the app and is still sold at the counter while it lasts.

The worked project: operational feasibility

Users' ability. Students use phones all day (Chapter 5's user classes). The counter staff member, Ganesh More, uses a phone but little else; so every counter action is a single large button, and nothing needs typing during the break. The owner uses the system in the morning and evening, at quiet times.

Willingness, and the concerns the team heard:

When things go wrong:

Support after the semester. The IT lab in-charge agreed to keep the machine on during college hours and to restart it if needed. The team writes a server guide for him (Chapter 60) and a user manual for the owner and the counter (Chapter 67).

Management support. The owner agreed to a two-week trial. The principal's office agreed after a letter and a short demonstration, on condition that only college email addresses may register.

Training. One half-hour session at the canteen with the owner and the counter staff, and a one-page guide taped beside the counter.

Verdict: operationally feasible, with walk-in sales continuing beside it, the owner allocating stock for pre-orders each morning, and the IT in-charge supporting the machine.

Two more questions: is it lawful, and is there time?

MU names three kinds of feasibility. Two more are often added, and a careful study answers both, because either can stop a project on its own.

Legal feasibility

Ask what the system collects about people, and what the law requires of whoever runs it. For most student projects the relevant law is about personal data.

India's Digital Personal Data Protection Act, 2023 (No. 22 of 2023) defines personal data as "any data about an individual who is identifiable by or in relation to such data", and calls the person who "determines the purpose and means of processing of personal data" the Data Fiduciary. For the worked project that is whoever runs the system: the canteen owner.

The Act is coming into force in stages. By a notification of 13 November 2025 (G.S.R. 843(E)), its main obligations, in sections 3 to 17, including notice, consent and the general obligations of a Data Fiduciary, come into force eighteen months after that date, which is 13 May 2027; one sub-section of section 6, about consent managers, comes in a year after the notification. A system built now should nevertheless be designed to meet them, because it will still be running then. Two of those obligations shape the worked project directly. Section 8(5) requires a Data Fiduciary to "protect personal data in its possession or under its control ... by taking reasonable security safeguards to prevent personal data breach", and section 8(7) requires personal data to be erased once "the specified purpose is no longer being served".

Until then, the Information Technology Act, 2000 already applies. Its section 43A makes a "body corporate", which its Explanation defines to include a "sole proprietorship or other association of individuals engaged in commercial or professional activities", liable to pay compensation if it is negligent in "implementing and maintaining reasonable security practices and procedures" for sensitive personal data. The rules made under it in 2011 list the first kind of sensitive personal data as a password.

So the law, as it stands and as it is coming, points the same way for a system like this:

• collect only what the purpose needs: the worked project stores a name, a college email address, a password hash and the orders, and nothing else, no phone number and no payment details;
• tell users what it is for: the registration page says what is stored and why;
• protect it with reasonable security: passwords are stored only as salted hashes (Chapter 46), access is by role, and the server is reached over the college network only;
• do not keep it longer than needed: orders older than the current term can be deleted by the owner, and accounts of students who leave can be removed.

The team also needed permission to use the college's machine and its email domain, which is a matter of the college's rules rather than the law, and they had it in writing.

This book explains what the texts say so that you can design responsibly; it is not legal advice, and a system handling personal data for real should have its legal position checked by someone qualified.

Schedule feasibility

Can the project be finished in the time available? Chapter 17 computes the worked team's schedule: 65 working days of work on the longest chain of tasks, against a semester of 15 weeks, which is 74 working days once the Gandhi Jayanti holiday on 2 October is taken out. That leaves 9 working days of slack for college events, examinations in other papers, and the things that go wrong. Feasible, with a margin, though not a large one.

The feasibility report

MU's first Course Outcome for this paper asks you to "prepare structured project documentation including SRS and feasibility reports". The feasibility report is where the findings of Chapters 6, 7 and 8 come together. It is short, because it summarises; the working stays in your notes.

A dependable structure:

1. The problem: the problem statement from Chapter 4.
2. The proposed solution, in a paragraph, and the alternatives considered.
3. Technical feasibility: the verdict, the stack, the key conditions.
4. Economic feasibility: costs, benefits, payback, sensitivity.
5. Operational feasibility: the process before and after, concerns and answers, support.
6. Legal and schedule feasibility.
7. Risks: the most serious ones, with mitigations.
8. Recommendation: go ahead, go ahead with conditions, or do not go ahead.

Three to five pages is plenty. Much of it will be reused in the project proposal (Chapter 33), which is why it is worth writing well.

The worked project: the feasibility report

Feasibility Report: Canteen Pre-order. Version 1.0, 19 August 2026. Prepared by Aditi Kulkarni, Farhan Shaikh, Sneha Nair and Rohan D'Souza. Guide: Prof. S. Iyer.

1. The problem. Students have a 40-minute lunch break and one canteen counter at which they both order and wait. Over five days 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. In a survey, 131 of 180 students said the queue makes them late for the 13:10 lecture at least once a week. The owner estimates that about Rs 600 of food is thrown away each day because the kitchen cannot know demand in advance.

2. Proposed solution and alternatives. A web application, with an Android app, through which students order before the break for a ten-minute pickup slot and pay at the counter on collection; a counter screen for the day's orders; a kitchen list; and the owner's menu, stock and daily report. Alternatives considered and rejected: a second counter (cost of staff), paper tokens (ordering still queues), a shared online form (no stock control or status), a general delivery platform (built for delivery, not collection).

3. Technical feasibility. Feasible with Node.js, Express and MySQL, which all four members have used, on a lab desktop running Ubuntu 24.04, reached over the college Wi-Fi, whose signal we confirmed throughout the canteen. Estimated peak about 7 orders a minute; we will test at 100 in a minute. Conditions: the Linux deployment is practised by week 8, and ordering is made safe when many students order the last portions at once.

4. Economic feasibility. One-time cost Rs 9,500, for a tablet at the counter; no running cost. Estimated benefit Rs 465.20 a day: Rs 265.20 of profit on half the lost sales at the owner's 25 per cent margin, and Rs 200.00 of food not wasted. Payback about 20 days of college; about 29 days if only a quarter of lost sales return. About 36 hours of students' time returned daily, unpriced.

5. Operational feasibility. Fits the canteen with two decisions: walk-in sales continue, and the owner allocates each dish's pre-order stock every morning. Concerns of the counter, the kitchen and the owner are answered in the design. The IT lab in-charge supports the machine; one training session and a one-page guide for the counter.

6. Legal and schedule feasibility. We store only a name, a college email address, a password hash and orders, with no payment data. Passwords are sensitive personal data under the Information Technology rules of 2011, and are stored only as salted hashes; the design follows the obligations of the Digital Personal Data Protection Act, 2023 that come into force on 13 May 2027. The college has permitted the use of its machine and email domain. The schedule needs 65 working days of the 74 available.

7. Main risks. Linux deployment inexperience (practise early); simultaneous orders for the last portions (safe stock updates, tested); Wi-Fi failure at lunchtime (walk-in fallback); students who order and do not come (recorded; policy for the college).

8. Recommendation. Proceed, on the conditions in sections 3 and 5, with a two-week trial agreed with the owner.

Do this for your project

1. Write the process before and after, step by step, with the people who do each step.
2. Take the table to the users and ask what worries them. Record each concern and what your design does about it.
3. List what can go wrong in operation, and what happens then.
4. Name who will run and support the system after the semester.
5. List the personal data you will store, and cut anything the purpose does not need.
6. Check the schedule against the weeks you have.
7. Write the feasibility report in eight short sections, and end with a recommendation.

Mistakes that cost marks

Operational feasibility answered in one line. "Users will find it easy to use" is an assumption. The before-and-after table and the list of concerns are evidence.

A system that replaces a process everyone relies on, with no fallback when it fails.

Personal data collected because a form had room for it. Every field you store is a field you must protect.

Treating a law as in force when it is not, or as irrelevant because it is not yet in force. Say what applies now and what is coming, and design for both.

A report with no recommendation. A feasibility study exists to reach a decision.

Quick revision

• Operational feasibility: fit with the process; users' ability; users' willingness; what happens when things go wrong; who runs and supports it; management support; training.
• The before-and-after process table is the core evidence.
• Resistance comes from people who lose something; record their concerns and answer each in the design.
• Legal feasibility: the personal data held and the law on it. DPDP Act 2023: sections 3 to 17 in force from 13 May 2027 (G.S.R. 843(E)); until then IT Act s.43A and the 2011 rules, which count a password as sensitive personal data.
• Schedule feasibility: the longest chain of work against the weeks available.
• The feasibility report: problem, solution and alternatives, technical, economic, operational, legal and schedule, risks, recommendation.

Questions you must be able to answer

1. What does operational feasibility assess, and why can a technically sound system fail it? Whether the system fits the organisation's processes and will be accepted, used and supported by its people. A technically sound system fails it when it disrupts how people work, makes someone's busiest moment harder, has no fallback when something fails, or has nobody to look after it.

2. How does a before-and-after process table help? It shows every step that the system changes, and therefore every place where someone must change their work. Each changed step is a point to check with the people who perform it, and the table reveals decisions such as keeping walk-in sales beside pre-orders.

3. Why does the worked project let walk-in sales continue? Because some students have no smartphone with internet, some will not be on the college Wi-Fi, and the system must not fail the canteen when the network fails. Pre-ordering takes orders out of the queue; it does not replace the counter.

4. Which law applies today to the passwords the worked project stores, and which is coming? Today, section 43A of the Information Technology Act, 2000, which requires reasonable security practices for sensitive personal data, and the 2011 rules under it, which list passwords as sensitive personal data. Coming, the Digital Personal Data Protection Act, 2023, whose sections 3 to 17, including the Data Fiduciary's duty to take reasonable security safeguards, come into force on 13 May 2027.

5. List the sections of a feasibility report. The problem; the proposed solution and the alternatives considered; technical, economic and operational feasibility; legal and schedule feasibility; the main risks with their mitigations; and a recommendation.

Elicitation: getting requirements out of people

"Elicit" means to draw something out. The word is chosen deliberately: requirements are rarely handed over in finished form. People know their work, not your system, and they describe problems and habits, not requirements. Your job is to draw the requirements out of what they say and do.

The techniques

No single technique is enough. Interviews tell you what people think happens; observation tells you what does happen; documents tell you what is supposed to happen. Where the three disagree, you have usually found something important.

Running an interview well

Most student interviews fail in one of three ways: no preparation, questions that suggest their own answers, and no record. A good interview has a shape.

1. Prepare. Know who you are meeting and what you need from them. Write eight to twelve questions, most of them open.
2. Open with their work, not your system. "Walk me through a normal lunch break at the counter" produces requirements. "Would you like an app?" produces politeness.
3. Ask for examples. "Tell me about the last time an order went wrong." A real example carries detail no general answer does.
4. Ask about exceptions. "What happens when a dish runs out? When a student disputes an order? When the power fails?" Exceptions are where systems break.
5. Do not design in front of them. Listen; the design comes later.
6. End with two questions. "Is there anything I should have asked and did not?" and "Who else should we talk to?" (Chapter 5).
7. Write up the same day, while you remember, and send the key points back to the person to check.

Recording what you hear

Every candidate requirement goes into one list, one row each, with enough information to trace it and argue about it later.

The source column is the one students leave out and examiners ask about. "Where did this requirement come from?" should always have an answer with a name and a date.

Analysis: turning notes into requirements

Raw notes contain duplicates, contradictions, wishes, solutions dressed as requirements, and gaps. Analysis cleans them up.

• Merge duplicates. Three people said the menu should show prices; that is one requirement with three sources.
• Separate problems from solutions. "The counter needs a buzzer" is a solution. The requirement underneath it is "the student must know when the order is ready".
• Resolve conflicts. When two stakeholders want incompatible things, the conflict goes to the person with the authority to decide, usually the owner, and the decision is written down with its reason.
• Find the gaps. For every action a user can take, ask what happens when it fails, and whether anybody else needs to know about it.
• Classify each as functional, non-functional, constraint or assumption.

Validation: checking with the people who know

Validation asks: is this the right system? It is done by putting the written requirements in front of the stakeholders and asking them to confirm or correct them. (Its partner, verification, asks whether the system was built to the requirements; that is testing, in Module 2.)

The usual way is a review: a meeting in which the stakeholders and the team walk through the requirements one by one. Before the review, check each requirement against a short list of qualities. A good requirement is:

• clear: one meaning only, to every reader;
• testable: somebody could design a test that it passes or fails;
• necessary: a stakeholder needs it, and you know who;
• feasible: it can be built with the time, skills and technology available;
• consistent: it does not contradict another requirement;
• complete: it says what happens in the exceptions, not only in the normal case;
• traceable: it has an identifier and a source.

A requirement that fails one of these is rewritten before the review, not during it.

Management: change and traceability

Requirements change. The owner changes her mind; a test reveals a case nobody thought of; a constraint turns out to be negotiable. That is normal. What is not acceptable is change that nobody records.

Two tools keep change under control.

A baseline and a version history. Once the requirements are agreed, that version is the baseline. Every later change is made in a new version, with a line in the document's version history saying what changed, why, and who agreed. Chapter 32 sets out the format.

A requirements traceability matrix. A traceability matrix is a table that links every requirement to where it came from and to everything built from it: the use case, the design element, the code, the test. It answers two questions an examiner can ask of any system:

• Forward: "This requirement: where is it implemented, and how do you know it works?" Follow the row to the right.
• Backward: "This screen, this table, this test: which requirement is it for?" Follow the columns back to the left. An element with no requirement behind it is either missing a requirement or should not exist.

The matrix is started now, with sources and requirements, and grows a column at each later stage.

The worked project: requirement engineering

Elicitation

In the two weeks after the observation of Chapter 3, the worked team held these sessions:

The survey of 180 students (Chapter 4) was already in hand, and so was the observation itself.

An extract of the notes, and what became of it

From Aditi's write-up of session 2, checked with Ganesh the next morning:

During the rush Ganesh takes money with one hand and passes plates with the other. He said he would never type anything at the counter between 12:30 and 13:10. The worst moments are when a student insists they ordered something they did not, and when two students claim the same plate. He wants to see only the orders for the next few minutes, not the whole day. When a student does not come, the food is sold to someone else at the end of the break.

Four candidate requirements came out of that paragraph: every counter action must be a single tap (a non-functional requirement, NFR-7 in Chapter 11); each order needs a number the student can quote (FR-11); the counter must be able to show one slot at a time (FR-14); and an order must be markable as not collected (part of FR-15).

Analysis: one conflict, settled

In session 1, the owner asked whether students could pay in the app, so that nobody could order and not pay. In session 4, four of the six students said they would not put money into an app run by a canteen. The survey had 124 of 180 preferring to pay at the counter.

The team did not decide this themselves. They took both views to the owner, with the survey numbers, and explained that online payment needs a payment gateway account the project cannot open (Chapter 4). She agreed to leave payment at the counter for this release. The decision went into the list as a rejected requirement with its reason and her name, and online payment went into the out-of-scope table.

The first requirements list, and the traceability matrix begun

After analysis, seventeen functional requirements survived, FR-1 to FR-17, set out in full in Chapter 10. The first two columns of the traceability matrix, with the use case column the next chapters add, looked like this:

Every row has a source. Chapter 35 adds the design column, and Chapters 54 and 55 add the tests.

Validation

On 25 August the team walked the owner and Ganesh through the draft SRS at the canteen, after the lunch break. Two changes came out of it. The head cook, invited at Ganesh's suggestion, asked for the cut-off to be 15 minutes before each slot rather than the 10 the draft said, because ten minutes was not enough to cook a biryani; FR-8 was changed and the change recorded in the version history. And the owner asked that an order not collected should not return its food to the stock, because that food had been cooked; that became part of FR-15 and of the rules in Chapter 43.

Do this for your project

1. Plan your sessions: who, when, which technique. Use at least three techniques.
2. Prepare open questions for each interview; always ask about exceptions, and end with "who else?".
3. Write up each session the same day and send the key points back to be checked.
4. Put every candidate requirement in one list with an ID, a source and a kind.
5. Analyse: merge, separate problems from solutions, send conflicts to the person who can decide, and record the decision.
6. Start the traceability matrix with a source for every requirement.
7. Hold a validation review with the stakeholders, and record every change it makes.

Mistakes that cost marks

Requirements with no source. "Where did this come from?" deserves a name and a date.

Asking stakeholders to design. "What buttons do you want?" gets opinions about screens; "tell me about the last time something went wrong" gets requirements.

Deciding conflicts yourselves. The team does not own the problem. The owner does, and her decision, recorded, protects you when it is questioned.

Skipping validation. An SRS nobody outside the team has read is a guess about what they need.

Changes made silently. A requirement changed without a version note makes the traceability matrix and the tests wrong without anyone knowing.

Quick revision

• Requirement engineering = elicitation, analysis, specification, validation, management.
• Kinds: functional, non-functional, constraint, assumption; a business rule usually becomes a functional requirement.
• Elicitation techniques: interview, questionnaire, observation, document study, workshop, prototype; use several.
• Record each candidate with an ID, statement, source, kind, priority, status.
• Validation asks "is this the right system?"; verification asks "was it built right?".
• A good requirement is clear, testable, necessary, feasible, consistent, complete, traceable.
• The traceability matrix links sources to requirements to use cases, design, code and tests, forward and backward.

Questions you must be able to answer

1. Name the activities of requirement engineering and what each produces. Elicitation, which produces notes and a list of candidate requirements; analysis, which produces a cleaned, classified and conflict-free list; specification, which produces the SRS; validation, which produces requirements the stakeholders have reviewed and approved; and management, which produces a version history and a traceability matrix.

2. Why is observation needed as well as interviews? Because interviews report what people believe happens and observation shows what actually happens, including actions people do without noticing and would never mention. Where the two disagree, there is usually an important requirement.

3. What is the difference between validation and verification? Validation checks that the requirements describe the system the stakeholders actually need: building the right thing. Verification checks that the system as built meets its requirements: building the thing right, which is what testing does.

4. What is a requirements traceability matrix, and what do forward and backward traceability mean? A table linking each requirement to its source and to the use case, design, code and tests that realise it. Forward traceability follows a requirement to its implementation and tests; backward traceability follows any design element, code or test back to the requirement that justifies it.

5. How did the worked team settle the question of paying in the app? The owner wanted online payment and most students did not. The team took both views and the survey figures to the owner, explained that a payment gateway account was not obtainable, and she decided to keep payment at the counter. The decision was recorded with its reason and her name, and online payment was placed out of scope.

6. Turn "the counter needs a buzzer" into a requirement. The buzzer is a solution. The requirement beneath it is that a student must be able to know when the order is ready, which the worked project meets by showing each order's status on the student's orders page, refreshed at least every 15 seconds.

Other words to hunt for: appropriate, adequate, user-friendly, flexible, efficient, as required, and/or, if possible, normally.

Business rules belong inside

A business rule is a rule of the organisation the system must enforce. Rules like "orders for a slot close 15 minutes before it" or "at most 5 of one item" are not decoration; they are exactly what a tester checks and exactly where the application can be wrong. Write them inside the requirement they govern, with their numbers.

User stories and acceptance criteria

Agile teams often write requirements as user stories:

As a student, I want to order lunch before the break, so that I do not lose my break in the queue.

A user story names who wants something, what, and why. It is a good way to start a conversation, and a poor way to end one, because it leaves out the rules. So each story carries acceptance criteria: concrete conditions that must hold for the story to be done. A common form is given, when, then:

Given the pickup slot 12:40, whose cut-off is 12:25,

when a student tries to order for it at 12:25,

then the order is refused with the message that ordering for 12:40 has closed.

For an SRS in this paper, write the shall-statement form: it is what an examiner expects, and it reads as a specification. Add acceptance criteria in the given, when, then form wherever a rule could be misread. They double as test cases in Module 2 (Chapter 55).

Organising the list

Group the requirements by what the user is trying to do, not by screen and not by the order you thought of them. A group per feature area makes gaps visible: an area with a create but no cancel, or a list but no way to change what is listed.

The worked project: the functional requirements

The worked team's specification, as it stood after the validation review of 25 August. Every rule in it is enforced by the application you will see in Module 2, which is why the numbers are so exact.

Accounts

FR-1. Register. The system shall let a person create a student account by giving a name of 2 to 80 letters, an email address at the college's own domain, and a password of 8 to 128 characters. It shall refuse an email address at any other domain, and an email address that already has an account. (Source: the principal's office, whose condition was that only college addresses may register; the survey.)

FR-2. Sign in and sign out. The system shall let a registered user sign in with their email address and password, keep them signed in for 8 hours or until they sign out, and let them sign out. When the email address or the password is wrong, it shall give the same message for both.

FR-3. Counter staff accounts. The system shall let the owner create a counter staff account with a name, an email address and a password.

The menu

FR-4. Today's menu. The system shall show anyone, signed in or not, today's menu: for each item its name, category, price, whether it is vegetarian, and whether it can be ordered now. An item with fewer than 10 portions left shall show how many are left; an item with none left shall show as sold out.

FR-5. Menu items. The system shall let the owner add a menu item, giving its name, category, price and whether it is vegetarian; change an item's price; and put an item on or take it off today's menu.

FR-6. Today's stock. The system shall let the owner set, for each item, the number of portions offered for pre-order today, from 0 to 1,000.

Ordering

FR-7. Place an order. The system shall let a signed-in student order one or more items that can be ordered now, from 1 to 5 of each item and no more than 10 items in all, for one pickup slot.

FR-8. Pickup slots. The system shall offer the pickup slots 12:30, 12:40, 12:50 and 13:00, on the canteen's own clock, and shall stop accepting orders for each slot 15 minutes before it.

FR-9. Stock. The system shall not accept an order for more of any item than is left, and shall reduce each item's stock by the quantity of every order it accepts. If any item of an order cannot be supplied, no part of the order shall be accepted.

FR-10. One order per slot. The system shall allow a student at most one active order, meaning placed, being prepared or ready, for each pickup slot.

FR-11. Order number. The system shall give each accepted order a number, and show it to the student as soon as the order is accepted.

FR-12. My orders. The system shall show a signed-in student their own orders for today, with each order's number, slot, items, total and status, and shall refresh the status at least every 15 seconds while the page is open.

FR-13. Cancel an order. The system shall let a student cancel their own order while its status is placed, and shall return its items to the stock.

The counter and the kitchen

FR-14. The counter's list. The system shall show counter staff and the owner today's orders, all together or for one chosen slot, with each order's number, the student's name, the items, the total and the status.

FR-15. Moving an order on. The system shall let counter staff and the owner move an order from placed to being prepared, from being prepared to ready, and from ready to collected or to not collected, and shall refuse every other change of status. An order marked not collected shall not return its items to the stock.

FR-16. The kitchen list. The system shall show counter staff and the owner, for a chosen slot today, the total quantity of each item in orders that are placed or being prepared.

FR-16 is worth a note. It was not on the team's first list at all. It exists because the counter staff sent the team to the kitchen, and the head cook explained that what the kitchen needs is not an app but a count of each dish per slot before the rush (Chapter 5).

The owner

FR-17. Daily report. The system shall show the owner, for today or any chosen date, the number of orders in each status, and the quantity and takings of each item in collected orders, with the day's total takings.

Acceptance criteria for the rules most easily misread

The team wrote given, when, then criteria for the four rules that caused the most discussion at validation:

Look at the FR-9 row. It says the thali is not taken when the biryani fails. That sentence is easy to miss and hard to build: it needs the database to treat the whole order as one unit that succeeds or fails together, which is what Chapter 45 builds and tests.

Do this for your project

1. Group your candidate requirements by what the user is trying to do.
2. Write each as "The system shall...", one behaviour per statement, naming who acts.
3. Put every limit and condition inside the requirement, with its number.
4. Hunt for the ruinous words (fast, easy, manage, etc., appropriate) and rewrite each.
5. Remove anything that is a design decision, and move anything about "how well" to your non-functional list.
6. Number them FR-1 onward, and never reuse a number.
7. Write given, when, then criteria for every rule a reader could misunderstand.

Mistakes that cost marks

A list of screens instead of behaviours. "Login page, menu page, cart page" says nothing about what happens on them.

Missing the unhappy paths. A requirement for ordering with nothing about sold-out items, closed slots or duplicates specifies half a system.

Requirements the code does not meet. An examiner who reads your SRS and then uses your application notices the difference. Update the requirement or the code, and record which.

Design in the requirements. "Using a MySQL table" in a requirement ties it to one implementation.

Unnumbered requirements. Without identifiers they cannot be traced, prioritised or tested.

Quick revision

• A functional requirement is one behaviour: input, processing with its rules, output.
• Form: "The system shall...", one behaviour, the actor named, the rules and numbers inside, testable, numbered, with a source.
• Banned words: fast, easy, manage, etc., appropriate, user-friendly, and/or.
• Business rules go inside the requirements they govern.
• User stories (as a... I want... so that...) start conversations; acceptance criteria (given, when, then) make them testable.
• Group by what the user is trying to do; a group with a create and no cancel shows a gap.

Questions you must be able to answer

1. What distinguishes a functional requirement from a non-functional one? A functional requirement states what the system does, a behaviour with an input, processing and an output. A non-functional requirement states how well the system does it, such as its speed, security, usability or compatibility.

2. Rewrite "Users can manage orders" as proper requirements. It hides two different behaviours by two different users: "The system shall let a student cancel their own order while its status is placed", and "The system shall let counter staff move an order from placed to being prepared, from being prepared to ready, and from ready to collected or not collected, and shall refuse every other change of status."

3. Why should a requirement not say how it will be built? Because the requirement is what the user needs and should stay true whatever the design. Tying it to a design decision, such as a particular database table, makes the requirement wrong whenever the design changes, and hides the actual need.

4. What are acceptance criteria, and write one for the worked project's cut-off rule. Concrete conditions that must hold for a requirement or story to be satisfied, often written as given, when, then. Given the slot 12:40 with its cut-off at 12:25, when a student orders for it at 12:25, then the order is refused because ordering for 12:40 has closed.

5. Why is FR-9's last sentence the hardest part of it to build? Because refusing the whole order when any item cannot be supplied means the stock taken for the earlier items must be put back automatically. The database must treat the order as a single transaction that either succeeds completely or leaves nothing changed.

Turning a quality into a requirement

A quality becomes a requirement when you can answer five questions about it:

1. Which quality? Name the characteristic.
2. Measured how? Seconds, per cent, taps, pixels, attempts, hours.
3. To what target? The number that separates pass from fail.
4. Under what conditions? How many users, on what device, over what network, at what time.
5. Verified how? Which test, in which chapter of your plan, will prove it.

Watch the difference:

Two details in the first testable row matter. "95 per cent" instead of "all" admits that at a moment of load a few requests will be slower, and sets a limit on how many. "On the lab server" fixes the conditions: the same system is faster on a powerful machine and slower on a weak one, so a performance requirement without its conditions cannot be checked.

Borrow numbers from standards

For some qualities, somebody has already done the hard work of choosing testable numbers, and you should use theirs rather than inventing your own.

Accessibility has the Web Content Accessibility Guidelines, WCAG 2.2, a W3C Recommendation. Its success criteria are precise:

Each of these is a requirement you can quote, with a number, and test. Level A is the minimum; level AA is the level most organisations aim for.

Password storage has the OWASP Password Storage Cheat Sheet, which Chapter 31 uses. Performance has no universal standard number, so your target must come from your own problem, as the worked team's did from its load estimate in Chapter 6.

The worked project: non-functional requirements

The worked team went down the ISO list and wrote twelve requirements. Every one says how it will be verified, and every one was verified; the last column says where.

Some notes on how they arrived at these.

NFR-1 is the load estimate of Chapter 6 made into a promise. The team estimated a peak of about 7 orders a minute and set the requirement at 100, about fourteen times more, because the estimate might be wrong and the cost of a slow rush is high.

NFR-2 came from a question nobody asked in an interview. Ganesh had said two students sometimes claim the same plate. Farhan asked what happens if they both press Place order for the last portion at the same instant. The answer depends entirely on how the stock is updated, and the requirement makes sure somebody tests it.

NFR-7's 320 pixels is WCAG's number, not the team's. Their first draft said 360, the width of a common phone. Reading WCAG 2.2, they found SC 1.4.10 sets 320, and adopted it: a published number is easier to defend than a guessed one.

The team measured NFR-8 before writing it. They computed the contrast of every text colour in their stylesheet with the formula WCAG gives for relative luminance, and the weakest pair, the red of an error message on white, was 6.47:1, comfortably above 4.5:1. A requirement you already know you meet is a strong one to put in front of an examiner.

Safety was considered and left out, in writing. Nothing the canteen system does can put a person or property in danger, and the SRS says so under safety, so the reader knows the question was asked.

Do this for your project

1. Go down the nine ISO/IEC 25010 characteristics. For each, write a requirement or a sentence saying why none is needed.
2. For each requirement answer the five questions: quality, measure, target, conditions, verification.
3. Take numbers from standards where they exist: WCAG 2.2 for accessibility, the OWASP cheat sheets for security.
4. Take performance numbers from your own load estimate, with a margin.
5. Add a "verified in" column and make sure your test plan in Module 2 contains every test it names.
6. Where you can, measure before you promise.

Mistakes that cost marks

Adjectives instead of numbers. Fast, secure, reliable, user-friendly, scalable: none is testable without a number and a condition.

A target with no conditions. "Within 1 second" on what machine, with how many users?

A non-functional requirement no test ever checks. It is a claim in the SRS the examiner can ask you to demonstrate.

Security as one line. Security is several different requirements about passwords, sessions, access and attack, each tested differently.

Accessibility forgotten. Many examiners now ask about it, and WCAG 2.2 gives you ready-made, testable requirements.

Quick revision

• A non-functional requirement says how well; it needs a number and a way to verify it.
• ISO/IEC 25010:2023 has nine characteristics: functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability, flexibility, safety. The 2011 edition had eight.
• Five questions: which quality, measured how, to what target, under what conditions, verified how.
• Borrow numbers: WCAG 2.2 (contrast 4.5:1, reflow at 320 CSS px, targets 24 by 24 CSS px, keyboard, labels); the OWASP cheat sheets for security.
• Performance targets come from your own load estimate, with a margin.
• Every requirement has a "verified in" entry that leads to a real test.

Questions you must be able to answer

1. Distinguish functional and non-functional requirements with one example of each from the worked project. A functional requirement states a behaviour: the system shall let a student cancel their own order while it is placed. A non-functional requirement states how well the system behaves: with 100 students ordering in the same minute, 95 per cent of menu and order requests are answered within 1 second.

2. What is ISO/IEC 25010, and how is it used when writing requirements? The international standard that defines a product quality model for software; its 2023 edition has nine characteristics, each with sub-characteristics. It is used as a checklist: for each characteristic the team either writes a measurable requirement or records why none is needed.

3. Rewrite "the system should be user-friendly" as testable requirements. For example: a one-item order takes no more than 4 taps from the menu page; every page is usable at 320 CSS pixels wide without sideways scrolling; every input has a visible label; every counter action is a single tap.

4. Why does NFR-1 say 95 per cent and name the lab server? Because under load a few requests are always slower, so the requirement limits how many may be, and because performance depends on the machine and the load, so a target without its conditions cannot be tested or reproduced.

5. Which WCAG 2.2 success criteria did the worked project adopt, and what does each require? 1.4.3, text contrast of at least 4.5:1; 1.4.10, no two-dimensional scrolling at 320 CSS pixels wide; 2.5.8, pointer targets of at least 24 by 24 CSS pixels; 2.1.1, all functions operable from a keyboard; and labels for every input, as 3.3.2 requires.

Writing one out

A use case can be written at three levels of detail. A brief use case is one paragraph. A casual one is a few paragraphs of story. A fully written one follows a template, and it is the form to use for the important and complicated goals of your project:

The heart is the main success scenario: the steps of the path where nothing goes wrong, written in plain sentences, each saying who does what. Then comes the valuable part, the extensions: for each step, what else could happen, and what the system does then. Numbering an extension after its step, 3a, means "instead of step 3 going as written".

Write the steps as what happens, not how the screen looks. "The student chooses the items and quantities" survives a redesign of the menu page. "The student taps the orange plus button beside the item" does not.

Two relationships between use cases

When use cases share behaviour or add to each other, UML offers two relationships. They are drawn in Chapter 20, but they are decided here.

Include. When the same steps occur in two or more use cases, they can be written once as a use case of their own, which the others include. The included steps always happen as part of the including use case.

Extend. When a use case adds optional behaviour to another at a particular point, under a condition, it extends that other use case. The extended use case makes complete sense without the extension; the extension only makes sense inside it.

Use both sparingly. A use case model with arrows everywhere is usually a flowchart in disguise. The worked team found one genuine extension and no genuine inclusion, and said so.

The worked project: the use cases

Actors and goals

The worked team had three human actors, from Chapter 5's user classes: Student, Counter staff and Owner. The owner can do everything the counter staff can, and more; in UML terms the owner is a specialisation of the counter staff actor, which Chapter 20 draws as an arrow with a hollow triangle.

The list

All seventeen functional requirements appear in the last column, and every use case realises at least one. That two-way check is the first thing the team's guide asked about.

UC-4 Place an order, fully written

Primary actor: Student. Goal: to order lunch for a pickup slot, and know the order number. Preconditions: the student is signed in. At least one item can be ordered and at least one slot is open. Trigger: the student opens the menu page.

Main success scenario:

1. The system shows today's menu, and the pickup slots that are still open with their cut-off times.
2. The student chooses one or more items and a quantity of each, and a pickup slot.
3. The student asks the system to place the order.
4. The system checks that the slot is still open, that the student has no active order for that slot, and that there is enough of every item left.
5. The system takes each item from the stock, records the order as placed, and gives it a number.
6. The system shows the student the order number and the slot.

Extensions:

• 2a. The student chooses more than 5 of one item or more than 10 items in all: the menu page will not let the quantity go higher. If a request arrives anyway, the system refuses it, naming each problem.
• 3a. The student has lost their connection: the page says it cannot reach the canteen server and the order is not placed. The student tries again.
• 4a. The slot has closed since the page was opened: the system refuses the order and says ordering for that slot has closed. The student chooses another slot and returns to step 3.
• 4b. The student already has an active order for this slot: the system refuses, saying so. The student chooses another slot, or keeps the existing order.
• 4c. An item has been taken off today's menu: the system refuses the order, naming the item.
• 4d. Fewer portions of an item are left than were asked for: the system refuses the whole order, saying how many are left, or that the item is sold out, and nothing is taken from the stock. The student changes the order and returns to step 3.
• At any step. The student's sign-in has expired: the system refuses the order and asks the student to sign in again.

Postconditions (success): the order is recorded as placed for the chosen slot and today's date, the stock of each item is reduced by its quantity, and the student has the number. Requirements: FR-7, FR-8, FR-9, FR-10, FR-11; NFR-1, NFR-2.

Read extension 4d again. It is FR-9's hardest sentence from Chapter 10, told as a story, and it will become a test in Chapter 53 in which a thali is ordered with too much biryani and the thali's stock is checked afterwards.

UC-6 Cancel an order, and the one extension

Primary actor: Student. Goal: to cancel an order the student no longer wants, before the kitchen starts on it. Preconditions: the student is signed in and viewing their orders (UC-5); the order is theirs and is placed.

Main success scenario:

1. The student asks to cancel the order.
2. The system asks the student to confirm.
3. The student confirms.
4. The system marks the order cancelled and returns its items to the stock.
5. The system shows the order as cancelled.

Extensions:

• 3a. The student changes their mind: the order is kept.
• 4a. The counter has started preparing the order since the page was loaded: the system refuses, saying the order is being prepared and can no longer be cancelled.

Cancelling happens only from the list of one's own orders, and only when an order is still placed. It is optional behaviour added to UC-5 at one point, under one condition. That is exactly what the extend relationship means, and it is the only one in the worked team's model: UC-6 extends UC-5.

They looked for an include and did not find a real one. Signing in is needed before most use cases, and some textbooks draw that as an include. The team treated it as a precondition instead, because signing in is a goal in its own right (UC-2), not a shared fragment of other goals, and wrote that reasoning into the SRS.

UC-8 Update order status, briefly

The counter staff member, seeing an order in the list for the current slot, moves it to its next status with a single tap: placed to being prepared, being prepared to ready, ready to collected when the student pays, or ready to not collected at the end of the break. The system refuses any other change, such as placed straight to ready, and says why. An order marked not collected does not return its food to the stock.

The team wrote UC-8 as a brief use case because its rules are already exact in FR-15. A fully written version would have repeated them.

Do this for your project

1. List the actors from your stakeholder register. Remember external systems, if any.
2. List each actor's goals, and name one use case per goal, verb first.
3. Check the level of each: satisfying in one sitting, neither a single click nor a whole job.
4. Map use cases to functional requirements, both ways.
5. Write the two or three most important use cases fully, extensions included. Brief versions are enough for the simple ones.
6. Decide include and extend relationships honestly; prefer a precondition to a doubtful include.

Mistakes that cost marks

Use cases that are screens. "Menu page", "Admin panel" are places, not goals.

Use cases that are steps. "Validate quantity" and "Check stock" have no actor who would call them a goal.

No extensions. A use case with only its happy path has specified the easy half.

Interface details in the steps. A redesign should not make a use case wrong.

Include and extend used as flowchart arrows. They are relationships between goals, not the order in which things happen.

Quick revision

• An actor is a role outside the system: a human, hardware or another system.
• A use case is one goal, yielding an observable result of value to an actor.
• Find them from actors and their goals; one use case per goal; check the level.
• A fully written use case: ID and name, primary actor, goal, preconditions, trigger, main success scenario, extensions numbered after their steps, postconditions, requirements.
• Include: shared behaviour always inserted. Extend: optional behaviour added at a point, under a condition.
• Every functional requirement is realised by some use case, and every use case realises some requirement.

Questions you must be able to answer

1. What is a use case, and how do you tell a use case from a step? A specification of how the system and an actor interact to achieve one of the actor's goals, yielding an observable result of value to that actor. A step, such as checking the stock, is not observable or valuable to the actor on its own; a use case, such as placing an order, ends with a result the actor wanted.

2. What is the main success scenario, and what are extensions? The main success scenario is the numbered sequence of steps when everything goes right. Extensions describe what else can happen at particular steps, alternatives and failures, numbered after the step they replace, such as 4a, together with how the system responds.

3. Distinguish include from extend, with an example. An include inserts shared behaviour that always happens as part of the including use case, used when two or more use cases share steps. An extend adds optional behaviour to another use case at a particular point under a condition; in the worked project, cancelling an order extends viewing one's orders, when the order is still placed.

4. Why did the worked team not draw sign-in as an include? Because signing in is a goal in its own right with its own use case, and it happens before the other goals rather than as a shared fragment inside them. It was written as a precondition of the other use cases instead.

5. What does extension 4d of UC-4 require, and how will it be tested? That when any item has too few portions left, the whole order is refused and nothing is taken from the stock. It is tested by ordering a thali together with more biryani than is left, checking the order is refused, and checking that the thali's stock is unchanged.

Won't Have this time. Requirements everyone has agreed will not be delivered in this release. They are written down all the same, so that they are not quietly slipped back in later, and so that nobody is surprised by their absence.

Two points about MoSCoW are often missed.

It is about effort, not only about counting. DSDM recommends that the Must Haves take no more than about 60 per cent of the effort of a project, and that around 20 per cent of the effort be Could Haves. A project whose Musts take 90 per cent of the time has no room for anything to go wrong.

It applies to a timeframe. "Won't have this time" means not in this release, not never. A requirement can be a Must for the project as a whole and a Should for its first increment.

Who decides

Value is decided by the person who owns the problem, here the owner of the canteen. Effort and risk are estimated by the team. A priority is agreed between them, and it must respect dependencies: if a Must cannot work without a Should, that Should is really a Must.

Two other techniques worth knowing

Value against effort. Draw a two-by-two grid: value to the stakeholders up the side, effort to build along the bottom. High value and low effort are quick wins, to do first. High value and high effort are major pieces, to plan carefully. Low value and low effort fill spare time. Low value and high effort are not worth doing.

Hundred-point allocation. Give each stakeholder 100 points to spread across the requirements however they like. The totals rank the requirements by how much people actually care, and they reveal disagreements between stakeholders that a meeting might smooth over.

Both are useful for sorting within a MoSCoW group, or for settling an argument about one.

The worked project: prioritising

Estimating the effort

Before they could check the 60 per cent guidance, the worked team needed an effort for each requirement. Farhan and Rohan estimated each one in person-hours to build and test, from their experience of the Express projects of Semester 4:

The first attempt, and what was wrong with it

The team sat with the owner, asked the Must question of each requirement, and produced this:

Each Must passed the test. Without registration (FR-1), the owner would have to create two thousand accounts. Without the stock (FR-6 and FR-9), the system would promise food that did not exist. Without the counter's list and its status changes (FR-14 and FR-15), the counter could not serve anyone. Each Should had a workaround: staff accounts could be created once by the team, the menu could be entered by the team, and the owner could count sales from slips as she does now.

But 46 of 64 hours is 71.9 per cent Must Have, and there were no Could Haves at all. Their guide, Prof. Iyer, pointed out what that meant: every hour of the plan was committed, and the first thing to go wrong would eat into a Must.

The second attempt

The team had in fact wanted three more features, and had never written them down because they were "extras". They added them, as Could Haves, with estimates:

Now the whole picture:

The Musts are now 59.0 per cent of the effort, just under DSDM's 60, and the Coulds give about 18 per cent of contingency. Nothing about the Musts changed. What changed is that the plan now had room to absorb trouble, and the room was written down.

Won't Have this time

The out-of-scope list of Chapter 4 became the Won't Haves, each with its reason: online payment, SMS alerts, a penalty for students who do not collect, delivery to classrooms, more than one canteen, and the stock of raw materials.

What happened, and the first release

The first release, the version that must exist for the canteen trial, is the Must Haves: 46 hours. The Should Haves were planned to follow within the same semester.

In the event, all the Musts and all the Shoulds were built. Of the Coulds, none was: the time went instead on making the stock rule safe when many students order at once (Chapter 45), which took longer than its 6-hour estimate. That is exactly what the Coulds were for, and the final report lists all three as the first items for a future release.

Prioritising non-functional requirements

Non-functional requirements are usually floors rather than features: a password is stored safely or it is not. Most are therefore Must Haves, and they are prioritised by checking that each is really needed at the level stated. An accessibility target is not dropped when time is short; a performance target of 100 students a minute might be relaxed to 50 if the evidence says 7 is the real peak, but only by a recorded decision.

Do this for your project

1. Estimate the effort of each requirement in hours, to build and to test.
2. With the owner of the problem, ask of each: what happens if this is not delivered? Sort into Must, Should, Could and Won't Have this time.
3. Check dependencies: a Should that a Must needs becomes a Must.
4. Add up the effort. If the Musts are well over 60 per cent, or there are no Coulds, you have no contingency: reconsider.
5. Write down the Won't Haves with their reasons.
6. Mark the first release: the Musts.
7. Keep the list. Every change of priority later gets a line in the version history.

Mistakes that cost marks

Everything is a Must. It means nothing was prioritised, and the plan has no contingency.

No Won't Haves. The scope has no written edge.

Priorities set by the team alone. Value belongs to the owner of the problem; a team that decides it alone is guessing.

Priorities without effort. Without hours, the 60 per cent check cannot be made.

Coulds quietly built first, because they are fun, while a Must waits. It happens, and it is visible in the Git history.

Quick revision

• Prioritise because time and people are fixed; scope is what flexes.
• MoSCoW: Must Have, Should Have, Could Have, Won't Have this time.
• Must = the "Minimum Usable SubseT"; the test is "what happens if this is not delivered?"
• DSDM's guidance: Musts at most about 60 per cent of effort, Coulds about 20 per cent as contingency.
• Value is the owner's to decide; effort and risk are the team's to estimate; dependencies can promote a Should.
• Other techniques: value against effort, hundred-point allocation.
• The first release is the Musts.

Questions you must be able to answer

1. What does MoSCoW stand for, and how do you decide whether a requirement is a Must? Must Have, Should Have, Could Have and Won't Have this time. A requirement is a Must when the answer to "what happens if it is not delivered?" is that there would be no point using the system; if any workaround exists, it is a Should or a Could.

2. Why is a project with 90 per cent of its effort in Must Haves at risk? Because there is no contingency. When anything goes wrong, the only work left to drop is a Must, so the project fails its own minimum. DSDM recommends keeping Must effort to about 60 per cent and around 20 per cent in Could Haves.

3. Why write down Won't Haves at all? So that the scope has a clear edge, stakeholders are not surprised by what is missing, and the items are not quietly reintroduced later. "This time" also records that they may come in a later release.

4. Show the worked team's corrected effort split. Must Haves 46 hours, Should Haves 18 and Could Haves 14, a total of 78. That is 59.0 per cent Must, 23.1 per cent Should and 17.9 per cent Could, against the first attempt's 71.9 per cent Must with no Could Haves at all.

5. What happened to the worked team's Could Haves, and was that a failure? None was built, because the time went on making concurrent ordering safe, which took longer than estimated. That is not a failure: Could Haves exist precisely to be dropped so that Musts and Shoulds are finished, and they are recorded as the first items of a future release.

Recording an assumption properly means answering four questions about it:

1. Why do we believe it? The evidence, if any.
2. What happens if it is false? The consequence for the system and its users.
3. How and when will we check it? A test, a question to someone, an observation during a trial.
4. Who owns it? One team member responsible for checking it.

An assumption with no evidence and a severe consequence is not really an assumption. It is a risk, and it belongs on your risk list with a mitigation (Chapter 6).

Dependencies

A close relative is the dependency: something the project needs from someone outside the team. The college's machine, the IT in-charge's time to set it up, the owner's agreement to a trial. List them beside the assumptions; each is an assumption that another person will do something.

When an assumption turns out false

It happens, and what matters is what you do next:

1. Record it: which assumption, when it was found false, how.
2. Assess the impact: which requirements, designs or plans relied on it.
3. Decide: change the design, change the requirement, add a workaround, or accept the limitation, and say who decided.
4. Update the documents, with a version note, so the SRS stops asserting something untrue.

The worked project: constraints

C-7 needs a comment, because by the test above it looks like a decision. The team could have chosen PHP. What made it a constraint is the other half: the team could not have chosen a technology none of them knew and still finished in 60 hours each. They recorded the skills limit as the constraint and the stack as the decision it led to.

The worked project: assumptions

A-2 is a risk, and the team said so

Consider A-2 closely, because it shows why assumptions must be taken seriously.

The system keeps one number per item: the portions left for pre-order. Orders reduce it; cancellations raise it; the owner sets it each morning. Nothing in the first release resets it overnight. So if the owner forgets one morning, the system starts the day with whatever was left the evening before: perhaps 12 portions of Veg Biryani that the kitchen has no plan to cook.

The team found this while writing the table above, when they asked "what if it is false?" of A-2. They had three options: reset every item to zero at midnight, which would make the menu look sold out every morning until the owner acted; record the date with each stock figure and treat an old figure as zero, which needed a change to the database design; or keep the design, and guard the assumption. With the design already under review, they chose the third for the first release: the owner's morning routine in the user manual (Chapter 67) begins with setting the stock, and the counter staff check it at 11:00. The limitation, and the date-stamped stock as its proper fix, are written into the SRS and into the final report's future work.

That is an honest outcome. An examiner who asks "what happens if the owner forgets?" gets an answer that shows the team thought about it, knows the weakness, and knows the fix.

A-5, and the price of hard-coding

A-5 exposed a smaller design decision. The pickup slots, 12:30 to 13:00, are written into the application's code as a fixed list. If the college changes its timetable, a developer must change the code. The team kept it that way, because the break had been the same for years and a settings page would have cost hours of a tight plan, and they recorded the consequence beside the assumption. Chapter 43 shows exactly where that list lives.

Do this for your project

1. List your constraints under the seven kinds, each with its source. Apply the test: could we change it by deciding differently?
2. List your assumptions: about users, the environment, other people's actions, the future.
3. For each assumption answer: why we believe it, what if it is false, how and when we check it, who owns it.
4. Move any assumption with no evidence and a severe consequence to the risk list.
5. Ask "what if it is false?" of each one against your own design. Expect to find at least one weakness; record what you decide.
6. List your dependencies on people outside the team.

Mistakes that cost marks

Constraints with no source. They read as excuses.

Decisions disguised as constraints. "We must use MySQL" invites the question "says who?".

Assumptions nobody checks. An assumption without a check and an owner is a hope.

Hiding the weakness an assumption reveals. Examiners ask "what if?" questions; a recorded limitation with a known fix is a good answer, and silence is not.

Quick revision

• Constraint: a limit set from outside the team (time, money, technology, law, standards, the organisation, interfaces). Test: could we change it by deciding? If yes, it is a decision.
• Assumption: believed true, not proved, relied upon. Record why believed, what if false, how checked, who owns it.
• An assumption with no evidence and a severe consequence is a risk.
• Dependency: something the project needs from someone outside the team.
• When one proves false: record, assess, decide, update the documents.

Questions you must be able to answer

1. Distinguish a constraint from an assumption, with an example of each. A constraint is a limit the project must work within, set from outside, such as the requirement that the code be kept on GitHub. An assumption is something taken to be true without proof, on which the project relies, such as that the owner will enter each day's stock before 11:00.

2. How can you tell a constraint from a design decision? Ask whether the team could change it by deciding differently. If it could, it is a decision; choosing MySQL was a decision. If it could not, because someone outside the team imposes it, it is a constraint, such as the college allowing only its own machine.

3. What four things should be recorded for each assumption? The evidence for believing it, the consequence if it is false, how and when it will be checked, and who owns the checking.

4. What weakness did the worked team find by examining assumption A-2, and how did they handle it? That the stock figures are never reset overnight, so if the owner forgets to set the day's stock, yesterday's leftover numbers are offered to students. For the first release they guarded the assumption with the owner's morning routine and an 11:00 check by the counter, and recorded the limitation and its proper fix, date-stamped stock, in the SRS and the final report.

5. What should a team do when an assumption proves false during the project? Record when and how it was found false, assess which requirements, designs or plans depended on it, decide on a change, a workaround or an accepted limitation with the name of whoever decided, and update the documents with a version note.

Agile in one paragraph

The Manifesto for Agile Software Development, written in 2001, sets out four values. Its authors prefer individuals and interactions to processes and tools, working software to comprehensive documentation, customer collaboration to contract negotiation, and responding to change to following a plan. It adds, in its own words, "while there is value in the items on the right, we value the items on the left more". The manifesto does not reject documentation or plans; it ranks them below working software and change.

Scrum in one paragraph

Scrum is an agile framework, defined by its authors in the Scrum Guide. The Scrum Guide of 2020 describes a Scrum Team of one Product Owner, one Scrum Master and the Developers, typically ten or fewer people. Work happens in Sprints, fixed-length cycles of one month or less. Each Sprint begins with Sprint Planning, has a Daily Scrum of fifteen minutes for the Developers, and ends with a Sprint Review, to inspect what was produced and decide what next, and a Sprint Retrospective, to improve how the team works. The work waiting to be done is the Product Backlog, an ordered list that changes as the team learns.

How to choose

Ask these questions of your own project. Each answer points towards some models and away from others.

Notice the tension in a Mini Project. MU wants four design documents at the end of Module 1, which is a waterfall-shaped demand: design before build. But the requirements will certainly change once users see the system, and the semester's end is fixed, which are agile-shaped facts. Pure waterfall ignores the second; pure Scrum ignores the first.

Most mini projects are best served by a hybrid: a planned design phase that produces MU's documents, followed by incremental building in short, fixed cycles, each ending in a working version shown to the users and the guide. That is not a failure to choose. It is the honest answer to the question, and it is exactly what the worked team chose.

The worked project: the choice and its reasons

The worked team wrote this in its project proposal:

We will use an incremental model in two stages. In the design stage (27 July to 10 September), we will complete the requirements, the UML set and the architecture, because MU requires these documents at the end of Module 1 and because our requirements come from stakeholders we can meet only a few times. In the build stage (from 11 September), we will build the system in two increments of two weeks, each ending in a working version that we show to the canteen owner and to our guide, followed by testing, deployment and documentation. We chose this over a waterfall model because the owner and the counter staff will understand what they need only when they use a working system, and over pure Scrum because the design documents are required at a fixed date and our stakeholders cannot attend frequent meetings.

And the increments, planned from the priorities of Chapter 13:

Increment 1 contains Must Haves, because if everything after it went wrong, it alone would still let the canteen take pre-orders. That is the practical meaning of delivering the most important part first. The team made one exception on purpose: FR-10, a Should, is checked inside the same database transaction as the stock rule, two statements in code that was being written anyway, so it was built with it (Chapter 45).

Borrowing from Scrum without pretending to be Scrum

The team took four Scrum practices that fit a student team, and said openly that they were not running Scrum:

• A backlog: the prioritised requirements list of Chapter 13, kept as issues in the team's GitHub repository (Chapter 56).
• A short stand-up, fifteen minutes after the Tuesday lecture each week instead of every day, because they are students with other papers: what each did, what each will do, what is blocking them.
• A review at the end of each increment, with the owner at the canteen after the lunch break.
• A retrospective at the same meeting: what went well, what to change.

They did not have a Scrum Master or a Product Owner in the Scrum Guide's sense. Aditi acted as the owner's representative within the team, because the owner could meet only at the end of each increment.

What the choice bought them

At the first increment review, on 24 September, Ganesh tried the counter screen during a real lunch break. New orders appeared on it only when the page was reloaded, and during the rush he never had a free hand to reload it. The team made the counter's list refresh itself every ten seconds in Increment 2, before anything else had been built on top of the counter screen, and recorded the change in the SRS. In a waterfall project, he would have seen the screen for the first time in late October.

Do this for your project

1. Answer the six questions in the table for your own project.
2. Choose a model; most mini projects will choose a design phase followed by short increments.
3. Write the choice and its reasons in two or three sentences, naming the models you rejected and why.
4. Plan the increments from your priorities: the first increment should be Must Haves only and should work on its own.
5. Decide which practices you will use: backlog, stand-up, review, retrospective. Put the meetings in your calendar.
6. Put the choice in your proposal (Chapter 33) and your plan (Chapter 17).

Mistakes that cost marks

"We used waterfall" with no reasons. The choice itself is less important than the reasoning; the guide will ask why.

Claiming Scrum without its parts. Saying "agile" while holding no reviews and keeping no backlog is easily exposed in a viva.

Increments that are layers. "Increment 1: the database; increment 2: the backend; increment 3: the frontend" delivers nothing usable until the end, which is a waterfall with extra steps. An increment is a working slice of the whole system.

No review with users. An increment nobody outside the team sees has lost its main benefit.

Quick revision

• An SDLC model decides the order, the overlap and the number of cycles of the development activities.
• Waterfall (once through, sequential); incremental (working pieces added in turn); prototyping (build to learn); spiral (risk-driven cycles); RAD (rapid, user-intensive); agile (short fixed cycles, working software, adapting plans).
• Scrum: Product Owner, Scrum Master, Developers (typically 10 or fewer); Sprints of one month or less; Sprint Planning, Daily Scrum of 15 minutes, Sprint Review, Sprint Retrospective; Product Backlog.
• For a mini project: a design phase for MU's documents, then short increments of working software, the first containing only Musts.
• Choose by: requirement stability, fixed deadline, customer availability, size and risk, document obligations, team experience.

Questions you must be able to answer

1. What does an SDLC model decide? The order in which the development activities happen, how much they overlap, and how many times the project cycles through them: once from start to finish, or repeatedly, delivering more each time.

2. Why is pure waterfall risky for a mini project? Because the users first see the working system at the end, when there is no time left to correct misunderstandings, and requirements for a real problem almost always change once users see something working.

3. Why did the worked team not use pure Scrum? Because MU requires the proposal, SRS, UML set and architecture document at a fixed point at the end of Module 1, and because the canteen owner could not attend frequent reviews. They used a design phase followed by two-week increments, borrowing a backlog, stand-ups, reviews and retrospectives.

4. What is an increment, and why should the first contain only Must Haves? A working slice of the whole system that can be used and reviewed. The first contains only Must Haves so that, if everything later went wrong, the system would still do what is essential.

5. Give one thing the worked team's choice of model allowed them to find early. At the first increment review, the counter staff member found that new orders appeared only when the page was reloaded, which he had no free hand to do during the rush. The list was made to refresh itself every ten seconds in the second increment, before other work depended on the counter screen.

Deliverables, not activities, at the upper levels. Name the upper elements with nouns: "SRS", "Application", "Deployment". A WBS is a breakdown of what is produced, not a list of how it is produced; the how comes in the schedule. Work packages may be phrased as things to produce, "the use case diagram", or as outcomes, "unit tests passing".

Mutually exclusive. A piece of work appears in exactly one place. If the database schema appears under both Design and Application, it will be estimated twice or, worse, done twice.

Small enough, and no smaller. A work package should be small enough that one person can estimate it with confidence and finish it without losing track. Many project managers keep work packages between about a day and two weeks of effort. A student team working a few hours a week scales that down: a work package of between two and twenty hours is about right. Anything bigger hides uncertainty; anything smaller turns the plan into a to-do list.

One owner each. Every work package has one person answerable for it. Others may help.

The WBS dictionary

A diagram shows the structure but not the detail. The WBS dictionary is a table that says, for each work package, what exactly it is:

The "done when" field is the most useful and the most often left empty. "SRS written" is not a criterion; "SRS v1.0 reviewed with the owner, changes made, and approved by the guide" is.

Three ways to draw it

A top-down chart, the classic picture: the project in a box at the top, deliverables in a row beneath it, work packages hanging below each. Clear on paper, and very wide.

A sideways tree: the project on the left, deliverables in a column to its right, work packages to their right. It shows the same structure and stays narrow however many deliverables there are, which suits a report and a phone screen alike.

An outline, numbered and indented, usually as a table with the estimates beside each work package. The least pretty, and the easiest to add up and to keep up to date.

A good WBS document has a picture and an outline: the picture to understand it, the outline to use it.

The worked project: the WBS

The worked team drew its WBS as a sideways tree, in PlantUML, and kept the source in its repository so that anyone could change it and draw it again:

Figure 16.1 The worked team's work breakdown structure: seven deliverables and twenty-eight work packages

This is the source of that figure:

@startmindmap wbs
* Canteen\nPre-order
** 1 Management
*** 1.1 Proposal
*** 1.2 Plan
*** 1.3 Reviews
** 2 Requirements
*** 2.1 Survey
*** 2.2 Interviews
*** 2.3 SRS
** 3 Design
*** 3.1 UML set
*** 3.2 Schema
*** 3.3 API
*** 3.4 Wireframes
*** 3.5 Architecture
** 4 Application
*** 4.1 Frontend
*** 4.2 Backend
*** 4.3 Database
*** 4.4 Security
*** 4.5 Errors
*** 4.6 Reviews
** 5 Testing
*** 5.1 Unit
*** 5.2 Integration
*** 5.3 System
*** 5.4 Load, security
** 6 Deployment
*** 6.1 Local
*** 6.2 Server
*** 6.3 APK
*** 6.4 GitHub
** 7 Documents
*** 7.1 Report
*** 7.2 Manual
*** 7.3 Presentation
@endmindmap

The source uses PlantUML's mind map form, whose branches grow sideways. PlantUML also has a form made for WBS charts, which starts with @startwbs and draws the classic top-down chart; the team tried it first, and with seven deliverables it came out nearly three times as wide as it is tall, too wide for their report's pages.

The outline, with estimates

Hours are person-hours of effort. Module 1's deliverables come first, then Module 2's, each module totalling the 120 hours that four students at MU's 30 hours each have for it.

The two modules together are 240 hours, which is exactly four students at 60 hours each: the 100 per cent rule applied to time. If the work packages had added up to 300, the plan would have been promising work nobody had hours for.

Meetings are work

The team's first outline had no hours for its own stand-ups, which Chapter 15 set at fifteen minutes every Tuesday. That is seven meetings in Module 1 and six in Module 2, and four people at each. With the reviews held with the guide and the owner, meetings come to 12 hours in each module, a tenth of its time. Time spent is part of the work whether or not anyone plans it, so the 100 per cent rule put the meetings in the WBS, as 1.3 and 4.6. The hours came from trimming other estimates, never from adding hours nobody had.

Checking it against Chapter 13

In Chapter 13 the team estimated 64 hours to build and test the seventeen functional requirements. In the WBS those features live in five work packages: frontend 18, backend 16, database 10, authentication and validation 12, and unit tests 8, which add up to 64. The two estimates agree because they were made together.

The rest of Module 2's hours are work no single requirement owns: error handling across the whole application, the reviews and stand-ups, integration, system, load and security testing, deployment and the documents. This is the work students leave out when they estimate from the feature list alone, and the reason their plans run out of time.

The Could Haves of Chapter 13 have no work package on purpose. They are contingency: built only if other work finishes early, which in the event it did not.

An extract of the WBS dictionary

Do this for your project

1. Put the project at the top and MU's deliverables beneath it: proposal, requirements, design, application, testing, deployment, documents.
2. Break each down until every piece can be estimated, owned by one person and recognised as finished.
3. Check the 100 per cent rule: nothing missing (meetings, reviews, testing, deployment), nothing counted twice, nothing out of scope.
4. Number every element and never reuse a number.
5. Estimate every work package in hours; check that the total fits your team's hours.
6. Write the WBS dictionary, with a real "done when" for each work package.
7. Draw it in a form that fits your report, and keep the outline for daily use.

Mistakes that cost marks

A WBS of activities. "Coding", "Testing", "Meeting" at the top level is a to-do list with no structure of deliverables.

Forgotten work. No meetings, no reviews, no testing, no deployment, no documents: the most common gaps, all caught by the 100 per cent rule.

A WBS that does not add up. Estimates totalling far more than the team's hours are a plan that cannot happen.

Work packages with no owner, or with "all" as the owner, which in practice means nobody.

"Done when" left empty, so nothing can ever be shown to be finished.

Quick revision

• A WBS is a deliverable-oriented, hierarchical breakdown of all the project's work.
• The bottom level is the work package: estimated, owned by one person, recognisable as done.
• The 100 per cent rule: the WBS holds all the scope's work and nothing else; parts add up to their parent.
• Upper levels are deliverables (nouns); elements are numbered (2, 2.3, 2.3.1); each piece of work appears once.
• The WBS dictionary gives each work package a description, deliverable, done when, owner, estimate and dependencies.
• The WBS feeds the estimate, the schedule, the resource plan, progress tracking and risk.

Questions you must be able to answer

1. What is a work breakdown structure, and what is a work package? A hierarchical breakdown of the whole scope of a project into deliverables and smaller components. The work package is its lowest level: a piece of work small enough to be estimated with confidence, assigned to one person, scheduled, and recognised as finished.

2. State the 100 per cent rule and explain what it catches. The WBS must include all the work in the project's scope and no work outside it, so that at every level the parts add up exactly to their parent. It catches forgotten work such as testing, reviews and deployment, work counted twice, and work that is not in scope.

3. Why are the upper levels of a WBS named with nouns? Because a WBS breaks down what the project produces, its deliverables, rather than the activities that produce them; the sequence of activities belongs in the schedule.

4. What is a WBS dictionary, and which field matters most? A table describing each work package: its description, deliverable, completion criterion, owner, estimate and dependencies. The completion criterion, "done when", matters most, because without it nothing can be shown to be finished.

5. How did the worked team check that its WBS was realistic? Its work packages add up to 240 person-hours, exactly four students at 60 hours each, and its feature work packages add up to 64 hours, the same figure as its estimate for the functional requirements in Chapter 13.

PERT also gives a measure of how uncertain an estimate is, (P - O) / 6, which for the SRS is 4 / 6, about two thirds of a day. A task whose optimistic and pessimistic estimates are far apart deserves a closer eye, whatever its expected duration.

Dependencies

A dependency says that one piece of work cannot start, or cannot finish, until another has started or finished. There are four kinds, and the first covers nearly every real case:

A lag is a wait added to a dependency: "the review can start two days after the draft is sent". A lead is an overlap: "testing can start three days before building finishes".

Milestones

A milestone is a point in time, not a piece of work: it has no duration. It marks something achieved or an event that happens: the proposal approved, the design review held, the report submitted. Milestones are what a guide checks and what the team celebrates, and they are where your college's assessment dates belong.

The critical path method

With durations and dependencies known, a short calculation gives every task four numbers. Count working days from 0, the first day of the project. A task that starts on day 31 and lasts 3 days works on days 31, 32 and 33; its finish, 34, is the day after its last day, which is also the first day a task waiting for it can start.

The forward pass, from the start of the project to the end, gives each task its early start (ES), the earliest it can begin, which is the latest early finish of all the tasks it waits for; and its early finish (EF), which is its early start plus its duration. The largest early finish in the project is the project length.

The backward pass, from the end back to the start, gives each task its late finish (LF), the latest it can finish without delaying the project, which is the earliest late start of all the tasks that wait for it; and its late start (LS), which is its late finish minus its duration.

Float, also called slack, is late start minus early start: how many days a task can slip without delaying the whole project. Strictly this is total float. Free float is the smaller amount a task can slip without delaying even the next task: the earliest early start of the tasks waiting for it, minus its own early finish. When a task leads straight into a critical one, as every task with float does in the worked plan, the two are equal.

The critical path is the chain of tasks with zero float, and its length is the project length. A day lost on a critical task is a day lost on the whole project; a day lost on a task with four days of float is not, until the float is used up. That one fact tells you where to watch most closely, where extra help makes the project shorter, and where it makes no difference at all.

Some textbooks count days from 1 and write a task's finish as its last day. The critical path and every float come out the same either way; only the day numbers shift by one.

The worked project: the schedule, computed

The worked team took sixteen tasks from its WBS and its SDLC plan (Chapter 15), each with a duration in working days and the tasks it waits for, and wrote a short program to do the two passes, so that a change to any estimate would recompute everything. It is written in JavaScript, the language of the whole application, it runs with Node.js, which Chapter 39 installs, and it lives in the repository beside the Gantt source, in docs/plan.

// cpm.js: the critical path of the team's plan, and the dates
// of every task. Run it from the project folder:
//   node docs/plan/cpm.js
//
// Each task is an id, a name, its length in working days, and
// the ids of the tasks it waits for. A task is always listed
// after the tasks it waits for.
const tasks = [
  ['C', 'Choose problem', 5, []],
  ['O', 'Observe, survey', 5, ['C']],
  ['I', 'Interviews', 4, ['O']],
  ['P', 'Proposal', 5, ['I']],
  ['S', 'SRS', 8, ['I']],
  ['U', 'UML set', 5, ['S']],
  ['W', 'Wireframes', 3, ['S']],
  ['D', 'Schema, API', 4, ['U']],
  ['A', 'Architecture', 3, ['D', 'W', 'P']],
  ['F', 'Frontend', 12, ['A']],
  ['B', 'Backend', 10, ['A']],
  ['V', 'Auth, validation', 6, ['B']],
  ['T', 'Testing', 5, ['F', 'V']],
  ['L', 'Load, security', 3, ['T']],
  ['Y', 'Deploy, APK', 4, ['V']],
  ['R', 'Report', 7, ['L', 'Y']],
];

// Forward pass: a task starts as soon as the last of the
// tasks it waits for has finished.
const early = {};
for (const [id, , days, after] of tasks) {
  const finishes = after.map((a) => early[a].finish);
  const start = Math.max(0, ...finishes);
  early[id] = { start, finish: start + days };
}
const end = Math.max(...tasks.map(([id]) => early[id].finish));

// Backward pass: a task must finish by the time the first
// task waiting for it has to start, or by the end.
const late = {};
for (const [id, , days] of [...tasks].reverse()) {
  const waiting = tasks.filter((t) => t[3].includes(id));
  const starts = waiting.map((t) => late[t[0]].start);
  const finish = Math.min(end, ...starts);
  late[id] = { start: finish - days, finish };
}

// Working day n as a date. Day 0 is Monday 27 July 2026, and
// weekends and holidays are not counted. JavaScript counts
// months from 0, so month 6 is July.
const HOLIDAYS = ['2026-10-02'];
const MONTHS = ['Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun',
  'Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec'];

function isWorkingDay(d) {
  const weekend = d.getUTCDay() === 0 || d.getUTCDay() === 6;
  const ymd = d.toISOString().slice(0, 10);
  return !weekend && !HOLIDAYS.includes(ymd);
}

function dateOf(n) {
  const d = new Date(Date.UTC(2026, 6, 27));
  let counted = 0;
  while (counted < n) {
    d.setUTCDate(d.getUTCDate() + 1);
    if (isWorkingDay(d)) counted += 1;
  }
  const day = String(d.getUTCDate()).padStart(2, '0');
  return `${day} ${MONTHS[d.getUTCMonth()]}`;
}

// The table. A task with early start 31 and early finish 34
// works on days 31, 32 and 33, so its last day is finish - 1.
const pad = (v, n) => String(v).padStart(n);
console.log('Id Task             Days  ES  EF  LS  LF'
  + ' Float  Dates');
for (const [id, name, days] of tasks) {
  const e = early[id];
  const l = late[id];
  console.log(`${id}  ${name.padEnd(16)}${pad(days, 5)}`
    + `${pad(e.start, 4)}${pad(e.finish, 4)}`
    + `${pad(l.start, 4)}${pad(l.finish, 4)}`
    + `${pad(l.start - e.start, 6)}`
    + `  ${dateOf(e.start)} to ${dateOf(e.finish - 1)}`);
}

const critical = tasks.filter(([id]) =>
  late[id].start === early[id].start).map(([id]) => id);
console.log(`Project length: ${end} working days,`
  + ` last day ${dateOf(end - 1)}`);
console.log(`Critical path: ${critical.join(' ')}`);

Run from the project folder, it prints:

$ cd canteen-preorder
$ node docs/plan/cpm.js
Id Task             Days  ES  EF  LS  LF Float  Dates
C  Choose problem      5   0   5   0   5     0  27 Jul to 31 Jul
O  Observe, survey     5   5  10   5  10     0  03 Aug to 07 Aug
I  Interviews          4  10  14  10  14     0  10 Aug to 13 Aug
P  Proposal            5  14  19  26  31    12  14 Aug to 20 Aug
S  SRS                 8  14  22  14  22     0  14 Aug to 25 Aug
U  UML set             5  22  27  22  27     0  26 Aug to 01 Sep
W  Wireframes          3  22  25  28  31     6  26 Aug to 28 Aug
D  Schema, API         4  27  31  27  31     0  02 Sep to 07 Sep
A  Architecture        3  31  34  31  34     0  08 Sep to 10 Sep
F  Frontend           12  34  46  38  50     4  11 Sep to 28 Sep
B  Backend            10  34  44  34  44     0  11 Sep to 24 Sep
V  Auth, validation    6  44  50  44  50     0  25 Sep to 05 Oct
T  Testing             5  50  55  50  55     0  06 Oct to 12 Oct
L  Load, security      3  55  58  55  58     0  13 Oct to 15 Oct
Y  Deploy, APK         4  50  54  54  58     4  06 Oct to 09 Oct
R  Report              7  58  65  58  65     0  16 Oct to 26 Oct
Project length: 65 working days, last day 26 Oct
Critical path: C O I S U D A B V T L R

Read a few rows by hand to see the method working.

Architecture (A) waits for D, W and P, which finish at 31, 25 and 19. Its early start is the largest of those, 31, and its early finish is 31 + 3 = 34: it works on 8, 9 and 10 September.

Frontend (F) could start at 34 and finish at 46. But the only task waiting for it is Testing (T), which cannot start before 50 anyway, because T also waits for V, which finishes at 50. So F may finish as late as 50, may start as late as 38, and has 4 days of float.

The Proposal (P) has 12 days of float: nothing waits for it except the architecture document, which cannot start before day 31. The team did not spend that float. The proposal is the document the guide reads first, and a proposal read early is feedback received early, so they finished it on 20 August as planned. Float is permission to slip, not an instruction to.

The critical path is C O I S U D A B V T L R, 65 working days: from choosing the problem, through the SRS, the UML, the schema and the architecture, the backend and its sign-in and validation, and the testing, to the report. A day lost on the backend is a day lost on the whole project; a day lost on the frontend is not, until four days are gone.

Against the time available

The semester gives the team 15 weeks from 27 July: 75 weekdays, less the holiday on 2 October, which is 74 working days. The critical path needs 65. That leaves 9 working days of slack for college events, examinations in other papers, and the things that always go wrong. This slack belongs to the whole project, measured against the deadline; it is not the float of any one task. Nine days is not a large margin, so the team watched the critical tasks at every stand-up.

The architecture document, the last of the design documents, is finished on Thursday 10 September, in the seventh week, and the design review is held on the last day of that week, Friday 11 September. The last day of work is Monday 26 October.

When the plan is too long

Had the critical path come to 80 days against 74, there are only three honest ways to shorten it:

• Crashing: put more people on a critical task. Help on a task with float shortens nothing.
• Fast-tracking: overlap tasks that were planned in sequence, such as starting the UML set before the SRS is completely finished. It saves time and adds the risk of rework.
• Cutting scope: build less. This is what the Could Haves of Chapter 13 are for.

Hoping to work faster is not on the list.

The Gantt chart

A Gantt chart draws the schedule as horizontal bars against a calendar: one row per task, each bar starting at the task's start date and as long as its duration. Arrows show dependencies, diamonds show milestones, and many tools can also mark today's date and shade each bar to show how much of it is done.

It is the most readable form of a schedule, and the form the syllabus names for the project timeline. It is a picture of the schedule, though, not the calculation: the numbers come from the method above, and the chart shows them.

The worked team drew its Gantt chart with PlantUML, from the same tasks and dependencies:

Figure 17.1 The worked team's Gantt chart, drawn by PlantUML from the source below

@startgantt gantt
printscale weekly
saturday are closed
sunday are closed
Project starts 2026-07-27
2026-10-02 is closed

[Choose problem] requires 5 days
[Observe, survey] requires 5 days
[Observe, survey] starts at [Choose problem]'s end
[Interviews] requires 4 days
[Interviews] starts at [Observe, survey]'s end
[Proposal] requires 5 days
[Proposal] starts at [Interviews]'s end
[SRS] requires 8 days
[SRS] starts at [Interviews]'s end
[UML set] requires 5 days
[UML set] starts at [SRS]'s end
[Wireframes] requires 3 days
[Wireframes] starts at [SRS]'s end
[Schema, API] requires 4 days
[Schema, API] starts at [UML set]'s end
[Architecture] requires 3 days
[Architecture] starts at [Schema, API]'s end
[Architecture] starts at [Wireframes]'s end
[Architecture] starts at [Proposal]'s end
[Design review] happens 2026-09-11
[Frontend] requires 12 days
[Frontend] starts at [Architecture]'s end
[Backend] requires 10 days
[Backend] starts at [Architecture]'s end
[Auth, validation] requires 6 days
[Auth, validation] starts at [Backend]'s end
[Testing] requires 5 days
[Testing] starts at [Frontend]'s end
[Testing] starts at [Auth, validation]'s end
[Load, security] requires 3 days
[Load, security] starts at [Testing]'s end
[Deploy, APK] requires 4 days
[Deploy, APK] starts at [Auth, validation]'s end
[Report] requires 7 days
[Report] starts at [Load, security]'s end
[Report] starts at [Deploy, APK]'s end
[Submission] happens at [Report]'s end
@endgantt

A few details of the source are worth copying:

• Project starts 2026-07-27 fixes day 0. saturday are closed and sunday are closed make weekends non-working days, and 2026-10-02 is closed does the same for the holiday, so every date PlantUML computes is a working date.
• Each requires line is a duration in working days, and each starts at [X]'s end line is a finish-to-start dependency.
• [Submission] happens at [Report]'s end is a milestone that follows a task: it moves if the report moves.
• [Design review] happens 2026-09-11 is a milestone on a fixed date, because the date is the guide's to set, not the plan's. The chart shows at a glance that the architecture document, the last design task, ends the day before.
• printscale weekly gives one column to a week, so the whole semester fits a page. The numbers along the top are the weeks of the year.

Two things in the drawing need reading with care. The Duration column counts calendar days, weekends included: the proposal's five working days, Friday 14 to Thursday 20 August, show as 7 days. And each milestone is listed as lasting one day, which is only how PlantUML draws a diamond; a milestone takes no time at all.

PlantUML computed its dates independently of the program above, and its Start and End columns agree with it on every task. Two separate calculations from the same tasks agreeing is a good check that neither contains a slip. It cannot check the estimates themselves, which are only as good as the team's judgement.

Putting your college's dates in

Put each of your guide's assessment dates into the plan the same way as the design review: one line each, on a fixed date. If your code review were fixed for Thursday 1 October, the line would be:

[Code review] happens 2026-10-01

A milestone on a fixed date shows whether the work it needs will be ready in time. If a bar that must finish before the review ends after the diamond, the plan has a problem, and it is far better to see it in August than on the day.

Keeping the timeline honest

A schedule made in August and never looked at again is a decoration. Every week, the worked team did three things at the Tuesday stand-up:

1. Marked what had finished, and how much of each task in progress was done.
2. Re-estimated anything that was clearly going to take longer.
3. Re-ran the program. If the project length grew past 74 working days, they decided what to cut, starting with the Could Haves (Chapter 13).

In the event, the stock rule in the backend took longer than its estimate (Chapter 45). The backend is on the critical path, so the extra days could not come out of any task's float: they came out of the nine days of slack before the end of the semester. That slack was also the only time the Could Haves would ever have had, so none of them was built, which is exactly the outcome Chapter 13 planned for.

Do this for your project

1. Take the work packages from your WBS. Estimate each one's effort, then its duration from the hours a day its owner can really give.
2. For uncertain tasks, use three-point estimates and the PERT formula.
3. For each task, list the tasks it must wait for; most will be finish to start.
4. Do the forward and backward passes, by hand for a small plan or with a short program like the one above.
5. Find the critical path and the float of every task. Compare the project length with the working days you have, leaving slack.
6. Draw the Gantt chart, and add your college's assessment dates as fixed-date milestones.
7. Update it every week, and re-run the calculation whenever an estimate changes.

Mistakes that cost marks

A Gantt chart with no dependencies. Bars placed by eye cannot tell you what a delay will do.

Effort used as duration. Twenty hours of work is not two and a half days for a student with other papers to study.

No holidays, no examinations in other papers. A plan that assumes every weekday is free is already late.

No critical path. Without it, nobody knows which delays matter.

Extra help put on a task with float. It makes that task shorter and the project no shorter at all.

A plan never updated. The guide will ask where you are against it, and "the chart is from August" is not an answer.

Quick revision

• Effort is person-hours; duration is working days in progress; convert using the hours a day people can really give.
• Estimate by judgement, analogy, bottom-up, or three-point: expected = (O + 4M + P) / 6, uncertainty = (P - O) / 6.
• Dependencies: finish to start (almost all), start to start, finish to finish, start to finish; with lags and leads.
• Milestones have no duration; your college's assessment dates are milestones on fixed dates.
• Forward pass gives ES and EF; backward pass gives LS and LF; total float = LS minus ES.
• The critical path is the zero-float chain; its length is the project length.
• A plan that is too long is shortened by crashing, fast-tracking or cutting scope.
• A Gantt chart draws the schedule as bars against a calendar, with dependency arrows and milestone diamonds.

Questions you must be able to answer

1. What is the difference between effort and duration? Effort is the number of person-hours a task needs; duration is the number of working days it is in progress. Duration depends on how many hours a day the people doing it can give, so eight hours of effort from a student who can give it an hour a day lasts eight working days.

2. Using three-point estimation, what is the expected duration of a task estimated at 6, 8 and 13 days? (6 + 4 × 8 + 13) / 6 = 51 / 6, which is 8.5 days. It is longer than the most likely estimate because the pessimistic estimate is further from it than the optimistic one.

3. Define float and the critical path. Float is how long a task can be delayed without delaying the project: its late start minus its early start. The critical path is the chain of tasks with zero float; its length is the minimum duration of the whole project, and any delay on it delays the project.

4. Why does the worked team's frontend have 4 days of float? Because the only task waiting for it, testing, also waits for the sign-in and validation work, which finishes on day 50, four days after the frontend's early finish on day 46.

5. What is a milestone, and how would you show your college's code review date on a Gantt chart? A milestone is a point in time with no duration, marking an achievement or an event. The review is added as a milestone on a fixed date, and the chart then shows whether the work it needs will be finished before it.

6. How long is the worked team's critical path, and how much slack does the semester leave? 65 working days. The 15 weeks from 27 July hold 74 working days once the 2 October holiday is removed, leaving 9 working days of slack.

7. The project is five days too long. Would two extra people on the frontend help? No. The frontend has four days of float, so shortening it does not shorten the project. Help must go to a task on the critical path, or tasks must be overlapped, or scope cut.

Allocation shares each work package's hours among the people who will do them. It passes two checks or it is wrong: every package's hours add up to its estimate in the WBS, and every person's hours add up to their capacity. If either fails, the plan is promising work that nobody has time for.

Checking the load, week by week

An allocation can give everyone exactly 30 hours and still be impossible, if 20 of someone's hours fall in one week. The load check finds this:

1. Give every work package the dates of its bar in the Gantt chart.
2. Spread each person's hours on it evenly over those working days, and put each meeting on its own day.
3. Add up each person's hours, week by week.
4. Mark every week in which anyone is over the limit. That is over-allocation.

There are three ways to remove an overload:

• Move the work within its float. A task with float can start later without delaying the project (Chapter 17). Moving it into a quieter week is resource smoothing, and the end date does not change.
• Give the work to someone else who has spare hours that week, and give that person hours back in a week when the overloaded member is free, so both still total their capacity.
• Delay the work until the person is free, even beyond its float. This is resource levelling, and when the work is on the critical path the end date moves with it.

Strictly, smoothing keeps the end date and levelling may not; in everyday use many people say "levelling" for both.

Responsibility: the RACI matrix

A responsibility assignment matrix lists the work down the side, the people across the top, and in each cell what that person's part is. The best-known form uses four letters, RACI:

• R, Responsible: does the work. A row may have several.
• A, Accountable: answerable for the work being done and done well, and the one who says it is finished. Exactly one per row, and in a student project this is the owner of Chapter 16.
• C, Consulted: asked for input before or during the work. The conversation goes both ways.
• I, Informed: told of progress or of the result. One way.

The single A is the point of the matrix. A row with two A's has nobody accountable, because each can say it was the other's; a row with none has the same problem more honestly. The A is not always the person who does most of the work, as the worked project shows.

The worked project: the resource plan

Hours, Module 1

Every figure is person-hours. The first column is the WBS number from Chapter 16, whose owners are the A's in the matrix further down.

Two rows are worth a second look. Everyone has hours on the SRS although Aditi owns it: each member wrote the requirements for the part they would build, and Aditi wrote the rest and edited the whole. And Farhan owns the API specification, because the backend must honour it, but Rohan wrote half of it, because he would test against it.

Hours, Module 2

Here too the owner is not always the main hand. Rohan is accountable for the integration tests, but Aditi and Sneha run them, in a week when he is deploying. And Rohan's two hours on the server are a practice deployment in the week of 14 September; Farhan's two are the real deployment in October, done from Rohan's notes.

The load check, and what it found

The team's first version of Module 1 put all of the plan, 1.2, in the proposal's week, because the plan goes into the proposal. The check showed the result at once: 12.7 hours for Aditi in the week of 17 August, when her share of the proposal, the whole plan and her share of the SRS all fell together.

The fix used two of the three tools. The skeleton of the WBS and the schedule needs only MU's list of deliverables, known from the first day, so Aditi drafted it in the week of 3 August, while the team was observing the canteen: smoothing, since the plan has no bar of its own and the end date did not move. The estimates need the requirements, so they stayed in the proposal's week and went to Farhan and Rohan, who would build and test what they were estimating (Chapter 13). To keep everyone at 30 hours, Aditi took over Farhan's hour at the interviews and one of Rohan's hours of observation.

After the change, week by week:

Week 7 includes the design review on Friday 11 September; the build that starts the same day is counted with Module 2. Nobody passes 10 hours in any week. The heaviest is Sneha's week of 24 August, 9.65 hours, when the end of the SRS, her part of the UML set and all six hours of wireframes fall together.

A load check shows spare time as plainly as overload. Aditi's week of 31 August holds only the stand-up. If the UML set, which is on the critical path, ran late, she is the one with time to help: Chapter 17's crashing, planned in advance.

The same check on Module 2's first version found two overloads. In the week of 14 September Farhan had 11.75 hours, and more than 10 again the week after, because the backend and the database were both his, and both are on the critical path, so nothing could wait. In the week of 5 October Rohan had nearly 15 hours: deployment, the APK and the integration tests all fell on him at once.

Deployment has four days of float, and the first idea was to use them. The check showed why that fails: four days later is the week of Rohan's load and security testing, and his overload simply moved there, to more than 14 hours in the week of 12 October. Float helps only when the week it moves work into is quiet.

So the team reassigned. Aditi and Rohan took part of the backend and the database in the weeks they were built, and Farhan took hours later, in authentication and validation, load testing and the server, where knowing the backend helps anyway. Aditi and Sneha ran the integration tests. And two of the server hours moved to the week of 14 September, for the practice deployment that Chapter 6 set as the answer to its first risk: nobody on the team had deployed Node.js on a Linux server. After the changes no week in Module 2 is over 8.25 hours, the heaviest being Farhan's week of 14 September.

Responsibility, Module 1

Every row has one A, and it is the owner Chapter 16 named. A dash means not involved.

The guide is consulted on the documents MU assesses and informed of the rest. The canteen owner is consulted wherever the system's behaviour or her canteen's facts are decided, and on the wireframes, because she and the counter staff are the ones who will use the screens during the rush. The meetings, 1.3, are left out: everyone attends them.

Equipment, software, services and money

A plan in which every cost is "nothing" is still a plan: each line says where the resource comes from and when, and the two lines that depend on other people, the lab machine and the owner's phone, have been asked for.

People outside the team

The interview dates are the ones Chapter 9 recorded, and the increment reviews are Chapter 15's. The guide's dates are the guide's to set; every other date was asked for as soon as the team knew it would need it.

Do this for your project

1. List your resources under the six kinds. For each, write where it comes from and the week it is first needed.
2. Write each person's capacity: MU's 30 hours a module, and your team's own weekly limit.
3. Share every work package's hours among people. Check both sums: each package equals its WBS estimate, and each person equals their capacity.
4. Do the load check: spread the hours over the Gantt bars, add them up by week, and mark every overload.
5. Remove each overload by moving work within its float, reassigning it, or delaying it, and check again. A move can shift an overload rather than remove it.
6. Give every skill the demonstration depends on a second person.
7. Write the RACI matrix with exactly one A in each row.
8. Book other people's time now: the guide's review dates, the client's reviews, the machine.
9. Put the resource plan in your proposal (Chapter 33), and repeat the load check whenever the schedule changes.

Mistakes that cost marks

Hours that add up but do not fit. Thirty hours each is not enough; the weeks have to fit as well.

"All" in every row. An allocation in which everybody does everything hides who is short of time and who is accountable.

One person for a critical skill. If only one member can deploy, a fever in the deployment week ends the demonstration.

Other people's time assumed. The guide's calendar and the client's lunch break are resources. Ask for them early.

Meetings left out. Fifteen minutes a week comes to between an hour and a half and two hours a module for each member, and that time has to come from somewhere.

Float used without looking. Moving a task can move an overload instead of removing it.

Quick revision

• Resources: people (hours and skills), equipment, software and services, money, other people's time, information.
• Capacity for this paper: 60 hours each, 30 per module, about 4 a week on average; agree a weekly limit as well.
• Allocation passes two checks: each package equals its estimate, and each person equals their capacity.
• Load check: spread the hours over the Gantt bars and add them by week; over-allocation is any week over the limit.
• Fixes: smoothing (within float, end date kept), reassignment, levelling (may move the end date).
• RACI: Responsible does it; Accountable, exactly one per row, answers for it; Consulted gives input; Informed is told.
• Bus factor: every critical skill should live in at least two heads.

Questions you must be able to answer

1. What does resource planning cover in a mini project? The people's hours and skills, the equipment, software and services, any money, other people's time and the information the system needs; when each is needed and who provides it; an allocation of the work that overloads nobody; and a record of who is responsible for what, usually a RACI matrix.

2. What is the difference between resource smoothing and resource levelling? Smoothing moves work only within its float, so resource peaks are reduced and the end date does not change. Levelling moves work until the resource is available, even beyond its float, so if the work is on the critical path the end date moves too.

3. What do R, A, C and I stand for, and why must each row have exactly one A? Responsible, who does the work; Accountable, who answers for it and says when it is finished; Consulted, who is asked for input; and Informed, who is told of the result. With two A's each can blame the other, and with none nobody answers for the work, so exactly one is needed.

4. The worked team's first allocation gave every member 30 hours in Module 1. What was still wrong with it? The hours were in the wrong weeks. With the whole plan placed in the proposal's week, Aditi had 12.7 hours in the week of 17 August, over the team's limit of 10. Drafting the plan's skeleton in the week of 3 August and giving the estimates to Farhan and Rohan brought her heaviest week down to 8.7 hours.

5. Why did using the deployment's float not remove Rohan's overload? Because the four days of float moved the deployment into the week of his load and security testing, where his total came to more than 14 hours instead. Float removes an overload only when the week the work moves into has room for it; otherwise the work must go to someone else.

6. What is a bus factor, and how did the worked team deal with its weakest skill? The number of people who would have to be unavailable before a piece of work stops. Nobody on the team had deployed Node.js on a Linux server, so Rohan made a practice deployment in the week of 14 September and Farhan made the real one in October from Rohan's notes, leaving two members who had done it.

One model, many views. The diagrams are not separate pictures that happen to share names. They are views of one model of one system: the Order in the class diagram is the same Order that appears in the sequence diagram and becomes a table in the database.

Fourteen kinds of diagram in two families

Annex A of the UML 2.5.1 specification divides its diagrams into two families:

• Structure diagrams show the static structure of the system: its parts and how they relate, irrespective of time.
• Behaviour diagrams show its dynamic behaviour: what happens, in what order, as time passes.

That is seven structure kinds and seven behaviour kinds, fourteen in all. The specification adds that the boundaries between the kinds are not strictly enforced: a diagram may mix structural and behavioural elements where that helps.

MU asks for five of the fourteen, plus one diagram that is not UML at all.

Where the ER diagram sits

The entity-relationship (ER) diagram comes from database design, not from UML. Peter Chen published the entity-relationship model in 1976, in the first issue of the journal ACM Transactions on Database Systems, twenty-one years before UML 1.1.

MU is right to list it with the UML diagrams, because every project with a database needs it. UML's class diagram can describe data too, but an ER diagram speaks the database's own language: entities, their keys, and how many of one relate to how many of another. The class diagram describes the objects the program works with; the ER diagram describes the tables they are stored in. Chapter 24 draws the worked ER diagram in both of its common notations.

MU's six, and the question each answers

Read the "drawn from" column as an order of work. The use case diagram comes straight out of the requirements. The class diagram comes from the things the use cases talk about. Sequence and activity diagrams show how the use cases actually happen, using those classes. The ER diagram stores what the classes hold. The deployment diagram puts it all on machines.

How the six must agree

Six diagrams that each look right can still describe six different systems. A complete UML set, the Module 1 deliverable (Chapter 35), is six diagrams of one system, and these checks prove it:

1. Every functional requirement is covered by a use case, and every use case traces back to at least one requirement.
2. Every actor is a user class or an outside system named in the SRS. An actor that appears nowhere else is a stakeholder somebody forgot to interview.
3. Every important use case has a sequence or an activity diagram showing how it happens.
4. Every message a sequence diagram sends to a part of the system is something that part can do: an operation of its class, or a route of the API.
5. Every class whose data must survive a restart appears in the ER diagram, with the same attributes.
6. Every artifact in the deployment diagram is something the architecture says will be built, and every node is a machine that really exists.
7. One thing, one name. An Order is not an OrderRecord in one diagram and a Purchase in another. Between code and database one mapping rule is allowed and should be stated, such as camelCase in JavaScript and snake_case in SQL, so that pickupDate is pickup_date. A name that breaks the rule is written down, with the one place in the code that translates it.

The worked project, checked

The worked team ran these checks before its design review, and again once the code existed (Chapter 35). Two examples show what agreeing looks like.

Placing an order. Use case UC-4, Place an order, covers FR-7 to FR-11. Two sequence diagrams show it happening: the page and the server, then the transaction inside the server that takes the stock. Every class they touch, Order, OrderItem and MenuItem, is in the class diagram, and each is a table in the ER diagram: orders, order_items and menu_items. The code that does it is the canteen-preorder artifact that the deployment diagram places on the server.

An order's status. The class diagram gives Order a status with six values: placed, preparing, ready, collected, cancelled and no_show. The state machine diagram has exactly those six states, and five arrows between them. The database stores the status in a column that allows exactly those six values, and the application's rules allow exactly those five moves (Chapter 43). Four places, one set of names.

And the checks found mistakes. The class diagram first called the line of an order OrderLine, while the table was order_items and the API sent a list called items, so the class was renamed OrderItem: one thing, one name. It also lacked three attributes the tables have, a menu item's category and whether it is vegetarian, and a user's password hash, which Chapter 21 shows added.

The worked project's model

The team drew one diagram more than MU asks for: a state machine diagram of an order's status, because FR-15's rule, which status may follow which, is exactly what a state machine shows. It kept every diagram as PlantUML source in its repository, under docs/uml:

The placing of an order was first drawn as one sequence diagram. At 666 pixels wide it could not be read on a phone without zooming, and it was a squeeze on a report page, so the team split it where the page stops and the server starts. Two readable diagrams are better than one that has to be zoomed.

Tools

You can draw UML with a pencil, with a drawing program, with a dedicated modelling tool, or from text. For thinking, a pencil is best. For the document you hand in, choose a tool that lets you change a diagram easily, because you will, many times.

The worked team chose PlantUML, a free, open-source program that draws diagrams from a short text description. Its advantages for a student team:

• The source is text, so it lives in the Git repository beside the code, and a change to a diagram shows up in the history like any other change.
• Anyone can redraw it. The same source and the same PlantUML version draw the same picture on any machine.
• It can be reviewed. A teammate can read the change to class.puml in a pull request, which nobody can do with a screenshot.

Every diagram in this book is drawn by PlantUML from source that the chapter prints, so that you can change it for your own project and draw it again.

To use it you need a Java runtime and the plantuml.jar file from the PlantUML website. From the project folder, this one command draws every diagram in docs/uml as an SVG file beside its source:

java -jar plantuml.jar -tsvg docs/uml/*.puml

Run with PlantUML 1.2026.8 on 30 September 2026, it redrew every UML figure in this book exactly, byte for byte, on a machine with nothing installed but Java. For some kinds of diagram PlantUML normally uses a separate layout program, Graphviz; the team's sources of those kinds begin with !pragma layout smetana, which tells PlantUML to use a layout engine built into it instead.

PlantUML's automatic layout has a price: it decides where the boxes go. A diagram that grows too large becomes unreadable, and the cure is the one the team used for the sequence diagram: split it, rather than shrink it.

Do this for your project

1. For each of MU's six diagrams, write the one question it must answer about your system.
2. Draw the use case diagram first, from your functional requirements; then the class diagram from the nouns the use cases use.
3. Draw a sequence or activity diagram for each important use case, using those classes.
4. Draw the ER diagram from the classes whose data must be stored, and the deployment diagram from your architecture and hosting plan.
5. Keep every diagram's source in your repository, in a folder of its own such as docs/uml.
6. Choose your names once and use them everywhere; write down your one mapping rule between code and database.
7. Run the seven checks before your design review. Expect them to find something.
8. Keep each diagram readable on one page. If it is not, split it.

Mistakes that cost marks

Diagrams copied from a textbook example. An examiner recognises a library management system in a canteen project's class diagram.

Six diagrams that disagree. A class with no table, a table with no class, an actor who appears in no requirement: each is a question in the viva.

A class diagram that is really an ER diagram. Foreign keys as attributes and no operations mean the class diagram describes tables, not objects; and an ER diagram with methods in it has the opposite problem.

One enormous diagram. If it needs zooming, it is two diagrams.

Diagrams drawn after the code. MU asks for the UML set at the end of Module 1, before building. A design drawn afterwards has never been used, and it usually shows.

A picture with no source. A screenshot cannot be changed when the design changes, so it stops being true.

Quick revision

• A model answers questions about a system before it is built; every diagram leaves most of the system out on purpose.
• UML is a standard modelling language maintained by the OMG; first formal version 1.1 (December 1997), latest 2.5.1 (December 2017).
• Fourteen diagram kinds in two families: seven structure (class, object, package, component, composite structure, deployment, profile) and seven behaviour (use case, activity, state machine; and the interaction diagrams: sequence, communication, interaction overview, timing).
• MU's six: use case, class, sequence, activity, deployment, and the ER diagram, which is not UML but comes from Chen (1976).
• The six are views of one model and must agree: requirements, actors, scenarios, operations, stored data, deployed artifacts and names.
• Keep diagram sources in the repository; split a diagram rather than shrink it.

Questions you must be able to answer

1. What is UML, and who maintains it? The Unified Modeling Language, a standard visual language for modelling software systems, maintained by the Object Management Group. Its latest formal version is 2.5.1, published in December 2017.

2. What are the two families of UML diagrams? Give two examples of each. Structure diagrams, which show the static parts of a system and how they relate, such as the class diagram and the deployment diagram; and behaviour diagrams, which show what happens over time, such as the use case, activity and sequence diagrams.

3. Is the ER diagram a UML diagram? No. It comes from database design: Peter Chen published the entity-relationship model in 1976. It is used alongside UML because it describes the database's tables, keys and relationships in the database's own terms.

4. How is a class diagram different from an ER diagram? A class diagram describes the objects the program works with, with their attributes, operations and relationships; an ER diagram describes the stored data, with entities, keys and the cardinality of relationships. They must agree on what is stored, but they answer different questions.

5. Name three checks that show a set of UML diagrams describes one system. Every functional requirement is covered by a use case; every class whose data must be kept appears in the ER diagram with the same attributes; and every message in a sequence diagram is an operation or route that the receiving part really has. The same thing must also have the same name in every diagram.

6. Why did the worked team keep its diagrams as PlantUML source? Because text lives in the Git repository with the code, so every change to a diagram is recorded and can be reviewed, and anyone with the same PlantUML version can redraw exactly the same picture when the design changes.

A use case is a goal, not a screen or a step

The specification says a use case yields "an observable result that is of value for Actors or other stakeholders". Chapter 12 turned that into two tests: can the actor see the result, and would they call it worth the visit? "Place an order" passes. "Click Submit", "Validate quantity" and "Home page" do not: they are steps and screens, not goals.

Include and extend, and the direction of the arrow

Both are dashed arrows with a keyword, and students reverse them more than anything else in UML. The specification settles it with one idea: the arrow points from the use case that depends to the use case it depends on.

• Include. The base use case cannot be complete without the included one, which always runs as part of it. So the base depends on the included use case, and the arrow runs from the base to the included. Use it when two or more use cases share the same steps. The specification's own example is a cash machine, where "Withdraw" includes "Card Identification"; a "Check balance" use case would include it too.
• Extend. The extended use case is complete and meaningful on its own; the extension only adds behaviour to it, at an extension point, when a condition holds. So the extension depends on the base, and the arrow runs from the extension to the base.

The extended use case lists its extension points inside its ellipse, under the heading "extension points", each as a name with an optional explanation. The condition of the extend may be shown in a note attached to the arrow; the specification makes that note optional.

Lines, not flow

A use case diagram is not a flowchart. It says nothing about the order in which use cases happen. The specification goes further: two use cases of the same system cannot be joined by a plain association at all, because each describes a complete use of the system. Between use cases there are only three relationships: include, extend and generalisation.

The worked diagram

The worked team drew its diagram from Chapter 12's thirteen use cases:

Figure 20.1 The worked team's use case diagram, drawn by PlantUML from the source below

@startuml use-case
!pragma layout smetana
left to right direction
skinparam actorStyle awesome

actor Student
actor "Counter staff" as Staff
actor Owner
Owner -|> Staff

rectangle "Canteen Pre-order" {
  usecase "Register" as UC1
  usecase "Sign in / sign out" as UC2
  usecase "Browse today's menu" as UC3
  usecase "Place an order" as UC4
  usecase UC5 as "View my orders
--
extension points
cancel: an order
is still placed"
  usecase "Cancel an order" as UC6
  usecase "View orders by slot" as UC7
  usecase "Update order status" as UC8
  usecase "View kitchen list" as UC9
  usecase "Manage the menu" as UC10
  usecase "Set today's stock" as UC11
  usecase "View daily report" as UC12
  usecase "Create staff account" as UC13
}

Student -- UC1
Student -- UC2
Student -- UC3
Student -- UC4
Student -- UC5
UC6 .> UC5 : <<extend>>
Staff -- UC2
Staff -- UC7
Staff -- UC8
Staff -- UC9
Owner -- UC10
Owner -- UC11
Owner -- UC12
Owner -- UC13
@enduml

Reading it

Three actors. Student, Counter staff and Owner, the user classes of Chapter 5. All three are human, and there are no system actors: the one outside system a canteen might have, a payment service, is out of scope in this release (constraint C-5).

The owner is a kind of counter staff. The hollow triangle from Owner to Counter staff is a generalisation: the owner can take part in every use case the counter staff can, signing in, viewing orders by slot, updating an order's status and viewing the kitchen list, as well as in the four that are hers alone. The diagram does not draw those four lines again for the owner; the triangle says it.

Thirteen use cases, UC-1 to UC-13, each realising at least one functional requirement (Chapter 12's table).

One extend. Cancel an order extends View my orders. A student cancels only from the list of their own orders, and only while an order is still placed, so cancelling is optional behaviour added to viewing, at one point, under one condition. View my orders names that point in its ellipse: cancel: an order is still placed. The student has no line of their own to Cancel an order, because they reach it only through the use case it extends.

No include. Most of the use cases need the user to be signed in, and many textbooks would draw «include» from each of them to Sign in. The team did not, for the reason Chapter 12 gave: signing in is a goal of its own, UC-2, and a precondition of the others, not a shared fragment of them.

Who is not an actor. The kitchen staff read the kitchen list every day, but no cook signs in: the counter staff open the list on the counter's screen. The kitchen is a stakeholder that benefits from UC-9, not an actor that interacts with the system, which is why the specification's phrase is "of value for Actors or other stakeholders". And FR-4 shows the menu to everyone, signed in or not. The team drew only the Student against Browse today's menu: the people who look at the menu are students deciding what to eat, and a role is held before signing in as well as after.

The source, line by line

• actor Student draws an actor. actor "Counter staff" as Staff gives a name with a space a short alias to use in the lines below.
• Owner -|> Staff is the generalisation, with the triangle at the Staff end.
• rectangle "Canteen Pre-order" { ... } is the system boundary; everything declared inside it is drawn inside it.
• usecase "Register" as UC1 is a use case. UC5 is written the other way round, with its text in quotes after as, so that its text can run over several lines: the line -- draws the divider, and the lines after it are the extension points compartment.
• Student -- UC1 is an association: a plain line.
• UC6 .> UC5 : <<extend>> is the extend: a dashed arrow from UC6 to UC5, labelled.
• left to right direction puts the actors on the left, and skinparam actorStyle awesome draws each actor as a head and shoulders rather than a stick figure, which the specification allows: other icons may denote an actor.

Checking it

The diagram passes the first two of Chapter 19's checks. Every one of the seventeen functional requirements is realised by a use case, and every use case realises at least one, so the diagram is a complete index of the SRS's functional requirements (Chapter 34). And every actor is a user class of the SRS.

It also passes a check of its own: every actor has at least one association, and every use case has an actor, directly, through the owner's generalisation, or, for Cancel an order, through the use case it extends. A use case nobody can reach is a requirement nobody asked for.

Do this for your project

1. Draw the boundary first and name it after your system.
2. Put your actors outside it: roles from your stakeholder register, and any outside system your system talks to.
3. Put one ellipse inside for each use case from your use-case analysis, named verb first.
4. Join each actor to the use cases whose goals are theirs.
5. Draw a generalisation where one actor can do everything another can, and more.
6. Add include only for steps two or more use cases really share, and extend only for optional behaviour at a named point; list that extension point in the extended use case.
7. Check the arrows' direction: from the use case that depends to the one it depends on.
8. Check that every requirement has a use case, every use case has a requirement, and every use case can be reached by an actor.

Mistakes examiners circle

Include and extend reversed. The most common single error in student use case diagrams. Say the rule aloud before drawing each arrow.

«include» from every use case to Log in. Signing in is a precondition, or a use case of its own; it is rarely a shared fragment.

Use cases that are screens or steps. "Home page", "Click Submit", "Validate input".

Lines between use cases with no keyword, showing the order in which things happen. A use case diagram has no flow.

The system, or its database, drawn as an actor. Actors are outside the boundary; the database is inside.

Actors named after people. "Lata" is a person; "Owner" is a role.

Actors inside the boundary, or no boundary at all.

Forty use cases on one page. Split the diagram by actor or by part of the system.

Quick revision

• Actor: a role outside the system (human, hardware or another system); stick figure or «actor» rectangle.
• Use case: a goal with an observable result of value; an ellipse inside the system boundary rectangle.
• Association: a solid line between an actor and a use case. No plain lines between use cases.
• Include: dashed arrow from the base to the included use case, which always runs.
• Extend: dashed arrow from the extension to the extended use case, optional, at an extension point, under a condition.
• The rule: the arrow points from the use case that depends to the one it depends on.
• Generalisation: hollow triangle pointing at the general actor or use case.

Questions you must be able to answer

1. What does a use case diagram show? The actors outside the system, the use cases inside its boundary, which actors take part in which use cases, and the include, extend and generalisation relationships between use cases and between actors. It shows what the system does for whom, not the order in which things happen.

2. Which way does the arrow go for include, and for extend? Why? For include, from the base use case to the included one; for extend, from the extending use case to the extended one. In both cases the arrow points from the use case that depends to the one it depends on: a base needs what it includes, while an extended use case is complete without its extension.

3. What is an extension point? A named place in a use case at which an extending use case may add its behaviour. It is listed inside the extended use case's ellipse under the heading "extension points", with an optional explanation.

4. Why is the owner drawn with a generalisation arrow to the counter staff? Because the owner can take part in every use case the counter staff can, as well as her own. The generalisation says so once, instead of repeating four associations.

5. The kitchen staff use the kitchen list. Why are they not an actor? Because they do not interact with the system: no cook signs in, and the counter staff open the list for them. They are stakeholders who benefit from the use case, and UML's definition of a use case allows its value to go to stakeholders other than its actors.

6. Why is there no «include» to Sign in? Because signing in is a goal in its own right and a precondition of the other use cases, not a fragment of behaviour they share. Drawing an include to it from every use case that needs it adds an arrow to most of the diagram and no information.

Read it from one class, across the line, to the number at the far end. On a line between User and Order with 1 at the User end and 0..* at the Order end: a user places any number of orders, and an order is placed by exactly one user.

One rule from the specification is worth knowing: where a diagram shows no multiplicity at the end of an association, no conclusion may be drawn about it. Absent is not the same as "one", so write them all.

Aggregation or composition

The test is two questions about the part: can it exist without the whole, and can it belong to two wholes at once? If both answers are no, it is composition. The specification's own definition: a composite part is included in at most one composite at a time, and if the composite is deleted, its parts are deleted with it.

Aggregation, the hollow diamond, is weaker, and the specification deliberately leaves its exact meaning to whoever uses it. Many teams therefore avoid it, and draw either a plain association or a composition. That is not a mistake; a hollow diamond whose meaning nobody can state is.

Domain model and design model

A class diagram can describe two different things, and a student should say which one theirs is.

A domain model describes the things of the problem itself: orders, menu items, users. It shows their attributes, their associations, and at most the few operations that carry the important rules. It says nothing about files, frameworks or the language.

A design model describes the classes or modules of the code: every operation with its parameters, visibility, the types of the language, often classes that exist only in the program, such as a controller or a data store.

MU's syllabus places the class diagram in the design phase, before building, so a student's class diagram is usually a domain model with its key operations. The worked team's is exactly that.

The worked diagram

Figure 21.1 The worked team's class diagram, drawn by PlantUML from the source below

@startuml class
!pragma layout smetana
top to bottom direction
hide empty members
hide circle

class User {
  id : int
  name : string
  email : string
  passwordHash : string
  role : Role
  isActive : boolean
}

class Session {
  id : string
  expiresAt : datetime
}

class Order {
  id : int
  pickupDate : date
  slot : string
  status : Status
  /totalPaise : int
  canMoveTo(to, by) : boolean
}

class OrderItem {
  quantity : int
  unitPricePaise : int
}

class MenuItem {
  id : int
  name : string
  category : Category
  pricePaise : int
  isVeg : boolean
  isAvailable : boolean
  stockLeft : int
  takeStock(n) : boolean
}

enum Role <<enumeration>> {
  student
  staff
  owner
}

enum Category <<enumeration>> {
  meals
  snacks
  drinks
  desserts
}

enum Status <<enumeration>> {
  placed
  preparing
  ready
  collected
  cancelled
  no_show
}

User "1" *-- "0..*" Session
User "1" -- "0..*" Order : places
Order "1" *-- "1..10" OrderItem
OrderItem "0..*" --> "1" MenuItem
Session -[hidden]down- Role
Role -[hidden]down- Category
Category -[hidden]down- Status
@enduml

Reading it

User 1 to 0..* Session, a composition. A user may be signed in on several devices at once, a phone and a laptop, each a session. Each session belongs to exactly one user and cannot outlive them, so the diamond is filled; the database carries that out by deleting a user's sessions with the user (Chapter 24).

User 1 to 0..* Order, "places". Any number of orders, each placed by one user.

Order 1 to 1..10 OrderItem, a composition. An order item cannot exist without its order and belongs to only one, so the diamond is filled. The 1..10 comes from FR-7: at most 10 items in one order, so at most 10 lines. The rest of FR-7, no more than 5 of any one item and no more than 10 items in all, is a rule about quantities that no multiplicity can express; the SRS states it, and the code checks it.

OrderItem 0..* to 1 MenuItem, navigable one way. Each order item refers to exactly one menu item, and the arrow says an order item knows its menu item while a menu item keeps no list of the orders it is in. It is not a composition: the biryani exists whether or not anyone orders it.

Three enumerations. Role, Category and Status, each with exactly the values the database allows.

No generalisation. The use case diagram made the owner a specialisation of the counter staff. The class diagram does not make Owner a subclass of User. Students, counter staff and owners hold exactly the same data, a name, an email and so on, and differ only in what they may do. A difference in permissions is a value, role, not a new class. A subclass is for a kind of thing that holds different data or behaves differently.

Two operations. canMoveTo on Order and takeStock on MenuItem carry the two rules the whole system depends on: which status may follow which (FR-15), and never selling food that is not there (FR-9). Everything else is data.

One derived attribute. /totalPaise can be calculated from the order's items. The team still stores it, and stores each item's unit price in OrderItem although MenuItem has a price too, for the same reason: a price changed tomorrow must not change the total of an order placed today.

The source, line by line

• class User { ... } declares a class and lists its attributes; a line with brackets, such as canMoveTo(to, by) : boolean, is an operation.
• enum Role <<enumeration>> { ... } declares an enumeration and shows UML's keyword above its name.
• hide empty members leaves out a compartment with nothing in it, as the specification allows, and hide circle removes the small lettered circle PlantUML otherwise puts in every box, which is PlantUML's own decoration and not UML.
• User "1" -- "0..*" Order : places is an association, with each multiplicity in quotes beside its class and the association's name after the colon.
• Order "1" -- "1..10" OrderItem is a composition: the draws the filled diamond at the Order end. User "1" -- "0.." Session is another.
• OrderItem "0..*" --> "1" MenuItem is an association navigable towards MenuItem.
• The -[hidden]- lines draw nothing. They only ask the layout to stack the three enumerations in a column, which keeps the diagram narrow enough for a phone.

What a class diagram means for a JavaScript backend

The worked application has no JavaScript class called Order. Its backend reads rows from MySQL and hands them on as plain objects, and it keeps the rules in modules of functions. That is normal for a Node.js application, and it does not make the class diagram wrong: the diagram describes what the system knows and what it can do, and the code shows where each piece went when the team built it (Chapters 42 to 45).

An order, as the application sees it, has exactly the fields the store selects, each translated from its column name:

const ORDER_COLUMNS = `o.id, o.user_id AS userId,
  u.name AS studentName, o.pickup_date AS pickupDate,
  TIME_FORMAT(o.pickup_slot, '%H:%i') AS slot, o.status,
  o.total_paise AS totalPaise, o.created_at AS createdAt,
  o.updated_at AS updatedAt`;

Every translation follows the camelCase rule, except one: the column pickup_slot is read as slot. That is the one name that breaks the rule, and Chapter 19's advice applies to it: it is written down, and it is translated in this one place and nowhere else.

The two operations are two functions. Order.canMoveTo(to, by) is canMove(from, to, role), where from is the order's current status:

// Who may move an order from one status to another. The
// owner can do anything the counter staff can.
function canMove(from, to, role) {
  const mover = MOVES[from] && MOVES[from][to];
  if (!mover) return false;
  if (mover === 'student') return role === 'student';
  return role === 'staff' || role === 'owner';
}

MenuItem.takeStock(n) is the store's takeStock, a single SQL statement that takes the stock only if enough is left:

    // Takes `quantity` from the stock only if that many are
    // left, in ONE statement, so two orders for the last
    // plate cannot both succeed. True if it was taken.
    async takeStock(conn, id, quantity) {
      const [result] = await conn.execute(
        `UPDATE menu_items
            SET stock_left = stock_left - ?
          WHERE id = ? AND is_available = TRUE
            AND stock_left >= ?`,
        [quantity, id, quantity]);
      return result.affectedRows === 1;
    },

And the derived total is calculated once, when the order is placed:

// lines: [{ quantity, pricePaise }]. Integers, so exact.
function orderTotal(lines) {
  return lines.reduce(
    (sum, line) => sum + line.quantity * line.pricePaise, 0);
}

If your project is written in Java, C# or PHP with classes, the mapping is even more direct: each class in the diagram becomes a class in the code, and each operation a method.

Checking it against the other diagrams

• Against the ER diagram (Chapter 24). Every attribute of every class is a column of its table, and every association is a foreign key: userId in Order is the association to User, which is why the class diagram does not list it as an attribute. The one renamed column, pickup_slot, is explained above.
• Against the sequence diagrams (Chapter 22). Every message sent to part of the system is an operation or a function it really has: taking the stock is takeStock.
• Against the state machine (Chapter 23). The six values of Status are the six states, and canMoveTo allows exactly its five arrows.

Do this for your project

1. Underline the nouns in your requirements and use cases; the important ones are your candidate classes.
2. For each class, list what it must remember: those are its attributes, each with a type.
3. Add only the operations that carry a business rule.
4. Draw the associations, and write a multiplicity at both ends of every one. Read each aloud across the line.
5. Choose composition only where a part cannot exist without its whole; avoid the hollow diamond unless you can say what it means.
6. Use an enumeration for a fixed set of values, and a subclass only for a kind of thing that holds different data.
7. Check every attribute against your database design, and write down any name that breaks your mapping rule.

Mistakes that cost marks

Foreign keys as attributes. userId : int inside Order says the same thing as the line to User, twice, and in the database's words rather than the model's.

Missing multiplicities. A line with no numbers says nothing about how many.

Multiplicities read the wrong way round. Read from one class across the line to the far end.

Composition everywhere. A menu item is not part of an order; it exists without one.

A class for every screen or table, such as MenuPage or OrderForm, in a domain model.

Subclasses for roles, when the only difference between the "subclasses" is what they are allowed to do.

Operations with no rule behind them, such as a getter and a setter for every attribute. They add ink and no information.

Quick revision

• A class: name, attributes, operations. Attribute: visibility / name : type [multiplicity] = default.
• Visibility: + public, - private, # protected, ~ package. A slash marks a derived attribute.
• Association with a multiplicity at each end, read across the line; an open arrowhead marks navigability.
• Composition (filled diamond): the part is in at most one whole and dies with it. Aggregation (hollow diamond): looser, meaning left to the modeller.
• Generalisation: hollow triangle to the general class. Dependency: dashed arrow from the user to the used.
• A domain model describes the problem's things; a design model describes the code's classes.

Questions you must be able to answer

1. What does a class diagram show? The classes of a system, with their attributes and operations, and the relationships between them: associations with multiplicities, aggregation and composition, generalisation and dependency. It shows structure that is true at every moment, not what happens in any one scenario.

2. Explain the multiplicities on the association between User and Order in the worked diagram. There is a 1 at the User end and 0..* at the Order end. Reading across the line, a user places any number of orders, including none, and every order is placed by exactly one user.

3. What is the difference between aggregation and composition? Which is used between Order and OrderItem, and why? In composition the part belongs to at most one whole at a time and is deleted with it; aggregation is a looser whole-and-part whose exact meaning UML leaves to the modeller. Order and OrderItem use composition, because an order item cannot exist without its order and never belongs to two.

4. Why is there no Owner subclass of User? Because owners, counter staff and students hold the same data and differ only in what they are permitted to do. A difference in permission is represented by the value of the role attribute, an enumeration; a subclass would be needed only if an owner held different data or behaved differently as an object.

5. Why does OrderItem store a unit price when MenuItem already has a price? Because prices change. The unit price is copied into the order item when the order is placed, so that an order keeps the price the student agreed to, whatever the menu says later. The order's total is stored for the same reason, although it could be derived.

6. The worked backend has no Order class. Is its class diagram still correct? Yes. The diagram is a domain model of what the system knows and does; the code keeps the data in plain objects and the rules in functions, and each operation in the diagram corresponds to a function in the code, such as canMoveTo to canMove and takeStock to the store's takeStock.

There are others. par shows parts that run at the same time, in any interleaving. critical marks a region that must not be interleaved with anything else. A frame labelled ref stands for a whole other sequence diagram, drawn elsewhere, which keeps a large scenario readable.

Drawing one: a scenario at a time

A sequence diagram shows one scenario. Not the system; not even a whole use case with every branch. Choose the scenario first:

1. Pick a use case, and write its main success scenario and its important extensions (Chapter 12).
2. Choose the level. Between the user, the page and the server, the participants are what the user sees. Inside the server, they are the parts of the code. Mixing the two in one diagram gives a diagram too wide to read.
3. Put the participants left to right, in the order in which they first act.
4. Write the messages top to bottom, each named after what its receiver can do.
5. Add a frame for each extension: break for a refusal, alt for a real choice, opt for something that may or may not happen, loop for repetition.
6. Check every message against the class diagram and the API.

The worked diagrams

The worked team drew UC-4, Place an order, at both levels.

The page and the server

Figure 22.1 UC-4 Place an order, between the student, the page and the server

@startuml sequence-request
!pragma layout smetana
autonumber
hide footbox
actor Student
participant "Menu page" as Page
participant "API" as Api

Student -> Page : Place order
Page -> Api : POST /api/orders
Api -> Api : check session\nand role
break not a signed-in student
  Api --> Page : 401 or 403
  Page --> Student : the message
end
Api -> Api : check input
break input wrong
  Api --> Page : 400 and\nthe problems
  Page --> Student : each problem\nby its field
end
Api -> Api : place order
alt accepted
  Api --> Page : 201 and the order
  Page --> Student : its number
else refused
  Api --> Page : 409 and the reason
  Page --> Student : the reason
end
@enduml

Read it top to bottom. The student taps Place order (1), and the page sends POST /api/orders (2). The API then does three things in turn, each drawn as a self-message, and each can stop the request:

• Checks the session and the role (3). If the student is not signed in, the answer is 401; if the person signed in is not a student, 403. The first break frame: nothing after it happens.
• Checks the input (6). A slot that does not exist, or an item listed twice, and the answer is 400 with each problem. The page shows a problem beside its field where the form has one, and the rest in the message at the top.
• Places the order (9). Either it is accepted, 201 with the order, and the page shows its number; or it is refused, 409 with the reason, such as "Only 2 left". An alt, because both are ordinary outcomes of placing an order.

The status codes are the application's own (Chapter 48 explains each). Every message the page sends is a route of the API, and every answer is one the page handles.

Inside the server: the transaction

Message 9, "place order", is where the rules of FR-7 to FR-11 are enforced. The second diagram opens it up:

Figure 22.2 Message 9 opened up: placing an order inside one database transaction

@startuml sequence-transaction
!pragma layout smetana
autonumber
hide footbox
participant "API" as Api
participant "Order\nservice" as Service
database "MySQL" as Db

Api -> Service : place(user, order)
Service -> Service : is the slot\nstill open?
break slot closed
  Service --> Api : slot_closed
end
Service -> Db : BEGIN
Service -> Db : lock the\nstudent's row
Service -> Db : count their orders\nfor this slot
Db --> Service : the count
break count is not 0
  Service -> Db : ROLLBACK
  Service --> Api : slot_taken
end
loop each item in id order,\nuntil one is short
  Service -> Db : take stock only\nif enough is left
  Db --> Service : 1 row changed, or 0
  opt 1 row changed
    Service -> Db : read its price
  end
end
break an item was short
  Service -> Db : read what is left
  Service -> Db : ROLLBACK
  Service --> Api : sold_out or\nitem_unavailable
end
Service -> Db : INSERT the order\nand its lines
Service -> Db : COMMIT
Service --> Api : the new order
@enduml

• Is the slot still open? (2) Each slot closes 15 minutes before its time (FR-8). If it has closed, the service answers slot_closed at once, before touching the database.
• BEGIN (4). Everything that follows, up to COMMIT or ROLLBACK, happens as one transaction: all of it or none of it (Chapter 45).
• Lock the student's row, then count their orders for this slot (5 to 7). FR-10 allows one active order per student per slot. The lock means that if the same student taps Place order twice in the same instant, the second request waits until the first has finished, and its count then sees the first order. If the count is not zero, the second break: roll back and answer slot_taken. The project's tests send two orders from one student at the same moment and check that exactly one is accepted.
• The loop (10 to 12). For each item, in the order of its id, the service takes the stock only if enough is left, in one statement, and the database answers how many rows it changed: 1 if the stock was taken, 0 if not. Only when it was taken does the service read the item's price, in the opt frame. Taking the items in id order is deliberate: two orders that share items always take them in the same order, so they can never wait for each other in a circle.
• An item was short (13 to 15). The third break. The service reads what is left, so that the student can be told "Only 2 left" rather than just "No", rolls back everything taken so far, and answers sold_out, or item_unavailable if the owner has switched the item off.
• Otherwise (16 to 18), insert the order and its lines, commit, and return the new order.

This is the diagram that answers the question every examiner asks of an ordering system: what happens when two students order the last biryani at the same moment? Both run message 10 at once. The database lets only one of them change the row while enough is left: that student's update changes 1 row, the other's changes 0, and the second student is told the biryani is sold out. Chapter 45 proves it with a test in which twenty students order the last five plates at the same moment, and exactly five are served.

What the first drawing got wrong

The team's first version drew the shortage as an alt inside the loop: one part for "taken", one for "short", with the rollback in the second. After the alt the diagram carried on to INSERT and COMMIT, so read top to bottom it said that the order was saved even after it had been rolled back. It also had no refusal for a second order in the same slot, although FR-10 forbids one. Both mistakes survived the design review. When the ordering code was built, in the first increment, a reviewer who compared the diagram with it found both, which is exactly what Chapter 19's checks are for, and the corrected diagrams became version 1.1 of the UML set (Chapter 35).

The fix was to draw each refusal as a break at the level of the whole diagram, so that everything after it is visibly skipped, and to make the loop stop at the first short item, as the code does. Every message was then checked against a function in the code: isSlotOpen, lockUser, countActive, takeStock, the menu store's findById, refusal and insert.

What the diagrams leave out

The replies to BEGIN, the lock, INSERT and COMMIT are not drawn; each diagram draws a reply only where its content matters to the story, such as the count or the rows changed. Activation bars are left out for the same reason. Both are choices of readability, not of UML: if your guide expects every reply and every activation, draw them.

The source, line by line

• actor Student and participant "Menu page" as Page declare the lifelines, left to right in the order written; database "MySQL" as Db draws the database with a cylinder head.
• Page -> Api : POST /api/orders is a synchronous message; Api --> Page : 201 and the order is a reply, dashed.
• Api -> Api : check input is a self-message.
• break slot closed ... end, alt accepted ... else refused ... end, loop ... end and opt ... end draw the fragments; the text after the operator becomes the guard.
• autonumber numbers the messages, which is what lets the text above say "message 9", and hide footbox stops PlantUML repeating the participants' names at the bottom.

Mistakes examiners circle

One diagram for the whole system. A sequence diagram is one scenario; draw several.

An alt where a break is meant. If the scenario carries on after a failure, the diagram says the failure did not matter.

Arrows that point up, or messages drawn out of order.

Messages nobody can receive: "save order" sent to a class with no such operation, or to the database as if it had methods.

Two levels in one diagram: a tap on a phone and an SQL statement among eight participants.

Guards missing from the fragments, so the reader cannot tell which part runs when.

Do this for your project

1. Draw a sequence diagram for each use case whose steps matter: at least the one your project exists for.
2. Draw it at the level of the user and the server first; open up the server in a second diagram where the rules live.
3. Name every message after a route, an operation or a statement your system really has.
4. Draw every refusal the code makes, each as a break, so that nothing after it appears to happen.
5. Compare the diagram with the code line by line once the code exists, and fix whichever is wrong.

Quick revision

• Lifelines across the top; time runs down; messages are horizontal or downward.
• Synchronous: filled arrowhead. Asynchronous: open arrowhead. Reply: dashed line. Creation: dashed, to the new lifeline's head.
• Activation: a thin rectangle on the lifeline.
• alt (choose one), opt (run or not), loop (repeat; loop(min, max)), break (run instead of the rest); guards in [square brackets], [else] for none of the others.
• Also par (in parallel), critical (not interleaved), ref (another diagram).
• One scenario per diagram, at one level.

Questions you must be able to answer

1. What does a sequence diagram show? The messages exchanged between the participants of one scenario, in time order from top to bottom: who calls whom, in what order, and what comes back, with frames for the parts that are chosen, optional, repeated or cut short.

2. Distinguish synchronous and asynchronous messages and replies in UML's notation. A synchronous message, whose sender waits, is a solid line with a filled arrowhead; an asynchronous message, whose sender does not wait, is a solid line with an open arrowhead; a reply is a dashed line.

3. What is the difference between alt, opt and break? Alt chooses at most one of several parts, the one whose guard is true. Opt runs its single part or does not. Break runs its part instead of the rest of the enclosing fragment, which is skipped, and is used for an early exit such as a refusal.

4. What happens, in the worked diagram, when two students order the last plate at the same moment? Both send the conditional update that takes stock only if enough is left. The database lets only one of them change the row: that update changes one row and the order goes on; the other changes none, and that student's order is rolled back and refused as sold out.

5. Why does the order service take items in order of their id? So that two orders that share items always take them in the same order. Each then waits for the other at most once, in one direction, and they can never deadlock waiting for each other in a circle.

6. What was wrong with the worked team's first sequence diagram, and how was it fixed? It drew a stock shortage as an alt inside the loop and then continued to insert and commit the order, so the diagram showed an order saved after a rollback; and it had no refusal for a second order in the same slot. Each refusal was redrawn as a break at the level of the whole diagram, and every message was checked against the code.

Swimlanes, and who may be in them

A swimlane says who does each action. Unlike a use case diagram, which shows only actors, the people who work the system, an activity diagram may give a lane to anyone in the process, including people who never touch the software. That is often the point of drawing one: it shows where the system fits into how the work is really done.

An activity diagram is not just a flowchart

It looks like one, and for a simple process it is read like one. UML adds three things a flowchart does not have: lanes that assign the work, forks and joins for work done in parallel, and a precise meaning for the two kinds of ending, which the specification defines: an activity final node stops every flow in the activity, a flow final node only its own.

Drawing one

1. Choose one process, from a use case or from the organisation's own work: "an order from the student's side", "serving an order".
2. List who takes part, and give each a lane.
3. Write the actions in order, each a verb phrase, in the lane of whoever does it.
4. Put every choice in a decision diamond in the lane of whoever makes it, and label every outgoing arrow with its guard.
5. Bring alternative paths back together with a merge, and parallel paths with a join.
6. End with an activity final node.
7. Check each action against the requirements and, where the system does it, against the code.

The worked diagrams

Ordering, from the student's side

Figure 23.1 Placing an order, from the student's side

@startuml activity-place-order
!pragma layout smetana
|Student|
start
repeat
  :Choose food
  and a slot;
  :Tap Place order;
  |System|
  :Check the slot and
  earlier orders, and
  take the stock, all
  or nothing;
  backward:Say why;
repeat while (Refused?) is (yes)
->no;
:Save the order
with its number;
|Student|
:Note the number;
stop
@enduml

The diagram is a loop. The student chooses food and a slot and taps Place order. The system makes one attempt, all or nothing: it checks the slot and the student's earlier orders, and takes the stock of every item, and either all of that succeeds or none of it happens. At the decision "Refused?", the system either says why, and the flow goes back, through the merge at the top, to the student choosing again; or it saves the order with its number, which the student notes.

The decision is in the System lane, because the system decides. The loop is drawn with a merge at the top and the decision at the bottom, which is how an activity diagram draws "repeat until".

Serving, from the counter's side

Figure 23.2 Serving an order, from the counter's side

@startuml activity-serve-order
!pragma layout smetana
|Counter|
start
:Start
preparing;
|Kitchen|
:Cook the
dishes;
|Counter|
:Mark ready;
if (Student
in time?) then (no)
  :Mark not
  collected;
else (yes)
  |Student|
  :Give the
  number
  and pay;
  |Counter|
  :Mark
  collected;
endif
stop
@enduml

Three lanes. The counter taps Start preparing; the kitchen cooks the dishes; the counter taps Mark ready. Then the one real decision of serving: does the student come before the break ends? If not, the counter marks the order not collected. If so, the student gives the number and pays, and the counter marks it collected. The two paths meet at a merge, and the activity ends.

The kitchen has a lane, but is not an actor. No cook ever signs in, so the kitchen is not in the use case diagram (Chapter 20). But the kitchen does real work in this process, and the diagram would be false without it.

What the first drawings got wrong

Both activity diagrams were redrawn when the team checked them against the code of the first increment, in version 1.1 of the UML set (Chapter 35).

Check, then take. The first ordering diagram had two actions, "Check the slot and the stock" and then, after the decision, "Take the stock". That describes exactly the mistake the system is designed to avoid: between checking and taking, another student can take the last plate, and two students are both promised it. The code checks and takes in one statement (Chapter 22). The diagram now shows one all-or-nothing action, so it says what the code does.

The decision in the wrong lane. "Accepted?" sat in the Student lane, as if the student decided whether their own order was accepted. It is the system's decision, so it moved to the System lane.

No kitchen. The first serving diagram had only the counter and the student, so the dishes appeared to cook themselves.

When a state machine says it better

An activity diagram follows a process from step to step. Sometimes the question is different: what can happen to one thing over its life? An order is placed, prepared, made ready, collected, or cancelled, or never collected. The rule FR-15 states is not a process; it is a list of which status may follow which, and who may make each move.

That is what a state machine diagram, another UML behaviour diagram, is for:

• A state is a condition the thing can be in: a rectangle with rounded corners.
• The initial pseudostate, a small solid circle, points to the first state.
• A final state, a circle around a small solid circle, is where its life ends.
• A transition is an arrow from one state to another, labelled in UML's form trigger [guard] / effect: what makes it happen, the condition that must hold, and what the system does as it happens. Any part may be left out.

The worked state machine

Figure 23.3 An order's life: its six states and the five moves between them

@startuml order-states
!pragma layout smetana
hide empty description
[*] --> placed : order accepted
placed --> preparing : counter taps\nStart preparing
placed --> cancelled : student cancels\n/ stock returned
preparing --> ready : counter taps\nMark ready
ready --> collected : counter taps\nCollected and paid
ready --> no_show : counter taps\nNot collected
cancelled --> [*]
collected --> [*]
no_show --> [*]
@enduml

Six states and five transitions between them. Each trigger names the button that fires it on the counter's screen, word for word: Start preparing, Mark ready, Collected and paid, Not collected. Only one transition has an effect: when a student cancels, the stock is returned, so the portions go back on sale. When an order is not collected there is no effect, and that is deliberate: the food was cooked, and it is gone.

The diagram is the code's rule, drawn. The application stores exactly these moves, and who may make each:

// Which status may follow which, and whose move it is.
const MOVES = {
  placed: { preparing: 'counter', cancelled: 'student' },
  preparing: { ready: 'counter' },
  ready: { collected: 'counter', no_show: 'counter' },
};

and decides in one place that only a cancelled order returns its stock:

// A cancelled order gives its food back to the stock. A
// no-show does not: that food was cooked and is gone.
function returnsStock(to) {
  return to === 'cancelled';
}

Every arrow of the state machine is an entry in MOVES, and every entry in MOVES is an arrow. Any other move, such as placed straight to ready, is refused (Chapter 43).

Do this for your project

1. Draw an activity diagram for each process your system changes: how the work is done with it, including the people who never use it.
2. Give every participant a lane, and put each decision in the lane of whoever decides.
3. Never split an operation that must be all or nothing into "check" and "do" in your diagram, or in your code.
4. Use a fork and a join only for work that really happens at the same time, and a decision and a merge for choices.
5. If your system has something that moves through statuses, such as an order, a booking or an application, draw its state machine, and make your code's rule table match it exactly.

Mistakes that cost marks

A decision drawn as a fork, or a fork as a decision: bars mean "all paths", diamonds "one path".

Guards missing from a decision's arrows, so nobody can tell which way the flow goes.

Decisions in the wrong lane. Whoever makes the choice owns the diamond.

Paths that never end, or end in mid-air, with no final node.

A flowchart of the code, with "i = i + 1" as an action. An activity diagram of a process is about the work, in the words of the people who do it.

Statuses drawn as an activity diagram. If the question is "what can happen to this order", draw a state machine.

Quick revision

• Action: rounded rectangle. Initial node: solid circle. Activity final: bull's eye, stops every flow. Flow final: circle with an X, stops one flow.
• Decision and merge: diamonds, one path runs. Fork and join: bars, all paths run; a join waits for all of them.
• Guards in square brackets on a decision's outgoing arrows.
• Swimlanes show who does each action, and may include people who never use the system.
• A state machine follows one thing through its life: states (rounded rectangles), transitions labelled trigger [guard] / effect, an initial pseudostate and a final state.

Questions you must be able to answer

1. What does an activity diagram show, and what are swimlanes for? The flow of a process from action to action, with its choices, its parallel paths and its ends. Swimlanes divide the actions by who performs them, so the diagram shows who does what as well as in what order.

2. Distinguish a decision node from a fork node. A decision, a diamond, sends the flow down exactly one of its outgoing paths, the one whose guard is true. A fork, a bar, sends it down all of its outgoing paths at once, to run in parallel; a join then waits for all of them.

3. What is the difference between an activity final node and a flow final node? An activity final node, a bull's eye, ends the whole activity: every flow in it stops. A flow final node, a circle with an X, ends only the flow that reaches it, and any other flows carry on.

4. Why is the kitchen a lane in the serving diagram but not an actor in the use case diagram? Because an actor must interact with the system, and no cook signs in; but the kitchen does real work in the serving process, and an activity diagram describes the process, including people who never use the system.

5. What was wrong with drawing "check the stock" and "take the stock" as two actions? It describes a check-then-act race: between the check and the taking, another student can take the last portion, and both are promised it. The system checks and takes in one indivisible step, and the diagram must show one all-or-nothing action.

6. When would you draw a state machine diagram instead of an activity diagram? When the question is what can happen to one thing over its life rather than how a process flows: its states, the events that move it between them, the conditions and the effects. The worked order's statuses and the moves allowed between them are a state machine, and the code's rule table matches its arrows exactly.

Participation. Whether every entity of a type must take part in the relationship. Total: every order is placed by some user. Partial: a user may have placed no orders at all.

Weak entity. An entity that cannot be identified by its own attributes, only together with the entity it depends on. A line of an order, identified by its order and its menu item, is the classic example.

Two notations

Chen's notation

The notation textbooks name after Chen draws:

Chen's notation is good for thinking: every attribute, key and relationship is a separate shape, so the structure of the data is visible at a glance. It is poor for a large design, because the ellipses soon fill the page.

Crow's foot notation

The other common notation draws each entity as a box listing its attributes, and puts the cardinality and participation at the ends of the relationship line:

The circle means zero, so the participation is optional; the bar means one; the three-pronged crow's foot means many. Read it the way you read a UML multiplicity: from one entity, along the line, to the symbol at the far end. This is the notation of most database design tools, and it fits a design with every column in it.

Resolving a many-to-many relationship

A relational database cannot store a many-to-many relationship directly: a column holds one value, so neither the orders table nor the menu items table can hold "all the items of this order" or "all the orders of this item". The relationship becomes a table of its own, an associative entity:

1. Make a new entity for the relationship: order_items.
2. Give it a foreign key to each side: order_id and menu_item_id.
3. Make the pair its primary key, if each pair may occur only once: one line per item per order.
4. Move the relationship's own attributes into it: quantity, and the unit_price_paise copied at the moment of ordering.

The one M:N relationship becomes two 1:N relationships: an order has many order items, and a menu item appears in many order items. The line of an order is also exactly the weak entity described above.

Conceptual, logical, physical

The same data can be designed at three levels, and the worked team drew two of them:

• A conceptual model shows the entities, their relationships and the important attributes, in the language of the problem. It ignores tables and types. Chen's notation suits it.
• A logical model shows every attribute, every key and every relationship in the form the database will need, with many-to-many relationships resolved. Crow's foot suits it.
• A physical model is the schema itself: the SQL that builds the tables, with exact types, constraints and indexes (Chapter 29).

The worked diagrams

The conceptual model, in Chen's notation

Figure 24.1 The worked conceptual model in Chen's notation

@startchen er-chen
top to bottom direction
entity USER {
  Id <<key>>
  Name
}
entity ORDER {
  Id <<key>>
  Slot
  Total <<derived>>
}
entity MENU_ITEM {
  Id <<key>>
  Price
}
relationship PLACES {
}
relationship CONTAINS {
  Quantity
  UnitPrice
}
USER -1- PLACES
PLACES =N= ORDER
ORDER =M= CONTAINS
CONTAINS -N- MENU_ITEM
@endchen

Three entities and two relationships. A USER PLACES many ORDERs, 1:N. An ORDER CONTAINS many MENU_ITEMs, and a menu item is in many orders, M:N, with the quantity and the unit price as attributes of CONTAINS, because they belong to the pair.

Keys are underlined: each Id. Total, dashed, is derived: it can be computed from the quantities and unit prices of the order's items.

Participation. ORDER's two lines are drawn thick, because its participation in both relationships is total: every order is placed by a user and contains at least one item. USER and MENU_ITEM take part partially: a user may never order, and an item may never be ordered. The textbook symbol for total participation is a double line. PlantUML draws a thick line instead, from the = in PLACES =N= ORDER; say so beside your diagram if you draw it this way, since an examiner may look for the double line.

What is left out. The conceptual model shows the canteen's data as the canteen would describe it, so the table of signed-in sessions, which exists only because the application needs it, does not appear, and each entity shows only the attributes that make the relationships clear. Every attribute is in the logical model below.

The logical model, in crow's foot notation

Figure 24.2 The worked logical model in crow's foot notation: every column of the schema

@startuml er
!pragma layout smetana
top to bottom direction
hide circle
skinparam linetype ortho

entity users {
  * id : INT <<PK>>
  --
  * name : VARCHAR(80)
  * email : VARCHAR(120) <<unique>>
  * password_hash : VARCHAR(200)
  * role : ENUM
  * is_active : BOOLEAN
  * created_at : DATETIME
}

entity sessions {
  * id : CHAR(64) <<PK>>
  --
  * user_id : INT <<FK>>
  * created_at : DATETIME
  * expires_at : DATETIME
}

entity orders {
  * id : INT <<PK>>
  --
  * user_id : INT <<FK>>
  * pickup_date : DATE
  * pickup_slot : TIME
  * status : ENUM
  * total_paise : INT
  * created_at : DATETIME
  * updated_at : DATETIME
}

entity order_items {
  * order_id : INT <<PK, FK>>
  * menu_item_id : INT <<PK, FK>>
  --
  * quantity : TINYINT
  * unit_price_paise : INT
}

entity menu_items {
  * id : INT <<PK>>
  --
  * name : VARCHAR(60) <<unique>>
  * category : ENUM
  * price_paise : INT
  * is_veg : BOOLEAN
  * is_available : BOOLEAN
  * stock_left : INT
}

users ||--o{ sessions
users ||--o{ orders
orders ||--|{ order_items
order_items }o--|| menu_items
@enduml

Five tables, every column of the schema, and the M:N relationship already resolved into order_items. Read each relationship both ways, from one table along the line to the far end:

• users to sessions: a user has zero or many sessions; a session belongs to exactly one user.
• users to orders: a user has zero or many orders; an order belongs to exactly one user.
• orders to order_items: an order has one or many items, never none; an item line belongs to exactly one order.
• order_items to menu_items: a menu item appears in zero or many item lines; each line is for exactly one menu item.

Inside the boxes, PlantUML's * before a column marks it mandatory: it must have a value, which is NOT NULL in SQL, and every column here is. «PK» and «FK» mark the primary and foreign keys; order_items has a composite primary key made of its two foreign keys, which is why each item can appear only once in an order. «unique» marks the other candidate keys: no two users share an email, and no two menu items share a name.

The source, line by line

• entity users { ... } draws an entity box; -- inside it draws the line that separates the key from the other columns.
• * id : INT <<PK>> is a mandatory column with a keyword.
• users ||--o{ sessions is a relationship: || at the users end means exactly one, o{ at the sessions end means zero or many. |{ would be one or many, and o| zero or one.
• hide circle removes PlantUML's own lettered circle from each box, and skinparam linetype ortho draws the lines with right angles.
• In the Chen source, entity, relationship, <<key>> and <<derived>> draw the shapes, and -1-, =N= put the cardinality on each line, = for total participation.

Checking it against the class diagram

Chapter 19's fifth check, class against ER, and one of Chapter 21's rules, meet here:

The check runs from the class diagram to the ER diagram: every attribute of every class must be stored. The reverse need not hold, and the table shows the one kind of column that is stored without being in the domain model.

The composition rows are worth noticing. The association from Order to User has no ON DELETE CASCADE, and that is deliberate: a user's orders are the canteen's records of what it sold, so the application never deletes a user. An account is switched off instead, by setting is_active to false, which sign-in and every session check honour. The first release has no screen for that; it is done in the database.

Do this for your project

1. List the entities from your class diagram's classes, and give each a primary key.
2. List each entity's attributes; mark composite, multivalued and derived ones, and every candidate key.
3. Draw each relationship, and give it a cardinality ratio and a participation at both ends.
4. Resolve every many-to-many relationship into an associative entity, with its own attributes.
5. Draw a conceptual model in Chen's notation for your report, and a logical model with every column in crow's foot notation for building the database.
6. Check it against your class diagram in both directions, and write down every difference with its reason.

Mistakes that cost marks

A many-to-many relationship left unresolved in a logical model: it cannot become a table.

A relationship's attributes placed in an entity, such as quantity in the menu item.

No primary key, or a name used as the key when two things can share a name.

Cardinality written at the wrong end. Read from one entity across the line to the far end.

Participation missing. "Every order has at least one item" is a rule the database should enforce, and it starts in the diagram.

Foreign keys without the line, or lines without a foreign key: the diagram and the tables must say the same thing.

Quick revision

• Entity type (rectangle), attribute (ellipse), relationship (diamond), in Chen's notation; key underlined, multivalued double ellipse, derived dashed ellipse, weak entity double rectangle.
• Keys: candidate, primary, unique, composite, foreign.
• Cardinality ratio: 1:1, 1:N, M:N. Participation: total (every entity takes part; double line) or partial.
• Crow's foot: bar = one, circle = zero, crow's foot = many; read from one entity to the far end.
• Resolve M:N into an associative entity with a foreign key to each side and the relationship's attributes.
• Conceptual (Chen), logical (crow's foot, every column), physical (the SQL schema).

Questions you must be able to answer

1. What does an ER diagram show? The entity types a system stores data about, their attributes and keys, and the relationships between them, with each relationship's cardinality ratio and participation. It is the design from which the database tables are built.

2. Distinguish cardinality from participation, with an example of each from the worked diagram. Cardinality says how many entities of one type can relate to one of the other: a user places many orders, and each order is placed by one user, 1:N. Participation says whether every entity must take part: every order must be placed by some user, total; a user need not place any order, partial.

3. How is a many-to-many relationship turned into tables? Use orders and menu items. It becomes an associative table, order_items, with a foreign key to each side, order_id and menu_item_id, which together form its primary key, and with the relationship's own attributes, the quantity and the unit price at the time of ordering. The M:N relationship becomes two 1:N relationships.

4. What is a derived attribute? Give the worked example. An attribute whose value can be computed from others. An order's total is the sum of its items' quantities multiplied by their unit prices; Chen's notation draws it as a dashed ellipse.

5. What is a weak entity? An entity that cannot be identified by its own attributes alone, only together with the entity it depends on. An order's line is identified by its order and its menu item together, and has no identity without the order.

6. Why are the canteen's users never deleted from the database? Because their orders are the canteen's records of what it sold, and deleting a user would mean deleting or orphaning those orders. So the orders table does not cascade deletes from users, the application has no way to delete one, and an account is switched off instead by setting is_active to false, which sign-in and every session check honour.

Environments inside environments. Inside the lab desktop runs Ubuntu 24.04, and inside Ubuntu three more execution environments: Nginx, a web server; Node.js 24, the runtime that executes the application; and MySQL 8.0, the database server.

Three artifacts. canteen-preorder, the application, deployed in Node.js; the canteen database's tables, deployed in MySQL; and canteen.apk, deployed on the phones.

Four communication paths, and what travels on each:

• Phone and counter to Nginx: HTTP on port 80, across the college Wi-Fi. This is the only door the system opens to the network.
• Nginx to the application: HTTP to 127.0.0.1, port 3000. The address 127.0.0.1 means "this machine": the connection never leaves the lab desktop. Nginx receives every request and hands it on.
• The application to MySQL: TCP to 127.0.0.1, port 3306, also inside the machine.

So neither the application nor the database can be reached from the network at all. The application listens on 127.0.0.1 unless told otherwise, which is its own default, and Ubuntu's MySQL listens on 127.0.0.1 in the configuration Ubuntu itself ships. Of the system's own software, only Nginx faces the network, and it is where HTTPS will be added (Chapter 60).

UML draws a communication path as a plain line. The worked diagram adds an arrowhead to show which side opens the connection, the phone to Nginx and never the other way, which is a convention worth stating beside your own diagram.

HTTP on the college network, and when HTTPS comes