Do I really need a requirements document for a software selection?

For a purchase meant to last for years, yes - but not in the form the term suggests. Six to ten pages with a volume baseline, ranked requirements, interface needs, data migration and an exit clause are enough. Without that basis a company compares presentations rather than systems. The Project Management Institute reports that 47 percent of unsuccessful projects miss their goals because of inaccurate requirements work (PMI 2014).

How long does it take to write in a mid-sized company?

Five working days spread across a handful of people is realistic: one day to draw the boundary around the case, one day for the volume baseline, one day for the requirements and their ranking, one day for interfaces and data migration, one day for exit, operations and weighting. Where figures can be pulled from the existing systems instead of estimated, it tends to be shorter.

How many vendors should be invited to quote?

Three to six is usually a sound frame. Fewer than three gives you no comparison, more than six ties up time without improving the decision. A two-stage approach works well: the requirements document goes to the longer list, and only the two or three vendors that meet all must criteria get a demo with your own data. That keeps the effort reasonable on both sides.

What belongs in a demo run with your own data?

Three of your own cases - a standard case, a frequent exception and the most awkward case of the last quarter - plus a small extract of real master data with your own number ranges, price tiers and units. The people who will use the system do the clicking, not the vendor. In addition, data export and one interface should be checked live. Personal details can be shortened or replaced beforehand.

Which contract points are overlooked most often?

Four regularly surface too late: data export in an open format including period and cost, the price jumps between user tiers, the exact scope of maintenance and support, and the rule under which prices may be adjusted. Silent contract renewal comes on top. All four can be settled at no cost before signing and only with difficulty afterwards.

What does a neutral pre-review of the requirements cost?

The scope depends on the number of workflows affected and the systems involved. For orientation: process analysis from 1,900 EUR net, implementation per automation or interface from 4,900 EUR net, ongoing support from 190 EUR net per month. A single workflow is usually enough to start with; the effort is agreed as a fixed price in advance so the pre-review stays predictable.

Choosing Business Software: Requirements Come First

A software selection rarely starts with a requirement. It starts with an appointment. A vendor shows the system, the demo runs smoothly, two weeks later a quote is on the table - and the company decides on something it has not described anywhere. What is missing is the foundation: a written account of what your own workflow actually demands. Without it you compare presentations rather than systems, and the vendor with the more polished pitch wins, not the one with the better fit. A selection that holds up reverses the order: measure your own workflow first, derive the requirements from it, then look at the market. This article follows the path from the first number to the signature - the volume baseline taken from live operations, a lean requirements document written in five working days, a weighted scoring matrix and a demo driven with your own data and your own cases. No product names appear in it; criteria do. How we record the workflow behind all of this is described under process analysis.

Key takeaways

The requirement comes out of the measured workflow, not out of a vendor feature list. Counting how often a case occurs and how long it ties people up gives you a yardstick every quote can be held against.
A workable requirements document for a mid-sized company fits on six to ten pages and takes one week: volume baseline, must-should-nice ranking, interface needs, data migration and the way back out.
Must criteria rule vendors out; should and nice criteria rank the remainder through weighting. That separation belongs before the first demo, not after it.
The demo is run with your own real data and three of your own cases, one of them an exception. A standard demo shows what a system can do - not whether it fits your operation.
The items that cost money later sit in the contract, not in the quote: data export in an open format, user tiers, the scope of maintenance and the rules for price adjustments.

The requirement comes from the workflow, not from the feature list

The usual entry point into a system selection is a list. It comes from the vendor, has three columns and two hundred rows, and nearly every row carries a tick. Such lists are not wrong, they simply answer the opposite question. They show what a system can do - not what the company needs. Between those two lies the entire difference between a purchase that still holds up after two years and one that gets worked around in daily practice. Make the list your basis and you are assessing feature coverage. Make your own workflow the basis and you are assessing fit. Only the second measure decides whether a case actually runs through faster than before.

The figures on this are clearer than everyday practice suggests. The Project Management Institute reports that 47 percent (PMI 2014) of unsuccessful projects miss their goals because of inaccurate requirements work, and 37 percent (PMI 2014) of the organisations surveyed name inaccurate requirements gathering as a primary cause of failed projects. This is not a technical problem. It arises long before rollout, at the moment when nobody wrote down what the result was supposed to achieve. Software can do a great deal; whether it does the right thing is settled at this point.

The second set of numbers comes from project statistics themselves. In its analyses the Standish Group classifies only around 31 percent (Standish Group) of the IT projects reviewed as successfully completed, while roughly 19 percent (Standish Group) are classified as failed. For a mid-sized company that means one thing above all: the normal case is not the smooth changeover but the project that takes longer and costs more than planned. On top of that comes the scarcest resource in the sector. 60 percent (Bitkom) of companies with 20 or more employees named a lack of time as an obstacle to digitisation in 2025 - precisely the time a second selection round after a bad purchase would consume.

