If you don't know what FURPS+ is, or at least requirement modeling then this discussion might be a little above you. Most of my references in this post will come from Craig Larman's book 'Applying UML and Patterns' which by the way is an excellent book and should be in your library along with GoF's Design Patterns and several others mentioned on other post throughout the forum.
For review many companies out there only have two types of requirements - Functional and Non-Functional. I don't like that black and white/broad generalization labeling; I prefer the FURPS+ model which stands for the following requirements types:
Functional
Usability
Reliability
Performance
Supportability
The '+' stands for everything else: Interface, Implementation, Operations, Packaging, Legal, etc.
Now arguably several things outside of 'Functional' <i>may</i> be better placed in a SSD (Supplemental Specification Document), but I think that would be dependent upon the requirement. For instance 'Application must be section 508 compliant' - by definition, that's a usability requirement, but that's a system wide requirement and should be applied as a part of the SSD, not as a part of the requirements document.
What I've come to ask opinion about is in particular a case of Functional Requirement or Usability Requirement?
First let me start by saying that I disagree that Usability Requirements are things like 'Application must be section 508 compliant', or 'Text must be visible up to 1 meter away' - these are things of accessibility - in your Windows control panel you have Accessibilty settings, not Usability settings.
To me Usability are things that make an application more usable - or user friendly; things that in themseleves do not make the application - the application would function within the specifications of the AVS (Application Vision Statement) without them, but they provide a better user experiance.
To support my arguement about usability this is dictionary.com definition of usability
<programming> The effectiveness, efficiency, and satisfaction
with which users can achieve tasks in a particular environment
of a product. High usability means a system is: easy to learn
and remember; efficient, visually pleasing and fun to use; and
quick to recover from errors.
Having said that the application I'm working on has a new business requirement - it's not quite a find feature, but it's similiar; I can't really discuss openly. We are having a lot of discussion on whether this is a functional or usability requirement...and before you knee-jerk post a reply, finish reading.
I know that traditionally a functional requirement is any system feature, while true, I believe a functional requirement should be something that is required by the system to perform the FUNCTIONS for which it was developed (are critical to the system performing as was envisioned in the AVS), not just any old feature - that is too broad of a statement to me.
Having said that now I ask you, how can <i>the system</i> finding something add functionallity to the system? The user of the system is more than capable of finding it themselves - they know where too look - it just does the work for them (consider it to how smart navigation scrolls the window to wherever you desire it to be). The overall vision or purpose of this application will not fail because of this 'search' feature not being implemented; in fact it's existed for quite sometime without it. What it does do is provide a better user experiance and make the system more user friendly, which increases it's USABILITY...it does not increase it's FUNCTIONALITY...the core system still functions the same.
Now I know I'm stretching the meaning of 'Functionallity' and 'Usability' in context to how it's general defined as in FURPS+ documents, I know this, and I know there are 'by the book' people out there who will feverantly disagree with my use of Usability Requirements and downgrading of 'Functionality' Requirements, but I really think what is defined in FURPS+ documents as usability falls under Accessibility and that functionality is too broad.
So now let's move on to the use case. Most people will say a use case is a positive sign that something is a functional requirement, not a usability requirement. Not so; Larman plainly states that while a use case usually is tied to functional requirements, they can also be used for other types (of requirements), especially when those other types strongly relate back to a functional requirement - which this one does for our application, and I think we would all agree that a Find feature is indeed something deserving of a use case, because if the feature is complex, or has the cability of becoming complex, then there needs to be a main success scenerio and execptional (alternative) flows, and even though it may not. There are also who will say it shouldn't have a use case at all because it doesn't meet EBP (Elementary Business Process) guidelines (it doesn't help the company make money), however it closely realtes to a use case that does meet EBP guidelines, which is an acceptable violation of the EBP guidelines in order to write a use case.
I wish I could get in touch with Larman directly to settle the debate, but I think he's unreachable
, but we have a lot of good people here on this forum and I'm interested in their experiances and their thoughts on this particular matter.
For review many companies out there only have two types of requirements - Functional and Non-Functional. I don't like that black and white/broad generalization labeling; I prefer the FURPS+ model which stands for the following requirements types:
Functional
Usability
Reliability
Performance
Supportability
The '+' stands for everything else: Interface, Implementation, Operations, Packaging, Legal, etc.
Now arguably several things outside of 'Functional' <i>may</i> be better placed in a SSD (Supplemental Specification Document), but I think that would be dependent upon the requirement. For instance 'Application must be section 508 compliant' - by definition, that's a usability requirement, but that's a system wide requirement and should be applied as a part of the SSD, not as a part of the requirements document.
What I've come to ask opinion about is in particular a case of Functional Requirement or Usability Requirement?
First let me start by saying that I disagree that Usability Requirements are things like 'Application must be section 508 compliant', or 'Text must be visible up to 1 meter away' - these are things of accessibility - in your Windows control panel you have Accessibilty settings, not Usability settings.
To me Usability are things that make an application more usable - or user friendly; things that in themseleves do not make the application - the application would function within the specifications of the AVS (Application Vision Statement) without them, but they provide a better user experiance.
To support my arguement about usability this is dictionary.com definition of usability
<programming> The effectiveness, efficiency, and satisfaction
with which users can achieve tasks in a particular environment
of a product. High usability means a system is: easy to learn
and remember; efficient, visually pleasing and fun to use; and
quick to recover from errors.
Having said that the application I'm working on has a new business requirement - it's not quite a find feature, but it's similiar; I can't really discuss openly. We are having a lot of discussion on whether this is a functional or usability requirement...and before you knee-jerk post a reply, finish reading.
I know that traditionally a functional requirement is any system feature, while true, I believe a functional requirement should be something that is required by the system to perform the FUNCTIONS for which it was developed (are critical to the system performing as was envisioned in the AVS), not just any old feature - that is too broad of a statement to me.
Having said that now I ask you, how can <i>the system</i> finding something add functionallity to the system? The user of the system is more than capable of finding it themselves - they know where too look - it just does the work for them (consider it to how smart navigation scrolls the window to wherever you desire it to be). The overall vision or purpose of this application will not fail because of this 'search' feature not being implemented; in fact it's existed for quite sometime without it. What it does do is provide a better user experiance and make the system more user friendly, which increases it's USABILITY...it does not increase it's FUNCTIONALITY...the core system still functions the same.
Now I know I'm stretching the meaning of 'Functionallity' and 'Usability' in context to how it's general defined as in FURPS+ documents, I know this, and I know there are 'by the book' people out there who will feverantly disagree with my use of Usability Requirements and downgrading of 'Functionality' Requirements, but I really think what is defined in FURPS+ documents as usability falls under Accessibility and that functionality is too broad.
So now let's move on to the use case. Most people will say a use case is a positive sign that something is a functional requirement, not a usability requirement. Not so; Larman plainly states that while a use case usually is tied to functional requirements, they can also be used for other types (of requirements), especially when those other types strongly relate back to a functional requirement - which this one does for our application, and I think we would all agree that a Find feature is indeed something deserving of a use case, because if the feature is complex, or has the cability of becoming complex, then there needs to be a main success scenerio and execptional (alternative) flows, and even though it may not. There are also who will say it shouldn't have a use case at all because it doesn't meet EBP (Elementary Business Process) guidelines (it doesn't help the company make money), however it closely realtes to a use case that does meet EBP guidelines, which is an acceptable violation of the EBP guidelines in order to write a use case.
I wish I could get in touch with Larman directly to settle the debate, but I think he's unreachable
, but we have a lot of good people here on this forum and I'm interested in their experiances and their thoughts on this particular matter.
Last edited: