They identify three areas of functionality:
A - functionality wished for by the customer, but not offered by the application
B - Functionality wished for by the customer, and offered by the application
C - Functionality not wished for by the customer, and offered by the application
Visually:
A is functionality that the customer wants, but does not get. This means additional costs. C represents functionality the customer pays for, but does not need. B is the area for which the customer can make a price comparison.
This model, like all models is i.m.h.o. a simplification. Using MoSCoW prioritization, one might group all "Must" and "Should" into the area "wished for", but one might also decide to add the "Could" or even "Would" groups to it. This might give considerable differences. For example, functionality not listed as required by the customer, might turn out to be a secondary wish not listed. Indeed, an inspection of the functionality of some off-the-shelf applications might yield considerable new insights. The nesma counting guidelines correctly mention the problem of counting the information model when counting off-the-shelf applications. One aspect they do not mention is the current trend of feature lists. Feature lists, for those not yet acquainted with them, are lists with short summaries of functionality. They may be formulated as the features found on the box of the product. For example, a word processor feature list might be: * the user can easily enter and correct text * the user can do elementary formatting such as bold, italics and underlined. * the user can use several fonts and character sizes * the user can print the text * the editing is wysiwyg * the user can create mailings by creating a document and connecting it to a variety of sources and so on. Feature descriptions sometimes are too short to make an FPA count. The person performing the FPA count will have to do some inquiries about the nature of the features.
Geen opmerkingen:
Een reactie posten