smiths
commented
4 years ago @peter-michalski, your definition, and interpretation, of NFRs is correct. The requirements listed in Section 7.2 are functional requirements. They are functional requirements added for the purpose of addressing NFRs, but they are still FRs. R12 is the only one that is stated as an NFR. (I like R12 as a starting point. @sorainsm, you should expand on this in the VnV plan.)
@sorainsm, I suggest that you re-categorize R8-R11 as FRs. You should also add NFRs that specify how to judge the operation of the system.
sorainsm
Just did a first quick skim through your CA and it looks very good.
One issue that I am seeing is that the NFRs look to me like functional requirements (even though the functions are not directly related to the main problem domain - they are design level functions to deal with NFRs which are not directly specified).
A common definition of NFR is "specifies criteria that can be used to judge the operation of a system, rather than specific behaviors" (found on Wikipedia, but still correct).
The NFR that you have listed are things the program does i.e. behaviours. I am wondering if the CA needs to specifically list the NFR that those behaviours are trying to address in order to make it easier for the programmer or reader of the CA to understand. For example, should R13 specify that it is for robustness?
Additionally, once the NFR of robustness is clearly established, is the behaviour that you have written a design decision instead of an abstraction?
I would like @smiths imput on this. I may misunderstand the NFR at this level and need to change my report in the future, now I am unsure.