1

Is this requirement:

The system is required to have an easier GUI to make it more usable by any kind of user (normal or disabled user)

a functional or non-functional requirement ? And Why ?

  • 2
    That's not not a requirement at all; it's a wish. Requirements are specific and testable. Accessibility is a requirement; see ada.gov/pcatoolkit/chap5toolkit.htm – Robert Harvey Oct 14 '18 at 1:13
  • 1
    @Robert The requirements at the link aren't specific and testable either. That's because they are high level business requirements [regulatory requirements which a business has to comply to], and not functional requirements. In a well-developed set of requirements, low-level functional requirements are traceable to high-level business requirements. – Nick Alexeev Oct 14 '18 at 3:11
  • @NickAlexeev: More specifically, Section 508 Standards, though to be fair, those don't look like testable functional requirements either. – Robert Harvey Oct 14 '18 at 19:26
1

Functional requirements specify the features that a system must implement.
Non-functional requirements specify all the other requirements that the system must implement.

If your requirement about a simpler GUI does not add new features to the system, but only specifies how easy it must be to access those features, then it is a non-functional requirement.

On the other hand, the distinction between functional and non-functional requirements is fairly arbitrary. Knowing if a requirement is a functional or non-functional requirement doesn't really help you to implement it.

1

A functional requirement is about what the system shall do. The term "functional" comes from "function" meaning something that takes some input and produces some output.

A non-functional requirement is about how (well) the system shall do what it does. These are usually quality requirements, such as performance, reliability or ease of use, or general technical requirements that apply to the whole system (e.g. standards to be enforces, operating system compatibility, hardware limitations).

You may also be interested in the difference between functional and non-functional requirements.

Your requirement does not tell at all what the system does, but it tells how the system shall do it. It is hence without any doubt a non-functional requirement.

Edit: As you can see in the comments, it would be advisable to rephrase your non-functional requirement in order to make it objective, less ambiguous, and verifiable.

  • Without any doubt, this is not a non-functional requirement, because it is not a requirement in the first place. See softwareengineering.stackexchange.com/a/118446/6605 and softwareengineering.stackexchange.com/a/380009/6605. But don't worry, many persons do the mistake of thinking that non-functional requirement is everything which is not a functional requirement, forgetting the mandatory criteria for a requirement in general. – Arseni Mourzenko Oct 14 '18 at 18:43
  • @ArseniMourzenko the fact that a requirement is not well expressed, too subjective, or not sufficiently precise is IMHO not sufficient to deny it the status of requirement. If the same requirement would be refined and expressed as: "the gui shall comply with Apple's human interface guideline and the WCAG 2.0 guidelines for accessibility" it would be less controversial but still a non-functionzl requirement. – Christophe Oct 14 '18 at 21:08
  • Not exactly. In my answer below/above, I explain why. The essence, the goal of a requirement is to be objective. A requirement which is subjective loses its purpose. – Arseni Mourzenko Oct 14 '18 at 21:23
0

https://en.m.wikipedia.org/wiki/Non-functional_requirement

User friendliness can be tested on target groups and it would show. So I would say it is functional. Non-functional is more like you have to use this particular brand of equipment or you must use green energy to operate it.

0

This is neither a functional, nor a non-functional requirement.

As I already explained a few years ago, requirements are objective, and, as already stated by Robert Harvey in his comment, testable. It may not necessarily be possible to code a test in a way unit tests are done, but there should be a way to have a validation test which would definitively and unambiguously indicate whether the requirement is fulfilled or not.

The first bad sign is the use of “easier.” Adjectives such as “easy,” “simple,” “nice,” or “user friendly” have a strong subjective connotation. Unless we agree specifically—and it is very possible to do so—on the precise measurements of the easiness, simplicity, niceness and user friendliness of a piece of software, the presence of such terms indicates that we're in front of something which is not a requirement.

The second problem is “more usable.” There should be no comparisons without targets in requirements. More than what? “More, compared to our previous product” or “More than the version 3.0 of Our Competitor Inc.” makes sense, as soon as the comparison itself may be translated into a validation test. But just “more”? No, this wouldn't make it.

If heavily reformulated (and by that, I mean removed completely and replaced by a real, correctly written requirement), it could become a non-functional requirement. Accessibility, already mentioned by Robert Harvey as well, is a very objective thing; for instance, a non-functional requirement for a website may specify a required level among Web Content Accessibility Guidelines (WCAG) three conformance levels: from then, either the website conforms to the required level and, thus, fulfills the requirement, or not.

But dreamy formulations about nice GUIs which are user-friendly? Keep it to the salespeople.

What's wrong with subjective requirements?

The goal of requirements is to make two companies or groups of persons agree on what the one entity wants the other to do. This is a contractual thing. Either you fulfill your contractual obligations, you get paid and everyone is happy, or you should prepare for litigation.

If requirements are objectively testable, there would be no litigation.

If requirements are flabby, you'll release the product, then the customer will claim that you haven't fulfilled your obligations, you'll reply that you did everything right, and he'll claim that you didn't, and your lawyers will waste months settling down. If I want to screw with your company, I'd do exactly that: draft a bunch of subjective requirements, and claim that I don't have to pay for your work, because the product you did is not the product I need. It doesn't have an easy GUI: I tested it on our disabled employee and he couldn't do anything with it. It's not fast enough, while I explicitly specified that I want it to be fast. It's not even user-friendly, although I clearly requested it to be.

  • Personally, I come to value customer collaboration over contract negotiation. So if a customer would give me a requirement, I would not reject it because it's subjective and not testable and hence would not fit the formal definition of a requirement. I would on contrary acknowledge the requirement but work out with the customer a better way to formulate what he/she really meant. – Christophe Oct 14 '18 at 21:28
  • But neither would you waste your time categorizing the requirement. The categorization into functional and non-functional requirements is useful in a context of a SRS, i.e. a formal document which has contractual value. – Arseni Mourzenko Oct 15 '18 at 14:40

Not the answer you're looking for? Browse other questions tagged or ask your own question.