A feature list is a sales aid

It is built so that the vendor's own product looks good in it - which is legitimate and still a weak yardstick. The yardstick belongs on the other side of the table. The Project Management Institute reports that only around 20 percent (PMI 2014) of organisations rate their own maturity in requirements work as high; that gap is where the systems come from that end up not doing what was needed. A company with written criteria turns the conversation around: it stops asking what a system can do in general and asks whether it can do these six things - and how.

The volume baseline: the number that carries the comparison

Before a single requirement is written down, someone has to count. The volume baseline answers four plain questions about exactly the case in question: How often does it occur? How many line items, rows or documents hang off it? How long does it take today from start to finish? And how many roles touch it? Those four values become an annual total, and that annual total is the currency in which every quote can later be assessed. Without it the discussion gets stuck on impressions: that is far too expensive, or the other way round, that will pay for itself somehow.

Converting it into money is simpler than it sounds. According to the labour cost survey of the Federal Statistical Office, labour costs per hour worked in the private sector averaged 45.00 euros (Federal Statistical Office) in 2025. So if you find that a case occurs one thousand two hundred and forty times a year and currently ties up twenty-two minutes, you arrive at around 455 hours and therefore at a good 20,000 euros of annual effort (sample calculation). That figure is the frame a purchase is allowed to move within, and it answers at the same time which requirement really is a must. How the cost of a single case can be established cleanly is described in the article on what a single case really costs.

Requirements extract for one workflow (example)

Case: create a quote and follow up                  (example)
-----------------------------------------------------------
Volumes from day-to-day operations
  quotes per year                           1,240
  of those with a special price               310
  line items per quote                    6 to 40
  handling time today                  22 minutes
  departments involved                          3
  annual effort (1,240 x 22 minutes)  about 455 h

Requirement                                  Rank    Weight
-----------------------------------------------------------
price tiers per customer and quantity        must      high
quote from a template in under 5 min         must      high
documents exportable as an open file         must      high
interface to accounting                      must      high
follow-up reminder                         should    medium
mobile access for field staff                nice       low
-----------------------------------------------------------
Must-have criteria rule a vendor out. Should and nice-to-have
sort the remaining ones through the weighting. Every line in the
lower block traces back to a figure in the upper one - that is
the only test a requirement has to pass at this stage.

The extract shows two blocks that belong together. The upper one states what was measured, the lower one what follows from it. That order is the actual trick: every requirement can be traced back to a number, and every number comes from live operations rather than from a wish list. Around 99 percent (Federal Statistical Office) of companies in Germany are small and medium-sized enterprises, and very few of them have a role that produces such a document on the side. That is exactly why the format has to stay lean. Where the numbers come from when they are not to be collected by hand is shown in the article on reading process data straight out of your systems.

A lean requirements document in one week

The term requirements document has a poor reputation, and it comes from projects that started with three hundred pages and ended up on a shelf a year later. For a mid-sized company a fraction of that is enough. Six to ten pages, written across five working days, cover what vendors need in order to submit comparable quotes. The effort spreads across a handful of people and a fixed frame. The Project Management Institute reports that 51 percent (PMI 2014) of organisations see insufficient resources for sound requirements work - a realistic weekly plan is the practical answer to that, not a bigger budget.

Step 1

Day 1: Draw the boundary around the case

Pick a single workflow with a start and an end - from enquiry to dispatched invoice, not the whole company. Draw the boundary too wide and you get a document nobody reads. Add a list of the roles that touch the case.

What emerges over those five days is not a legal document but a working basis. It goes to three to six vendors, it goes into the assessment, and it later goes into the contract as an annex. That is what turns a collection of wishes into a commitment both sides can be measured against. Which workflow to tackle first when several are jammed at once is a decision of its own; there is a straightforward way to score it, described in the article on which processes to tackle first.

Must, should and nice: the split that sorts the field

The most effective column in the whole document is the one holding the rank. Must means: if the system cannot do it, the vendor is out - no discussion, no workaround, no promise to add it later. Should means: it works without, but it counts in the assessment. Nice means: it is pleasant and must not turn a decision. Experience shows this order tips over as soon as a demo is running: a well-executed feature from the nice category moves to the front because it is visible, while a must criterion such as data export stays invisible. That is why the ranking is put in writing beforehand and is not changed during the selection meetings.

Volume baseline

Frequency, size, duration and roles involved per case. Those four values turn a gut feeling into an annual total - and the annual total into a cost frame.

Must, should and nice

Every requirement gets exactly one rank. Must criteria exclude, should criteria score, nice criteria only decide when two vendors are level.

