A requirements brief is what a company hands to a development partner so the partner can scope and price the work. It usually runs two to four pages and covers how the process works today, the systems and data involved, the constraints and who decides. Its job is to settle the questions that would otherwise be argued halfway through development, when changing course costs the most.
It is not a design or a technical specification. A good brief says what the software must do and leaves the how to the people building it. The common mistake is writing a wish list of features instead of a problem and a measure of success, which makes quotes hard to compare and scope hard to hold.