6 Oct 2012

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.