I have some doubts about defining non-functional requirements relative to security, modifiability and usability.

Relative to security for example a requirement for a system that needs to use https because it deals with financial information. Can a security non-functional requirement for this be "all transactions that involve financial information must be encrypted"? Because it seems to be a non-functional requirement, however it doesn't seem measurable.

Relative to modifiability, in the case in which a system must be implemented in a way that it is easy to add new functions. How can we define a non-functional requirement for this that its not vague and is measurable?

And about usability, is "the system must present understandable error messages" a non-functional requirement? Because it's not functional, however, its not measurable, so can it be considered a non-functional requirement? Also are requirements like "the interface must be responsive" and "the system must be cross browsing" non-functional requirements relative to usability?

@gnat: no, not a duplicate. This question is about specific cases of something which either is or is not a non-functional requirement. The other question is asking for a definition of a non-functional requirement, and is answered with a bunch of examples, but no definition, nor criteria. The other question won't be helpful to the OP.
– Arseni MourzenkoJun 11 '17 at 17:54

1 Answer
1

“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 maintainability index of Java and JavaScript code is measured using SonarQube definitions specified in appendix C, part 2. Bash scripts are excluded from the maintainability index. If the project needs to use an additional language, this document should be revised.

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).