software requirements

Ken is one of the guys, who explains to me, the standard procedures defined for Engineering Changes for his company. The responsibility of me and my consulting team is to customize and to maintain a commercial software product, to suit his company's process needs.

Let me try to explain of what is that I actually do for a living. Here is a company that builds aircraft engines, which, not surprisingly, is made up of thousands of components. To design, to develop, to repair, and to service these components that make aircraft engines, not so surprisingly, this company gotta have hundreds of Engineers working on these components - simultaneously.

And those Engineers work hard. Engines are made, and sold. They are installed into nice, big airplanes. People fly on those airplanes all over the world... yada, yada, yada, and the whole world is a happy place.

Now lets say, a component, that goes into such an aircraft engine, requires a modification for engineering reasons, such as, a re-design to handle more pressure. Or Probably, it has to be modified for quality requirements, such as, a change in the inspection method. Well, if we have to change it, Why don't we just do it ? Not so fast, Young man!!!

When hundreds of engineers working on thousand different components, obviously, we need a standard process of doing it. Also, we need a pre-defined way of documenting those changes, so that we can go back or reverse the change, if needed. Now, go back to first paragraph... Just read the first paragraph, and come back here.

So, now you know what I do, right ? Yes, that's what I do. If you didn't get it, I can say all that in a line - I make a living by trying to make a commercial software work for a business.

So, Where were we ? We were talking about Ken. Ken and I were talking about how to keep track of a component, that is just lying there, and is never used in any engine - Of course, using the software. Well, the process and the software is already there, and Ken just wants to know how it works.

When we were talking about another related functionality, I said that it is already there, and showed the paragraph in the documentation explaining it. He said,

I know this requirement. But we forgot what we meant, when we asked you to do it. If you could say me, how you made your program to do this, then, we could know what we meant, when we asked for that.

And he laughed. Then, I laughed.

I was reminded of this Dilbert Cartoon, when the analyst asks the user for his software requirements. The user asks the analyst to make a software that would tell the requirements. In Software, it is always like that.

When you buy a car, you exactly know what you are buying. When you buy a software, you really don't know what you are buying. When you put your hands on it and start using it, you wonder "Did I really pay for this ? Why did I ask for this ?". That's why it is so difficult to define a software requirement, especially, when it is customized for a business.