Interface needs

Which systems have to connect, in which direction, at what interval? A system without an open interface simply moves the manual work somewhere else.

Data migration

Which records move over, in what quality, with how much history? The scope of the migration belongs before the price negotiation, not after it.

Roles and permissions

Who may view, who may edit, who approves? Without that information the user tier is calculated wrongly - and the licence cost stops matching later on.

Exit and export

In which format, within what period and at what cost does your own data come back out? Asking before signing costs nothing; asking afterwards costs a great deal.

Two of the six chapters are regularly underestimated, and both concern connectivity. A system with no documented route to the outside creates exactly the manual work it was meant to remove - what a connection delivers technically is described on the page about interfaces, while merging records from several sources is covered on the page about data integration. There is a staffing background to this: 74 percent (Bitkom) of companies with 20 or more employees named the shortage of skilled staff as an obstacle to digitisation in 2025. Where people are scarce, every additional manual transfer between two systems is more expensive than the interface that would have replaced it.

A scoring matrix instead of gut feel

Once the quotes are in, the part begins where most selection procedures go soft. Three systems were demonstrated, all three can do much the same at their core, and the decision falls on rapport or on price. The scoring matrix replaces that with arithmetic: each should and nice criterion gets a weight from one to three, each vendor gets a score from zero to five per criterion, and the two are multiplied. The result is not a truth but a traceable ranking - and above all a record that still explains six months later why the decision went the way it did. The Project Management Institute puts the share of spending on projects and programmes that is lost through poor requirements work alone at 5.1 percent (PMI 2014).

Aspect	Impression from the demo	Weighted assessment
Basis	Whatever appeared in the presentation	The criteria from the requirements document
Visibility	Interface and handling dominate	Data export and interfaces count as well
Comparability	Each vendor shows its own strengths	All vendors are checked against the same list
Traceability	Reasoning lives in people's memory	Score and weight documented in writing
Reaction to renegotiation	A discount reshuffles the ranking	Price is one criterion among several
Result after two years	Hard to reconstruct	The original must criteria can be checked

A common objection is that such a matrix creates false precision. That holds true if you treat the total score as a verdict. It is a structuring tool: the value lies in the conversations that happen while the weights are being assigned. That is exactly where a team notices that a follow-up reminder for sales matters more than the tenth reporting option - an insight that also underlies the article on how to produce quotes faster and follow up consistently. The number at the end only orders what the discussion has already clarified.

The weighting is set before the first demo

Assign the weights only after the appointments and you will unconsciously weight what you have just seen. That is why the weighting column belongs in the requirements document and is signed off by management before the first vendor enters the building. Two effects show up straight away: the selection round gets shorter because everyone knows what to watch for. And the discussion after the last demo takes minutes instead of weeks, because all that remains is entering scores.

The demo with your own data and your own cases

A standard demo is a rehearsed sequence with clean sample data, round numbers and no exceptions. It is informative, but it does not answer the decisive question: does your own case run through it? Only a demo where the company holds the reins settles that. Three of your own cases are picked in advance and sent to the vendor: a standard case, a frequent exception and the most awkward case from the last quarter. Along with them goes an extract of real master data with your own notation, price tiers and units.

The difference usually shows up within the first quarter of an hour. Your article number has fourteen digits and a special character, the price tier depends on customer and quantity at the same time, the exception calls for a partial delivery with a different billing address. Details like these are absent from any demo built on sample data. Yet they decide whether the case later ends in four clicks or in four detours. Preparation matters: look for examples during the meeting itself and you are back in the standard demo.

Hand over three of your own cases in writing beforehand - a standard case, an exception and the most awkward case of the last quarter, each with the expected outcome.
Provide real master data in small volume: your own article numbers, price tiers, units and customer addresses instead of the vendor's sample records.
Let the people who will use the system do the clicking rather than watching the vendor demonstrate - only then does the true number of steps per case become visible.
Trigger the data export during the meeting and look at the file it produces. What does not work here tends not to work any better after the purchase either.
Have one interface checked live: one record in from the third-party system, one document back out - including the question of what happens when something fails.
Enter the scores during the meeting while the impression is fresh, and close the assessment before the next vendor arrives.

The people who will work with the system belong in the demo. Not as an audience, but at the keyboard. Someone who performs the case daily recognises within minutes whether an input screen matches the workflow, while management tends to focus on reporting. Both are needed, but the order of attention decides how well the system is accepted later. How to plan a rollout that actually lands in day-to-day work is covered in the article on bringing staff along with new workflows.

Real data in a demo: sparingly and deliberately

A small extract is enough for a meaningful demo, and personal details can be shortened or replaced beforehand. What matters are the structural features - length and format of the numbers, pricing logic, units, special characters - not the complete customer base. If an extract is handed over, purpose, scope and deletion should be agreed in writing. Which obligations apply is set out in the article on data protection when digitising processes; assessing an individual case remains a matter for qualified review.

