Business domain analysis, knowledge capture and software requirements - Are we there yet?
It is 2018 and yet, most software projects are over-budget, shipped late, and sometimes completely miss the mark, with users clamouring in frustration "this is not what I wanted". So what seems to be the cause?
The Agile Manifesto and the Lean Startup approach have done wonders to help realign business and IT, shortening the development cycles and prioritizing what should be built.
However, the early phases of the development cycle, especially the design and requirements phase, remain largely artisanal: the realm of sticky notes, Word documents and oral communication with hard-to-find domain experts.
Specifically, architecture notes and design decision documents quickly become out of date, as developers churn away at the problem and code their way through the backlog. Even then, the nice set of specifications and requirements written by business analysts and end users is soon exposed for what it is: a false or incomplete understanding of the real problem to be solved. Software development is inherently a discovery process, a series of learning experiments.
So how do we solve the requirements problem in the software development cycle?
This is a question I set to answer with better collaborative tools, tailored for product managers and tech leads. If you’re building B2B solutions and need to accelerate your software engineering practice, contact me :)