Requirements analysis is part of requirements engineering, the discipline companies use to elicit, control and manage requirements, which also includes requirements management. Requirements management is also a subdiscipline of business analysis and a management task for developing complex systems efficiently and with few errors. Requirements engineering is frequently used for complex systems and IT projects. It initially involves identifying, analysing, classifying and prioritising requirements to support the successful implementation of a project. Its broader aims are to clarify objectives, increase project efficiency, identify and minimise errors and, ultimately, stay on schedule and reduce project costs. The following sections provide more information about the methods and objectives of requirements engineering, requirements elicitation and requirements analysis.
Table of Contents
Methods and objectives of requirements elicitation
Requirements engineering begins with eliciting requirements, followed by analysing them. Depending on the product or project, all relevant parties should be involved in eliciting requirements. These generally include both internal and external stakeholders, such as project managers, customers, employees and others involved in implementation. When requirements are being gathered for complex IT projects, for example, developers will naturally be involved, along with funders, marketing staff or users where appropriate. For products and services, customers are among the most important stakeholders. Gathering their requirements before developing a product or software helps you avoid building something that misses their actual needs.
Requirements elicitation initially involves capturing stakeholders’ expectations and wishes in detail. Requirements can be gathered through online surveys, workshops or one-to-one interviews, for example. The aim should be to present the requirements in a structured form so that they can subsequently be analysed. For this purpose, all relevant parties may be given an online questionnaire asking which requirements they consider necessary. Both functional requirements, such as technical requirements, and non-functional requirements, such as quality requirements, are generally collected. Depending on the project, the elicitation may focus on some or all dimensions: technology, finances, personnel, time and other resources.
The most common elicitation methods at a glance:
| Method | Strength | Limitation |
|---|---|---|
| Online survey | Reaches many stakeholders at once, comparable responses | Little room for follow-up questions |
| Workshop | Shared understanding, conflicts surface immediately | High scheduling and facilitation effort, small groups only |
| Interview | In-depth insights, including tacit knowledge | Time-consuming, hard to compare |
| User observation | Shows actual behaviour rather than statements | Resource-intensive, does not capture wishes for new features |
| Document analysis | Draws on existing knowledge from manuals, standards and predecessor systems | May be outdated or incomplete |
In practice, many projects combine methods: the online survey captures the breadth, while interviews or workshops explore contentious points in depth.
Additional requirements may also be obtained from other sources, such as manuals, reference models, standards or, where available, documentation for a predecessor product or system. User observation can also provide useful insights when eliciting requirements for IT projects.
Conducting requirements elicitation and analysis
Requirements analysis follows requirements elicitation. The requirements gathered are examined against specific quality criteria. As part of requirements analysis, each requirement is checked against criteria including the following:
Requirements should also be checked for possible contradictions and examined for potential risks.
During the analysis, the requirements are therefore examined, structured and classified according to specific quality criteria such as feasibility, necessity, correctness and verifiability. They can then be prioritised and documented for the implementation of the project. Which requirements are ultimately included in a requirements catalogue or specification is decided after this careful review and assessment. The requirements documentation is generally submitted to the stakeholders for final review.
The process at a glance
Prioritising requirements
Not every requirement can be implemented straight away. A tried-and-tested approach is the MoSCoW method:
- Must have: essential; without it, the project will not succeed
- Should have: important, but not required for the first milestone
- Could have: desirable if time and budget allow
- Won’t have (this time): deliberately deferred
You can ask stakeholders for their assessment directly in the survey, for example with a matrix question (each requirement rated as must, should or could) or a ranking question in which respondents order the requirements by importance.
Objectives of requirements elicitation and analysis
- Identify relevant requirements
- Structure and classify requirements
- Identify contradictions
- Avoid inconsistencies
- Minimise sources of error
- Identify risks
- Develop systems efficiently
Requirements management is an ongoing process. Another component is change management, which addresses any necessary changes to requirements that may arise during the project.
Eliciting requirements with an online survey in 5 steps
- Define stakeholders and goals: Who is affected, and which decision should the elicitation inform? Decide whether everyone receives the same questionnaire or each group (e.g. users, IT, management) gets its own questions.
- Build the questionnaire: Structure it by topic, e.g. current situation, functional and non-functional requirements. With branching, respondents see only the questions relevant to their role.
- Invite participants: Share the survey link or invite stakeholders directly from LamaPoll.
- Analyse and consolidate the results: Analyse closed questions in the survey reports, condense free-text responses into requirements and check for duplicates and contradictions. You can export the raw data for your requirements catalogue.
- Prioritise and agree: Derive a prioritised list of requirements from the results and submit it to stakeholders for sign-off.
Sample questions for requirements elicitation
Use these questions as a starting point for your own questionnaire and adapt them to your project.
| Question | Question type |
|---|---|
| Current situation | |
| What tasks do you currently perform with the existing system? | Multiple choice |
| How satisfied are you with the current solution? | Rating question |
| Functional requirements | |
| Which functions do you absolutely need for your day-to-day work? | Multiple choice with an “Other” field |
| Which task should the new system make easier for you? | Open-ended question (free text) |
| Which other systems does the solution need to exchange data with? | Multiple choice |
| Non-functional requirements | |
| How important are usability, speed, data protection and accessibility to you? | Matrix question |
| Which devices does the solution need to work on? | Multiple choice |
| How many people will use the solution at the same time? | Numeric input (spin box) |
| Prioritisation | |
| Rank the following requirements in order of importance. | Ranking question |
| Are there any other requirements we have not yet considered? | Open-ended question (free text) |
Questionnaire template for requirements elicitation and analysis
With the LamaPoll online survey tool, you can create and conduct your own requirements elicitation and analysis, which are part of requirements engineering. Online surveys can be used to collect and analyse project requirements in a structured way. The following questionnaire template uses the example of a company’s IT setup, including the software it uses. The questionnaire automatically adapts to each respondent by skipping questions and pages that are irrelevant to them. A dynamic online questionnaire like this makes it easy to collect and then analyse project requirements. Try it for yourself!
Features for requirements analysis with an online survey
Conclusion: Structured requirements elicitation saves time and money later on, because misunderstandings and missing requirements come to light early. An online survey lets you reach all stakeholders at once and collect comparable responses that you can analyse and prioritise straight away. Start with our template and adapt it to your project.
More applications: Identify customer needs and Measure UX and usability
