Further requirements

5 Further requirements

In this section, we list some further requirements, which are not so much functional specification, but rather general requirements or also

5.1 Adaptability, parameterization, and options and defaults

Since the intention is that the tool is not usable for just one conference, but for many, certain things must be adaptable per conference. We call one conference an instance of a conference. Each instance of a conference is characterized by number of basic data, which must be provided in the configuration phase. At later phases, additional information (papers, reviewers etc.) are provided.

All in all, the whole thing is required to offer quite an amount of things the users can adapt. Part of these adaptability is described and discussed here and is part of the standard scenario of reviewing. There are much more things imaginable, for instance: besides the program chair, someone wishes to have a financial chair and a local organizer listed on the web-page, someone things the background color of the generated web-pages should be green, and weirder things ...).

To make the tool useful in practice, a good balance between hard-coded decisions and adaptable variations will be crucial. A couple of things should be kept in mind here:

Modesty:: don't get carried away! The fact that one can easily include another battery of check-buttons to adapt this and than and other does not mean the user will like this.
Empty options/switching off features: take care that options or features can also be switched off. If the user don't want a requistration phase in the, he may completely switch it off, for instance. This is related also to the point ``modesty''.

A useful technique in this context is also the choice of good defaults. There are always users, who want to fiddle with everything and they should be given freedom to a certain extent. There are also others, who don't bother, provided the default setting are usable. Therefore, making good defaults enhance and keep the number of necessary variation points beyond that small, enhances the usability quite a lot.

5.2 Webserver & download version

The software should be usable also as some web server managing more than one conference. The alternative is, that one user (in the role of the admin) downloads the source code, install it, adapts it for his or her needs and uses it for organization. The consequence of the ``webserver'' requirement is simple: more than one conference must be held in the data base at the same time, without any information flow (other than the information concerning the general public and other than by the administrator) between the two conferences.⁸

5.3 Changeability, non-standard scenarios

A general remark which applies to almost everything described above. namely: we concentrated on the smooth, standard evolution of the event.

In general, the tool must be prepared that this is not the case, which basically means, that choices once made must be changeable. Basically, all data in the data base must be ``manually'' adapted if need be, the problem is that is must not unnecessarily interfere with the process. Possible non-default scenarios are:

a reviewer does not review, and is removed.
an additional review about a paper is delivered, or a paper is re-assigned.
the chair (or the committee) decides that one particular paper is rejected/accepted despite the fact that perhaps the numerical valuation or the status of the discussion would indicate otherwise. The valuation of the rest of the papers must not be ``confused'' by that.