Jump to content

Talk:Non-functional requirement

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Recent-ish Paragraph Addition

[edit]

It strikes me that it might be a touch PoV-ish for us to analyze the comparative value of one term or another term for what is accused of being the same thing (the whole "Quality of Service" vs. "Non-Functional Requirements" paragraph), particularly without the benefit of obvious sourcing. At a minimum, the paragraph has a dramatically unencyclopedic tone (the links are also pointing to a topic of only tertiary relation). I'm going to go in and salvage what there is to salvage and remove the rest.Cool moe dee 345 12:58, 24 September 2007 (UTC)[reply]

Terminology

[edit]

I feel incomfortable with this article in a very general sense. According to ISO/IEC 9162 there are various aspects of quality to be considered for a quality model. The foremost is certainly the target group affected by a certain quality level. A user judges certain aspects differently from a customer or a developer. If we look at the most comprehensive quality model in the ISO standard (for an "internal" point of view) we see that functionality, effectivity, usability, reliability, maintainability, and portability are treated on the same level. They all account to quality. Neither is there an indication that distinguishing functional from non-functional aspects is helpful, nor is functionality excluded from being a quality attribute. The WP article deliberately draws a border between quality attributes and functionality which does not exist for a careful requirements engineer.

I must admit that the terminology in RE literature is very confusing. The area is difficult to discuss because what is a non-functional requirement for somebody is a functional one for somebody else. High availability is typically seen as a non-functional attribute by requirements engineers, product managers etc. dealing with application functionality, simply because they expect HA being a property of the underlying platform or runtime environment. But for someone designing such a platform HA has aspects of functional requirements because it is associated with particular functions for monitoring, fail-over, recovery etc.

This article could be significantly improved by adding a critical analysis of the terms it uses. Still I do not see the necessity to keep it. There are no articles about "non-effectivity", "non-"usability", "non-maintainability" quality attributes. Why is there an article about "non-functional" requirements? Personally I like the differentiation between functionality and "quality of service" because it makes clear what is meant. "Quality attribute" does not tell whether it is an attribute that describes a certain quality aspect, or an attribute that a product must have in order to exhibit a certain quality. Or, in OO speak, is it a quality.attribute or a product.quality_attribute?

-- Joachim Schnitter 2008-07-10 14:23 CEST

Response to last

[edit]

Distinguishing between functional and nonfunctional may not be useful to your particular task but it is essential when performing functional decomposition.

Items in the list that can be stated as an action/activity (for example failure management => manage failure) are probably functional requirement categories. —Preceding unsigned comment added by 206.190.75.9 (talk) 21:08, 25 April 2011 (UTC)[reply]

Further response

[edit]

"Distinguishing between functional and nonfunctional ... is essential when performing functional decomposition." This has the ring of tautology, but I'm unclear from the article's example how this works. Isn't timeliness of the data a functional requirement? Imagine the conversation between analyst and user ...

"What customer data do you want?"

"Identifiers, including preferred name and title; social demographics; contact modes and addresses; history of enquiries, orders, sales, payments and correspondence; and CSR (Customer Service Representative)'s file notes."

"When do you want it?"

"As soon as it changes!"

The requirement for real-time data is a fundamental architectural concern for the whole system. It thus becomes a critical functional requirement to deliver all changes to customer data effectively in real-time. One chooses whatever metric one needs, but always embeds that in an operational definition; for example:

  1. Initiate update of the distributed database, including all local copies, within 100 ms of transaction completion;
  2. Monitor time to update and raise exception flag if transaction still incomplete after 600 ms;
  3. All online enquiries must reflect time of last transaction initiation, time of last transaction completion and post user warning flag if there is a pending update transaction."

So what's non-functional about the timeliness requirement? yoyo (talk) 08:30, 17 July 2012 (UTC)[reply]

