Information Technology Reference
In-Depth Information
not the windshield wipers need replacement) are there in the work order.
Similarly, when a customer wants something to be delivered as software,
he or she could use more simplified methods of communicating. Do not
assume that formal, heavy requirements documents are always necessary.
What does this mean? It means that requirements can range from “no
explicit requirements” to very formal requirements where every detail has
been spelled out. It is not that one is better than the other. The difference
depends mainly on the type of project and the risks involved.
The Element of Trust
In software development there must be an element of trust between the
customer and the developer when it comes to specifying and interpreting
requirements. The customer must recognize the business imperatives of
the developer, and the developer must make a fair attempt to interpret
the requirements to the benefit of the customer.
If there is a lack of trust between the parties, then the solution is not
to go down the path of more and more detailed requirements in the hope
that, by doing so, all ambiguity will be destroyed and requirements made
absolutely clear. That will not happen. A better approach is to take a fair
shot at the requirements, have good management and risk reduction
processes to support the implementation of the requirements, and maintain
a reasonable level of trust.
The Technical-Business Divide
One of the divides that exists in the world of software is the so-called
technical-business divide (Figure 4.1). Certain aspects of the deliverable
are clearly technical, while others are purely in the business domain. Yet
a practical solution always straddles both aspects. To maintain this dis-
tinction as seriously as some people do is to do a disservice to the way
problems get solved, and solutions get delivered. Because one is delivering
a business solution through technology, both skill sets are equally essential.
Analysts are expected to bridge the divide, acting as translators and
go-betweens. That world view itself needs a little tweaking. All business
requirements need not come from the business folks, and all technical
requirements are not the prerogative of the technical delivery people
alone. Because the end result is a techno-business solution, the dialogue
should be more intense and direct than it is in many environments today.
Without the proper intermix of the two, the future will always remain
uncertain.
