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

intended and captured accurately by the business analysts properly. The end users
would use this document as the reference point for all interactions with the soft-
ware development team and in accepting the final product when it is delivered. The
software development team would refer to this document to carry out the sub-
sequent software development activities namely derivation of product specifica-
tion, design of the proposed software product/system, and developing the user
acceptance test plan of the product. We need to document URS in such a manner
that the users would have no trouble in understanding the document and accord
approval to the document. To ensure that aspect, we need to use the user's lan-
guage while documenting the URS. Or, in other words, we need to avoid any
jargon normally part of software development fraternity or the software devel-
opment organizations. IEEE standard 1233 deals with defining SyRS. It is com-
mon for organizations to have in place documentation guidelines to ensure that
free-form language that can give rise to ambiguities, vagueness or conflicting
meaning, has not crept into the document. A suggested set of documentation
guidelines are provided as Appendix A to this topic.
We need to document the requirements in the logical groups we arranged while
analyzing the requirements. It is also advantageous to use the same nomenclature
that is in the list of requirements generated during the requirements analysis. That
will maintain consistency between the two documents. A suggested template for
documenting URS is given in Table 5.1 . It contains essentially five sections: Title
page, table of contents page, project information page, requirements definition
pages and closing pages including appendixes, if any.
In agile software development methodology projects, it is common to replace
URS with a set of User Stories which describe the requirements in a descriptive
manner. In true conformance to the agile philosophy, no template or format is
commonly advocated and the stories are formatted differently in different orga-
nizations. The cardinal rule in this case is that the project team, which usually
comprises the client representative, must be comfortable in the format and be able
to use it to develop the software. Therefore, no attempt is made here to present a
format for documenting the User Stories in this topic.
So is the case with Use Case methodology. Use Cases are also used to docu-
ment URS. A Scenario description is used to capture user requirements along with
the Use Case diagram. There is no standard format or template commonly advo-
cated in Use Case methodology to document the requirements.
5.2.2 Software Requirements Specification
A Software Requirements Specification (SRS) document may be referred by dif-
ferent names in individual organizations as explained in Chap. 2 but, irrespective
of the specific name used in the organization, the document contains the specifi-
cations for the proposed software product/system. I am using the name ''SRS
(Software Requirements Specification)'' in this topic because it is christened so by