Start with the business problem, not a list of screens. Who will use the system, how often, and what does the process look like without it? An experienced team who knows what you are trying to achieve will suggest a cheaper route to it outsourcing company; one who only sees the requirements as given can only price your assumptions along with the work.

Define what is included as short scenarios: a walk through each important path. Just as important, state explicitly what is out of scope. An explicit exclusion list saves more friction during acceptance than almost anything else in the document. Indicate as well which parts are firm and which may still change — estimators price uncertainty, and pretending everything is fixed helps no one.

Set out your constraints. The list covers existing systems the enterprise software development company has to talk to, existing databases and their quality, compliance requirements, expected load, target platforms and any technology you are committed to. If a deadline is real, say what depends on it: a good team is usually able to cut the right scope to meet it, but only if they know it exists.

Say what done means for the important items. Clear acceptance criteria need not use special syntax: a short list describing what a user should be able to do is sufficient. This single habit compresses acceptance testing by a surprising margin and closes off most late-stage disagreement.

To close, state what you want in the response. Request a breakdown by feature or module, a written list of assumptions, whatever the team considers risky and an optimistic and a pessimistic figure. Read a wide range as information, not evasion: it normally identifies where your description is thin. From there clarify that area and ask for a new estimate — the second estimate will be much more reliable.