> My understanding of functional requirement is that it is binary
Not so easy.
1) Very often (too often) functional requirements are poorly worded, and they leave things open to interpretation or to implied meanings.
Example:
"as user Foo, when authenticated in I should be able to open and modify all the documents I own, so that I can amend them".
Does such user story look good? Probably; but it says nothing about the "contrasting" stories. A lot of times there won't be a story that says...
"as user Foo, when non-authenticated I shouldn't be able to see any document by anybody". or
"as user Foo, I should be able to see and modify my documents and only my documents"
so if a non-authenticated user or a different user has access to your docs, you aren't probably breaking a functional requirements, but it's probably not how the system was meant to behave by most stakeholders.
2) Very often the functional requirements are OK for the sweet spot, but break on corner cases; so many people just won't notice what's wrong.