Jun
7
Solving Complex Problems
June 7, 2006 |
Analysis techniques exist to help us structure problems.
That’s hardly a radical conclusion or a bold new insight. However, it was driven home to me recently as a consequence of my day job. I’ve been working lately on producing more “developer-friendly” requirements, which in this instance, consist largely of a very detailed feature list and UI specifications. So far, the developers like it, but I’m noticing that it’s a lot more work for me.
My problem is that a feature list doesn’t provide me with any guidance.
To help explain what I mean, let’s look at use cases. Use cases start with a few things:
- Actors–in other words I know something about the people involved.
- A start point–so I know what conditions exist at the beginning of the use case.
- A goal, or end point–so I know what the actor is trying to do.
Those three things structure my problem for me. I know that the actor has to get from the start point to the goal. I can then break it down into sub-goals that take the actor partway there and keep breaking it down until I have the minimum number of steps the actor must complete to get to the goal. I then ask what can go wrong at each step and how it can either be fixed or how it causes the goal to fail. Lather, rinse, repeat until the use case is done.
Feature lists, on the other hand, require you to actually invent the structure as you go along. Instead you get buckets–things that the system does. You have to fill the bucket until there’s enough information. When’s that? No way to tell, not really, because the desired end state is often very vague. The structure of the problem doesn’t guide you in any way towards a complete solution. You have to figure out for yourself when you’re done.
This, by the way, is what process is for. Process is there to reduce ambiguity and to structure the problem. This is why more experienced teams can get away with less process–they have both a higher tolerance for ambiguity and are better at structuring familiar problems.
Highly structured techniques are like training wheels on a bike–they help analysts work through problems that they can’t structure and organize in their head. Eventually, the better ones will stop needing the training wheels, and be able to work in a more free-form environment. Some will even get good enough to graduate to unicycles. The important thing for the unicycle riders to remember sometimes is that there will always be people needing the training wheels, and we shouldn’t dump people straight onto unicycles and send them out to play in traffic.
Which brings us back to my current efforts with the BA Body of Knowledge. I’m not doing this for the people who are already playing with unicycles and riding them over tightropes. The real purpose is to get those BAs who’ve just been handed the training wheels to the point where they can take off the wheels and ride their bike down a street.
Comments
What I'm Reading- Agile Requirements Information Model (4) – Subset For Agile Programs (a): Features and Feature BacklogScaling Software Agility
- The Great Implication of Context-Driven MethodologyJames Bach's Blog
- User stories versus Use CasesBusiness Analyst Blog
- Can Use Cases Possibly be Agile?Agile Product Owner (.com)
- A little bit of levity for the holidays from iRiseThe iRise Blog
- The end of reposiphilia?The Forrester Blog For Technology Product Management & Marketing Professionals
- IT ethics and the recessionIT Project Failures
- Risk Assessment ModelingEDS' Next Big Thing Blog: Read and Respond to What the EDS Fellows Say About Technology
- Test Requirements, Don't Test CodeHerding Cats
- Enterprise architecture is optionalBizRules Blog