From Customer Problem to Measurement Requirement

A useful measurement solution starts with the customer's decision, not the name of an instrument. The requirement should explain what information is missing and how a valid result will change the next action.

Translate the problem into a question

Ask whether the customer needs a field trend, a sample result, an identification, a personal record or another quantity. Describe the source or material, operating state and arrangement. “We need radiation monitoring” is a starting point, not yet a complete requirement.

Include the workflow in the solution

Instrument response is one requirement. Setup, acquisition, data handling, interpretation and maintenance are also part of the delivered workflow. An appropriate detector can still create an incomplete solution if its output cannot be used in the customer's records or decision process.

Nucleolenz's published laboratory gamma spectroscopy workstation case study describes the integration of a detector, analyzer, shielding and acquisition workflow. It is a concrete reference for discussing system integration, not evidence of outcomes for an unnamed new customer.

Agree on evidence before describing success

Define the delivered configuration and acceptance activities. Specify which result or demonstration supports each requirement and which assumptions remain to be checked at installation. Keep measured outcomes separate from expected benefits.

The Table Mount Gamma Spectrometer can provide a product context for a bench-spectroscopy requirement. Verify the actual configuration against the task instead of treating a case study as a universal recommendation.

Rewrite a vague request in stages

A fictional customer asks, “Can we monitor radiation in this room?” The first conversation should uncover the decision behind that request. Do they need to observe a fixed field, investigate changing conditions, record individual exposure information or analyze samples? Each answer leads to a different measurement requirement.

For a fixed-field example, the brief can then identify the intended detector position, operating states to represent, required quantity and how the information will be received. Unknowns should remain explicit. A blank marked “to be assessed” is more useful than an assumed specification that later becomes a disputed delivery promise.

Separate the result from the surrounding service

• Measurement: the quantity, radiation conditions, arrangement and required performance evidence.
• Operation: who sets up, reads, checks and maintains the equipment.
• Information: what is displayed, stored, exported or transmitted, with units and status.
• Decision: who interprets the result and which approved process uses it.

These are connected requirements. For example, a correct local reading may not meet a project need if the required remote record omits its units or event time. Conversely, a polished dashboard does not establish the validity of the upstream measurement.

Agree on a useful acceptance conversation

For each requirement, write the proposed demonstration, test, inspection or analysis and the record to retain. Identify the configuration and conditions involved. If a requirement can only be assessed at the installation site, state that dependency before delivery rather than treating a bench demonstration as a substitute.

Then ask what happens when the requirement changes. A new sample type, detector location or output format may need a new assessment. Keep the agreed version and the reason for later revisions. The practical takeaway is a requirement that someone else can read and verify: what information the system must provide, under which conditions, and how the project will know it has done so.

A customer story should use approved facts, permission-cleared identities and traceable results. A requirement guide can be useful before those facts exist: it gives the engineering discussion a clear structure and prevents a plausible narrative from being mistaken for evidence of a completed deployment.