Analysis Smells

Okay I'm thinking about definitions 0, 1, and 4 off of the WhatIsAnalysis page:. When you are trying to understand a software problem, what are typical errors and mistakes that are made?
The following is not an answer to the above question, but instead is offered in the same spirit as CodeSmells.

Common AnalysisSmells:
A problem I've seen on a number of occasions is that an analyst has a specific implementation technology in mind when analysing the requirements. It then becomes easy to think: "feature X is probably difficult to implement -- let's hope users don't want it". The analyst, explicitly or implicitly, neglects to consider that feature. When the requirements spec is finished, it is obvious that the chosen technology is a good fit because there are no requirements that are show-stoppers. 6 months down the line, the neglected feature comes to light, but because its a show-stopper for the implementation technology, it is put off till the next version.

It is important to record all the requirements, especially those that are thought to be difficult. This is a matter of professionalism and integrity as well as good sense.

One example I've seen more than once is a save/restore feature for a simulation. Users realise that a simulation that takes several hours (or days) to run, so it would be really nice if they could save the simulation state periodically for when the computer crashes. But the super-optimized C (or C++) code that implements the simulation model has no concept of the explicit state of the model. It's the type of thing that's easy to add early but, especially with traditional development methods, is very difficult to add later. The reason for not putting it in early is that 'surely that'll slow things down'.

Databases (relational vs objects) offer a rich source of examples too. If a type of transaction is difficult (or slow) then, rather than fix the problem, it much easier to pretend that users don't really want that feature. As another example: users don't really want method grained version control for Java do they? Many tools use file based versioning, so assume users don't want finer grains.

Of course, analysis in a vacuum is also a problem: "You want the software to determine the optimal route for your sales people to visit 1000 cities, in real time? Well, I'm sure our clever programmers can do that."

-- DaveWhipp
CategoryAnalysis

EditText of this page (last edited April 3, 2007) or FindPage with title or text search