36 lines
1.8 KiB
Markdown
36 lines
1.8 KiB
Markdown
# 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
|
