Building Better Systems Through Better Analysis

From Reqs to Specs.

In my other piece, I wrote how business requirements documents don’t work very well, how they create a trial and error process, and prototypes make it into production.

Much of the reason is that there is no analysis, general design, or detailed design. Nor is anyone in charge of these areas.

Much of my work in development has been doing the analysis and design that were not done in the first place. Here are some of the techniques that I’ve used. And some that have been very useful when others have done them for me.

Why “Business Requirements” Don’t Work

From Reqs to Specs

One aspect of IT Development that I’ve noticed for a very long time is that no one is thinking things through.

The result, is not a solid piece of software, but just a prototype. Unfortunately, these prototypes make it into production too much of the time.

Is it any wonder that so much software does not work? How many days since the last glitch in some website or software that you worked with? I’ll bet not many.

Why does this occur? A lot of it is the way that IT work is divided now. Think of the classic Waterfall Method and the responsibilities for the tasks:

Task	Responsibility
Requirements	User, Business Analyst
Analysis	???
General Design	???
Detailed Design	???
Build	Developer
Maintain	DBA

Thoughts On Useless Documentation

Have you ever noticed how useless so much documentation is?

Apple II Documentation

Microsoft:
Tell you everything, except how to get to the window, in order to do the thing you want to do.

Unix Man Pages:
Tell you everything, except what you need to know: a simple example that works.

Sourceforge Projects:
Documenation is sometimes completely erroneous, or leaves out very fundamental things, making successful installation or use impossible. See some of my other posts.