From: Andrew Gabb (agabb@tpgi.com.au)
Date: Sat Dec 06 2003 - 15:39:48 EST
Monterey, Laura L CONT wrote:
> I had come to understand functional requirements as something
> that could be tested, and non-functional requirements as more
> subjective, which would encompass such characteristics as
> usability, look-and-feel, speed, reliability, etc. I'm told by
> one of our programmers that all requirements are testable, but
> that in the case of non-functional req's, you can test in several
> ways, one of which is to simply demonstrate the feature/system to
> the customer and get their acceptance. "Is that fast enough?" If
> they reply, "Yes, that's fine," you're done.
Firstly, 'fast enough' is more of a performance requirement than a functional requirement. Secondly, testability is not a good criterion for 'functional' - weight and other physical requirements are easily tested, but not usually regarded as functional either. Functional reqs usually state what the system should *do*, nonfunctional reqs address all the other stuff - according to definition - which can include how well it does it, where it can be used, how it should be made, etc., etc. Performance reqs are sometimes included in NFRs, sometimes not.
[ Damn! I didn't want to get into a fruitless discussion about categories. Although it's interesting to some of us from a philosophical point of view, it usually doesn't advance us very far in the practice. For more on this subject, please see the paper 'Requirements Categorization' at http://www1.tpgi.com.au/users/agabb/ ]
'Non-functional' requirements are often given a bad name because they include (inter alia) what I call quality requirements (or quality factors, or the 'ilities'). These types of requirements are often (a) difficult to establish, (b) difficult to define, (c) difficult to test, and often omitted, possibly because of some or all of the above.
> With respect to a user requiring a "robust system" that "loses no
> data when the system crashes," if I received such a requirement
> from a user, I would initially consider this a non-functional
> requirement, for "robust" is "not testable." push for more
> clarification before passing it on to the programmers. My
> programmers will read that req and immediately want to know how
> much data loss constitutes "none" and what "never" is, and the
> quantified answer would guide how they implement the software
> solution. (In our case here, with one of our main software
> products, the solution might be separate redundant systems
> running the same data.)
Robustness, integrity, reliability, maintainability are still NFRs, I'm afraid.
> So, it seems to me that by defining the boundaries (use numbers,
> set limits), the requirements analyst works the issue to the
> point where a non-functional requirement (marketing hype) turns
> into a functional requirement, and the final product -- a solid,
> unambiguous, quantified, testable requirement -- is what gets
> included in the SRS. Am I right? I'm just learning RE, so please
> tell me if I am incorrect.
Sorry, Laura, but you are incorrect. The SRS will include functional and other reqs.
Andrew
-- Andrew Gabb email: agabb@tpgi.com.au Adelaide, South Australia phone: +61 8 8342-1021, fax: +61 8 8269-3280 ----- ------------------------------------------------------------------------------- To send a message to this mailing list send it to re-online@it.uts.edu.au. To unsubscribe from this mailing list, email majordomo@it.uts.edu.au with the message `unsubscribe re-online' in the BODY of the mail.
This archive was generated by hypermail 2.1.6 : Mon Dec 08 2003 - 09:00:13 EST