Software Requirements Builder for Schools

The expensive mistakes in public software procurement happen before any supplier sees the tender. Most of them come from confusing an assumed solution with the actual need. "Must be cloud-based" is a solution; the need is usually "remote access with low maintenance". A spec built from solutions, or copied from one product's brochure, produces bids you cannot compare and a purchase you cannot defend.

This tool separates needs from solutions, forces every requirement to be measurable, and prioritises them. It is a discovery assistant, not an RFP generator. It never names a product, never scores a vendor, and never steers you toward any supplier, including Smootables. The output is your own work product.

A buyer writes "the system must be modern and user-friendly". A supplier cannot prove that, and two vendors will both claim it, so it cannot decide a bid. The assistant marks it as vague and proposes a measurable rewrite: "a new office administrator can record a full day of attendance without training in under 15 minutes", with an acceptance test the supplier demonstrates during evaluation.

Another buyer writes "must integrate with our student register". That is a real boundary, so it passes, and it is tagged to the office and data-management staff. By the end you have a set of requirements that read the same way to every bidder, each tied to the people it serves.

The builder is free. The wizard, the requirements table, must/should/could/won't prioritisation, the gap checklist, the stakeholder-coverage check, the evaluation matrix, and every export run in your browser and keep working even if the assistant is unavailable.

The assistant steps (challenging your needs, drafting requirements, writing the tender document, and scoring quality) call an AI model. Those have a generous daily ceiling per browser to keep the tool free for everyone. If you reach it, your document is safe: export it and continue tomorrow, or open your saved draft on another day.