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

formats and templates etc. The activities that ensure that quality is indeed built
into the artifact are verification and validation.
3. Obtaining approvals—An artifact is not deemed fit for use in the project until
it is approved by the concerned executives. In the case of Requirements
Specification, the approvals are accorded by the IS department (in the case of
internal projects) or the concerned project manager (in the case of external
projects) as well as the approvals of the end user department or the client
organization. These two levels of approvals authenticate the information con-
tained within the artifact for use on the project.
4. Configuration management—Configuration management is the set of activi-
ties that ensure that any changes to approved artifacts are affected in a con-
trolled manner. That is each change request is raised, evaluated, impact
ascertained, approved/rejected and approved change requests are implemented
in the artifact conforming to an organizational process and the project plans.
Covering configuration management comprehensively is beyond the scope of
this topic and interested readers are referred to the topic ''Mastering Software
Project Management: Best Practices, Tools and Techniques''. 1

Performing all the above four activities diligently is referred to as the ''estab-
lishment of requirements'' for the project. Let us discuss all these activities in
detail in the following sections.

5.2 Documentation

As noted in Chap. 2 , we have two requirements specifications. One is User
Requirements(URS) Specification aimed at capturing the needs of the end users and
the other is Software Requirements Specification (SRS) aimed at guiding the design
and construction of the product. IEEE terms these two documents as Systems
Requirements Specification (SyRS) and Software Requirements Specification
(SRS). However, individual organizations may have different names for these two
documents as noted in Chap. 2 . We will discuss both these documents in this section.
Documenting the requirements, be it URS or SRS, is describing each of the
captured requirements in detail with all relevant details in a comprehensive and
structured manner so that the concerned stakeholders can understand the
requirements without any ambiguity and ensure that their stakes are well provided
for. The stakes for the providers of information for the document are that their
requirements are understood as intended and accurately captured by the software
development team. The stakes for users of the document are to ensure that all the
necessary information is available in the documents to carry out their own
downstream activities. The crux of documenting the requirements lies in ensuring
that there is no ambiguity in the documented requirements. Normal free-flowing

1

By Murali Chemuturi and Thomas M. Cagley, Jr., published by J. Ross Publishing, Inc., 2010.