Validation and verification of system requirements

    Very often confused are the two concepts of validation and verification. In addition, the validation of system requirements is often confused with the validation of the system itself. I suggest sorting this out.

    In the article “Modeling an object as a whole and as a composition”, I examined two approaches to modeling an object: as a whole and as a construction. In the current article, we will need this division.

    Let us have a designed functional object. Let this object be considered by us as part of the construction of another functional Object. Let there be a description of the construction of the Object, such that it contains a description of the object. In such a description, the object has a description of the whole, that is, its interfaces to interact with other objects within the framework of the Object's construction are described. Let the object be described as a structure. Let there be an information object containing requirements for the design of the description of the object as a structure. Let there be a body of knowledge that contains the rules of inference, on the basis of which a description of the object as a structure is obtained from the description of the object as a whole. The body of knowledge is what designers at institutes teach - a lot, a lot of knowledge. They allow on the basis of knowledge about the object to design its construction.

    So, you can start. We can argue that if the object is correctly described as a whole, if the body of knowledge is correct, and if the rules of inference were followed, then the resulting description of the construction of the object will be correct. That is, on the basis of this description, a functional object will be built corresponding to the actual operating conditions. What risks may arise:

    1. Use of incorrect knowledge about the Object. The Model of the Object in people's heads may not correspond to reality. They did not know the real danger of earthquakes, for example. Accordingly, the requirements for the object may be incorrectly formulated.

    2. Incomplete recording of knowledge about the Object - something is missing, mistakes are made. For example, they knew about the winds, but forgot to mention. This can lead to an insufficiently complete description of the requirements for the object.

    3. Invalid body of knowledge. We were taught the priority of the mass over other parameters, but it turned out that it was necessary to increase the speed.

    4. Incorrect application of inference rules to the description of an object. Logical errors, something is missing in the requirements for the design of the object, the trace of requirements is violated.

    5. Incomplete recording of the findings on the design of the system. Everyone took into account, everyone calculated, but forgot to write.

    6. The created system does not match the description.

    It is clear that all project artifacts appear, as a rule, in their completed form only at the end of the project, and even then not always. But, if we assume that the development is waterfall, then the risks are the same as I described. Checking each risk is a specific operation that can be given a name. If anyone is interested, you can try to come up with and voice these terms.

    What is verification? In Russian, verification is a check for compliance with the rules. Rules are made out in the form of a document. That is, there must be a document with documentation requirements. If the documentation meets the requirements of this document, then it has passed verification.

    What is validation? In Russian, validation is a verification of the conclusions. That is, there should be a body of knowledge that describes how to get a description of the structure based on data about the object. Verification of the correct application of these findings is validation. Validation is including checking the description for consistency, completeness and comprehensibility.

    Validation of requirements is often confused with validation of a product built on the basis of these requirements. This is not worth doing.

    Also popular now: