Do You Rely on the Demand and Requirements from the Business Community?

We can’t rely on the requirements coming from the business community. I guess that suddenly a feeling of disbelief, distrust, hesitation, denial or helplessness comes up. But let me remove at least a few doubts.

• The business community knows the business domain probably better than anyone else. At least, I hope so. However, no knowledge and expertise is complete and infallible.
• The business community is the main source of input for corporate IT. There should be no doubt about that either.

Stating that one should not rely on requirements coming from the business community does not mean that IT people may never rely on those requirements or that all those requirements are always wrong. What it means is that IT people should be very careful about these requirements and not consider them as the bible, the Quran, the law or whatever other undisputable reference. If it was, there wouldn’t be changes later on, would it?

Quite often the demand of the business is something like “we need a software that does this, that and that”.  Actually, their demand expresses requirements describing a solution. This implies they created a mental picture of the solution they want. Thus, they conceived already the solution, be it vaguely or maybe already more precise.

Reflecting the Paper Administration

Paper administration is what they know (or knew) and it is their source of inspiration. Since the paper administration is by far more concrete than the abstract world of software, it is easier to deal with concepts existing in paper administration. The solution demanded by the business community often reflects concepts that do exists or could exist in a paper administration. For example: they can ask to “send the demand to another service” as if computers still works with documents. while in fact data can be shared and do not need to be sent. In IT, plenty of concepts, even by far more innovative than “data sharing”, can be invented. IT scientists are better positioned to conceive such concepts and they are more likely to appreciate to which extend such ne concepts can make a difference.

“The computer knows …”?

It happened already a few times in my career that the business experts expressed requirements containing the expression “.. the computer knows ..”. Such requirement explains what the computer should do when “it knows” something. (“the computer knows that the user wants to do this or that and so he already present this or that information”). When asking how the computers knows what to do, there is no definite answer. Computers aren’t humans. The human can interpret a situation and deciding or knowing what to do. Computers can’t interpret, read minds, guess intentions or improvise solutions. Thus they don’t know what to do by themselves. I guess artificial intelligence could help here, but this would explode the invested budget and kill the benefits of the system.

Lacking of Completeness

The requirements often expresses only the main stream process or global solution. The business is executed by people. People can easily deal with exceptions. They can deviate from prescribed procedures. Computers can’t. Every process, every case and every exception must be considered, described and implemented. The business community isn’t accustomed to think in this way.

The business expert can tell you that a case isn’t important because it happens only rarely. Nothing needs to be foreseen. Maybe implicitly he/she means that other features have a greater priority and expects that it will be implemented later. The chance exists this will be forgotten and redesigning processes or revisiting code to implement this additional case may mean a lot of rework. Anyway, the day the rare case happens, the business people won’t be able to wait for a next release and business may have been damaged.

No clue of impact

The business experts may ask for a small change implicitly supposing the change to be local. Unfortunately, since data is shared or used in larger processes, the impact is far more important. Requests needing to restructure the data architecture usually imply that the software applications using this data are also adapted. In worst cases, it is the design or architecture that must be adapted or other technologies must be chosen. Two times I experienced such a case.

No Idea of the Required Work

Some requirements may appear as being only “a detail” to the business community. Nevertheless, they may have a huge impact on the software system. And, some requirements may be solved very quickly, while they may appear to demand a great effort to the business community.

Having the business community filtering what is important and what isn’t based only on business knowledge and on what they assume is important for software development can have unexpected effects.

Trial and error

When the business demand reflects already a solution, it implies that the business community have been thinking about the solution. They already conceived to some degree the solution. It is an evidence that the business community is not at ease when expressing IT solutions. This is not a blame. It isn’t their domain, nor is it their responsibility. Since they assume that software can always be changed, they are tempted to try and to experiment. Then they will discover errors and ask for adapting the IT solution. They aren’t completely wrong about it. Software solutions can often be adapted. But this takes time, resources and it has a cost.

Immature solution

Business community aren’t trained in analysis and in the conception of software solutions. But they urgently need a solution. If they could already have something that at least solve the most critical parts of the problem, it would already relieve the pressure on them. Consequently, their requirements may be based on immature ideas and partial insight in the real issues. If the ideas aren’t clear, the requirements won’t be. Some may remain vague or ambiguous.

It is important to clarify that business requirements are not requirements coming from the business community. These are requirements about the business and it doesn’t matter where the requirement comes from. Thus, the IT department can express business requirements as well.

Conclusion

Requirements often arrive late. They are incomplete, ambiguous and not very innovative. If the IT community base their projects on requirements coming from the business, they may expect a lot of changes, and thus rework. It appears to software developers that business people don’t know what they want. And this is often true. But very often, business people know very well what they don’t want or need. IT people should understand this if they want to serve the business well.