I really like "mining" here. At least for me the connotations fit really well. I think it's better than "inventing", because it's not like requirements come from thin air. They exist in a raw form buried in the stakeholder's minds / domain knowledge and they are extracted to a useable form through hard labor.
Inventions don't come out of thin air either. They interact with context, needs. They arise within limitations. Etc.
I totally disagree. The spec dies not exist. It isn't buried in your customers' brain or your CEO's. It isn't mined. It is invented, one way or another, by those making the damned thing.
The "requirement" for a spaceship is "must travel to the moon." What software requirement mining tries to do is mine Kennedy's mind for the design of the bathroom.
The requirements and the spec are very different things. The requirements are exactly the thing that comes from the stakeholders. The spec is a way longer document that must match the requirements, but it is not the requirements.
Also, the requirements for a spaceship are only "must travel to the moon" if your customer is a 5 year old child. The real list of requirements is way longer and includes things like "must be compatible with our existing launch infrastructure".
While it's true that requirements come from the stakeholders, often the stakeholders don't really have them, they don't know them, and when they think they know them, often those are not the "real requirements" but some proxies which may even need to be violated to get a good product - i.e. I may think that a significant requirement is to ensure that some thingamajig very reliable and has many redundant duplicates/backups, but a better solution is a design that removes that thingamajig at all.
The key problem in obtaining the requirements is not a problem of communication (as the original article states) but in the work that needs to be done by (or with) the stakeholders to figure out the actual requirements. And I'm not talking about making the detailed spec, I'm talking about the big conceptual requirements which often after some proper analysis get a fundamental change of perspective. This is the main issue in making good products. If you simply make a spec for the requirements the stakeholders initially think they have, your success will depend on how much thought and work they have given to choosing these requirements, and often that will be lacking.
