Big Analysis Up Front

The second stage of the traditional RADI software lifecycle, after BigRequirementsUpFront. The aim is to take a comprehensive customer wish list, identify priority areas and potential problems, allocate resource and refine budget and timescale estimates.

I usually feel that activities during this stage tend to be ill defined and rushed.

-- ColinMacDonald

Traditionally followed by BigDesignUpFront


I look at it as one part of the process of understanding. Your analysis will end up being wrong of course. But the activity is itself one part of the process of getting to what is right. Any largish project requires a lot of hypothesizing, reformulating, back stepping, and forward stepping. Just like in your life many mistakes were made, but you learned from them and they helped you get where you are now. The key seems to know how to balance. Your analysis will not last so don't cling to it, let it guide you, not define you. -- AnonymousDonor

Too good to be anonymous, whoever you are.

The underlying question, though, is "What is the most effective way to progress towards understanding?" (I phrased it this way because I do not believe anyone will ever reach complete understanding). Are thought experiments and written documents the best way to gain understanding, or is a more interactive method of trial and adaptation more effective?

-- WayneMack


Analysis must be done in the context of meeting a particular set of goals. I just love the way XPers want to "interview" end users and capture their "user stories" as requirements. Heh. Check out QualityFunctionDeployment for a much more precise and concise method of determining what a client really wants. In summary, it works like this:

Assign a set of points to the value of any particular requirement in relation to all the other requirements. Thus, if there is a maximum of ten points for the product and Speed is assigned a value of 5, Size is 3, and Cost is 1, then whatever other consideration there is can't have a weight greater than 1. If the client thinks that Coolness needs to be greater than 1 for this new product then he has to give up some weight for another factor, possibly Size or Speed.

The obvious question arising from this line of reasoning is, "how do we measure these characteristics?" You will have to come up with a set of criteria for measuring all the characteristics of value to the client at the start of analysis. The client is the ultimate source for these measurement criteria, of course. As long as everybody understands what is being measured and what the relative measurements mean in relation to each other then you can proceed to provide an analysis that the client will find useful. Otherwise, you are just shooting at Yet Another Moving Target.

The problem with the approach defined above is that a measurement system is not defined. One of the first criteria for a measurement system is a unit of measure. Without an underlying unit of measure, mathematic relations do not hold. In the example above, I doubt there is any way that one could show that "Speed" is 5 times "Cost" and "Size" is 3 times "Cost." Without those relationships, 5 + 3 + 1 does not equal 9, and is in fact indeterminate. The problem with this type of approach is that it gives the impression of rigor, while in truth it is highly subjective.

I'm afraid you've misunderstood the intention of the numbers. The idea here is to have the customer assign relative values to the characteristics he wants, then come up with measurement schemes to insure that the product meets those relative values. If the characteristics are Speed, Size, and Cost then the customer says he wants the box to run fast as a more important characteristic than it being small, which is more important than it being cheap. We can then figure out how big it has to be to run X fast, and how much bigger it needs to be to run 1.2 X fast, 1.5 X, etc. The customer can then see the relationship between speed and size. Then we figure cost into it and he can see everything in relation to everything else.

This thing about relative values is to give us a handle on what is important to him. Once we have a clue about the relative values then we know how to approach a design.


CategoryAnalysis


EditText of this page (last edited October 25, 2010) or FindPage with title or text search