Information Technology Reference
In-Depth Information
reflected in the specifications, one is working to the requirements. If the
specifications do not meet the true requirements, then the deliverable may
still be according to specifications, yet the problem may not get solved
as it should have been. We accept common usage in this chapter, and
use the term “requirements” to refer to the requirement specifications that
we use for building software.
Requirements are an agreement between the developers and the cus-
tomers. Developers include all the groups, both business and technical,
that are on the design and delivery side. Customers include those who
are funding the work, and also the actual users of the applications being
delivered. Together, the parties involved are called stakeholders. We
discuss stakeholders in more detail in later sections.
It is quite apparent that in this matter two sides are involved — one
side specifies the requirements and the other side delivers on those
requirements. Between the two, there is a communication process that
leads to the development of requirements. Whenever there is a commu-
nication process involved, there is a chance that the communication does
not occur properly. When requirements turn out to be “incorrect,” one
often blames “poor communication.” Consider a theoretical situation: what
if there was only one party involved, where one was developing the
application for oneself, and to one's own requirements? The communica-
tion problem would decrease, but still not go away. One would still find
that the requirements were arrived at through multiple iterations. There
could be a possibility that the requirements are wrong for the problem
being solved. So the issue with requirements goes beyond solving com-
munication problems between multiple parties. It has to do with the nature
of requirements itself, the way they emerge, and the process by which
they get developed and, of course, communicated to others.
Language is the primary means of communication between parties
while gathering requirements. (The word “gathering” is an interesting
choice; it conveys an image of someone walking about picking up what
one needs and putting it in a basket.) We also employ formal tools when
there is a need to express precisely what we mean. These could be
diagramming or modeling tools, such as dataflow diagrams, ER (entity
relationship) diagrams, interaction diagrams, and many others. Structured
systems analysis and design techniques have been around for a few
decades now. There are a number of good topics on such diagramming
and representational techniques and this topic does not go into their
details. The increase in precision of communication that these tools offer
does not preclude the fact that the diagrams and models may get inter-
preted wrongly. The solution is not to make the tools more complex,
trying to nail every ambiguity, but to combine good representational
