# Requirements management: turning wishes into testable requirements > How wish lists become solid requirements: processes as the starting point, prioritisation into must and should, acceptance criteria and a way to handle changes during the project. URL: https://techport.ai/en/it-beratung/entwickeln-und-beschaffen/anforderungsmanagement --- 1. [IT Consulting](/en/it-beratung)/ 2. [Build and Buy](/en/it-beratung/entwickeln-und-beschaffen)/ 3. Gathering requirements properly [Build and Buy](/en/it-beratung/entwickeln-und-beschaffen) # Gathering requirements properly By Redaktion techport.ai, IT-Beratung · Last updated on 21 August 2026 The most expensive sentence in IT projects is: that is not how we imagined it. It gets said during testing, which is exactly the point where changes cost most. The cause almost never lies in poor work. It lies in requirements gathered as a collection of wishes rather than a description of what has to work at the end. A good requirement is testable. You can determine whether it is met without debating intentions. That sounds obvious and in practice it is the difference between a project with an acceptance and a project with a renegotiation. ## How you notice it * Requirements sit as keywords in a spreadsheet and every point is important. * Testing raises questions that were already asked in the workshop. * The vendor says it was not in scope, and both sides are right. * There is no person who decides what applies in case of doubt. ## Why this happens Requirements are usually gathered from the people who run the process daily, and they describe it as it runs today, including the workarounds that arose from limitations of the old system. At the same time the translation into a form a vendor can quote and a developer can build is missing. On top of that comes the understandable tendency to write down everything ever wished for, because nobody wants to take responsibility for a deletion. ## How we go about it 1. **Process before function.** We start with the workflow rather than a function list: who does what, in which order, with which information, and where waiting times and errors arise today. From that workflow we derive what a system has to be able to do. 2. **Formulate requirements testably.** We write every requirement so that its fulfilment can be established, with trigger, expected result and special cases. Added to that are the non-functional points that cause the most disputes later: response times, volumes, permissions, logging, availability. 3. **Prioritise and let someone decide.** We weight into must, should and could, with a named person per department who is allowed to make that call. Without that role every requirement becomes a must and the prioritisation becomes worthless. 4. **Allow changes in an orderly way.** We set up a simple procedure by which new requirements during the project are assessed, costed and decided deliberately. Not every change is bad, but every change has to be visible. ## What you gain * Offers that are comparable because they rest on the same basis. * An acceptance based on criteria rather than impressions. * Fewer renegotiations because less is left open. ## From our projects When we derive requirements from the process rather than from a collection of wishes, a substantial share of the original points regularly falls away. The most common reason: they describe workarounds that exist only because the old system could not do something. The second most common: they are special cases occurring once a year for which a manual solution is cheaper than a permanent function. Those deletions are uncomfortable while they feel like sacrifice, and straightforward as soon as the effort per requirement becomes visible. ## Häufige Fragen How detailed do requirements have to be? Detailed enough that a vendor can quote bindingly and a tester can check fulfilment. For standard software the level of the workflow with its relevant special cases is usually enough. For custom development you additionally need field and rule level, because there nobody has a standard as a fallback. Who should own the requirements? Someone from the department who knows the process and is allowed to decide, supported by someone who makes the wording testable. If IT writes the requirements alone they become technical. If the department writes them alone they stay untestable. The two roles together produce a document you can work with. ## Let us talk about Gathering requirements properly In a thirty minute first call we work out where your biggest lever sits and whether we are the right people for it. [Arrange an initial call](/en/kontakt)[Our software](/en/loesungen) ## Further reading [Build and BuySelecting and introducing softwareHow a software selection succeeds: derive requirements from processes, make vendors comparable with your own script, review contracts, plan migration and secure adoption.](/en/it-beratung/entwickeln-und-beschaffen/software-auswahl)[Rollout and ChangeIT projects that deliverWhy IT projects fail in mid-sized companies and what helps: fill the roles, limit the scope, document decisions, name risks early and tie completion to actual use.](/en/it-beratung/einfuehren-und-veraendern/it-projektmanagement)[Build and BuyUsing custom development wellWhen building yourself beats the standard, how to avoid dependence on individuals, secure quality, protect source code and rights, and carry the operation long term.](/en/it-beratung/entwickeln-und-beschaffen/individualentwicklung)[KnowledgeIT glossaryTerms from IT, software and security, briefly explained.](/en/it-beratung/glossar)[KnowledgeIT maturity checkKnow where your IT stands in ten minutes.](/en/it-beratung/reifegrad-check) Back to the field [Build and Buy](/en/it-beratung/entwickeln-und-beschaffen) Rt Written by [Redaktion techport.ai](/ueber-uns), IT-Beratung Mehr als 15 Jahre Erfahrung in IT-Projekten des Mittelstands, Auswahl und Einführung von Unternehmenssoftware, Aufbau von IT-Betrieb und Informationssicherheit in wachsenden Organisationen. [More about us](/en/ueber-uns) More from techport.ai [ Software Custom process software for mid-sized companies. ](/en/loesungen)[ HR consulting People processes and the systems behind them. ](/en/hr-beratung)[ IT maturity check Ten minutes to a clear position. ](/en/it-beratung/reifegrad-check)[ HR maturity check 24 statements, a result per field. ](/en/hr-beratung/reifegrad-check)[ Funding BAFA grant plus more than 50 programmes for delivery. ](/en/foerderung)[ Process in practice How workflows become reliable software. ](/en/sop-praxis)[ Data and AI Analysis, forecasts and assistance systems. ](/en/daten-ki)[ About us The people behind techport.ai. ](/en/ueber-uns)