# Goals

### Goals for the end-user

* Easy-to-use user interface
  * Consistent structure for commands, parameters and options 
  * User needs to provide only data which is required for the specific task
    * e.g. data that can be derived from other data should not need to be provided
  * Informative feedback - in both cases:
    * Success
      * high-level information about the performed actions is shown - possibly enriched with selected useful details
    * Failure
      * clear information about the error is shown - and where applicable, possible solutions are mentioned
  * Intuitive user-interface, which requires only little documentation - but where necessary, documentation is provided either in the 
    * help function or
    * in separate documents (e.g. in cases where longer explanations are helpful)

### Goals for the developer

* Easy-to-understand architecture and code
  * clear architecture (with high-level documentation)
  * clear control flow
  * sufficient control about the order of execution
  * consistent and intuitive naming of modules, fields and functions
  * documentation where helpful

### Goals for end-user and developers

* Clear modularization concept
  * modules can be run separately (in the sense that they only involve other modules where strictly required)
    * similar to the interface segregation principle but on module level 
    * useful for developers e.g. for integration testing and for maintainability of the code (due to less dependencies)
    * for end-users for selected modules, i.e. if they have a need to run the module separately  
  * modules can be easily combined by developers in order to provide composed functionality
  * modules require minimal input (i.e. only input which is strictly necessary for their execution)
      * similar to the interface segregation principle but on data-level