Requirements

Functional Requirements

1. An authenticated user can create a "Data Source" with a name, optional description, and a series of data entries. Each data entry includes a date/time, a numerical value, and optional textual note.
2. A "Data Source" may include additional information to describe or differentiate the source, such as place name, address, PEA meter number, or a thumbnail photo.
3. A user can define multiple data sources such as "Electric Meter", "Water Meter", "Car odometer", or "blood pressure".
4. For each data source, an authorized user can input entries with a date/time and numerical value, such as electric meter reading.
5. An authorized user can view and edit past data entries.
6. The user who creates a data source can grant permission to other users to access and view/edit the data source's data.
7. Users must authenticate themselves to view or edit data sources.
8. A User can be authenticated using LINE auth, OAuth with Google as provider, or local username/password.
   • Username/password may be limited to web interface.

Nonfunctional Requirements

Security

1. Any locally stored passwords should be securely stored as hashes. Use a hash algorithm that is resistant to brute force attacks.
   • As of 2025, Argon2 (esp. Argon2id) is strongest, Scrypt is 2nd, and Bcrypt would be the 3rd choice.
2. Application must log all access to the application.
3. Application must log all input and changes to data values.
4. Record or regularly export all logs to an external location in a way that prevents deletion of logs in case of a security breach of the deployment site(s).

Platform Requirements

1. Application has both a web-based and mobile interface.
2. The initial mobile interface is a LINE MiniApp.
3. The web application and database can be self-hosted for development and testing.
4. The application and database can be deployed to a cloud service or virtual private server (VPS).
5. Design and implementation should not be tightly coupled to vendor-specific technology to avoid vendor lock-in. Examples are non-standard databases such as Firebase.

Data and Access Requirements

1. A data source contains a series of numeric values with a date/timestamp. The numeric values may be integer (such as reading from a standard electric power meter) or floating point (decimal).
2. A User can view data from only the data sources he owns or has been granted access to.
3. A User can create or have access to multiple data sources.
4. To prevent data flooding attacks, there is a limit on how many data sources one user may create.
5. There may be optional data validators for data sources.
6. A data source has descriptive information and may or may not be associated with an address.

Aspirational Features (Nice to Have)

Functional

• A single data entry (reading) can have multiple values, such as systolic & diastolic blood pressure, plus heart rate (often measured at same time).
• Data entries can be acquired automatically, such as readings from an environmental sensor.
• A data entry can be made using a photograph, such as a photo of an electric meter.
• Graph of data for a selected period.
• Sort and filter data, such as filter by date range.
• User can export data to a file or other device., e.g. Google Drive.
• Monitor and block suspicious or excessive use.
• Later versions will add an Android application, but this is not included in the initial implementation.
• Notify users when selected events occur, such as unsuccessful login attempt or change to a user's data source.

Nonfunctional

• Allow other forms of authentication, such as OAuth with other providers, Passkeys, or biometrics on mobile devices.
• Monitor and block users after a set number of consecutive failed login attempts.
• Monitor for suspicious activity and block IP addresses or devices when such activity occurs.