On gathering requirements(medium.com)
medium.com
On gathering requirements
https://medium.com/@KiwiCoder/on-requirements-gathering-d270d078bbac
1 comments
I don't think your experience is at odds with what I'm saying. There are practical, real-life issues that will always trump the mechanics of product development.
I wasn't disagreeing with you. Quite the opposite. Doing a good job of gathering requirements can be the difference between success and failure. I think my experience shows that there's a lot of education necessary before the software industry as a whole realises how much time and money a project can save with requirements. That will happen though, in time. Usable was about 5 years too early.
My startup, UsableHQ, went through the Ignite100 accelerator, got funded, and then failed because no one wanted to buy our product, was all about requirements management. We built an app that helped you gather the requirements (clever Apache Tika integration for pulling things out of tendering docs in different formats), manage the process of keeping track of how the requirements change though the project (lovely Node and Backbone single page app), and then export the final requirements document at the end to pass on to acceptance and testing QA teams. We spent about 2 full years thinking about how best to stop requirements getting out of hand, putting a stop to scope creep and gold plating, and making project less prone to failure.
Unfortunately we forgot to prove that there was actually a market. At the top end when you're designing an aeroplane there are huge enterprise apps for doing this stuff. At the bottom end a decent project manager can keep it all in their head. In the middle, there's a few project management apps that make a nod to requirements, but not much, so we thought we could sell to that segment. We were wrong.
The problem is that the cost of failing to manage change in a project isn't actually very big. The project might be a few weeks late, or $5000 over budget, or it fails to do something that was in the list of requirements, but that's not really a big deal to either the client or the team implementing it. No one's job is on the line. There aren't any penalties. It's just 'oh, we should fix that I guess'.
Gathering requirements, and keeping on top of what changes, is never as important as the project as a whole, and it turns out that a lot of projects just aren't very important to the people doing them.