Most technology projects that collapse do not fail because of bad programmers. They fail months before a single line of code is written — at the stage where nobody bothered to define what the system is supposed to do, for whom, and why. That is exactly the job of information systems specification: turning a vague idea (“we need a system to manage our customers”) into a precise document you can build from, price from, and measure against.
What information systems specification is (and what it is not)
Information systems specification is the process of mapping business needs, workflows and users — and translating them into defined requirements: what the system does (functional requirements), how fast, how secure and how available it must be (non-functional requirements), how it looks (interface specification) and which technologies it runs on (architecture).
What it is not: a specification is not “an 80-page document nobody reads”. A good specification is a living working tool — as short as possible, as precise as necessary. Nor is it a stage you can skip because “we will figure it out as we go”: the data shows this is the most expensive bet in the entire project.
The numbers from the field: two documented stories
The FBI burned $170 million on a system that never went live
Between 2001 and 2005 the FBI developed Virtual Case File — a system for managing investigation files. The project was cancelled in 2005 after roughly $170 million in spending, without the system ever entering service. The congressional inquiries that followed pointed to one central cause: requirements that were never properly defined up front and that changed constantly — hundreds of requirement changes mid-development. The technology did not fail. The specification did.
Denver Airport: 16 months of delay over a baggage system
The automated baggage system at Denver International Airport became a classic case study: unrealistic requirements that were never reconciled with operational reality delayed the opening of the entire airport by 16 months, with overruns in the hundreds of millions of dollars and carrying costs of roughly a million dollars for every day of delay. In the end the system was almost entirely abandoned in favour of a simpler solution — one that could have been specified from the start.
And for anyone who thinks this only happens to giants: a PMI study found that nearly half (47%) of projects that miss their goals fail because of poor requirements management, and long-standing research from IBM and NIST showed that fixing a defect in production costs 30 to 100 times what it costs to fix at the requirements stage. An hour of specification saves a week of development.
Six steps to an information systems specification that actually works
1. Business goal before anything else
You do not start from “which screens do we need” but from “which business problem are we solving and how will we measure success”. A CRM built to shorten lead response time looks very different from one built to increase repeat sales. One sentence of purpose plus two or three success metrics — before anything else.
2. Mapping processes and users
Sit with the people who will actually use the system — not only with the managers. Map the existing process step by step, including the ugly exceptions (a cancelled order, a returning customer, the side spreadsheet everyone quietly relies on). Most of the expensive surprises in development hide precisely there.
3. Functional requirements: what the system does
Every requirement should be phrased so that it can be tested: “the system sends an alert to the manager within 5 minutes of a ticket being opened” — yes. “The system will be user-friendly” — no. Prioritise with MoSCoW (must / should / could / not now), because a first version that contains everything is a version that will never ship.
4. Non-functional requirements: performance, security, availability
How many concurrent users? Which data is sensitive and who is authorised to see it? What happens when the system goes down? These are the sections easiest to skip in a specification — and the most expensive to discover after go-live.
5. Interface and user experience specification
Wireframes of the core screens and the end-to-end user journey. You do not need full visual design at this stage — you do need certainty that the user gets from point A to point B without getting lost.
6. Architecture, integrations and the summary document
Which existing systems does it need to connect to (accounting, payments, messaging, ERP)? Build or buy? It all converges into a specification document (SRS) that also includes cost estimates and a timeline — and that becomes the basis for comparing vendor quotes against exactly the same yardstick.
What an information systems specification costs
Specification for a small-to-medium system (a business application, a customised CRM, an operational system) typically runs between $4,000 and $16,000, and in more complex projects it reaches six figures. A common rule of thumb: 10–15% of the total project budget goes to specification. That sounds like a lot, until you remember that the FBI paid $170 million for the decision to economise at this stage. Just as important: an independent, objective specification, produced separately from the software house that will build the system — so that whoever sets the price is not also the one defining what is needed.
Specifying AI systems: what changes in 2026
When you specify an AI-based system — a service chatbot, a recommendation engine, intelligent automation — questions arise that never existed in classical specification: what data do you actually have and how good is it (a good model on bad data equals a bad system), what accuracy threshold makes the system harmful below it, where is a human in the loop required, and what do you do when the model hallucinates in front of a real customer. On top of that, the specification must define ongoing costs (tokens, API calls) that do not exist in conventional software. That is how you avoid joining the 80% of AI projects that fail.
Frequently asked questions
How long does an information systems specification take?
For a small-to-medium system: three to eight weeks, depending on the number of processes and connected systems. A broad enterprise project can take two to four months. A specification that drags on longer than that is usually a sign that you are trying to specify too much at once.
What is the difference between business and technical specification?
Business specification answers “what and why” — processes, users, requirements and success metrics, in language every manager understands. Technical specification answers “how” — architecture, databases, APIs. The order matters: technical before business is building a house from the roof down.
Can you skip specification on a small project?
You shorten it — you do not skip it. Even a one-month project only needs a 5 to 10 page document with a goal, the core processes and a prioritised requirements list. The difference between that and “we will figure it out as we go” is usually the difference between a 10% overrun and a 100% overrun.
Who should write the specification — us or an external vendor?
Only you know the business knowledge, but an experienced analyst knows which questions to ask, how to phrase testable requirements and how to translate them into language development vendors can price. The winning combination: an objective external analyst working closely with your key people.