Imagine that you are tasked to elicit Requirements for a new IT system that needs to be designed to help an organisation deliver their products and services in an improved fashion into the future. So where do you start?
Maybe you might start by needing to understand what the current system does, or understand what the users currently do. Most of the techniques that Business Analysts use to elicit requirements focus on what is currently done.
What leads us to think that the analysis of what people currently do in their jobs and what features and limitations that current systems have are good indicators of what needs to happen to take a company and its business into the future?
Paul Ralph, an insightful academic from Lancaster University in the UK, has written an article titled, “The Illusion of Requirements in Software Development” (see http://arxiv.org/pdf/1304.0116.pdf) that neatly captures some of the fallacies that exist today in capturing requirements. Much of Paul’s work centres on the impossibility of adapting to a fast-changing world.
However it is the US academic, Roger Martin, from Rotman School of Business, that captures the dilemma neatly when he talks about the need to avoid focussing on the past in order to innovate. Martin’s statement is in the context of organisational strategy not IT system requirements, however the need for IT systems to reflect the execution of strategy within an organisation allows Martin’s statement to dovetail neatly into the topic of business requirements (see http://www.marcelmuench.de/2013/01/abductive-reasoning/).
Martin refers to the US pragmatist, Charles Sanders Pierce, as the creator of a branch of logic that is termed “abductive logic” and the contrast between this style of thinking and the more usual inductive and deductive forms of logic is quite striking when one thinks of the process of “eliciting requirements” (see Wikipedia for the definition – extract follows).
The term elicitation is used in books and research to raise the fact that good requirements can not just be collected from the customer, as would be indicated by the name requirements gathering. Requirements elicitation is non-trivial because you can never be sure you get all requirements from the user and customer by just asking them what the system should do. Requirements elicitation practices include interviews, questionnaires, user observation, workshops, brainstorming, use cases, role playing and prototyping.
My assertion would be that, in most of the cases listed above, the Analyst uses inductive and deductive techniques to determine requirements. However this should not (I use the absolute for emphasis) be the case for systems that are truly future-facing.
Modern techniques for software development, I am referring here primarily to Agile Development, Scrum and Extreme Programming, are ways of taking inductive and deductive logic and executing them faster in the context of IT systems development. Fundamentally they do not change the way we think about IT systems, and by implication, the way we think about the business and its future.
My argument is that we need to become more future-focussed in our IT systems development thinking and using what is termed “Design Thinking” is one way to accomplish that aim. Let’s explore this in future blog posts …