What is the difference between Requirements Elicitation and Requirements Analysis?

5 Answers 5


Based on my understanding of the English language and trying to be logical about what should be the difference:

Requirements Elicitation = Requirements Gathering. This is asking what are the requirements, what if this, what if that, etc. This is about asking the questions and getting responses. How well are the answers is another matter entirely. This requires the stakeholders to answer their part of what is to be done and why.

Requirements Analysis. This is more the organizing of answers to the first part. Which solution is optimal? What are the trade-offs of various possible implementations. In this part there may be the odd question but it isn't the main point as this is about seeing which solution may be better under various constraints,e.g. which is the fastest or cheapest. This is more about how is something to be done and why does that way make more sense than another.

Another way to think of this is that the Elicitation has to come before the Analysis as otherwise you are analyzing nothing, which may not be that useful or productive.


Requirements Elicitation is about finding out what customers (and potential customers) say they think they want. It produces a wishlist (well, you might be polite and call it something else, but that's what it is).

Requirements Analysis is about distilling the wishlist to produce a list of actual requirements together with dependencies between them. It also involves saying that some things on the wishlist are out of scope for one reason or another (e.g., you're proposing to do a project on some client software and the customers asked for you to do something that clearly requires major server changes).

Once you've done the requirements analysis, you're in a position to come up with a plan taking into account the resources and time available. You're also passing a project milestone; if you've not got coherent requirements, it's time to abandon the project as impossible to plan.

For reference, I like to keep the output of the Elicitation in a wiki and the outcome of Analysis as feature requests in a bug tracker with cross-references. I'm sure there are other ways to do it.

  • Often it’s not even what they think they want, but what they think you want to hear. Or what they think causes the most amount of work because they don’t want change.
    – gnasher729
    Jan 23, 2023 at 8:54

Requirements Elicitation: the process through which the customers, buyers, or users of a software system discover, reveal, articulate, and understand their requirements.

Requirements analysis: the process of reasoning about the requirements that have been elicited; it involves activities such as examining requirements for conflicts or inconsistencies, combining related requirements, and identifying missing requirements.

Requirements specification: the process of recording the requirements in one or more forms, including natural language and formal, symbolic, or graphical representations; also, the product that is the document produced by that process.

Requirements validation: the process of confirming with the customer or user of the software that the specified requirements are valid, correct, and complete.


For any project, be it a short-term or a long-term project, it is very important that the requirements are clear and complete. This could be ensured by requirement elicitation and analysis

Requirement analysis: is taking account of all the possibly conflicting requirements of the various stakeholders, analyzing, validating, and documenting the requirements. Typically, development of user scenarios, identifying use cases and prototypes can be considered for the analysis.

Requirement Elicitation: is the process of bringing out all the details required for the successful implementation of a solution catering the demand of the end-users and other stakeholders , without any major deviations, either in the planned efforts or in the schedule.


Here is the answer from ChatGPT (my own take is at the end).

*Requirements elicitation and requirements analysis are two distinct activities in the software development process that are concerned with gathering and defining the needs of stakeholders for a software system.

Requirements elicitation is the process of gathering information about the requirements for a software system from stakeholders such as customers, end-users, business analysts, and subject matter experts. The goal of requirements elicitation is to gather as much information as possible about what the stakeholders expect from the software system in terms of functionality, performance, and behavior.

Requirements analysis, on the other hand, is the process of evaluating the requirements gathered through elicitation and determining the feasibility of building a software system that meets those requirements. This process involves reviewing, organizing, and verifying the requirements, and identifying any ambiguities, gaps, or inconsistencies in the requirements. The goal of requirements analysis is to ensure that the requirements are complete, consistent, and unambiguous, and to identify any potential problems that may impact the development of the software system.

In summary, requirements elicitation is focused on gathering information, while requirements analysis is focused on evaluating the information gathered and ensuring that the requirements are well-defined and feasible to implement.*

My Take: At the end of the day we must identify the needs of the stakeholders and document them as verified and validated requirements. I think Analysis encompasses all of that, but if people want to call the first part of that 'elicitation' a la the IIBA, then there is no harm in it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.