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

Coming to the practice of combining URS and SRS into one document like the
user story or the scenario, we need to take the specific instance into cognizance.
Iterative construction of the product is possible in many cases but not all. Building
one thousand row houses is possible to achieve in ten iterations of hundred houses
per iteration. But constructing a building like the Empire State Building, or the
Sears Towers or the Petronas Towers or the Burj Dubai is not workable in itera-
tions. So if the proposed software product/system is amenable for iterative con-
struction, perhaps SRS may be skipped. Another important consideration is the
need for software maintenance to determine the need for an SRS. If the devel-
opment language is of self-documenting variety or has an IDE (Interactive
Development Environment) that makes it easier to understand the source code and
maintain it easily, perhaps, we can skip SRS.
Barring those specific cases mentioned in the above paragraph, I humbly submit
that skipping the SRS is not a good practice. There are standards of ''GMP'' (Good
Manufacturing Practices) for various types of manufacturing industry. I wish that
our software development industry can also come up with ''GSDP'' (Good Soft-
ware Development Practices), some day!
Table 5.2 provides a suggested template for documenting SRS. It has essen-
tially eight sections, namely, the title page, table of contents, project information,
hardware and system software specifications page, interface specifications page,
core functionality specification pages, ancillary functionality specification pages,
and the closing pages.
5.3 Quality Control of the Documents
In the establishment of requirements, ensuring that quality is built into the
requirements specifications is very important. The impact of an error that escaped
being caught and rectified in this phase would have serious impact when uncov-
ered in later stages. If the escaped error is caught in software design phase, we
have to retrace our steps by one level before we can move forward. If the error is
caught in the software construction phase, we need to retrace our steps by two
levels and if the error is caught during the acceptance stage, we need to retrace our
steps by three levels besides the embarrassment of being pointed out by the cus-
tomer. If the error is caught after the software product/system is implemented, we
might even have to suffer losses. The later the error is unearthed, the greater is its
impact and loss. Therefore, we need to subject these requirements specification
documents to diligent quality control activities. The possible quality control
activities are verification and validation. Quality control and quality assurance
activities are very important in software development. Therefore, we have dedi-
cated a separate chapter for a detailed discussion of these activities including
concepts. These are discussed in greater detail in Chap. 6 .