The Requirements That Start With Not

Requirement documents describe what the system should do. The clauses that matter most in this category describe what it must not.

Why negative requirements matter here

Timesheet products ship with monitoring features, frequently enabled by default, and frequently not mentioned in the sales conversation.

A capability that exists will eventually be used. Once screen capture is available in the product you bought, someone will ask for it, and the conversation is much harder than it would have been at procurement.

And the workforce will find out what the product can do, because the product's own marketing tells them.

Writing the exclusion into the requirements makes it a contractual matter rather than a policy someone can quietly change.

The exclusions worth stating

No screen capture or screenshots, at any interval.

No keystroke or mouse activity scoring.

No application or website logging.

No automatic deduction of idle time without the person's confirmation.

No continuous location tracking. A location check at the moment of clocking in is a different thing and should be stated separately if you need it.

No webcam capture.

No silent manager edits: every change to a person's record visible to that person.

How to put them in a tender

As a mandatory requirement, not a preference.

Ask whether the capability can be disabled at account level, permanently, rather than per user.

Ask whether disabling is logged and whether re-enabling requires an administrative action that leaves a trace.

Ask what the defaults are on a newly created account, and verify it yourself in a trial rather than accepting the answer.

Ask what happens on upgrade: new features frequently arrive enabled, and that is how monitoring appears in a system that was bought without it.

The commercial reality

Some vendors cannot meet these exclusions because the monitoring is the product.

That is useful information early. It removes them from the shortlist before anyone has invested time.

Others will meet them readily, and a vendor that answers these questions precisely is usually a vendor that answers other questions precisely.

What to do with the answers

Attach the written answers to the contract, rather than keeping them in an email thread.

Include a term about feature changes: notification before anything is added that changes what the system observes.

Record the configuration at go-live, including which capabilities are off, so that a later change is detectable.

Re-check after every vendor upgrade, which takes twenty minutes and is the only way to know the exclusions still hold.

Recording the state at go-live

The baseline that makes a later change detectable.

On the day you go live, record every capture setting and its state.

Screenshot the configuration pages, or export the settings where the product allows.

File it with the implementation record.

Compare after every upgrade.

Without this, "monitoring was never enabled" is an assertion. With it, it is a documented fact with a date, which is what you need if anyone ever asks.

Check the defaults yourself

Vendor answers about defaults describe intent; the account describes reality.

Create a trial account and look, before asking anyone.

List every capture feature and its state.

Compare against what you were told.

A gap here is not necessarily dishonesty — sales and product frequently disagree about defaults — and it is exactly the kind of thing that should be settled before a contract rather than after an upgrade.

Exclude disposable identities

Temporary credentials can undermine accountability and lifecycle controls. This unusual example is useful for testing what the system should reject or restrict.