LIFT-TRACK Requirements Document

PEGS Ref: G.1

Priority: Very High

Rationale:
Product Alignment: an app useful in daily life.

Acceptance Criteria:
A user can log a full session in less than 3 minutes of cumulative input time (excluding effort).

PEGS Ref: G.2

Priority: Very High

Rationale:
Justifies value: structure + history + progression.

Acceptance Criteria:
The PEGS document describes at least 2 current solutions and their limits.

PEGS Ref: G.3

Priority: Very High

Rationale:
Immediate user value.

Acceptance Criteria:
Dedicated screens exist for: fast input + progression + frequency.

PEGS Ref: G.5

Priority: High

Rationale:
Real usage during training, context constraints.

Acceptance Criteria:
A flow 'Start Session → Log Set → Finish' requires ≤ 5 main actions.

PEGS Ref: G.6

Priority: High

Rationale:
Avoids time traps; keeps focus on the core.

Acceptance Criteria:
The list of exclusions is visible and validated.

PEGS Ref: G.7

Priority: Very High

Rationale:
Clarifies expectations and arbitration.

Acceptance Criteria:
A 'Stakeholders' section lists needs and success criteria.

PEGS Ref: E.1

Priority: Medium

Rationale:
Reduces misunderstandings in requirements and UI.

Acceptance Criteria:
Glossary contains at least 10 terms and is used in descriptions.

PEGS Ref: E.3

Priority: Very High

Rationale:
Standard requirement expected for a fitness app.

Acceptance Criteria:
User can export and delete their data from settings.

PEGS Ref: E.3

Priority: Very High

Rationale:
In gym: 4G/Wi-Fi is often irregular.

Acceptance Criteria:
Offline mode: create a session and log sets without error even without network.

PEGS Ref: E.3

Priority: Very High

Rationale:
Fast input = adoption.

Acceptance Criteria:
Manual test: logging a set in < 5s on a mid-range mobile.

PEGS Ref: E.4

Priority: High

Rationale:
Realistic scoping without targeting obsolete devices.

Acceptance Criteria:
List of tested environments (at least 1 Android + 1 desktop browser).

PEGS Ref: E.6

Priority: Very High

Rationale:
Data loss kills trust.

Acceptance Criteria:
After restarting the app, logged sets are still present.

PEGS Ref: S.1

Priority: Very High

Rationale:
Global App' vision (not just API).

Acceptance Criteria:
A component diagram is provided.

PEGS Ref: S.1

Priority: High

Rationale:
Avoids database editing / facilitates content evolution.

Acceptance Criteria:
An admin can add/edit an exercise and see it on the user side.

PEGS Ref: S.2

Priority: Very High

Rationale:
Basis for multi-device usage + backup.

Acceptance Criteria:
Creation/Login/Logout tested successfully.

PEGS Ref: S.2

Priority: High

Rationale:
Minimal useful customization in the gym.

Acceptance Criteria:
Preferences impact display (e.g., kg/lb) immediately.

PEGS Ref: S.2

Priority: Very High

Rationale:
Speeds up input and reduces errors.

Acceptance Criteria:
Search + filters functional; exercise card displayed.

PEGS Ref: S.2

Priority: Very High

Rationale:
Functional core.

Acceptance Criteria:
Create a session with ≥ 3 exercises and find it in history.

PEGS Ref: S.2

Priority: Very High

Rationale:
Real tracking in the gym.

Acceptance Criteria:
Log ≥ 10 sets in a session and finish the session.

PEGS Ref: S.2

Priority: High

Rationale:
Supports the workout flow.

Acceptance Criteria:
After validating a set, timer starts in ≤ 1 action.

PEGS Ref: S.2

Priority: High

Rationale:
Huge time saver.

Acceptance Criteria:
Pre-filling visible and editable; tested on 2 successive sessions.

PEGS Ref: S.2

Priority: Very High

Rationale:
Access to recorded data.

Acceptance Criteria:
Display sessions from the last 30 days + detail of one session.

PEGS Ref: S.2

Priority: Medium

Rationale:
Motivation and progression reading.

Acceptance Criteria:
A PR is updated automatically after a new performance.

PEGS Ref: S.2

Priority: Medium

Rationale:
Expected benefit G.3.

Acceptance Criteria:
A stats screen exists and reflects logged sessions.

