Case study: how to scope a device-information tool, from idea to specification

This is a worked example we use to teach scoping, not a story about a particular client. It shows how a one-sentence idea becomes a specification you can actually build, which is the step most beginners skip.

The idea

"I want software that checks a computer's serial number, RAM, processor and other details." It sounds clear, but it leaves out who uses it, where it runs and what happens to the data.

Step 1: name the users and the problem

Suppose an IT team looks after 200 office laptops and keeps records in messy spreadsheets. Their problem: they do not know exactly what hardware they own, so warranty claims, upgrades and audits are slow.

Step 2: decide what it must do

• Must have: read serial number, processor, RAM, storage, operating system and battery health on one computer.
• Should have: save a report as PDF or CSV, and send results to a central dashboard.
• Later: alerts when warranties expire.

Step 3: face the technical reality

A normal website cannot read this information, because browsers keep websites away from hardware details. So the tool must be a small installed program or script on each computer, with a dashboard on the web for the results. Discovering this on day one saves weeks of wasted building.

Step 4: privacy and security by design

• Tell users exactly what will be collected, and get their permission.
• Collect only what you need, and send it over an encrypted connection.
• Control who can see the dashboard and keep an access log.

Build in stages: a script on one computer, then the report, then the dashboard, then deployment. Each stage is small enough to test.