Validation and verification of system requirements
Very often they confuse 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 propose to sort out this issue.
In the article “Modeling an object as a whole and as a composition,” I looked at two approaches to modeling an object: as a whole and as a structure. In the current article we will need this division.
Suppose we have a projected 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, an object has a description as a whole, that is, its interfaces for interaction with other objects are described within the framework of the Object structure. Let the description of the object as a construction be given. Let there is an information object containing requirements for the design of the description of the object as a structure. Let there is a body of knowledge that contains the rules of inference, on the basis of which the 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 are taught in institutions - a lot, a lot of knowledge. They allow, on the basis of knowledge about the object, to design its structure.
So you can start. We can argue that if the object is correctly described as an integer, if the body of knowledge is correct, and if the derivation rules were followed, then the resulting description of the object construction will be correct. That is, on the basis of this description a functional object will be constructed corresponding to the actual operating conditions. What risks may arise:
')
1. Use of incorrect knowledge about the Object. Object model in people's heads may not correspond to reality. Did not know the real danger of earthquakes, for example. Accordingly, the requirements for the object may be incorrectly formulated.
2. Incomplete record of knowledge about the Object - something is missing, mistakes are made. For example, they knew about the winds, but forgot to mention. This may lead to an incomplete description of the requirements for the object.
3. Invalid body of knowledge. We were taught the priority of the masses over the other parameters, but it turned out that it was necessary to increase the speed.
4. Incorrect application of the rules of inference to the description of the object. Logical errors, something is missing in the requirements for the construction of the object, the trace of requirements is violated.
5. Incomplete recording of the findings of the system design. All counted, all 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 not always. But, if we assume that the development is a waterfall, then the risks are as I described. Verifying each risk is a specific operation that can be named. 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 drawn up 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 been verified.
What is validation? In Russian, validation is a validation of the conclusions. That is, there should be a body of knowledge, which describes how to get a description of the structure based on the data about the object. Checking the correctness of the application of these findings - there is validation. Validation is also a check of the description for consistency, completeness and clarity.
Often, the validation of requirements is confused with the validation of a product based on these requirements. So do not.
In the article “Modeling an object as a whole and as a composition,” I looked at two approaches to modeling an object: as a whole and as a structure. In the current article we will need this division.
Suppose we have a projected 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, an object has a description as a whole, that is, its interfaces for interaction with other objects are described within the framework of the Object structure. Let the description of the object as a construction be given. Let there is an information object containing requirements for the design of the description of the object as a structure. Let there is a body of knowledge that contains the rules of inference, on the basis of which the 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 are taught in institutions - a lot, a lot of knowledge. They allow, on the basis of knowledge about the object, to design its structure.
So you can start. We can argue that if the object is correctly described as an integer, if the body of knowledge is correct, and if the derivation rules were followed, then the resulting description of the object construction will be correct. That is, on the basis of this description a functional object will be constructed corresponding to the actual operating conditions. What risks may arise:
')
1. Use of incorrect knowledge about the Object. Object model in people's heads may not correspond to reality. Did not know the real danger of earthquakes, for example. Accordingly, the requirements for the object may be incorrectly formulated.
2. Incomplete record of knowledge about the Object - something is missing, mistakes are made. For example, they knew about the winds, but forgot to mention. This may lead to an incomplete description of the requirements for the object.
3. Invalid body of knowledge. We were taught the priority of the masses over the other parameters, but it turned out that it was necessary to increase the speed.
4. Incorrect application of the rules of inference to the description of the object. Logical errors, something is missing in the requirements for the construction of the object, the trace of requirements is violated.
5. Incomplete recording of the findings of the system design. All counted, all 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 not always. But, if we assume that the development is a waterfall, then the risks are as I described. Verifying each risk is a specific operation that can be named. 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 drawn up 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 been verified.
What is validation? In Russian, validation is a validation of the conclusions. That is, there should be a body of knowledge, which describes how to get a description of the structure based on the data about the object. Checking the correctness of the application of these findings - there is validation. Validation is also a check of the description for consistency, completeness and clarity.
Often, the validation of requirements is confused with the validation of a product based on these requirements. So do not.
Source: https://habr.com/ru/post/244337/
All Articles