We want to adopt ISO 25000 quality model, which explicitly states it does not deal with functional requirements (i.e. its Functional suitability is truly about assessing how the functions fit in the context etc.).
According to this and other sources, quality is a non-functional attribute, basically a sum of quality attributes.

But - what about the functional requirements? Are they not part of quality? Some state that "what" (functions) is not enough to perceive quality ("how" - fast, efficient, robust...), but on the other hand, if there are bugs in the functionality, isn't an indication of bad quality? Even though following the 25000 model, they are out of scope of its asssesment.
But I certainly cannot have a perfectly robust, efficient, fast software that just does not according to its functional specs..yet following this standard, it would be the case.

Personally, I would say that the overall quality must include both functional quality AND non-functional, yet I have never read anything like that.

  • 1
    "According to this and other sources, quality is a non-functional attribute" - do you have a public reference for these "other sources" (or for the part of the ISO you are referring to), so we can read the exactly what you found? I.e. the Wikipedia article about non-functional requirements says "non-functional requirements are often called quality attributes", not "quality is a non-functional attribute", so maybe it is just a misunderstanding?
    – Doc Brown
    Jul 24, 2020 at 17:48
  • 1
    John, another thing which confuses me is your statement "ISO 25000 quality model, which explicitly states it does not deal with functional requirements"* - a short google search found me this page about Functional Suitability in ISO 25000, which gives me the impression the opposite is true. Did I misunderstand something?
    – Doc Brown
    Jul 24, 2020 at 18:04
  • Yes, you misunderstood (as I did a few years ago). The Functional suitability is about appropriatness of the functions provided, their fitness, correctness from this perspective. I asked the very same questions and I think it was Robert Harvey who explained that to me. In addition, the standards explicitly mentiones, that all these are non-functional. I will add the link to that answer. sqa.stackexchange.com/questions/13512/…
    – John V
    Jul 24, 2020 at 18:36
  • @DocBrown I forgot to mention you in the previous post. Here the explanation from the standard, why Functional suitability is not about functionality itself: .... subtle distinction that functional suitability addresses how well aligned the function is with the functional requirements but does not include the functional requirements themselves.
    – John V
    Jul 24, 2020 at 18:59

2 Answers 2


I think you are misunderstanding, since "quality is a non-functional attribute" doesn't make sense.

The ISO 25000 series of standards, known as SQuaRE, are all about requirements related to the quality attributes of systems and software. At one point in time, these were referred to as "non-functional requirements", but that really wasn't a good name for them. You may still see the term "non-functional requirement", but "quality attribute" is the preferred term. Wikipedia has a pretty solid list of quality attributes of systems.

So, yes, functional requirements are part of the overall quality of a system. However, they aren't the "quality attributes" of the system, so they are beyond the scope of the ISO 25000 series of standards.

Functional requirements are covered in ISO/IEC/IEEE 12207 and ISO/IEC/IEEE 29148. There are a few other life cycle process standards for very small and large enterprises that are related to 12207 that may also be relevant for some organizations.

A follow-on question might be why quality attributes get a whole set of standards for themselves. I'm not sure, but I'd guess that it's because it's easy to tell if a functional requirement is implemented. If it's implemented, then it must be verifiable by inspection, demonstration, test, or analysis. Not only is it harder to write good quality requirements, but its also more difficult to verify them and monitor the system's ability to support them over time. The ISO 25000 series attempts to address these concerns.

  • No, that was really just my poor phrasing. What I meant is - according to the ISO 25000, the quality consists of quality attributes, all of which are non-functional. So I just wonder - should it not at least mention that apart from that, functional requirements are important too? Looking at the product itself, certainly you need both parts. It just bothers me that not a single article, book etc. mentions that the actual functionality is obviously important to quality, too. You might have a robust, fast system, but what good it is if fails its functional specs?
    – John V
    Jul 24, 2020 at 19:03
  • 1
    @JohnV I don't think that's really how ISO standards work. They all have a scope. The scope of the 25000 series SQuaRE standards is all about quality attributes (or non-functional requirements). Other standards address requirements engineering, verification, validation, and the SDLC.
    – Thomas Owens
    Jul 24, 2020 at 19:12
  • Yeah, I guess you are right. But on the other hand, if you look into the literature, I was not able to find a single source mentioning that functionality also matters to quality, all repeat this non-functional (or now rather quality) attributes collection... Very rarely I found "functional quality" being stated as a part of the quality.
    – John V
    Jul 24, 2020 at 19:39
  • 2
    @JohnV The definition of "quality" in ISO/IEC 25010:2011 ("degree to which the system satisfies the stated and implied needs of its various stakeholders, and thus provides value") or ISO/IEC 24765:2017 (""ability of a product, service, system, component, or process to meet customer or user needs, expectations, or requirements") includes functional quality. If the needed functionality is not present, then the system cannot satisfy stakeholder needs.
    – Thomas Owens
    Jul 24, 2020 at 20:15
  • Yes Thomas, I know, and that is why I find it odd that no sources (in general) consider functionality as part of quality. Maybe it is taken as a prerequisite, because without the "what", the "how" does not make sense? If a product is "just" working (performing the calculation), you cannot really say if it is of high or low quality, it is the "how is it working" that let you quantify - fast enough, slow, resource wasting...
    – John V
    Jul 25, 2020 at 8:53

Every valid functional requirement contains a clear and unambiguous test that, when performed, proves that the requirement has been satisfied. Simply execute that test, and if it passes, the requirement has been 100% fulfilled.

Bugs are an indication that a functional requirement is not fulfilled.

If you want to create a quality metric to describe that state of fulfillment, you're certainly welcome to do so. I would imagine that ISO 25000 has something to say about how to conduct that measurement, and that it would apply satisfactorily to functional requirements given the proper treatment.

If you want to throw in "intangibles" like robustness, efficiency and speed, those are still non-functional requirements, and can be dealt with accordingly under ISO 25000.

  • 1
    Exactly, but that is my point - according to this standard (or the older one, 9126), quality is comprised of these non-functional attributes. I remember even some of the descriptions stating that there is functionality (what) and non-functional characteristics (how), which define quality. But that implies that quality is somehow different from functionality, but that cannot be true. I could not find a single mention that functionality contributes to the overall quality, which must be the the case (I believe).
    – John V
    Jul 24, 2020 at 18:48
  • What I am trying to say - when assessing the quality, if I follow this standard, it seems that only non-functional attributes matter. I find it odd that in all the references and sources, a very few ever mention the so called "functional quality".
    – John V
    Jul 24, 2020 at 19:01
  • This concept of "quality as it relates to functional requirements" seems very important to you. Are you under pressure from management to implement this standard? Have they articulated a rationale or justification for implementing the standard? Because, with the imposition of any standard comes increased costs, and those costs must pay for themselves in some way. Jul 24, 2020 at 19:53
  • Actually, not at all, I am just genuinely interested (and well, confused). Just now, doing some research, I found the following in Google books: " Software quality is clearly the composition of some or all of the following non-functional attributes...".... why no sources, at all, mention functionality? Or do they think that functionality itself does not mean quality (because it merely does it what it should do?)
    – John V
    Jul 24, 2020 at 20:01
  • to me it seems asymmetrical: if functional requirements are met, the quality can still be low, because of NFRs. But no amount of NFRs can make up for missing FRs. What I mean is that even a high quality (super robust, efficient, secure..) system might have functional defects, but will we still say it has low quality? ...PS: Searching further, most sources just say quality=sum of quality requirements, i.e. NFRs. I do not get how they view the FRs, then. Looking at the McCall's model, his quality attribute of Correctness was actually FR: Extent to which a program satisfies its specifications..
    – John V
    Jul 24, 2020 at 20:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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