Repository navigation
Requirements
Published automatically on 2026-10-23 14:17 UTC. Edit the repository source; direct Wiki edits will be overwritten.
Historical project planning. This page preserves the original requirements and roadmap; it is not a statement of current functionality. See Project Archive and Home.
This page documents the functional and non-functional requirements of the 6MWT application.
The application shall support the complete execution of a Six-Minute-Walk Test.
The test shall
- be started manually
- run for exactly six minutes
- stop automatically after six minutes
- allow the user to pause the test at any time
- allow the user to abort the test at any time
The application shall continuously receive GPS position updates during an active walk test. For this project, GPS is the primary sensor used for distance estimation.
The application shall estimate the walked distance from the recorded GPS positions.
During an active walk test the application shall display
- remaining test time
- an indication when GPS signal is temporarily lost (see FR9)
The application shall record every received sensor sample during a walk test.
Each sample shall contain
- timestamp
- sensor type
- sensor source
- measured values
- session identifier
The recorded data shall be stored locally for later analysis.
Each walk test shall receive a unique session identifier. All recorded sensor data shall be associated with the corresponding session.
The application shall validate incoming GPS measurements before they contribute to the calculated walking distance.
Validation criteria shall include
- implausible position jumps
- unrealistic walking speeds
- poor GPS accuracy (below a defined threshold)
- duplicate measurements
Measurements that fail validation shall be flagged and excluded from the distance calculation, but still be recorded raw (see FR5) for later analysis.
The distance estimation shall remain functional when individual GPS measurements are flagged as implausible by FR7.
The application shall apply a defined strategy (e.g. interpolation, smoothing, or exclusion) to compensate for excluded or missing measurements, so that short-term GPS inaccuracies do not significantly distort the calculated distance.
Temporary GPS signal loss shall not terminate an active walk test. The application shall continue recording as soon as valid GPS measurements become available again, and shall inform the user while no signal is available.
The application shall define a common sensor interface that all sensor sources (including GPS) implement, so that additional sensor sources can be integrated without changes to the walk test logic.
Possible future sensors include
- step counter
- heart rate monitor
- smartwatch sensors
- Health Connect / Apple Health
An active walk test shall continue running while the application is in the background or the device is locked, including continued GPS tracking and sensor data recording.
After completion of the walk test, the application shall provide a basic fitness assessment based on the measured walking distance (e.g. classification against reference values).
The application shall allow the user to export recorded session data (e.g. as CSV or JSON) for external analysis.
Nice to have
The application shall handle unexpected errors (e.g. application crash, unexpected termination) during an active walk test gracefully.
If the application is restarted after an unexpected termination during an active session, it shall inform the user about the interrupted session and shall not silently lose already recorded data (see FR5).
The application shall allow the user to view a list of previously recorded sessions including their results and to delete individual sessions and their associated data.
The application shall provide an onboarding sequence that explains, before the first use of the test, what the Six-Minute-Walk Test is, what data is required, how the test is carried out, and how results are presented.
The application shall provide a start screen giving an overview of the test and allowing the user to start a new test.
Before a walk test is started, the application shall allow the user to enter patient information required for the fitness assessment (FR12), consisting of
- name
- age
- gender
- height
- weight
Before a walk test is started, the application shall provide a screen with preparation instructions for correctly carrying out the test (e.g. video instructions).
During an active walk test, the application shall provide a screen displaying the information defined in FR4, and allowing the user to pause or abort the test (see FR1). Aborting the test shall require the user to confirm the action before the test is cancelled.
After completion of a walk test, the application shall provide a screen displaying the test results, including the walked distance and the fitness assessment defined in FR12.
A walk test can be aborted by the user. In this case the test data shall still be saved but marked as incomplete. A fitness assessment shall potentially be skipped.
The application shall follow a modular architecture that separates sensor sources, business logic, persistence, and presentation. Presentation, application logic, and data persistence shall remain independent to improve maintainability and testability.
Adding new sensor sources (via the interface defined in FR10) or new distance estimation algorithms (see FR3) shall require only minimal changes to the existing code base.
Core application logic shall remain independent of Flutter widgets wherever possible, to facilitate automated testing.
Recording high-frequency sensor data shall not block the user interface or noticeably delay the display of live test information (FR4).
Failure of optional sensor sources shall not prevent the execution of a walking test. Recorded data shall not be lost in the event of an application crash during an active session.
Raw sensor data shall be stored locally in a format suitable for later evaluation, algorithm development, and debugging.
The application shall explain the procedure of the walk test to the user before it is started (via an instruction/explanation screen), so that a first-time user can start and conduct the test without external instructions.
The application shall log key events (e.g. test start/stop, sensor errors, GPS status changes) with severity levels (e.g. debug, info, error) to simplify debugging, performance analysis, and future development.
Location data recorded during a walk test shall remain stored locally on the device by default and shall not be transmitted to external services without explicit user consent.
Continuous GPS tracking and background execution (FR11) shall be implemented so as to avoid excessive battery drain during a six-minute session.
The application shall support a defined minimum set of Android and iOS versions.
Nice to have
The application shall support multiple languages.