Establishment of Requirements - Requirements Engineering and Management for Software Development Projects - page 73

through all the tests, the mass manufacture begins. In these cases, the prototype is
used more to prove the product design than to document the product specifications.
Prototypes are also used when building one-of-a-kind product such as ships,
aircrafts, rockets and so on. The quantity of these products would be just one. So
building a full scale prototype is not possible. In these cases, the prototype is a
scaled down model of the proposed product. The prototype is subjected to all
applicable tests in the laboratory. Once the prototype passes through all the tests,
the main product would be built. Here too, the prototype is built mainly to prove
the design than to document product specifications.
Thus as you can see, prototype is not really used to document product speci-
fications in the manufacturing industry but to prove the design. The step of doc-
umenting product specifications is not skipped in the manufacturing industry. The
design for the proposed product must be ready to begin building prototype.
But in software industry, in some organizations, prototypes are advocated to
supplant the product specification document. The prototype would contain the
fulfillment of both the user requirements and product specifications but it is not
possible to move backwards from prototype towards extracting the product

specifications.
In agile methodologies, user stories are used to carry out software design. They
skip the step of documenting the product specifications. Agile goes from user
stories direct to design and then on to product construction. In most cases of agile
development, they go straight from user stories to product construction skipping
both product specification and product design. Agile adherents consider effort
spent on documentation other than which is absolutely essential as wasted effort.
Software development is unlike manufacturing as it does not involve the
making and breaking of any physical material. A mistake is not visible to
everyone; it is not lying on the floor in front of everyone but lurking inside the
computer; one needs to open the program to locate it. Correcting a mistake in
manufacturing involves a lot of noise made by the equipment, and waste of
material. Correcting a mistake in software development is just ''debugging''
without involving noise or material wastage. On the other hand, to determine the
material defect, one needs to carry out chemical analysis in manufacturing. In
software development, looking at source code is adequate to understand the defect.
So, what are the conclusions? Do I advocate preparing an SRS or skipping it?
When it comes to building a prototype, I am not very enthusiastic. We need to
take approval from the customer/end-users only for the URS. SRS is inherently an
internal document for the guidance of the software designers. Prototype is essential
to prove the product design. But I have had occasion to see wherein the end-user
organization is not able to decipher even the URS. They want some solution to
their problems in information management but expect the software developer to
use his/her expertise to come up with the solution for the problem that is not
properly defined by the end-users. In such cases, even the URS is not approved. In
such cases, a prototype is perhaps the only solution to move forward, wherein a
prototype is URS, SRS and design all rolled into one. Except in such extreme
cases, I do not see or recommend the use of prototype to supplant SRS.