Non Functional Is Nonsense

The discussion below (up to Aug 98 when I came across it in Nov 99) all looks pretty helpful but I do find the choice of the name of the page and the inital paragraphs pretty confusing.

TomGilb was the first methodologist (I believe) to suggest in the 80s the use of the term 'functional requirement' for an atomic requirement (either there or not - such as "system can produce aged debtor report"). All other kinds of requirement he says we should attempt to quantify or we simply don't know what we're talking about (and certainly nobody else will). QualityAttributes is normally what he and others have called these slippery creatures - see GilbMeasurabilityPrinciple and ImpactModelling.

Given these definitions, which at least have the virtue of clarity, why is non functional nonsense? Is it the old confusion with AcceptanceTest (which verifies a UserStory in XP, and which may therefore test a non-functional requirement in Gilb's terms)? -- RichardDrake

One of the main problems with "Non-Functional" is simply that you cannot define things precisely in terms of what they are not. Don't tell me what your requirements are NOT (non-functional), tell me what they ARE e.g. specific functions (functional) that are either there or not, qualities with specifications of how they will be verified including a scale of measure and the desired point on the scale required. -- StuartWoodward

We often use the term Non-functional to describe things like performance, modifiability, usability. And we tend to talk about functional when we mean "meets an explicit business (usually end user) requirement".

Even if we discount the usual hotair issued by mathematics fans about the words function, functionality, etc and take the word functional at is everyday meaning - we still have problems.

As the debate in MakeItFastBreaksMakeItRight shows, performance is one of those things which often is somewhere near the front of the mind of the person making requirements. Or even worse, it is just assumed.

The real problem with "non-functional" requirements is that they tend to get left out of much of the design process and this can be a real disaster.

I think we need to ensure that we consider all of the possible required QualityAttributes of a system up front.

One of the Microsoft books that I have (it may be a SteveMcConnell book) discusses coding priorities. The idea is that for particular bits of code, speed is more important than memory usage, or safety is more important than speed, etc. -- MichaelFeathers

I've never seen a "bit of code" profit from significant consideration of speed or memory usage before function. And I've never seen a big program that couldn't be optimized if it needed it. And, most tellingly, I've never done a performance measurement that didn't turn up a surprise in terms of where the problem really was. If I gave advice, it would be to code for functionality, refactor for clarity, (optionally) optimize for performance. Make it work, make it right, make it fast. -- RonJeffries

I think it depends upon scope. If you know exactly how something is supposed to work and the "bit" is small enough, and you do not mind sacrificing flexibility, you can think about memory and time tradeoffs before coding and do okay. It's just important to know that you may end up rewriting things if requirements change. But that is okay if the scope is small. Who said "As the speed of development approaches infinity, the value of reuse approaches zero?" Same idea. If you can develop fast enough to unwind optimizations in a narrow domain, thinking about optimization ahead of time can work out. -- MichaelFeathers

In XP, we make a UserStory for any quality attribute. I can't recall ever having a quality attribute that didn't come down to user quality. Examples, anyone? -- RonJeffries

"In XP, we make a UserStory for any quality attribute." What does such a UserStory look like? Could you provide an example? -- KielHodges

Quality in the form of correctness comes from our AcceptanceTests, of course. We say (to the customers), "You only have to test the things that you want to work".

Performance stories might say "The system must be able to pay 12,000 biweekly employees in no more than twelve hours. Six would be preferable." My point, if I had one, was that most quality attributes over which one would make a decision come down to some kind of user requirement. -- rj

OK, today I contradict myself. The XP rules clearly relate to some kind of "quality" issues that are not directly reflected in stories. We do PairProgramming, among other reasons, because it improves code quality. We RefactorMercilessly, which improves code quality, which lets us go faster.

Most of the development rules go to the ability to go fast and to go forever ... but they do it by producing something that one might call internal quality. See MartinFowler's remarks on InternalAndExternalQuality. -- RonJeffries

Internal quality allows us to go fast, which assists us in meeting our deadlines. On time delivery is not "some kind of user requirement"? -- BillJamison

Of course it is. I don't understand the question. -- rj

I'm not sure I understand why you say you have contradicted yourself. The internal quality brought about by the development rules directly supports external quality attributes (in this particular case, on-time delivery). And there would seem to be a user story in the form of a deadline. Or am I way off in the long grass? -- BillJamison

Is it not so much "non-functional" as "emergent"? Performance, modifiability, usability are properties that emerge from the total system rather than being coded in one place. This is one reason why they are tricky to deal with; they have to be held in mind all the time, which is bad.

(Speed looks different because there is often a fairly small piece of code that effects the total speed most; on the other hand, we often don't know which piece of code that is until after we've finished the explicit features, so it's still emergent.) -- DaveHarris

Something else struck me the other day when thinking about this. Space and Time are like money. They are cost items. You pay in time and space to get functionality. -- MichaelFeathers

Yes, and so is the time and effort needed to deliver a particular story, so include these as Qualities you may have to worry about in addition to the Purpose for writing the code. -- DickBotting

OK, so how do you handle these? Normally, you assign tasks to implement a specific story. How do you estimate and assign the above 'performance story'? What about one which says, "The main functions of the system must be usable by a novice with no training, but experienced users must be able to take advantage of shortcuts to improve their system utilization?" Or "All edit screens must support at least 50 levels of 'undo'"? These kinds of requirements apply to many, many stories in the system. I don't see how you can task them independently. -- RussellGold

Surely each shortcut is a story? Surely there's only one undo stack, and surely the undo "language" evolves as new things come along needing undone? Surely, this program, like most others will be optimizable by profiling and removing hot spots? Aren't these all independent tasks? -- RonJeffries

Maybe I have misunderstood how you are supposed to use stories, and who writes them. I have been assuming that they are written by people with the business knowledge, not the technical knowledge, and that the expertise in how to design a good user interface and architect a system are found in the development team - which works from, but does not write the stories. With these assumptions, I would not expect the customer to design an optimal GUI, or specify how undo stacks are built and used, any more than I expect a user story to establish coding standards. Are my assumptions incorrect? Is the team made up only of coders and there is a separate team of GUI designers, reuse experts, analysts and architects which actually turns customer-stated requirements into user stories? -- RussellGold

I'm not sure I believe in inserting a particular quality into existing code as a particular part of a project. I experience these as guidelines to discovering a "good" solution. Typically a flash of insight: "I don't care how fast this runs, as long as it does it before Xmas." -- DickBotting

It is much like dividing all requirements into two categories, those we describe as functional, and those we do not describe as functional. The first category we describe, the second category being fuzzy, including things not yet clear, or belonging to future functionals, we decline in including. -- DonaldNoyes