Is there an appropriate term for a requirements-gathering methodology where requirements are gathered as contrived by developers while the system is being developed, as opposed to the usual / normal / healthy process (where requirements are gathered from actual stakeholders).
Put another way, what is it called when a requirements team reverse-engineers a system day-to-day, (hopelessly) trying to keep up with what the developers did recently.
I'm expecting to be either surprised or entertained.
You may call it "Requirements-Reverse-Engineering" in a sophisticated manner. Though I don't understand what one would achieve by adding such requirements unless and until they add some value or usability to the customer.
"Non-Fiction Requirements Gathering"
You never know the requirements until the actual stakeholders give impossible and utterly incomplete requirements to a developer. Because only when you have to make the boat float will they remember that they need a bottom on it.
A four step process to writing successful software:
"Growing the system" is a nice way of describing the methodology used by a development group that is being exceedingly agile and 'spur-of-the-moment'.
If you have a group growing the system, then why bother wasting any effort on post-release requirements docs? Sounds very make-work.
Many (big,famous) software projects start out (unofficially) with this type of development methodology, but the ones that are successful work because at least one of the developers is also somewhat of a domain expert. That is, if you have someone who's spend a lot of time working in the domain, then you don't need a big formal process with user champions, committees and masses of paperwork. BUT, it all comes down to actually having a small team, an intense focus and a lead developer who really "gets it", not just one that thinks they do (which is more often the case). Failure rates for this type of thing are huge.