From: Andrew Gabb (agabb@tpgi.com.au)
Date: Tue Dec 02 2003 - 19:43:30 EST
Many of us are confused with regard to RE nomenclature, Max, because
so many people, including many of those who write RE books and
articles, do not use the same nomenclature. There is no *right*
meanings of these words.
I have no real problem with the definitions of feature below, noting that usually a feature relates to a *system* rather than the users' requirements. Def 3 below sounds like a requirement, and to some extent it is, but the requirement probably comes as an output of system design, and is not necessarily directly derived from a user need.
Look at it this way. The user requirements state what a system should do for the users. After the system has been developed, it can be said to have a set of 'features' (as we read about in the glossy brochure), which is what it can do (in the case of *functional* features). In most cases we can trace the features back to the users' requirements in some way. Note that a single user requirement (eg being able to archive data) may be met by a number of features or vice versa.
I'm not going to discuss nonfunctional requirements because the term
has different meanings for different authors. If you like, think of it as all requirements which *aren't* functional in nature.
Note also that despite defs 1, 2, 3 below ('service' is a form of function), features are *not* necessarily functional in nature. I'll leave it to you and others to find examples.
> -- "This application is very robust. It never loses data while
system is
> crash."
>
> Would you please tell me whether this is a feature or in more
> general points of view.
This is a feature which is difficult (or impossible) to prove or test. Basically it's marketing hype, and the second part is probably not true. But the vendors would consider it to be a feature. This feature would probably trace to the the users' requirements for reliability and integrity. However some users might express this as a requirement too, ie "The application shall be very robust, and never lose data as a result of a system crash."
Hope this helps a little.
Andrew
zhangq@enel.ucalgary.ca wrote:
> I am comfused by the relationship of Feature, fuctional requirements and
> nonfunctional requirements. Here are the definitions of feature
>
> =============================== CITE =================================
> Feature is :
>
> 1. “a coherent and identifiable bundle of system functionality that helps
> characterize the system from the user perspective” -- C. Reid Turner e.tc,
> A conceptual basis for feature engineering, The Journal of Systems and
> Software 49 (1999)
>
> 2. “a prominent or distinctive user-visible aspect, quality, or
> characteristic of a software system or systems” -- Kang, Kyo C. etc.
> Feature-Oriented Domain Analysis Feasibility Study (CMU/SEI-90-TR-21,
> ADA235785), CMU-SEI, 1990.
>
> 3. “an externally desired service by the system that may require a
> sequence of inputs to effect the desired result” -- Institute of
> Electrical and Electronics Engineers. IEEE Recommended Practice for
> Software Requiements Specifications (IEEE Std 830-1998), New York, N.Y.:
> Institute of Electrical and Electronics Engineers, 1998
>
> 4. “a service that the system provides to fulfill one or more stakeholder
> needs” -- Dean Leffingwell, Managing Software Requirements: A Unified
> Approach, AT&T, 2000
>
> =========================== Cite Finish =============================
>
> All this definitions imply that feature only describe the functionality of
> a system which I suppose belongs to functional requirements. But I also
> think the statement below is useful and meaningful to the users
>
> -- "This application is very robust. It never loses data while system is
> crash."
>
> Would you please tell me whether this is a feature or in more general
> points of view.
>
> ????????????????? Question???????????????????????????
>
> Whether the statements describe the nonfunctional aspects of the system
> could be a feature.
>
> ?????????????????????????????????????????????????????
>
>
>
> Thank you and best regards
> Max
>
> -------------------------------------------------------------------------------
> 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.
>
>
>
-- 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