I frequently employ an exercise when teaching my courses; I ask the audience members to think for one moment of their idea of a "dream home". I ask them whether they thought about this before and the majority of them agree that yes, indeed over the course of their lives they have given this topic a lot of thought and can envision this building pretty well.
Then I tell them that they now have to sit down with me - and I am willing to invest as much time as needed - and describe the house to me in detail, down to the type of flooring in the kitchen and living room, colour of the walls in the master bedroom including the exact shade, specific type and model of faucets in the bathrooms, molding in the dining room area, etc., etc., etc. The goal of this exercise is that at the end of it I should have a detailed blueprint of the building and the bill of materials including product SKUs I can go to, say, Home Depot with and purchase all the necessary supplies.
After a couple of minutes someone in the room exclaims,
“But that is impossible! How can you expect us to know all the little details about the house?”
Why am I telling this story? The reason is that thinking that one can easily come up with a complete list of detailed requirements at the beginning of the project is a self-deception. Requirements elicitation is a long and at times painful process of probing, asking questions analyzing the preliminary results, coming up with more questions and investigating again.
Furthermore, once the technical experts sit down to have any kind of requirements elicitation interaction with customers or users, they (the users) do not necessarily provide the analysts with a structured model of requirements that follows a predefined taxonomy. In other words, the customers rarely start these conversations by saying, “I will cover all of the high-level business requirements first, followed by product features. And at the very end I will provide you with all the functions and attributes of the product".