Information Technology Reference
In-Depth Information
in an existing product thus does not require very detailed requirement information.
Testing for nonfunctional requirements like performance, stress, and load testing is
also easy, as previous behavior of the application is well known and new and modi-
fied features will not change the behavior of the application drastically.
But when it comes to custom software development, things are totally different.
Nothing is known about functional and nonfunctional aspects of the application
beforehand. During requirement gathering meetings the project team documents
whatever is being said and expressed by the customer. Once the so-called require-
ments are gathered and documented, they are sent to the customer for approval. The
customer adds, deletes, or modifies the requirements wherever they want changes
in the original document. So now the requirement document is approved and the
design team starts architecting the system. During any phase of the project, if the
customer wants any changes, he communicates these changes through change
requests. These changes impact the design and subsequent phases of the project.
Can the testing team rely on this requirements document for testing the appli-
cation? What is the accuracy and completeness of this document? Has whatever was
expressed by the customer during requirement gathering been completely covered
in the document? Is whatever was expressed by the customer during requirement
gathering accurate and complete? Experience shows that the essence of any com-
munication cannot be captured 100%. Customers often do not know their require-
ments themselves completely. Many of their requirements are vague or incomplete.
Putting all things together, one can confidently say that for testing the application,
the tester cannot rely only on the requirement document. The tester has to look
beyond the requirement document. Unfortunately one more limiting factor for the
testing team is that they are engaged in the project late and do not have firsthand
information about many things. This means they do not have many avenues for
information and so they rely heavily on whatever documents they have.
One more aspect to be considered here is that with software applications user
base crossing business boundaries, it is difficult to gather requirements for all users.
Nowadays many applications are being used by your customer's customer. In such
instances it is extremely difficult to gather all requirements.
10.. Project Process Information
The customer should be informed about the processes that will be followed for the
project in detail. This will help the customer to understand how each process is
linked to other processes and how processes are implemented. Even if the service
provider is assessed with the CMM maturity model and/or other process models,
these models do not show how the processes defined in these models are actually
implemented with the service provider. At any rate, these process models are actu-
ally nothing but processes and broad guidelines about the processes. It is up to the
service provider as to how he implements them. We deal with legal and government
