In response to my previous blog someone drew my attention to an article published a year ago by Ron Tolido: “De Dood van Requirements” (the death of requirements). The author foresees a brighter future if we stop thinking in terms of requirements, a future where ict and business collaborate in such a way that there is no longer a need to specify requirements.
It is a compelling vision. Traditionally, requirement elicitation and management consumed an inordinate amount of time and effort. So instead of just trying to speed things up, elimination seems a valid cure.
In a world where businesses need to react and interact within a couple of weeks or even days, traditional development is indeed very inadequate.
This goes beyond the waterfall versus agile debate. There is simply no time left to build things, let alone perform time consuming requirements elicitation. The future is one where businesses can dynamically assemble and reconfigure solutions using services run by the company and services available outside the company.
As all businesses become digital, business and ict will fuse, making requirements obsolete.
In recent years we have seen a move away from detailed requirements specifying the solution with detailed step by step descriptions and user interface designs. Newer approaches tend to put more emphasis on the desired outcomes. Regardless of the techniques used, the underlying principle is that the team creating the solution participates in the design using outcomes as a goal.
As a <user> I want to <do something> such that <outcome>.
The requirements of the business are embedded within the stated user goals. Not the technique is of importance here, it’s what is stated in the <outcome> part that makes the difference. For more on the distinction between business and system requirements, read this post.
This shift has relieved the business analyst from specifying ict details, tapping into the creativity of the solution teams instead. The shift however hasn’t done away with requirements all together. For this to happen, business and ict need to collaborate differently. No longer are the processes designed first, the ict support afterwards. As the business becomes entirely digital the process and the digitalization are the same.
The task at hand is no different that the task of designing business processes today. End to end processes are created to serve customer needs, using the capabilities available to the organisation, be it internally or externally. If certain capabilities are lacking, these have to be acquired in some way.
The statement of the need to develop the end-to-end process that delivers a certain product or service (a certain outcome) is a requirement, albeit of a higher, more solution independent level than the IT-centric specifications known today as requirements.
The lack of the process is the problem that needs to be resolved as required by the strategy of the company. To be honest, I haven't yet encountered a company that puts the label "requirement" on that kind of decision.
The starting point when creating new digitised services is thus a decision based on the strategy and the current capabilities of the organisation. What we need to assemble the solution however is a portfolio of services (or capacities, capabilities, functions) from which we can compose the end-to-end process.
The hardest part will be to foresee and build the necessary services before there is a real business need. Instead of doing away with requirements all together, we need to move from stipulating solution specific IT requirements to predicting what will be needed and build a flexible platform to support that.
Being impossible at the process level, these requirements will be derived from the strategy of the company. The requirements for services won’t be about business processes but about company capabilities. The ict services are the new business capabilities.
Requirements are dead. Long live requirements!