In short
Requirements analysis is the project step in which you identify, check and document what a software system has to do and under what conditions. It translates the goals, wishes and constraints of those involved into unambiguous, verifiable requirements before architecture and code are created.
In professional terms it belongs to requirements engineering as described by the International Requirements Engineering Board (IREB) and the standard ISO/IEC/IEEE 29148.
Without requirements analysis, a team builds on assumptions. This usually only becomes apparent late, during testing or acceptance, when changes cause a great deal of effort. A clean analysis is therefore the basis for any custom software development, for reliable quotes and for an acceptance that nobody argues about at the end.
What does requirements analysis involve?
The IREB divides requirements engineering into four main activities: eliciting, documenting, validating and negotiating and managing requirements. Requirements analysis covers the first three. The fourth activity, managing them over the entire lifetime, is requirements management (see below).
- Eliciting: who is affected (stakeholders), which sources exist (documents, legacy systems, laws, users), and what do those involved really need, even if they do not say so explicitly?
- Analysing and documenting: statements are organised, contradictions uncovered, terms clarified and requirements formulated so that they can be tested later.
- Validating and negotiating: those involved confirm that the documented requirements correctly reflect their needs. Conflicts between departments are decided here, not only in the sprint.
Types of requirements
The IREB distinguishes three types. The separation helps to ensure nothing is forgotten, because functions almost always dominate in conversations.
| Type | Question | Example |
|---|---|---|
| Functional requirement | What should the system do? | The system automatically generates a delivery note from a confirmed order. |
| Quality requirement (non-functional) | How well should it do it? | The search delivers results without noticeable waiting time even under full load; the metric and limit are specified concretely. |
| Constraint | What is given and not negotiable? | The data stays in a data centre in the EU; the existing ERP will not be replaced. |
For quality requirements, the standard ISO/IEC 25010 offers a catalogue of characteristics such as reliability, security, performance and maintainability. These requirements later shape the software architecture more than any single function.
How to recognise a good requirement
ISO/IEC/IEEE 29148 names characteristics of good individual requirements. The most important ones in practice:
- Necessary: if it is dropped, the system lacks something essential.
- Unambiguous: there is only one reading. Words such as "fast", "simple" or "user-friendly" are not unambiguous without a metric.
- Complete and singular: a requirement describes exactly one thing, and does so in full.
- Feasible: it can be implemented with the resources available.
- Verifiable: it is possible to check whether it is fulfilled. Acceptance criteria and test cases are later derived from this.
Methods of requirements analysis
No technique suits every project. In practice you combine several, depending on whether the knowledge is in people's heads, in documents or in a legacy system.
| Method | Well suited for | Limit |
|---|---|---|
| Interview | Detailed knowledge of individual experts, goals of decision-makers | Time-consuming, only delivers the view of those interviewed |
| Workshop | Alignment between departments, a shared picture of the process | Needs neutral moderation; otherwise the loudest person prevails |
| Observation at the workplace | Implicit knowledge, processes nobody explains any more | Only possible for existing processes |
| Document and system analysis | Replacing a legacy system, forms, interfaces, data models | Easily adopts outdated rules without checking them |
| Questionnaire | Many distributed users, weighting of needs | Only finds what is asked about |
| Prototype or click dummy | Interfaces and processes that are hard to describe | Tempts people to talk about design instead of content |
A click dummy is particularly helpful when those involved only realise what they are missing when they look at it. For complex business processes, event storming is suitable: domain experts and developers place the events of a process on a timeline together.
Documenting and prioritising
Depending on the approach, the results end up in a requirements specification (the client's view), a functional specification (the contractor's response), in use cases or as user stories in a product backlog. Prioritisation methods include MoSCoW (must, should, could, won't) or the Kano model, which distinguishes basic, performance and delight features. Users only notice basic features when they are missing, which is why they are often not mentioned at all in interviews.
Example: requirements analysis for a customer portal
A wholesaler wants business customers to trigger reorders online themselves instead of by email and phone. The first statement is: "Customers should be able to order online." The analysis turns this into verifiable requirements:
- Eliciting: interviews with sales and the back office show that every customer has their own prices and their own range and that orders are currently entered into the ERP by hand.
- Analysing: this results in a functional requirement (display customer-specific prices), a constraint (prices and stock come exclusively from the ERP) and a quality requirement (stock and price are up to date when the order is completed).
- Formulating: as a user story: "As a buyer for a business customer, I want to repeat an earlier order with one click so that I can reorder standard goods faster." Acceptance criterion: items that are no longer available are flagged before sending, and the basket only takes over available items.
- Validating: in the review with sales and accounting, it emerges that customers with open items are not allowed to order. This rule was not in any document and is added as a new requirement.
The last step shows the benefit: without the analysis, the rule on open items would only have been noticed as a bug after go-live.
Requirements analysis vs requirements management
The two terms are often used interchangeably but describe different tasks. Requirements analysis clarifies which requirements apply. Requirements management ensures that these requirements remain traceable, up to date and consistent over the entire lifetime of a project and beyond.
| Requirements analysis | Requirements management | |
|---|---|---|
| Goal | Understand the need and record it as verifiable requirements | Control requirements over the life cycle and keep them traceable |
| Timing | Focus at the beginning, again with every major extension | Continuous, from the first draft to maintenance |
| Typical activities | Finding stakeholders, interviews, workshops, modelling, formulating, negotiating | Versioning, prioritising, maintaining status, assessing and approving changes, ensuring traceability |
| Result | Requirements specification, backlog, use cases, acceptance criteria | Current, versioned set of requirements with a change history |
| Guiding question | What exactly do we need? | Which version applies, who changed what, and what depends on it? |
At the heart of requirements management is traceability: for every requirement it is clear where it comes from, where it is implemented and which test checks it. When a change comes in, this linkage shows which parts of the system are affected. In agile teams, a well-maintained product backlog takes over many of these tasks. In regulated environments or fixed-price projects, a formal change process with assessment and approval is common.
Requirements analysis in agile and traditional projects
In the traditional approach, for example according to the V-model, requirements analysis is a phase of its own at the beginning, and its results are fixed in the contract. In agile software development it does not disappear but is spread out: a rough target picture and the most important constraints are clarified early, and the details of each user story shortly before it is implemented. A discovery phase combines the two, because it examines the problem, users and technical risks before the first increment is built.
The most common mistakes are the same in both worlds: only talking to decision-makers instead of future users, writing down solutions instead of problems ("We need a dropdown") and postponing quality requirements until later. If you do not want to tackle the analysis on your own, we support you with requirements analysis and project management, from the stakeholder round to the prioritised backlog.
FAQ on requirements analysis
What is requirements analysis, explained simply?
Requirements analysis clarifies before development what a piece of software must be able to do, for whom and under what conditions. To this end, those involved are interviewed, processes and documents are examined and the results are recorded as unambiguous, verifiable requirements.
Who carries out the requirements analysis?
Usually a requirements engineer, business analyst or product owner, together with the business departments. It is important that someone moderates the discussions neutrally and understands both the business and the technical language.
What is the difference between requirements analysis and a requirements specification?
Requirements analysis is the activity; the requirements specification is one possible result of it. In the requirements specification, the client records the identified requirements in a solution-neutral way, often as the basis for a tender.
What methods of requirements analysis are there?
Common ones are interviews, workshops, observation at the workplace, document and system analysis, questionnaires, and prototypes and click dummies. Use cases, user stories, process models and requirements specifications are used for documentation, and MoSCoW or the Kano model for prioritisation, for example.
What is requirements management?
Requirements management is the management of requirements over the entire lifetime of a system: versioning, prioritising, assessing and approving changes, and tracing where each requirement is implemented and tested. Requirements analysis supplies the content; requirements management keeps it up to date.
Do you want to turn the results into a document that can be accepted? We help you write the requirements specification so that you can compare quotes. How a requirements specification is structured in concrete terms is shown in our guide to requirements and functional specifications.