Open with the reason this banking software development company should exist, not your preferred technology. Who will use the system, how many times a day, and what happens today? A vendor who understands the goal can propose a simpler way to reach it; one who only sees a feature list can only price exactly what you asked for.
Define what is included as short scenarios: a walk through each important path. Every bit as useful, list what you are not building. A written out-of-scope list prevents more friction later than any other single page. Also mark which decisions are settled and which are still open — estimators price uncertainty, and pretending everything is fixed helps nobody.
Set out your constraints. This means existing systems the software has to talk to, the data you already hold and its condition, compliance requirements, user volumes, supported browsers or devices and any technology you are committed to. If there is a hard date, say what depends on it: a team is usually able to cut the right scope to hit it, provided they hear about it early.
Define what completion means for each item. Testable acceptance criteria do not require formal language: a short paragraph describing what a user should be able to do will do. That one addition compresses the review at the end by a surprising margin and removes the usual argument at handover.
To close, say what you expect back. Require a breakdown by feature or module, the assumptions behind each number, the main risks and a low number application support and maintenance services a high number. Read a wide range as a signal about the brief: it tells you the part of the brief that needs work. From there rewrite that part and ask for a new estimate — the revised figure will be the one worth planning around.
Recent Comments