"Should" in requirements

[muralidn]

@liziscool

R5 and many nonfunctional requirements make use of the word "should" as shown below.

"Should" in requirements usually denotes that the requirement is optional (https://softwareengineering.stackexchange.com/questions/185868/best-practice-for-usage-of-shall-and-must-while-writing-requirements). I don't think that is the case here.

[liziscool]

I agree, but I am hesitant to use 'shall' for something that is subjective. I choose 'should' because I feel like the requirement could be satisfied in varying degrees, for example, R5 is basically saying that for trivial input signals (e.x. a sine wave at 20 Hz), the output of my program should be comparable to what is known as a 'time-frequency transform' for that signal (on a heat map it would look like a red line at 20 Hz). But they won't be exactly the same (due to differences in implementation, each kind of time-frequency transform results in a mildly different representation). So the comparability could vary greatly, which is why I don't want to use the word 'shall'.

Maybe it is just an indicator that my requirements are too vague/subjective.

[muralidn]

Thanks for the clarification!

Now that I think of it more, I suppose "should" in functional requirements does make sense, in the context that in certain 'cases' this requirement may not be satisfied. The 'cases' are probably system constraints then, or perhaps output constraints?

Dr. @smiths can you please let us know your thoughts on this? Also, is this even applicable to NFRs?

[smiths]

The functional requirement should say what is to be calculated. The accuracy of those calculations are covered by the nonfunctional requirements. The verification of whether the requirements are met is covered in the verification and validation plan.

The confusion seems to start with R5 - as R5 is written it is an incomplete test case, not a requirement.