Thomas Kuhn published The Structure of Scientific Revolutions in 1962, redefining the dialog about how science progresses, changing it from a purely philosophical prescription to incorporate the sociology of how real scientists actually behave.
In it, to his everlasting damnation, he introduced the phrase “paradigm shift,” which has since been tortured to insanity by a generation of management consultants who never bothered to actually read Kuhn’s seminal work.
It’s a shame, because the underlying idea — that major advances entail a complete change of perspective and worldview — is quite valuable. A paradigm shift doesn’t disprove old ways of looking at things. It makes them irrelevant.
For example: IT is in the midst of a paradigm shift that makes the old idea of requirements irrelevant.
“Requirements” is a holdover from a time when functional managers and end-users asked IT for a system. IT, responsible for delivery of working software that did something useful, asked the logical question, “What are your requirements?” What we got in response were a series of attributes. Software that possessed those attributes “fulfilled the requirements.” Whether it did something useful for the business wasn’t IT’s problem.
That isn’t how things work anymore, for which we should be eternally grateful. IT and functional managers now share responsibility for making sure business change happens. With this new scope, IT and representatives of every affected part of the enterprise must collaboratively redesign the target business function.
Defining requirements is irrelevant to this process. Instead, we must create a high-level “functional design” that describes new business processes, employee roles, and the technology that will be used by employees in their new roles to implement the new processes.
“High level” is a vague term. In practice, it means allowing no more than seven boxes in any diagram and no more than seven bullets of text in any narrative. When necessary for clarity, you can elaborate each box or bullet with one more level.
Once everyone agrees that this new design will work, you can drill down to as many more levels as necessary to create a detailed specification from which developers can code, testers can test, and trainers can train employees in their new roles.
It might seem that the difference between requirements and design is simply word play. It isn’t: Requirements are attributes; designs describe how things will work. This is far more than a semantic distinction.
It’s a different paradigm.