There are the basic criteria that should be followed during static testing of the requirements specifications. These criteria require that each software requirement be complete, unique, consistent, traceable, feasible and maintainable.
Completeness. The set of requirements is considered as complete if all its components are available and each such part is completed. When checking the set of requirements for completeness, one must give special attention to the following points:
- Requirements should not include expressions such as “to be defined”, “et cetera”, “and so forth” and the like.
- Requirements should not refer to non-existent supplemental information,for instance, such as a non-existent specification.
- The requirement should make reference to functionality that is not yet defined.
Uniqueness. Every requirement must be accurately and clearly formulated. It must have only one interpretation. The requirement must be readable and understandable. But if the requirement is particularly complex it is possible to use supplemental material such as charts or tables to facilitate understanding of the information. If, for the sake of persuasiveness, expressions such as “this is obvious” or “needless to say” are used, it may well be that the author is attempting to divert your attention from a particular ambiguous statement.
When technical documentation requires improvement, it is naturally sent to people specializing in creating the high-quality content. There is a tendency to use technical writing service that helps to produce technical documents useful for the target public to understand the product.
Consistency. The requirements must be in sync with each other or meet the current standards. However, if the requirements are in conflict with each other, then one must assign priorities to them in order to eliminate such conflicts. The ability to detect defects caused by conflicting requirements requires thorough knowledge of the entire document specifying the requirements, and understanding of existing standards or other external technical conditions.
Traceability. Each requirement must be given a unique identifier that allows you to track its development over the life cycle. In work products that become available at later stages of the life cycle, such as a test plan, each requirement must linked to its sources which are one or more system requirements. The requirements traceability matrix is an excellent tool for ensuring that all requirements formulated for a system are analyzed in the test protocols.
Comments are closed.