6

Trying to understand the standards (ISO) but so far, I find it very confusing. 50% of books state Functionality naturally belongs under Functional requirements, while the other 50% state that Functionality, as a quality factor, deals with non-funtional aspects of functionality. Some just show a list of NFRs and include Functionality (ISO9127) or Functional suitability (ISO25010), some exclude them explicitly.
What is correct? If these quality models are to present quality factors, those should be truly non-functional but it contradicts the definitions in ISO itself (Degree to which a product or system provides functions that meet stated and implied needs when used under specified conditions = isnt clearly functional?)

An example from Google Books - I really do not understand:

Full model of software quality consists of following non-functional qualities:

-Functional suitability: Degree to which a product or system provides functions that meet stated and implied needs (functional requirements).

So what does the above definiton say? That non-functional characteristic is actually functional?
But in most sources, Functional suitability is considered NFR..one of the many is shown below:

enter image description here

Others say that ISO25010 do not address functional requirements at all...

EDIT: So I believe those claiming that this standard deals with functionality are truly wrong, in the ISO document, I found the following:

The scope of the models excludes purely functional properties (see C.6), but it does include functional suitability (see 4.2.1).

4 Answers 4

3
+50

At first let's look at the definition of functional requirement term from ISO/IEC 27000:2014 standard:

functional requirement
requirement that specifies a function that a system or system component must be able to perform

— So functional requirements are what software should do.


Then, coming back to

functional suitability
degree to which a product or system provides functions that meet stated and implied needs (functional requirements)

Functional suitability is measured value of comparison between

  • things that software can actually do
  • and things that software should do.

— That's why functional suitability is non-functional requirement. It covers not only the functions software is expected to do, but also what it really does.

2
  • Short, simple and makes sense.
    – John V
    Jun 23, 2015 at 6:12
  • Good answer. I suggest however the following definitions based on IREB Glossary: Functional requirement: A requirement concerning a result of behavior that shall be provided by a function of a system (or of a component or service) -- Not just "are what software should do" (Ref: ireb.org)
    – K J
    May 7, 2020 at 9:39
2

You can think of a product as someone's attempt to satisfy a list of requirements. Ideally, those requirements are someone's attempt to solve an actual problem.

From a myopic point of view, QA is about verifying that a product satisfies requirements. But the definition quoted in the question points to a deeper definition of quality: whether a product actually solves the original problem.

2
  • Yes I know that but the main issue here is why some authors, including peer reviewed papers, differ on what is functional and non-functional. Why some consider "functional suitability" functional and some do not? It is called "Suitablity" but on the other hand, it deals with "functional completeness, correctness etc.". Some non-functional view I saw simply verified no.of functions against the requirements, not their correct implementation.
    – John V
    Jun 17, 2015 at 5:47
  • 2
    Go ask the authors. These concepts are not laws of physics; they're just conventions established by an ISO committee. A more interesting question might be how all this applies to you and your job.
    – user246
    Jun 17, 2015 at 12:31
2

Functional Suitability

This characteristic represents the degree to which a product or system provides functions that meet stated and implied needs when used under specified conditions. This characteristic is composed of the following sub characteristics:

Functional completeness. Degree to which the set of functions covers all the specified tasks and user objectives. Functional correctness. Degree to which a product or system provides the correct results with the needed degree of precision. Functional appropriateness. Degree to which the functions facilitate the accomplishment of specified tasks and objectives.

Non-functional Characteristic

In addition to the obvious features and functions that you will provide in your system, there are other requirements that don't actually DO anything, but are important characteristics nevertheless. These are called "non-functional requirements" or sometimes "Quality Attributes."

Here are some examples of non-functional requirements:

Performance requirements Requirements about resources required, response time, transaction rates, throughput, benchmark specifications or anything else having to do with performance.

Operating constraints List any run-time constraints. This could include system resources, people, needed software, ...

Platform constraints Discuss the target platform. Be as specific or general as the user requires. If the user doesn't care, there are still platform constraints.

Accuracy and Precision Requirements about the accuracy and precision of the data. (Do you know the difference?) Beware of 100% requirements; they often cost too much.

Modifiability Requirements about the effort required to make changes in the software. Often, the measurement is personnel effort (person- months).

Portability The effort required to move the software to a different target platform. The measurement is most commonly person-months or % of modules that need changing.

Reliability Requirements about how often the software fails. The measurement is often expressed in MTBF (mean time between failures). The definition of a failure must be clear. Also, don't confuse reliability with availability which is quite a different kind of requirement. Be sure to specify the consequences of software failure, how to protect from failure, a strategy for error detection, and a strategy for correction.

Security One or more requirements about protection of your system and its data. The measurement can be expressed in a variety of ways (effort, skill level, time, ...) to break into the system. Do not discuss solutions (e.g. passwords) in a requirements document.

Usability Requirements about how difficult it will be to learn and operate the system. The requirements are often expressed in learning time or similar metrics.

2
  • 1
    But you miss the point - Functional suitability is - according to ISO25010 - consider NON-FUNCTIONAL, which is the point of this post..it is one of the quality attribute. This is confirmed by other non-functional evaluation frameworks like SNAP and various book, the two of which I quoted.
    – John V
    Jun 22, 2015 at 15:50
  • See the OP, I included a screenshot of a book clearly showing how Functional suitability is classified as NFR.
    – John V
    Jun 22, 2015 at 16:06
0

To take this a little further, regarding the calculation of FS, this paper provides an idea: Functional Suitability Measurement using Goal-Oriented Approach based on ISO/IEC 25010 for Academics Information System

Your Answer

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

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