• Each requirement must be provided with a unique identifier so that it can be unambiguously referenced to it when planning test coverage or designing test cases, as well as in test reports.
• Software requirements must be presented from the point of view of the user of the system. System and acceptance tests should be designed based on definitions of the requirements, therefore, these definitions should be formulated from the system level perspective. This principle prevents the appearance of requirements affecting the internal properties of the system and requiring detailed knowledge of the code for successful testing. Such requirements should arise in the late stages of development and be covered by unit testing and integration testing.

To be able to know whether or not certain software apps run properly on the required platforms people resort to multi-platform testing services to verify the programs’ functionality and performance.  

• There must be both functional and nonfunctional requirements. Functional requirements are the requirements that describe the services and functions that the system being developed should provide to the users. Non-functional requirements describe the limitations imposed on the operation of the system, for example, the number of simultaneous users, and the standards that the system must meet.
• The requirements definition document must be placed under configuration management. This, at least, means that this document is subject to version control and that all versions of the document must be placed in a secure repository, such as, for instance, a directory whose content is usually duplicated. If the requirements are subject to change, we should be able to make sure that the corresponding changes are made in the test cases of system and acceptance tests.
• The structure of the requirements definition document can be based on the specifications defined in the IEEE Standard 830: The IEEE Guide to Software Requirements Specifications.

There is a requirements definition document that was prepared for a fictitious Test Management Toolkit, TMT. This application allows managers and engineers, test specialists to manage test plans, defect reports, test results, and other information related to software testing. TMT is a Web application, so several geographically remote users can simultaneously participate in several testing projects.