Screenshots

Read down the right-hand column: every functional requirement is covered, and nothing is photographed twice. That is the test of a shot list. Two more shots go in the implementation chapter rather than the appendix, because they are evidence of deployment and not of a requirement: the service running under systemd, and the browser at 320 pixels wide with the page still whole.

Make the state reproducible

The reason students end up with bad screenshots is that they take them from whatever the application happens to contain at midnight. Every project in this book's shape has three switches that give you the same picture every time.

The seeded accounts and dishes. npm run db:setup loads sql/seed.sql: Lata Pawar the owner, Ganesh More at the counter, and the students Priya Menon, Kabir Singh, Ananya Rao and Yusuf Khan, all with the password canteen-demo, and fourteen dishes with prices and stock. Never take a screenshot with a real student's name or address in it, and you never have to: the demonstration data is there for this.

The clock. Screens like the counter's exist only during the lunch break, and a screenshot session at 10 p.m. shows every slot closed. DEMO_TIME in .env stops the clock at an instant you choose:

Leave DEMO_TIME empty for real use. A screenshot taken with it set is honest as long as the report says the data is demonstration data, which is what appendix C's first line says.

The window. Decide one width and keep it. The worked shots were taken in a browser window 1280 pixels wide for the counter and owner pages and 390 wide for the student's, which is a phone's width, because that is how each is really used. A picture of a phone page in a 1600-pixel window with two thirds of it empty teaches the examiner nothing.

A repeatable order of work, which takes about twenty minutes for twelve shots:

1. npm run db:setup to put the data back.
2. Set DEMO_TIME for the group of shots you are taking, and npm start.
3. Sign in as the account that screen belongs to.
4. Place the orders the shot needs, in the same words every time.
5. Take the shot, name the file for what it shows, and write its caption at once.

Capturing and captioning

Take a real screenshot, never a photograph of a screen. Cmd+Shift+4 on a Mac, Win+Shift+S on Windows, or the browser's own full-page capture. A photograph of a monitor, with the room's reflection in it, is the single clearest sign of a report assembled in a hurry.

Crop to the browser's content, or include the address bar deliberately when the address is the point. Close every other tab, hide a personal bookmarks bar, and shut the developer tools.

Caption every shot, and number it. A caption says what the reader is looking at and what it proves:

Figure C.8: the counter's list for the 12:40 slot, 29 September 2026. Order 15 is ready to collect, order 16 is being prepared, and order 17 has just been placed. The four buttons are the only moves the counter may make (FR-14, FR-15).

Three things in that caption, and all three matter: what screen, what state, and which requirement. A screenshot with no caption is a decoration; the same screenshot with that caption is evidence.

Keep them as PNG, not JPEG. Text and flat colour compress badly as JPEG and come out fringed, which on a printed report looks like a low-quality scan.

Save the files with names that say what they are, in one folder, in the repository: docs/screenshots/08-counter-1240.png. The report then cites the folder, and the next person to change the counter page knows exactly which picture to retake.

Retake them last

The screenshots are the last thing you make before the report is bound. In the worked project the counter's order number was made larger on the afternoon of 9 October, because Ganesh said at the acceptance session that he read it twice (Chapter 54). Every counter screenshot taken before that afternoon shows the old size, and the report's own text describes the change. The rule that prevents the contradiction is mechanical:

After the last change to any screen, retake every screenshot of that screen. Twelve shots from a seeded database with a fixed clock is twenty minutes' work, which is why the state was made reproducible in the first place.

The same rule applies to the presentation (Chapter 74) and to the README (Chapter 69): both carry pictures, and both go stale the same way.

Do this for your project

1. Build the shot list from your requirements, one shot for each, none twice.
2. Reset to seeded demonstration data before a session; never screenshot a real user's data.
3. Fix the clock, or otherwise fix the state, so the same picture can be taken again.
4. Choose one window width for each kind of screen and keep it.
5. Screenshots, not photographs; PNG; no developer tools, no personal tabs.
6. Number and caption each one: what screen, what state, which requirement.
7. Keep them in the repository with meaningful names.
8. Retake every affected shot after the last change to a screen, and do it before binding.

Mistakes that cost marks

Photographs of a monitor, taken with a phone.

Screenshots of a version that no longer exists, contradicting the report's own text.

Five pictures of the same page and none of the owner's report.

No captions, so the examiner must guess what each proves.

Real students' names, addresses or orders in the pictures.

Unreadable text, because the page was captured zoomed out or the image was scaled down to fit.

Developer tools open, a personal bookmarks bar, or twenty other tabs across the top.

An error message in the corner that the report never mentions.

Quick revision

• Screenshots are evidence, and the only evidence before the demonstration.
• Build the shot list from the requirements: one for each, nothing twice.
• Make the state reproducible: seeded data, a fixed clock (DEMO_TIME), one window width.
• Never a real user's data; the demonstration accounts exist for this.
• Real screenshots, PNG, cropped, nothing personal on screen.
• Number and caption: what screen, what state, which requirement.
• Retake after the last change, before binding; the counter's order number is the worked example.

Questions you must be able to answer

1. Why are screenshots a deliverable in their own right? Because the report is read before the system is seen, and until the demonstration they are the only evidence that the software exists and behaves as described. They also show whether the finished screens match the design the report presents.

2. How do you decide which screenshots to take? From the requirements, not from the application. Each functional requirement gets the one shot that proves it, which is also how you notice that a requirement has no screen to photograph.

3. What makes a screenshot reproducible, and why does that matter? Seeded demonstration data, a fixed clock and a fixed window width. It matters because screens go stale: when a page changes, the shot must be retaken, and that is twenty minutes' work only if the state can be recreated exactly.

4. What belongs in a caption? The screen, the state it is in, and what it proves, with a requirement number. "The counter's list for the 12:40 slot: order 15 ready, order 16 being prepared, the four moves the counter may make (FR-14, FR-15)."

5. Why must screenshots never contain real users' data? Because a report is read, copied and kept by people who were never told about it, and a student's name beside their lunch order is their business. The seeded demonstration accounts exist precisely so that no real data is ever needed.

6. When should screenshots be taken? Last, after the final change to the screens, and before the report is bound. A screenshot older than the software it depicts contradicts the report that contains it, and that contradiction is the examiner's next question.