Analysis is usually a significant part of most software development efforts. As such, it would be reasonable to assume that analytical methods are well understood, even if analytical skills are not commonplace. However, there is often a great deal of tension between stakeholders that centers on the mechanisms and products of analysis, indicating that this assumption is not valid.
The reasons for this are many and varied, and I will explore them in this series of articles.
A Specification is Not an Analysis
For this first installment I would like to draw a distinction between the activities of analysis and design, but not in the narrow way that those terms are usually interpreted and defined; that in which ‘analysis’ is about requirements, and ‘design’ is about technical implementation choices. Indeed, it is precisely those ‘definitions’ that leads to a great deal of the friction. For the remainder of this article, these two terms both refer to activities that business analysts engage in. Care should be taken in particular to avoid the narrow interpretation of ‘design’ as ‘technical design’ and instead to interpret it as any form of specification of a solution to a problem.
Analysis is not About ‘What’ a System Must Do
There seems to be a notion that is gaining popularity, clearly stated and opposed by Robert Martin in ‘Analysis versus Design’, that analysis represents ‘what’ a system must do and design represents ‘how’ it should do it and that analysis and design are inseparably intertwined, if not identical, because of the way that ‘how’ at one level of abstraction can easily be turned into ‘what’ at the next, more concrete, level.
This notion is flawed in a fundamental way. Analysis, at whatever level of abstraction, is not about what will be built but instead is about the problem to be solved. To understand this problem, we will need to employ all of Kipling’s ‘six honest serving men’; not just ‘what’, but ‘how’, ‘why’, ‘when’, ‘where’ and ‘who’.
It is often the case that once the problem is clearly understood, a solution emerges easily, but this does not mean that the two should be conflated. Furthermore, in the design or invention of that solution, use will be made once more of those same ‘serving men’, so the definition of analysis and design in terms of ‘what’ and ‘how’ respectively is perverse.
Many analysts believe that their primary purpose is to produce requirements documents. However, requirements are an invented solution, not an analysis – i.e. a set of requirements is one response to an existing problem, but their is usually nothing that makes it the only possible response and it certainly is not a representation of the problem. The word ‘requirement’ also denotes a sense of finality and definitiveness that often forms the thin end of a wedge between stakeholders.
For example, I was recently told by an analyst that a requirement of the system I was helping to build was that a certain screen should have a function to print that screen out. There are several legitimate reasons why a hard copy might be required. One such reason is that some regulatory body requires a hard copy of a transaction to be kept for some period of time. In this case though, there was no such regulation and the analyst could give me no reason for the requirement other than ‘because the users have asked for it’. One telephone call later, I discovered that users were going to pass the hard copy to users of another system who would copy the data into their system. Of course, behind this problem is a much larger and more insidious enterprise level problem of data duplication but solving that was not a step we could take. Needless to say, we designed a far better solution to the problem, much to (almost) everyone’s joy.
For a less technical example, consider the joke about the man that goes to the doctor and says ‘Doctor, it hurts when I do this’ and raises his arm. The doctor’s responds with ‘Well, don’t do that then’. The doctor has clearly designed a solution to the patient’s complaint, but only in the most superficial way. In fact, he has designed without analysis. In order to come up with a better solution, the doctor must work with the patient more to analyse the problem. After a while he may diagnose the problem which is a presentation of his analysis to the patient. Finally, he can design a solution to the problem, which we usually call a prescription or a course of treatment. The doctor could omit any of these steps (and several sadly do), but the consultation would then generally be considered poor.
Analysis is About The Problem to be Solved
In believing that analysis is about solving a problem and producing requirements, we often fail to address the real problems because those problems have not been revealed or understood. Addressing the real problem will make the stakeholders’ lives easier and also may be technically easier to implement. For ‘easier’, you may in this case read ‘quicker, cheaper and more robust’.
What stakeholders generally want is for their poorly understood problem to be diminished or to go away altogether. It is the analyst’s primary purpose to shed light on the problem. Once this is done, we may confidently engage in flights of fancy to invent and design a solution.