Software Engineering Asked on January 2, 2022
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.
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.
Answered by Thomas Owens on January 2, 2022
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.
Answered by Robert Harvey on January 2, 2022
Get help from others!
Recent Questions
Recent Answers
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP