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:
|Requirements||User, Business Analyst|
Who Is In Charge?
Most places do not have anyone responsible to do three very fundamental things. Analysis. General Design. And Detailed Design. But they charge ahead and build systems anyway.
At one large financial company that I worked at, there was a personnel structure that I have never seen, either before or since. Normally, if there is a business analyst, there is only one, and a number of tech people. But at this place, with ten people in the group, there were four business analysts!
The business analysts had “discussed” the “requirements” for over a year. Then I was hired, and was expected to build the system in one or two months! That is, in addition to maintaining four other complex systems that I hadn’t built, and knew nothing about. And of course, had no documentation.
Is there a problem with this picture? What do you think the quality of the systems they produced were?
Business Analysts And Skill Sets:
You would think that a “Business Analyst”, would do something called “Analysis”. But most I’ve worked with do nothing of the sort. They talk to the business users and just pass on “Requirements”.
Many business analysts don’t even know how to do simple data queries with SQL! So, they can not even verify if the data is available to work with!
If you do online searches for “university courses business analyst” and variations, you will find in the course descriptions, “requirements” many times. But you will rarely find the word, “specification”.
Typical “Requirements Gathering” Process:
Business Analyst talks to user, and understands 80 to 90%. Assumes that what the user said is 100% accurate. But at least sometimes the user is incorrect.
Business Analyst retains 50% of what the user said.
Business Analyst does not do any data analysis or verify the information given.
Business Analyst writes down 20% of what the user said into a “Requirements Document”.
Business Analyst gives Requirements Document to the developer who is now supposed to charge ahead and build something.
If you think of it, there is a loss of knowledge along the way, that looks something like this:
Little of what the developer needs is in the document.
Another way to look at it would be in a Venn Diagram:
There is little knowledge or information intersect between the User, Business Analyst, and Developer. The developer gets only a small part of what is actually needed to build something.
Problems With Requirements Documents:
Some companies create documents with lots of pretty colors, graphics, logos, fonts. In some big companies, the document has to fit into some strange format that does not work at all. When you get these documents, they are full of prose. Abstractions. Selling features. Benefits. But unfortunately not much useful information for the people who will actually build the system.
Reading and interpreting many of these documents is really difficult. I would compare it to the work of criminal sketch artist. You read/listen. But then you wonder what they meant. Did they mean this? That? Like a sketch, you come up with an idea, and ask, is that what you mean? It’s a long trial and error process. Then you go back and work on it some more. Have more questions. Rinse and repeat.
Isn’t the purpose of the requirements document to communicate? If so, why do they communicate so poorly?
Most IT Development Processes Have No Specifications:
Without a specification, the development process is a trial and error process. Consider a relatively simple report.
A lazy developer may read the docs, and then will just start coding. A better one will try to make sense of them (as just described), then start.
Business Analyst, and Project Manager will test what the developer made. It won’t be right. Make changes. Rinse and Repeat.
Eventually the work is migrated from the Development to Test environment on Friday.
The User tests. It may or may not be right. Emails Business Analysts, and Project Manager with any errors or corrections.
Developer changes the program again. Install new version in Test environment on Friday.
Rinse and Repeat.
It’s a long trial and error process.
In subsequent posts, I’ll detail some analysis techniques to move from “requirements” toward useful “specifications”.