Non-functional requirements for activity-related data entry

[tmillross]

These NFRs relates to the upcoming work of @AnjeKnottnerus & me, under the guidance of @bsteubing Please feel free to comment or add suggestions. This work will eventually address this issue and this one on upstream repo. Functionality is described in different Issues.

1. Viewing, adding and editing activities is intuitive for inexperienced users
2. Editing values takes the minimum possible time for experienced users
3. Finding the most commonly viewed and edited activity data is easy
4. Resizing interface elements is rarely required
5. Common activity data (e.g. name, quantity, unit) can be viewed and edited in a consistent and predictable way
6. Uncommon (e.g. user-specific) key:value pairs can be flexibly created and edited (with potentially reduced consistency due to increased flexibility)
7. Guidance information available where necessary (through tooltips)
8. Editing values unintentionally is difficult
9. The project and database of activities being viewed or edited is clear
10. Activity data integrity is maintained across GUI, memory, and disk
11. User can be confident in the knowledge that data-entry mistakes can be recovered from (automatically where reasonable, or manually otherwise)

[tmillross]

we'll also need to consider formulas and parameters within the activity tables