1.8 KiB
1.8 KiB
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
- Success
- 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
- modules can be run separately (in the sense that they only involve other modules where strictly required)