It's viewed as not a function because it's not stating a function viewed in terms of a specific input, output or process. Which "transaction" is unspecific for example, seems intended to apply to all the individual functions of the system. You could try making these part of individual functions, but grouping these and any other timing requirements into the non-functional has practical use of keeping them together and not unnecessarily expand your requirements list and functional testing by replicating it into each function that will apply. Plus two other things:

  • First thing is these are also going to depend on things not within the system -- the storage response time is going to make hardware implications, and "distributed database" will make communications approach and telecomm quality of service contract implications, and recording the time will drag in external time reference and a new set of system-wide functions to synchronize to that clock and audit checking time records.
  • Second thing is that in theory we're talking part of a wider development process and lifecycle intents and these are seem fragments of something internal. To 'initiate' is not something apparent at a user interface or stating a final effect so it seems part of something from a higher level earlier statement that has been decomposed (broken into parts) in this way. That means hopefully that decomposition emerged from some reasoned Systems engineering analysis of tradeoffs recorded with organized Requirements management traceability. When developers get to building a particular part of the system, they have all the requirements for that functional part organized so they can proceed with some confidence and speed. When testers get to checking o a part they have the same requirements, and when integration happens to a larger construct the testers know which overall properties then come in for test. (If instead you've got just the common generic phrase stuck in or copied from elsewhere just to hurry past requirements writing then it's a waste of space and writing time and the developers / testers will learn to ignore it and maybe users will be looking at an hourglass.)

Markbassett (talk) 13:18, 28 August 2013 (UTC)[reply]

Software security is both functional and quality

[edit]

Software security is both functional and quality

For software

  • Functional: "you're not allowed to do that" messages; the set of menu items displayed to a user; the subset of data displayed to a user; user security changes system behavior
  • Quality: resilience to SQL-embedding; code checks that security is in place; inter-layer security; component and interface design

Ref: http://www.opensecurityarchitecture.org/cms/definitions/it_security_requirements — Preceding unsigned comment added by 115.186.240.40 (talk) 00:37, 3 April 2012 (UTC)[reply]

Non-functional as it's testing the security of the system not a single test of whether a user is or is not permitted to access something or not. --Walter Görlitz (talk) 01:10, 3 April 2012 (UTC)[reply]
So 'the set of menu items displayed to a user' is a function of the 'menu-display component', and 'the subset of data displayed to a user' is a function of the 'data access filter component'. (?) 115.186.240.40 (talk) 05:51, 3 April 2012 (UTC)[reply]

Functional vs quality is an artifact of simplifying the analysis process

[edit]

1. Business analysts tend to sweep quality features under the carpet during the analysis process because the analysts' main added value is helping the business think about how they do business and what business they are doing; this is more interesting for the business, more interesting for the business analyst, and allows the business analyst to demonstrate their insight and gain repeat business.

