356 lines
11 KiB
Markdown
356 lines
11 KiB
Markdown
# SPEC.md
|
|
|
|
## 1. Executive Summary
|
|
|
|
**Product Name:** OrgMyLife
|
|
**Stakeholder Role:** Developer and primary user
|
|
**Product Type:** New product
|
|
|
|
**Goal (one sentence):**
|
|
Create a personal coordination system that aggregates life domains, proposes prioritized actions, and reduces mental load while increasing quality of life.
|
|
|
|
**Business Context:**
|
|
The stakeholder manages multiple professional roles (DB, dHive), personal life, and commitments across fragmented tools (calendars, emails, notes, task systems), leading to coordination overhead and missed prioritization.
|
|
|
|
**Primary Target Users:**
|
|
|
|
* Initially: single primary user (self)
|
|
* Later: family members and dHive colleagues
|
|
|
|
**Core Functional Scope Summary:**
|
|
The system consolidates calendars, emails, notes, and task sources, identifies actionable items, proposes prioritization, and interacts with the user through daily digests and weekly retrospectives. It supports user-confirmed execution of actions such as scheduling, task creation, and restructuring of information.
|
|
|
|
**In Scope:**
|
|
|
|
* Aggregation of multiple calendars, email systems, and note sources
|
|
* Central task identification and management
|
|
* Suggestion-driven prioritization
|
|
* Daily and weekly guided interactions
|
|
* User-confirmed execution of planning actions
|
|
* Visibility into key planning data (tasks, deadlines, conflicts, priorities)
|
|
|
|
**Out of Scope:**
|
|
|
|
* Fully autonomous decision-making without user confirmation
|
|
* Technical implementation details
|
|
* Final definition of tool-specific integration rules (to be defined later)
|
|
|
|
**Main Open Questions:**
|
|
|
|
* Role-specific differences for future users (family, colleagues)
|
|
* Exact definition of task lifecycle and statuses
|
|
* Level of automation for time tracking analysis
|
|
* Boundaries of knowledge graph usage and structure
|
|
* Handling of sensitive/private calendar data across contexts
|
|
|
|
**Main Acceptance Indicators:**
|
|
|
|
* Reduced perceived mental load
|
|
* Increased feeling of control
|
|
* Regular engagement with daily and weekly flows
|
|
* Fewer forgotten tasks and missed priorities
|
|
* Measurable increase in time for sport and personal life
|
|
|
|
---
|
|
|
|
## 2. Goal
|
|
|
|
**One-sentence goal:**
|
|
Reduce coordination overhead by centralizing, structuring, and actively guiding personal and professional planning.
|
|
|
|
**Detailed goal:**
|
|
OrgMyLife aims to unify fragmented information sources (calendars, emails, notes, task systems) into a single coordination layer that not only aggregates data but actively assists in prioritization and execution. The system should act as a proactive assistant that continuously surfaces relevant actions, identifies conflicts, and guides the user through structured planning and reflection routines.
|
|
|
|
**Business value:**
|
|
|
|
* Increased productivity through better prioritization
|
|
* Reduced manual coordination effort
|
|
* Improved work-life balance
|
|
* Better utilization of time and energy
|
|
|
|
**Intended outcome:**
|
|
Users experience clarity, control, and reduced cognitive load while maintaining or increasing output quality and personal well-being.
|
|
|
|
---
|
|
|
|
## 3. Stakeholder Context
|
|
|
|
* **Respondent role:** Developer and primary user
|
|
* **Perspective:** Individual productivity and life management
|
|
* **Context:** Multiple jobs (DB, dHive), family life, sports, volunteering
|
|
* **Scope:** This specification reflects a single stakeholder interview
|
|
|
|
---
|
|
|
|
## 4. Target Users
|
|
|
|
### Primary User
|
|
|
|
* Individual managing multiple life domains
|
|
* Needs centralized visibility and guidance
|
|
* Experiences fragmentation and overload
|
|
|
|
### Future Users
|
|
|
|
* Family members
|
|
* dHive colleagues
|
|
|
|
### Needs
|
|
|
|
* Clear prioritization
|
|
* Reliable overview of commitments
|
|
* Reduced manual coordination
|
|
* Guided planning routines
|
|
|
|
### Pain Points
|
|
|
|
* Fragmented tools and data sources
|
|
* Missing synchronization
|
|
* Forgotten tasks
|
|
* Lack of centralized task management
|
|
* No structured prioritization process
|
|
* Insufficient planning for personal time (e.g., sports)
|
|
|
|
### Differences
|
|
|
|
* Primary user: full control and configuration
|
|
* Future users: likely limited visibility and permissions (to be defined)
|
|
|
|
---
|
|
|
|
## 5. Current Situation / Current Process
|
|
|
|
### Current Setup
|
|
|
|
* Multiple calendars: Outlook (DB), Google (private/family), Nextcloud (dHive)
|
|
* Multiple email systems: Outlook 365, Gmail, Nextcloud, GMX
|
|
* Notes across various systems (including Confluence, Jira, loose notes)
|
|
* Mattermost used without structured task management
|
|
* Separate time tracking application
|
|
|
|
### Workarounds
|
|
|
|
* Manual tracking and coordination
|
|
* Ad-hoc prioritization
|
|
* Informal note-taking
|
|
|
|
### Main Gaps
|
|
|
|
* Incomplete or broken synchronization
|
|
* Lack of central task list
|
|
* Missing buffer times
|
|
* No systematic prioritization
|
|
* No analysis of time tracking data
|
|
* High manual effort
|
|
|
|
### Failure Points
|
|
|
|
* Tasks forgotten
|
|
* Deadlines missed or recognized too late
|
|
* Conflicting or invisible calendar entries
|
|
* Under-planning of personal priorities (e.g., sports)
|
|
|
|
---
|
|
|
|
## 6. Functional Scope
|
|
|
|
### Core Capabilities
|
|
|
|
1. **Aggregation Layer**
|
|
|
|
* Combine multiple calendars, email systems, and note sources
|
|
* Provide unified visibility
|
|
|
|
2. **Task Identification**
|
|
|
|
* Extract tasks from emails and notes
|
|
* Consolidate into a central task system
|
|
|
|
3. **Prioritization Support**
|
|
|
|
* Suggest prioritization based on:
|
|
|
|
* urgency
|
|
* importance hierarchy (family > DB/dHive critical > customer potential > personal interest)
|
|
* energy level
|
|
|
|
4. **Planning Assistance**
|
|
|
|
* Suggest scheduling (e.g., sport, tasks, buffer times)
|
|
* Detect conflicts and gaps
|
|
|
|
5. **Interactive Guidance**
|
|
|
|
* Daily digest:
|
|
|
|
* overview of the day
|
|
* new important items
|
|
* Weekly retrospective:
|
|
|
|
* structured reflection
|
|
* prioritization review
|
|
|
|
6. **Action Execution (User-confirmed)**
|
|
|
|
* Create/modify calendar events
|
|
* Create and manage tasks
|
|
* Block time slots
|
|
* Send invitations
|
|
* Organize notes and maintain knowledge graph
|
|
|
|
7. **Availability Sharing**
|
|
|
|
* Provide selected free time slots for external booking
|
|
|
|
8. **Transparency Layer**
|
|
|
|
* Show:
|
|
|
|
* full calendar overview
|
|
* open tasks
|
|
* top 5 priorities
|
|
* deadlines
|
|
* conflicts
|
|
* origin of suggestions
|
|
|
|
---
|
|
|
|
## 7. Business Rules
|
|
|
|
* The system must not act autonomously without user confirmation
|
|
* All suggested actions require explicit approval
|
|
* Exceptions: explicitly commanded actions may be executed directly
|
|
* All rules must be visible and modifiable by the user
|
|
* The system should actively ask clarifying questions when ambiguity exists
|
|
* Prioritization follows defined hierarchy but allows subjective override
|
|
* The system must explain its suggestions (traceability of origin)
|
|
|
|
---
|
|
|
|
## 8. Business Objects / Functional Data Objects
|
|
|
|
* **Task**
|
|
|
|
* Represents actionable work item
|
|
* Has priority, status, origin
|
|
|
|
* **Calendar Event**
|
|
|
|
* Represents scheduled commitment
|
|
* May originate from different systems
|
|
|
|
* **Time Slot**
|
|
|
|
* Represents available or blocked time
|
|
|
|
* **Suggestion**
|
|
|
|
* System-generated proposal (e.g., reschedule, prioritize)
|
|
* Includes explanation/source
|
|
|
|
* **Reminder**
|
|
|
|
* Unscheduled but relevant item
|
|
|
|
* **Note / Knowledge Object**
|
|
|
|
* Structured or unstructured information
|
|
* Connected via knowledge graph
|
|
|
|
* **Priority Item (Top 5)**
|
|
|
|
* High-level focus topics
|
|
|
|
---
|
|
|
|
## 9. In Scope
|
|
|
|
* Multi-source aggregation
|
|
* Central task management
|
|
* Suggestion-based prioritization
|
|
* Daily and weekly interaction formats
|
|
* User-controlled execution of actions
|
|
* Conflict detection and visibility
|
|
* Knowledge organization support
|
|
|
|
---
|
|
|
|
## 10. Out of Scope
|
|
|
|
* Fully autonomous system behavior
|
|
* Technical integration details
|
|
* Final definition of all external system rules
|
|
* Detailed UI design specifications
|
|
|
|
---
|
|
|
|
## 11. Requirements
|
|
|
|
1. The system must aggregate multiple calendars into a unified view.
|
|
2. The system must aggregate inputs from multiple email systems.
|
|
3. The system must identify potential tasks from incoming information.
|
|
4. The system must provide a central task list.
|
|
5. The system must suggest prioritization of tasks based on defined criteria.
|
|
6. The system must allow user override of all prioritization decisions.
|
|
7. The system must provide a daily digest of relevant items.
|
|
8. The system must conduct a weekly retrospective in an interactive format.
|
|
9. The system must propose scheduling actions (e.g., tasks, sports, buffers).
|
|
10. The system must detect and highlight conflicts across calendars.
|
|
11. The system must display key information (tasks, deadlines, priorities, conflicts).
|
|
12. The system must explain the origin of suggestions.
|
|
13. The system must require user confirmation before executing actions.
|
|
14. The system must allow execution of user-approved actions (e.g., scheduling, task creation).
|
|
15. The system must support availability sharing for external booking.
|
|
16. The system must organize notes and maintain a knowledge structure.
|
|
17. The system must ask clarifying questions when data is ambiguous.
|
|
18. The system must allow rules to be viewed and modified.
|
|
|
|
---
|
|
|
|
## 12. Open Questions / Items to Clarify
|
|
|
|
* How should task statuses and lifecycle be defined?
|
|
* What level of automation is expected for time tracking analysis?
|
|
* How should different user roles (family, colleagues) interact with the system?
|
|
* What data privacy boundaries exist between contexts (work vs private)?
|
|
* How detailed should the knowledge graph be?
|
|
* How should duplicate or conflicting tasks be resolved?
|
|
|
|
---
|
|
|
|
## 13. Risks and Ambiguities
|
|
|
|
* Ambiguity in prioritization logic (subjective vs rule-based)
|
|
* Undefined role model for future multi-user usage
|
|
* Potential overload from too many suggestions or questions
|
|
* Integration limitations affecting completeness of data
|
|
* Risk of user distrust if suggestions are not transparent or accurate
|
|
|
|
---
|
|
|
|
## 14. Acceptance Perspective
|
|
|
|
The product is successful if:
|
|
|
|
* The user feels in control of their commitments
|
|
* The system is used daily and weekly as intended
|
|
* Fewer tasks are forgotten or delayed
|
|
* Planning effort is significantly reduced
|
|
* The user gains measurable time for personal priorities (e.g., sports, family)
|
|
* The backlog no longer creates mental stress
|
|
|
|
---
|
|
|
|
## 15. Glossary
|
|
|
|
| Original Term | English Explanation | Notes |
|
|
| ----------------- | ---------------------------- | ------------------------------------------ |
|
|
| Priorisierung | Prioritization | Based on subjective and rule-based factors |
|
|
| Bauchgefühl | Gut feeling | Subjective decision influence |
|
|
| Knowledge Graph | Structured knowledge network | Used for notes and relationships |
|
|
| Retro | Retrospective | Weekly reflection format |
|
|
| Mental Load | Cognitive burden | Key problem to reduce |
|
|
| Backlogjonglage | Managing backlog overload | Informal term for task overload |
|
|
| Zeiterfassungsapp | Time tracking application | Currently underutilized |
|
|
| Mattermost | Team communication tool | Used without structured task management |
|