My question aim to draw a fine line between Requirements Elicitation and Requirements Analysis. What is the difference between these two?
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.
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.