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

Therefore software development organizations implement a rigorous
configuration management process to ensure that the integrity of project's software
artifacts is protected. It is protected using a configuration management tool or a
directory/folder structure coupled with strict security enforcement. Once a software
artifact is brought under the rigor of configuration management, changes to the
artifact are strictly controlled conforming to the organizational change management
process. We discuss change management as applicable to requirements management
in Chap. 8 . When is the right time to bring the requirements specifications documents
under the rigor of configuration management? As a general rule, a software artifact is
brought under the rigor of configuration management only after the final level of
internal approval is accorded to the artifact. So, if we receive any feedback from the
customer as a response to our submission for approval, the artifact would still be
subjected to change management process.
Establishment of requirements is depicted pictorially in Fig. 5.1 .
5.6 Establishment of Requirements in COTS Product
Implementation Projects
COTS product implementation products differ from software development projects
because the software product is already available. But, it has to be customized,
either by building a layer over the product which is the case most of the times or
modifying the source code which is the case in a few cases. The stages in
implementation of a COTS product from the software engineering standpoint, in
an organization are:
1. Gaps analysis—This is comparing the functional practices existing in the
organization with the functionality available in the COTS product to bring forth
the gaps between them. The gaps are recorded in a gaps analysis document. Each
of the gaps is analyzed to determine one of the three possible alternative courses
of actions to bridge the gap. The three possible alternatives are to customize the
COTS product, customize the organizational practice or take no action and leave
both as they were. We discuss this document in detail in the subsequent sections
2. Statement of Work (SOW) preparation—This draws upon the gaps analysis
document to determine the customization necessary for the COTS product. The
gaps that would be bridged by customizing the organizational functional
practices are omitted in the SOW document. The gaps that need customization
of the COTS product would be included in the SOW document. We will discuss
this document also in the subsequent sections.
3. Software design—Using the SOW document, software design is carried out to
bridge the selected gaps. When a layer is proposed to be built over the COTS
product, a Software Design Document would be prepared. When it is proposed
to modify the source code of the COTS product, a Conversion Guidelines
document would be prepared. This activity is beyond the scope of this topic.