Dissertaç ˜ao de Mestrado Mestrado em Engenharia Informática Jo ...

3. AN APPLICATION RECONFIGURATION FRAMEWORK 3.1. Architectural Requirements
Non-functional requirements:
Usability: The error messages must clearly identify the source of the error.
5. The user must receive information relative to the grammar fitness with a given config-
uration file.
Description: When the user attempts at parsing a configuration file with a given parser,
he/she must be informed if the parsing was successful or not, as well as the quantity of
file recognized by that parser.
Non-functional requirements:
Usability: The sections of the configuration file that were parsed and those that were not
must be clearly identified.
6. The user must be able to store a functional parser generated by the tool, in order to be
used on later tool runs.
Description: When the user checks a new parser to parse a configuration file entirely,
he/she must be able to store it in a repository so it can be reused.
Non-functional requirements:
Security: The user must be able to see the parsing outcome in order to check if the parser
is indeed operating as intended to.
7. The user must be able to reconvert a configuration file syntax from generic syntax to
the original one.
Description: Given a configuration file in generic syntax, the user must be able to convert
it into its original syntax, keeping its functionality unharmed.
8. File conversion must not eliminate comments.
Description: On the original to generic syntax conversion, the comments should be stored
in order to show up in the final file.
9. The user must be able to halt the tool execution at some point and continue the config-
uration process later.
Description: In the middle of the configuration process (i.e., right after the original to
generic syntax conversion), the administrator should be able to halt the execution flow,
have the necessary data stored, such as the file in the generic syntax or the tentative
23