Pile of books on software development contains information that the requirements must be tested. And, according to statistics, more errors build into a product on the levels of creation and design of the requirements, than during the coding.
As soon as it comes to practice, very often the requirements just do not pass the proofread procedure (and sometimes do not read them). If it comes to a proofreading, it usually ends up by spelling and punctuation. And then the error gets to the end user.
Why? Many reasons are for this. The first - the psychology. Here "isn't thought up here" and different contexts of thought, and much more. The second - lack of the described verification techniques. There are a lot of literatures and courses, but there is no practically on the verification subject.
The topic will be considered at the workshop:
* Psychological barriers to verification;
* Verification techniques;
* Example of an use-case verification submitted by the participants of the uml2.ru community.