And as long as I'm posting UML tips to get you ready for the case study, there are two other analysis effects you should strive for. The first of these is The Outline Effect.
It’s difficult to learn a new domain. Analysts have to constantly learn new domains and requirements. They’re always learning and studying. How can they better focus on the information that they gather and draw knowledge from it? Some teams work in the same domain from project to project, but many teams tackle a new domain with every project. And even within a single domain, technology and end-user needs are constantly changing. Very few teams can coast through a project relying only on what they knew in the past.
Forces that contribute to this problem include:
- Many new facts to comprehend. The first thing you have to learn is roughly how many things there are to learn.
- Passive learning (i.e., reading and listening) is less effective than active learning.
- Too much information. This can lead to lost information.
An extremely powerful answer to these forces is The Outline Effect: require analysts to create an Outline of the problem domain and the problem. Don't just read, Outline! Now, I use “Outline” in a general sense. They might create an actual outline; but they might also create a UML model, or they might restate the requirements in a different form from how the customer presented them. Obviously, I'm a fan of UML models as Outlines; but regardless of the specific approach, the goal is to restate and reformulate the requirements in your own words and pictures.
Research shows that active learning fixes lessons in the brain more thoroughly. Reformulating the requirements involves more of the brain than does passive review. Reading a document requires you to process words in the language centers of your brain, but not much more – and even less, when the material gets dry and you start to get drowsy. Outlining a document, on the other hand, forces you to move the material into your forebrain, so that you can think about how you want to restate what you read; and then you have to push the knowledge back through the language centers and other “creative” parts of your brain to create the restatement. Heck, even your motor centers have to be involved, since you have to write or type or draw (or even sculpt) to create the restatement.
And more brain leads to better analysis, which is the point of this blog, of course. Not only do you apply more thought to it, but you also fix it more firmly in your brain. Your memory works by association, so the Outline gives you associations to the requirements in more places in your brain. Furthermore, reading the Outline can trigger memories that help you recall what you learned as you created it.
And finally, creating the Outline requires a more careful review of the requirements sources, so less slips through the cracks. It gives you a focus, so that you know when you’ve completed that part of the analysis. And it gives you a check for completeness: if you haven’t finished the Outline, you’re not done reading!
In some cases, consider a throw-away analysis: the analysts and developers analyze the system in advance from written docs just as a way to learn the domain. Then throw it away, because it’s probably more wrong than right. This is one of my favorite tools as a consultant when I’m working with an existing development team: I want them to be primary participants in the analysis, but I also want to speak their language and pull my weight on the project. So I’ll start with an Outline (probably a UML model) just to familiarize myself with the domain; and then I’ll throw it away when I start working with the team, so that I can learn the domain as they see it.
The Outline Effect is also a necessary and useful precursor to The Echo Effect, coming up next.