2. Quality features can and are usually assumed by the business and the business analyst because they are common to other similar systems/processes/products and fall into the 'common knowledge' bucket. But, in the case of systems/processes/products being marketed as 'high-quality' the quality features will be thought about and discussed (e.g. Volvo's car-door-hinge-strength, BMW's car-door-close-thunk, the iPad's Retina display resolution).

3. Business users and business analysts only have so much time and effort to spend on analysis.

4. 'common knowledge' features are assumed to be dealt with by the implementation team


1 + 2 + 3 + 4 --> the importance of quality features vs. business function features in the analysis process depends on how much profits/marketing will benefit from each feature --> the likelihood that the feature will be in the business requirement or quality feature bucket --> the likelihood that the feature will take more effort than allowed for in the project plan — Preceding unsigned comment added by 115.186.240.40 (talkcontribs) 01:03, 3 April 2012 (UTC)[reply]

That has been noted before. I was just at a session where the presenter stated that there is no such thing as a non-functional requirement since it all comes back to functionality. However, we're not creating definitions here simply reflecting their use in the industry. --Walter Görlitz (talk) 01:14, 3 April 2012 (UTC)[reply]
But the article could and should make it clear that the functional/non-functional divide is _to an extent_ a sliding scale based on the emphasis of the industry, business, and project; and on the terminology of the methodologies or academic areas being used. — Preceding unsigned comment added by 115.186.240.40 (talk) 05:15, 3 April 2012 (UTC)[reply]
It's not though. It's clearly defined for the majority of those in the industry and there are really only a few outliers who have radically divergent definitions. However, if you are discussing non-functional requirements with them, they would understand what you mean even if they don't agree with the definition. To reference that anecdotal experience would be nearly impossible.
May I suggest that you draft what you'd like to add and some of the other editors and I can look it over and make suggestions? It would prevent an edit war over the content. --Walter Görlitz (talk) 05:24, 3 April 2012 (UTC)[reply]
OK 115.186.240.40 (talk) 05:52, 3 April 2012 (UTC)[reply]
Leaving aside the aspersions cast by the first writer in this section on the professionalism of business analysts for the moment (---Grrr!---), I'd like to respond to Walter Görlitz's report and comments. First, I'd agree with the presenter who said there are no non-functional requirements; it's an oxymoron. Second, I'd have to disagree with Walter, since as a practitioner, and even after reading this article, I have no clear idea what you mean by the term "non-functional"; so, whilst I might understand your specific concerns, and be able to hold a meaningful and useful conversation with you about them, I'd still reject their classification as non-functional.
Very often in business, it's philosophically simpler to take a purely operational view of systems; and according to that worldview, a system IS what it DOES.
It was the very peculiarity of the notion of a non-functional requirement (sic) that aroused my curiosity and brought me to this article.
So I have only one request for editors: please do ensure that if, as Walter wrote:
It's clearly defined for the majority of those in the industry and there are really only a few outliers who have radically divergent definitions.
that clear definition appears prominently on the page, and that those radically divergent definitions are also noted. With citations for all, if possible. That way, an antediluvian practitioner like myself might begin to make sense of the apparent waffle presently in the article. yoyo (talk) 08:04, 17 July 2012 (UTC)[reply]
Term "non-functinal requirements" *exists* with particular meaning and is used, so if Functional Requirements is getting an article then Non-functional Requirements about should also get an article. It doesn't matter if one presenter disagrees or not that 'qualities' are important. It doesn't matter if I think it's poor label choice. (I'd prefer Quality Requirements or something else to give the group obvious meaning and motivate entries as opposed to something that sounds like 'broken requirements' or 'everything else we don't care about'). This category does not motivate individually, but is the group that really determines things about the system as a whole, such as operating cost and whether it ultimately is usable. There are anecdotal examples of Military systems deployed then found to be 'hangar queens' not dependable enough or supportable in the field. More commonly people are familiar with computer systems subjected to 'featuritis' that have hundreds of functional abilities but are too complex to understand and run too slow for satisfaction. I'll try and put something of this on the page content. Markbassett (talk) 13:55, 27 August 2013 (UTC)[reply]
I think the term "Non-Functional" is a misnomer. I think it gives associations to things like esthetics and other things that strictly are not functions but may contribute to the value of the product. Strictly speaking it should be the set of requirements not related to functions, which obviously is not what is meant here.
In a lot of literature on engineering design, this distinction is not used. I think you have functions, and some of these functions can have requirements with numerical attributes associated to them. This does not make them "non-functional". I think it is important not to clutter a framework with too many concepts, since it makes it harder to use. I think Quality requirement would be better, even though I would regard this as a subset of a function. Petkr (talk) 18:05, 2 May 2022 (UTC)[reply]

Math function, not software function

[edit]

Wikilink I have to Function(mathematical) and blank box maybe needs more talk to explain that the function in functional requirement refers to nature of action, something characterized by what the inputs are and outputs are without looking at detail of implementation, so took the model already existing in mathematics, also known as the black box model. Systems Engineering describe a motor inputs as gas, oil, air, and power; controls pedal; and output torque.on axle. The requirement term is not not necessarily software and not limited to implementing software parts I procedural languages that have a function construct. Software language use of the term also relates to the math model, which predated both things and was widely known. Hope this clears it up somewhat. Markbassett (talk) 06:13, 7 September 2013 (UTC)[reply]

Sure. It doesn't make much more sense now than before the lat August fixes, but perhaps that too will change over time. I see what you were trying to do though. Sorry I reverted so quickly. Walter Görlitz (talk) 07:08, 7 September 2013 (UTC)[reply]
No problem; just trying to be clearer that I was saying it was based on models that existed before the term was used, and that where I attributed it to being based on the mathematical notion of function I had been truly intending to attribute it to mathematics. And I'd have to check the chronology in 1960s books anyway -- both Systems Engineering requirements management and Software development may have independantly gotten their idea from experience with math functions, centuries older and well known, and my SE/RM text says it is from analogy to math functions and black box ... but maybe software got there a decade before systems engineering did. Markbassett (talk) 12:55, 9 September 2013 (UTC)[reply]


Change Title ??? (recreating some of crash-lost edits...sorry, don't remember URLs) In looking at this a bit more with Google's ngram viewer and I think the analogy to Math function should stay since it's the analogy I have as given in Systems Engineering texts as model before that, plus the wikipages that link there convey the concept of input-output abstraction better. But now I think maybe title for this article should change to Quality Requirements. As best I recall, points for this werre:

  • Quality Requirements is synonym about 20 times more common usage, and sequence of increased use also favors it.
  • Functional requirements is longstanding the term,I had cites including 1898 Steam plant and viewpoints of classes of stakeholders, and use in contracting such as school plant for chairs circa 1920s (?) and so forth.
  • Quality requirements has no article in Wikipedia, only side mentions, such as a sidebar within Computer Programming
  • Non-functional requirements phrase exists in VERY limited amounts prior to 1980 -- saw one I think circa 1820, or in biological sense (Hydra cells or agricultural or microscopy journal circa 1890s) and then relationship to Patent and Trademark law from 1950s.
  • Quality I think I saw circa 1971 in government engineering sense and nonfunctional 1981 in US contracting e.g. the federal guidelines, an awkwadly named NonFunctional Configuration Audit NFCA ...
  • Timing of rise is interesting order; functional ramps up from the 1950s then stabilizes; quality in the 1980s and again early 1990s then stabilizes; nonfunctional is almost non-existent prior to 1980 when it climbs steeply still ongoing. By 1999 nonfunctional is in use for both software and systems engineering (Reliability Engineering, etcetera) but the main point seems to me that Quality Requirments is still the more common label.

My guess would be that 'Quality' grew out of 1960s being a topic in multiple venues like the environment (water quality) and advanced technology (NASA and nuclear power), then the 1980s Japan quality manufacturing and popularity of 'Total Quality Management' in U.S. starting circa 1991. My impression is that functional/nonfunctional came into software thru structured programming and into systems engineering by way of patent and contract law... but that the predominant label for this Nonfunctional would be Quality requirements, and the other label just a mention. I'mnow thinking to move the math function analogy over to Functional requirement and then relabel this article Quality equirement. Anyone agree ? Markbassett (talk) 17:35, 10 September 2013 (UTC)[reply]

Non-Functional Requirements are more than Quality Requirements

[edit]

There are at least four types of non-functional requirements: data requirements specifying mandatory data types that are used in multiple requirements, interface requirements that specify mandatory interfaces, quality requirements which specify mandatory levels of quality characteristics and their attributes (see ISO Quality Standards), and various types of constraints (e.g., architecture, design, implementation, integration, and configuration decision to be treated as requirments). The whole section on non-functional requirements needs to be rewritten to clarify these distinctions. See The Method Framework for Engineering System Attributes by Firesmith et al. — Preceding unsigned comment added by 128.237.28.16 (talkcontribs) 13:19, November 18, 2013‎ (UTC)


Emotional Factors such as "Wow."

[edit]

Sorry, but no. That's not a "software requirement" of any kind, and I don't appreciate my edit being reverted. Instead of reverting under the theory that "all non-functional requirements are unmeasurable" (which is patently false, by the way), I think the onus is on you to defend "emotional factors such as 'wow'" as worthy of being in a requirements document.— Preceding unsigned comment added by 100.32.118.122 (talkcontribs) 03:48, 7 May 2016 (UTC)[reply]

You're re referencing a single idea of what non-functional testing is. That idea is described by groups such as ISTQB. Others state that non-functional requirements are all requirements that are not accounted within the range of functional requirements. Kaner refers to them as "parafunctional" and indicates "includes testing attributes of the software that are general to the program rather than tied to any particular function, such as usability, scalability, maintainability, security, speed, localizability, supportability" and calls the area "so vague as to be dysfunctional". See http://testingeducation.org/BBST/foundations/BBSTFoundationsNov2010.pdf p.44 and following. Walter Görlitz (talk) 02:26, 9 May 2016 (UTC)[reply]

Contrast functional/non-functional

[edit]

"a non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours."

It would be better to simplify the difference: functional requirements are about the dynamics of a system (function), and non-functional requirements are about the statics of a system (structure). Please fix this. I don´t because there are way too much rules in wikipedia that I don´t know. Rodolfoap (talk) 12:52, 22 August 2023 (UTC)[reply]