Functionality requirement - part I

The system should specify the grammatical errors made by the writer in such a way that the end-user is able to correct them.

This requirement can be restated as a property of a relation among the error taxonomy, the writer model, the end-user model and the advice model that may or may not hold for a particular system under test. To illustrate this rather complicated idea, we will consider a particular error -- determiner-noun number disagreement in English noun phrases (abbreviated as EDetNNum) -- and show how the other parts of the model relate to the error taxonomy. We examine each major element of this requirement in turn.

The grammatical errors made by the writer

For each class of writers, an EDetNNum error has a certain frequency or significance level, derived from empirical analysis of texts. This is one way of instantiating the various sources of errors associated with particular writer classes in the writer model. So we can think of some set of instantiated writer models (e.g. one for L1 English writers, one for L2 English-L1 French, one for L2 English-L1 Danish...) with their error sources expressed in terms of the classes in the error taxonomy:

WriterClass1:
Language proficiencies: English 10 ...
Error sources: intentional: EDetNNum 1; ANOtherError 1...
               performance: EDetNNum 3; ANOtherError 2...
               medium: EDetNNum 5; ANOtherError 5...
...

WriterClass2:
Language proficiencies: French 10
                        English 5
                        ...
Error sources: intentional: EDetNNum 4; ANOtherError 4...
               performance: EDetNNum 4; ANOtherError 4...
               medium: EDetNNum 5; ANOtherError 5...

These error frequencies can be viewed from the other direction, as contributing significance values to elements of the error taxonomy:

ErrorClassEDetNNum:
Frequencies: WriterClass1 9
             WriterClass2 13
             ...

ErrorClassEModNNum:
Frequencies: WriterClass1 8
             WriterClass2 13
             ...

We can sum up these significances, if they are evenly distributed among the relevant classes, or we can keep them separate if, as in this case, different classes of writers make different numbers of errors. This will be a consideration when we come to choose reportable attributes.

If this significance value is above a certain threshold (this is a property of the relation between writer models and error taxonomy), we can say that EDetNNum is one of the grammatical errors made by the writer, and methods should be devised for testing system performance on that error.

The specification made by the system

In terms of our task model, the system specifying the grammatical errors...in some way is a relation between systems, errors and advice. For a particular system, we could have:

System1:
Advice: ErrorEDetNNum: Number of suggestions: 1
                       diagnosis support: name of error type, 
                                          examples
                       suggestions: explicit replacement
        ANOtherError: ...

System2:
Advice: ErrorEDetNNum: Number of suggestions: 1
                       diagnosis support: name of error type, 
                                          examples
                       suggestions: general instructions

This is the main relation that is to be determined by testing. We test a system and fill in the advice given for types of errors, according to some method. This will be dealt with in the section Methods on methods.

The correction of errors by the end-user

The element In such a way that the end-user can correct the error is a relation between errors and the advice an end-user needs to correct them. Thus, it provides a criterion or threshold value against which to test the information collected under the previous heading (the specification made by the system). We might have, for a number of classes of end-user:

End-user1:
ErrorEDetNNum: Advice: Number of suggestions: ANY
                       diagnosis support: name of error type, 
                                          examples
                       suggestions: drawing attention

End-user2:
ErrorEDetNNum: Advice: Number of suggestions: 1
                       diagnosis support: name of error type, 
                                          examples
                       suggestions: explicit replacement

With this information, we can work out that both System1 and System2 would pass the test for EDetNNum as far as End-user1 is concerned, but only System1 would do so for End-user2, because the latter requires explicit replacement suggestions to make the change correctly.