PEGS Ref: S.2

Priority: High

Rationale:
Speeds up recurrent usage.

Acceptance Criteria:
Create a template and start a session from that template.

PEGS Ref: S.2

Priority: High

Rationale:
Avoids frustration during mobile input.

Acceptance Criteria:
Edit an existing set and verify stats recalculation.

PEGS Ref: S.2

Priority: Very High

Rationale:
Reliability + Offline.

Acceptance Criteria:
Cut network: input ok; restore network: sync occurs without loss.

PEGS Ref: S.2

Priority: Medium

Rationale:
Avoids over-complexity while remaining coherent.

Acceptance Criteria:
Simulate 2 edits: user sees a conflict message and the final result.

PEGS Ref: S.2

Priority: Medium

Rationale:
Portability + Assignment + GDPR.

Acceptance Criteria:
Export download; file contains sessions + sets.

PEGS Ref: S.2

Priority: Low

Rationale:
Value but not core V1.

Acceptance Criteria:
Add a measurement and display it on a simple curve.

PEGS Ref: S.2

Priority: Low

Rationale:
Nice-to-have; risk of scope creep.

Acceptance Criteria:
Share a readable summary via phone apps.

PEGS Ref: S.3

Priority: Very High

Rationale:
Global App: mobile + web.

Acceptance Criteria:
Same flow possible on mobile and desktop without blocking.

PEGS Ref: S.3

Priority: Medium

Rationale:
Quality and inclusivity without huge cost.

Acceptance Criteria:
Manual audit: 200% zoom ok; web tabbing ok.

PEGS Ref: S.3

Priority: Medium

Rationale:
Comfort in gym/low light.

Acceptance Criteria:
Toggle dark mode; persistence of choice.

PEGS Ref: S.4

Priority: Very High

Rationale:
Validates main flow.

Acceptance Criteria:
Flow tested end-to-end without useless navigation.

PEGS Ref: S.4

Priority: Very High

Rationale:
Critical for trust.

Acceptance Criteria:
Test in airplane mode: full session saved then synced.

PEGS Ref: S.4

Priority: Medium

Rationale:
Progression benefit.

Acceptance Criteria:
Exercise History' view displays at least 5 last performances.

PEGS Ref: S.5

Priority: Very High

Rationale:
Time-to-code: avoid over-engineering.

Acceptance Criteria:
Backlog shows these items as MUST; V2/V3 as SHOULD/COULD.

PEGS Ref: S.5

Priority: High

Rationale:
Adoption: slowness kills usage.

Acceptance Criteria:
Manual measurement: navigation Home → Session < 1s.

PEGS Ref: S.6

Priority: Very High

Rationale:
Helps assignment + quality without heavy testing.

Acceptance Criteria:
A manual test file covers 100% of V1 MUSTs.

PEGS Ref: S.6

Priority: Very High

Rationale:
E.6 Invariant applied.

Acceptance Criteria:
Test: force stop app then relaunch: data intact.

PEGS Ref: S.6

Priority: High

Rationale:
Basic hygiene, without writing a security thesis.

Acceptance Criteria:
Scan: no plaintext password; connection via HTTPS.

PEGS Ref: P.1

Priority: Very High

Rationale:
Avoids ambiguity and guides screen/permission design.

Acceptance Criteria:
A Roles → Rights matrix is available and covers all V1 features.

PEGS Ref: P.3

Priority: High

Rationale:
Protects Time-to-Code and prevents loss of focus.

Acceptance Criteria:
A 'Scope V1' document exists, with a 'Not Included' section.

PEGS Ref: P.4

Priority: Very High

Rationale:
Rapid Dogfooding: validate usage before adding features.

Acceptance Criteria:
A user can log 10 complete sessions on mobile without blocking bugs.

PEGS Ref: P.5

Priority: High

Rationale:
Maximizes real usage without multiplying native apps initially.

Acceptance Criteria:
The same functional base is accessible on phone and desktop.

PEGS Ref: P.6

Priority: High

Rationale:
Reduces classic failure modes of a solo-dev personal app.

Acceptance Criteria:
A risk/impact/mitigation table exists.

PEGS Ref: P.7

Priority: Very High

Rationale:
Facilitates academic evaluation and project steering.

Acceptance Criteria:
100% of requirements have ID + PEGS + MoSCoW + acceptance criteria.