Writing an Anticheat Requirements Document

Short answer

An anticheat requirements document lists what your server must get from an anticheat, what it should have, and how you will test each item. Give every requirement an ID, a priority, an owner, and an acceptance test you can run on staging. Judge each option against this document, not against its feature list. An option that fails a Must requirement is out, whatever else it offers.

Start with the server profile

Write the profile in plain terms. A requirement such as works for our players cannot be tested. A requirement that names your Minecraft versions, your server software, and your proxy can be.

• Server type and game modes, such as PvP, survival, or a network hub.
• Share of Java and Bedrock players, and whether Geyser and Floodgate are in use.
• The exact Minecraft versions you support, and the proxy in front of them.
• Plugins that move players or change combat, such as teleport, mount, or custom-item plugins.
• Staff size, staff hours per week for alert review, and who makes punishment decisions.

Write each requirement as a testable statement

Each row has one requirement and one test. Keep the test concrete enough that two staff members would reach the same result.

Set priorities before you read vendor pages

Priorities set after reading vendor pages tend to follow the marketing. Setting them first keeps the decision tied to your server.

• Must: an option that fails is rejected, whatever else it does.
• Should: scored on a fixed scale, such as 1 to 3.
• Could: used only to break ties between options that pass every Must.
• Write the priorities and weights before you read any vendor page, and date them.

Use this document skeleton

Keep the document short. The skeleton below fits on two pages once filled in. Replace each bracketed field with your own value.

Title: Anticheat requirements, [server name], version [n], date [YYYY-MM-DD]
Owner: [name, role]
Approvers: [names]
1. Server profile: [summary, versions, proxy, plugin list]
2. Requirements:
   REQ-01 | [statement] | Must | [acceptance test] | Owner: [name]
   REQ-02 | [statement] | Should | [acceptance test] | Owner: [name]
3. Scoring: [scale and weights]
4. Out of scope: [items]
5. Change log: [date, change, reason, approver]

Write acceptance tests you can run

An acceptance test names the input, the place it runs, and the observable result. Avoid results that depend on opinion, such as the plugin feels fine.

• Name the server copy, such as staging, and the exact build.
• Name the script or the manual steps, and how many times they run.
• Name the output you will check, such as a log line, a channel message, or a config value.
• Name the person who signs off on the result.

Make each test repeatable

A test you cannot repeat tells you nothing when the next update arrives. Store the script, the server copy, and the expected output together, so the same check runs again after each change.

Review and sign off

Sign-off is a short review, not a formality. The approver should be able to point to the test record behind each Must requirement.

• Send the document to each vendor and ask for a written response to each requirement.
• Run the Must tests on staging for every option still in the running.
• Score the Should requirements from your test records, not from vendor claims.
• Record the decision and its reason, including any Must that failed.
• Review the document after each Minecraft update and each change in server type.

What a requirements document cannot do

A requirements document does not test detection quality. It makes your test plan explicit. Keep any claim about detection rates out of the document unless you have your own staging data. FairPlay can be scored like any other option. Its checks are listed in the FairPlay reference, and its claims need the same acceptance tests as everyone else's.