SCULTRASERVICES
Discuss a Project
Toggle navigation

Product design & engineering

Product Requirements Quality Checker

Find unclear wording, missing acceptance criteria and gaps in ownership or traceability.

Free · no signupInputs stay in this tab

Illustrative example loaded. Replace the inputs with your own data.

Review context

Paste an existing requirements list

Requirements and verification

Keep each requirement independently testable. Existing text is preserved; findings update as you edit.

Requirement 1
Describe the required behaviour, condition or constraint.
Set conditions, expected outcome and objective pass/fail rule.
Requirement 2
Describe the required behaviour, condition or constraint.
Set conditions, expected outcome and objective pass/fail rule.
Requirement 3
Describe the required behaviour, condition or constraint.
Set conditions, expected outcome and objective pass/fail rule.

Review summary

Checks complete1 / 3No listed rule triggered
Review findings6Wording and traceability flags
Must requirements with open findings1Resolve before baselining

These checks identify common gaps. Engineering judgement is still needed to validate meaning, feasibility and coverage.

Findings by requirement

Needs review · Must

REQ-001

The dashboard shall be fast, intuitive and reliable.

  • Unmeasured languageDefine the testable meaning of: fast, intuitive, reliable.
  • Missing acceptance criteriaSpecify conditions, expected outcome and an objective pass/fail rule.
  • Verification method absentChoose test, inspection, analysis or demonstration.
  • Owner absentName the accountable person or role.
Checks complete · Must

REQ-002

The system shall display the latest sensor reading within 2 seconds of receiving a valid message.

Owner: Product engineering. Verification: Test. Source: Approved performance requirement (example).

Needs review · Should

REQ-003

The system shall retain event logs for TBD days.

  • Unresolved placeholderAssign an owner and close this open decision before baselining.
  • Missing acceptance criteriaSpecify conditions, expected outcome and an objective pass/fail rule.

Review boundaries

  • The checker preserves your wording and never invents customer needs, acceptance criteria or owners.
  • A complete checklist is not proof of consistency, regulatory compliance or technical feasibility.
  • Inspect requirements for failure cases, interfaces and conflicts that text rules cannot reliably detect.

How to check product requirements quality

Review individual requirements from a product requirements document (PRD) or engineering specification. The checker uses explicit rules to flag common drafting gaps; it does not rewrite your requirements or certify that a specification is complete.

  1. Add each requirement's ID and statement, then its acceptance criteria, owner, source, priority and verification method.
  2. Review flagged vague terms, unresolved placeholders, duplicates and missing review fields. Each finding explains the rule and a suggested action.
  3. Clarify the requirement with your product or engineering team, run the checks again and export the findings and traceability matrix.

When to use this tool

  • Preparing requirements for a design, engineering or supplier handoff.
  • Finding statements that lack a measurable acceptance criterion or an accountable owner.
  • Organising a requirements review without sending the entered specification to SCULTRA.

For a source-validated engagement, explore our Product Design service.

Method and limitations

A deterministic checklist looks for vague terms, unresolved placeholders, multiple obligation words, duplicate IDs or statements, and missing acceptance criteria, owners, sources and verification methods. Each finding has a reason and a suggested action. ‘Checks complete’ means no listed rule was triggered; it does not mean the requirement has been independently approved.

This checker cannot understand all semantic conflicts, prove technical feasibility, assess an entire regulatory standard or verify that acceptance criteria test the intended customer need. Treat its findings as prompts for an engineering review.

Input values are processed in your browser. Project files, CSVs and printed reports contain your entered data. Keep downloaded files private when needed. Page-visit analytics follow your cookie preferences.

Common questions

Does the tool rewrite our requirements?

No. It preserves your text and shows review findings. You decide which wording, acceptance criteria and verification methods fit your product.

Can we paste an existing requirements list?

Yes. Paste one requirement per line and add the rows to the review. Then fill the acceptance criteria, source, owner and verification method for each.

What is the difference between acceptance and verification?

Acceptance describes the pass/fail outcome and conditions. Verification identifies how that outcome will be checked: test, inspection, analysis or demonstration.

Take the result further.

Work with SCULTRA to validate the evidence and turn the findings into a practical next step.

Discuss this resultProduct Design