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

language is prone to inject ambiguity into the document, especially in the English
language, which is unusually rich in the availability of multiple words with similar
(not identical) meaning. It is also rich in the adages, idioms and phrases which are
not uniformly interpreted all-over the world. Regional flavors influence interpre-
tation of the meanings of the written word. Again, English language also facilitates
obfuscation of meaning very easily. Therefore, it is common practice to restrict the
free usage of language in documenting the requirements in the software devel-
opment organizations.
The normal practice in organizations is to eliminate ambiguity in the documents,
to define a set of documentation guidelines and to ensure conformance to that
guideline in all software engineering documents. All standards organizations such as
IEEE, ANSI, JSS as well as government departments do have their own docu-
mentation guidelines for preparing professional documents. A suggested docu-
mentation guideline is provided in Appendix A. Another alternative is the Planguage
of Tom Gilb 2 which is briefly described in Appendix B. IEEE is working on this
aspect in their project P1805—Guide for Requirements Capture Language (RCL).
We can also use those guidelines in our organization with or without change.
However, every organization is unique in its own way and it is better to derive an
organizational documentation guidelines/standard appropriate for its unique envi-
ronment and use it in the documentation of requirements. This organizational
guideline can draw upon the best aspects of all such available guidelines.
One other aspect worth discussing here is the methodologies available for doc-
umenting the requirements. There are literally a plethora of methodologies con-
tinuously coming into, and going out of, fashion in the software engineering field.
These include SSADM, OOM, UML, and Agile methodologies (Scrum, DSDM,
Clearcase, XP and so on). These are all in vogue in different organizations and each
has its own followers. However, those methodologies are used to describe the heart
of the document. The other sections of the document such as title page, table of
contents, system information, constraints, and closing pages are left uncovered by
these methodologies. Therefore, in the templates provided in the following sections,
I have indicated where specific methodological deviations can occur.
5.2.1 User Requirements Specification
URS captures all the requirements provided by the end users as well as other
sources at one place in a comprehensive and structured manner. This document
would be used by two sets of audiences, namely the end users and other providers
of requirements as well as the software developers. Providers of requirements
would refer to this document to ensure that their requirements are understood as
2 Book—Competitive Engineering: A handbook for Systems Engineering, Requirements
Engineering , and Software Engineering using Planguage , Elsevier Butterworth, Heinmann, 2005.