I believe we are many in the same situation. At the same time as we are developing the software we define the requirements in different formats – verbally, written or as drawings & models. Also we define our requirements in parallell with other projects who are dependent on our project or vice versa, and who already have started development.
This is basically something good. Previously many did the specifications up front – sometimes for months or years (!), then handed over to development who tried to understand and implement what was written. This led to many errors so the ”requirements phase” has basically disappeared completely.
I have many good experiences from working with requirements in parallell with development. It’s pretty messy and frustrating for everyone, but in the end, the result seems to get a bit better off.
The problem arise when the organization do want to work like this, and at the same time expects the product owners, business analysts, solution architechts or whoever works with requirements to have ALL the answers exactly specified completely for every conversation.
”If you can’t give us a complete specification this week on feature x then we cannot commit to give you any delivery for the next 8 months, and possibly not at all”
-”But, in order for us to give you a good spec we need to see your first version of the software so we know where the gaps are, and can fill in the blanks”
I have seen this many times. You don’t want a 6 months requirements specification phase, because you know this will generate too many errors. Still you don’t want to accept that by removing this you DON’T have a complete specification to offer, you DON’T have the answers to new or modified business rules and you actually HAVE to have a development process that deals with this. (There are many available..)
It seems so hard for many organizations to accept the fact that there is no specification and to adjust the processes to fit with the new reality of requirements discovery during development.
Those organizations who learns how to facilitate the new way of working by building in these facts into agreements with suppliers or dependent organizatons will succeed.
And those who have realized you need people who spend more or less 100% of their time with requirements investigation, disvovery, design in the teams & projects will also have a better chance to succeed. In mature teams, with time, the ”agile” requirement process will settle but it needs attention, competence and focus.
We’re in the middle of a change and too many are trying to work both in the old and the new way with requirements. This creates only more mess. Let’s accept the new form of working with requirements in parallell with development, and adjust our organizations, agreements and contracts to this.