At this step, the requirements (assertions) on the behaviour of the functions under test should be identified in the documentation. Each requirement should be atomic (“elementary”). An atomic requirement cannot be split into smaller requirements or it is not reasonable to do so.
Here we only consider the requirements concerning the behaviour of the functions to be tested. That is,
The function returns 777 on success
is a requirement of this kind while
The structure contains the following fields: int num; double dub; <…>
is not.
The requirements should be marked up in a special way in the documentation using KompoZer HTML editor enhanced with ReqMarkup plugin. Each requirement is given a unique ID and is linked to the corresponding fragment of the documentation.
By default, the text of a requirement (i.e., its textual representation) is the contents of that fragment. If it is necessary to improve readability of this text or, for instance, collect the full text from several locations in the documentation, the complete text of the requirement can be specified manually using ReqMarkup tool.
The text specified manually must not change the meaning of the requirement. It is just a clearer representation of what is stated in the documentation. This textual representation does not replace the contents of the corresponding fragment of the documentation, it is just the text associated with the particular requirement ID.
In most of T2C file generation targets, the textual representation of a requirement will be output to the test execution log (journal) if a test detects that the requirement is violated. That is why this text should better be readable and clear: it can help find out what has gone wrong in the system under test.