Contract points that cost money later

The price on the quote is the smaller part of the bill. The larger amounts come from terms that do not appear in the quote at all and only turn up in the contract or the terms of use. That applies in particular to subscription models, whose share keeps growing: the European Commission has set the target that by 2030 at least 75 percent (European Commission) of companies in the EU should use cloud services, data analytics or artificial intelligence. Anyone renting commits to running costs and to the conditions under which they can get back out. What data comes along when moving off an older system is described in the article on migrating data from a legacy system.

Data export: in which format, to what extent and within what period does the company get its data back? An open file format with a documented structure belongs in the requirements document as a must, not in a footnote as a request.
User tiers: what does the eleventh user cost, what does a seasonal worker for three months cost, and can accounts be cancelled again? Price jumps between tiers only become apparent once you grow.
Maintenance and support: which services are included, what response times apply, and what does a change outside the standard cost? A percentage of the purchase price says little on its own.
Price adjustment: under what rule and at what interval may the price rise? A link to a published index is traceable; a free adjustment after notification much less so.
Term and cancellation: how long does the contract bind you, how long is the notice period, and does it renew silently? These three details decide how much room you have in two years.
Operations and storage: where does the data sit, who backs it up, and what does the tested route back look like? When moving off an environment that grew over years, more depends on this than on feature coverage - background under legacy replacement.

One point is almost universally forgotten even though it moves money every month: administering the accounts. Who gets which permissions in the new system, and how an account disappears again when someone leaves, belongs in the selection rather than in the operations that follow - otherwise the company pays licences for people who left long ago. The article on accounts and permissions when staff join and leave shows how to map that in an orderly way. In the scoring matrix it is a should criterion with a high weight, not a nice-to-have.

Bad purchases that keep repeating

The patterns by which a system selection goes wrong are remarkably similar across industries. They rarely have anything to do with poor software and nearly without exception with a requirement that was not written down beforehand. The Standish Group classifies around 50 percent (Standish Group) of the projects it analyses as completed but over time or over budget - that is the actual normal case, and the six patterns below account for a good part of it.

Specialising on the exception: a system is chosen because it handles the rare special order particularly elegantly - and makes the ninety percent of standard cases more cumbersome in return. The volume baseline would have prevented that.
The system without an open interface: everything looks coherent from the inside, but there is no documented route out. The manual work then simply moves elsewhere. What a connection means technically is explained in the article on what an interface actually is.
Deciding on the strength of the demo: the vendor with the most convincing presentation wins because no weighting existed. Experience shows this surfaces in the second year, when an invisible requirement turns out to be missing.
The system that is too large: software built for group structures gets rolled out for fifteen workstations. The licence is affordable, the rollout is not - and maintaining it permanently ties up time the company does not have.
The system that is too small: it fits today and runs into limits within two years on user count, data volume or separate entities. A look at the planned development of the business belongs in the volume baseline.
Buying with no exit plan: the data export was not checked before the purchase. At the next changeover, getting your own data back then costs more than rolling out the successor.

What all six patterns share is that two hours of arithmetic beforehand would have avoided them. The effort for a volume baseline is typically under one percent of what a new system plus rollout costs. The same arithmetic sits behind the question of whether automation is worth it at all; the article on when automation pays off works through the full calculation. Both cases rest on the same foundation: measured volumes instead of estimated ones.

The most expensive item in a system selection is the one nobody wrote down before signing. It comes back later as an additional quote - and by then there is no leverage left.

Project experience

What a company can do itself before the vendor round

The larger part of a sound selection happens before the first vendor appointment, and it takes no specialist knowledge. A workflow is bounded, its volumes are counted, the requirements are written and ranked, the weights are set. Where a spreadsheet that grew over years currently runs as the unofficial core system, it often already supplies a large part of the volume baseline - what its limits are and what takes its place is described in the article on when replacing a spreadsheet workaround is worth it. The order is what matters: count, write, weight, then invite.

That leaves the question of when outside support makes sense. It is worthwhile where neutrality counts: in recording the workflow, in the volume baseline and in the technical check of whether a system can connect to the existing landscape at all. What comes afterwards - rollout, data migration, training - can be planned once the decision rests on a solid basis; how a structured rollout runs is shown on the page about training and rollout. And anyone who has the workflow recorded first gets two results for one effort: a requirements document and a list of improvements that work even without new software - described under process analysis.

Sources and Studies

This article is based on data from the Project Management Institute (PMI 2014), the Standish Group, Bitkom, the Federal Statistical Office and the European Commission. The figures quoted refer to the state of the respective publication.