Quality scoring

A requirement is only as good as it is clear and verifiable. traceunified analyzes the wording of a requirement against established requirements-language practice, flagging weaknesses early — while they’re cheap to fix — rather than at review or audit.

Writing-quality checks

The quality analyzer inspects the wording of a requirement against language rules drawn from EARS, INCOSE, and IEEE 29148, and surfaces issues such as:

• Pattern conformance — whether the requirement follows a recognized structured form (an EARS-style pattern), and warns when a statement packs in too many conditions to be clear
• Atomicity — flagging multiple “shall” statements in one requirement, which should usually be split so each requirement is singular and independently verifiable
• Measurability — flagging requirements with no measurable or testable criteria, since an untestable requirement can’t be verified
• Sufficient detail — flagging descriptions too short to be meaningful
• Implementation leakage — flagging implementation-specific terms, since a requirement should state what is needed, not how to build it

Each finding is categorized by severity, so you can tell a hard problem from a gentle suggestion and prioritize accordingly. The word lists and rules behind the checks are configured by your administrator (see Quality analysis).

Working with the results

Quality analysis runs when you choose Run checks on the requirement. If you edit the requirement afterwards, a stale banner tells you the results no longer reflect the current text, so you know to run the checks again. The quality score and category badges may update live as results change. Findings are grouped by category, with a clear indication of what’s clean and what needs attention.

They’re guidance, not a gate — but resolving them before review means cleaner requirements, smoother approvals, and stronger evidence. Coverage and the quality of the links around a requirement are assessed separately, in Traceability.