“All transactions should be encrypted.”
This is a non-functional requirement. You claim that it is not measurable. Why wouldn't it be? I can make a test which will pass if a given action requires HTTPS, and fail if it works through HTTP.
It doesn't mean it is a useful requirement. Having just HTTPS doesn't mean transactions are secure. You may have an invalid certificate. Or an outdated version of SSL which was proven to be unsecure. However, just stating that “all transactions should be encrypted” is a good start, and from there, you can expand into a range of more technical but still verifiable requirements, such as that the website should have a rating of A+ on Mozilla Observatory, given that a test will be obvious to do, thanks open source.
If you deal with financial information, make sure the requirements are drafted by a security expert in collaboration with a lawyer and then reviewed by other security experts. The actual requirements will probably be verbose and very specific, requiring a precise version of SSL and a precise certificate authority, detailing audits and logs and how those logs are stored, etc. “All transactions should be encrypted” is ways too general: should I simply use HTTPS between the customer and my reverse proxy? Or should I keep the whole chain encrypted, down to the database?
“The system should make it easy to add new functions.”
This is not a requirement. Don't write it down, since you can't do a test which will unambiguously show that the requirement is fulfilled. In general, terms such as “easy,” “fast,” “beautiful,” “comfortable,” “convenient,” “pleasant,” are a good sign that this is not a requirement. A requirement needs to be perfectly objective; independently of the person testing the conformity of the system to the requirement, the result should always be the same.
What could be measured, however, is the maintainability index, and it's here that non-functional requirements could be useful. For instance, by telling that:
Requirement 12.34: maintainability index
Every method should have a maintainability index of 60%.
Every class should have a maintainability index of 75%.
In average, the system should have a maintainability index of 95%.
The measurement is limited to the code which is written specifically for the project. All third-party libraries, would they be imported through package managers such as npm, or committed directly to the version control, are excluded.
you are providing measurable criteria which will result in a pass-fail test.
“The system should present understandable error messages.”
This is not a requirement either. Even worse, it imposes implementation, and limits the work of interaction designers. It's like to say that the code should contain methods of ten LOC or less—it makes no sense to restrict developers for no reason.
It is one thing to tell that “The buttons should be pretty.” You do write a useless requirement, but at least it doesn't do too much harm outside the requirements document. It is a different story when you end up with requirements such as “The buttons should have nice round corners and have a beautiful shadow.” Not only the requirement is still useless, but now it forces the designer to take decisions which would result in a poor interface, instead of doing her job.
Without the “understandable error messages” constraint, an interaction designer can bring her actual skills to do a product which would be understandable, for instance by getting rid of error messages in the first place. When such messages are relevant, the interaction designer would ensure they are actually reflecting the user approach in order to be understandable (given that cultural differences may make them much less understandable when translated into other languages).
Functional or non-functional requirement?