- Jack Be Nimble
- Wicked Problems and Gordian Knots
- Jack Be Quick
- Jack and Jacqueline Jump over the Candlestick
- Agile Business Analysis and Iterative Development Cycles
- And Jill Came Tumbling After
- Knowledge Artifacts
- Jack Sprat Could Eat No Fat
- Traditional Business Analysis
- The Requirements Document
- They Have Licked the Platter Clean
This chapter is from the book
This chapter is from the book
This chapter is from the book
Traditional Business Analysis
Traditional, or sequential, business analysis refers to writing a requirements document to serve as the foundation for the system development effort. The requirements document is usually completed, or mostly completed, before construction begins. At least, that’s what’s normally meant by traditional process. This is often known as waterfall—which is misleading—and far too many people spend far too much time telling you how evil, wasteful, calamitous the waterfall process is.
It doesn’t have to be.
Some amazing systems have been developed using the traditional approach, and there are often very good reasons for using it. For example, if you work in the pharmaceutical or medical arenas, or in aeronautical or the military, you are required to write the complete specification and be able to prove that the implementation matches the specification and that all the requirements have been tested.
Why these industries? Because human lives depend on their systems. Because all of them are audited by overseers who are charged with ensuring that the systems work, and work as intended. That’s comforting to know when you are at 39,000 feet or having a tumor treated by a linear accelerator.
Similarly, for most outsourcing projects or some government projects, there is a need for a complete and rigorous specification. There are also organizations that, for one reason or another, want to produce a specification.
Of course, there are many instances of noncritical development efforts that produced far too much documentation, but that does not mean that no documentation is the answer. Naturally, there have been specifications that were badly written and produced the wrong result. But blaming the specification because of the person who wrote it is wrong.
So what should you do if you are working in the traditional way?
Most of what we have written in this book also applies to the traditional business analyst. Let’s look at a traditional project.
Before reading further, please expunge from your mind the thought of a team of business analysts working for month after month producing a requirements document that is so thick it can only be moved using a forklift. And, once produced, the document is barely touched by the developers, who know that they will not be able to find what they need from it, and in any event, even if they deliver the wrong product, nobody will know because nobody can read the huge specification and prove them wrong. So who cares?
Those days are gone. Long gone. Nobody does it like that anymore. They haven’t for years.
Traditional Process
The traditional process produces a complete specification before starting construction, but what you should do to produce that specification is more or less the same as if you were using an agile approach.
You identify the customer segments and their problems You solve the right problem. You design a business solution that attracts its audience and slots neatly into its environment. You ensure the right product is developed.
The differences lie in the approach you take to these tasks. Consider the process shown in Figure 7.10: the discovery side of an agile process. You have seen this diagram in previous chapters, and we have written about the details in previous chapters, so there is no need to describe these activities again here.
)
Figure 7.10 The discovery activities. These are also appropriate for traditional projects.
Note in this figure the feedback and iteration arrows. These are the things that make the difference for traditional projects. Your aim is to produce the requirements document at the end, but you do not necessarily produce it all at once. The way you do it depends on the kind of problem you are solving.
Let’s start by dividing problems into routine, complicated, and complex.
Routine Problems
Routine problems exist in a well-understood domain and are the kind of problems that you and your organization have solved numerous times. You work for a logistics company; you have another logistics problem. You work for a movie distributor; this is another movie distribution problem. Moreover, you probably have only a few customer segments for routine problems.
How big is this problem? If you consider this to be a small to moderate problem, it’s possible to collect all the customer segments and their individual problems. You can then proceed with all of them at the same time, finding business solutions that solve the problem, moving through investigation and designing the solution. Design means designing the total package for all your segments, which you then specify in your requirements document.
Routine problems exist in a well-understood domain and are the kind of problems that you and your organization have solved numerous times.
If your routine problem is large, you would probably divide the customer segments at the time of identification and work through the activities producing the requirements document for a subset of segments. You might make use of business events to prioritize and partition further. The large iteration arrow shown in Figure 7.10 indicates that you iterate back and pick up the next segment, do the same again, and repeat until the solution for all the segments has been specified.
Complicated Problems
Let’s say that your problem is beyond routine. Complicated problems have lots of components interacting with each other. It’s a difficult problem in that it might be partly or wholly unknown to you, but you are still able to determine if it is working correctly. For example, a commercial airplane is complicated, as are some websites. Amazon’s site springs to mind as an example of a complicated problem—there are lots of components, and they need to work correctly together for you to pay and have your stuff delivered tomorrow.
Complicated problems have lots of components interacting with each other.
Let’s start with a medium-size complicated problem. As usual, you determine the customer segments and then select a few of the higher priority ones. Work through finding the best solutions, and investigate them as usual. Instead of designing the work for them, iterate. Go back and pick up the next set of segments and repeat the process. When you have finished investigating all the segments, you design the whole solution at the same time. It is necessary to do it this way because you must ensure that all the components of the complicated solution work together.
This is a large task. You can, of course, subdivide the design now that you know the whole of it, using pieces of the solution that have similar characteristics as your partitioning theme.
If your complicated problem is very large—say, something as big as air traffic control—then slicing and iterating is quite intricate. The difficulty lies in coordinating the various sections of the solution so that they work in harmony when you’ve finished.
Complex Problems
Complex or wicked problems are those with too many unknowns, or too many unpredictable effects, to be able to determine absolutely if any solution is working correctly. For example, the economy and mapping the seabed are complex problems. There are too many unpredictable causes and effects.
By way of illustration, suppose you are charged with building a solution to predict crime. Consider the number of variables that contribute to crime: criminals, their attitudes and upbringing, opportunities, financial situation, weather, locality, presence of police or security guards, and so on. Each of the variables has an effect on one or more others. This results in a level of complexity that makes it difficult, if not impossible, to determine if the results are accurate. The predictive policing systems in operation at the time of writing are good, but nobody can really say if the results are as accurate as they could be.
Complex problems are those with too many unknowns, or too many unpredictable effects, to be able to determine absolutely if any solution is working correctly.
For complex problems, the first step is to identify the known, or routine, parts of the problem. These are most likely the automated parts, which are more predictable than the human parts. Depending on the size of the problem, you would select a subset of the known problems and work the discovery activities up to and including design. Although you probably produce a requirements document for the design, it is important not to commit to developing it yet.
Iterate for the rest of the routine parts of the problem until they have all been designed.
Now it becomes both tricky and fascinating. You have to model the effects of the routine parts of the solution as they interact with the unpredictable elements of the problem. You are using something like the safe-to-fail probes we spoke of earlier to determine the feasibility of your complete solution.
Once you are satisfied that you have designed the optimal components, produce your requirements document and proceed to development. It might be that you have already developed some of the components of your complex system; you needed them to make your testing more realistic. This is often necessary, but it is also necessary to keep in mind that your developed components are, until proven, an experiment.