| # PCC Student Task Manager — GitLab Epics & Issues
|
|
|
| 11 epics · 51 issues · 212 man-hours total
|
|
|
| ## How to enter
|
|
|
| 1. **Labels first** (Group → Manage → Labels): `epic::categories`, `epic::interface`, `epic::optional`, `epic::persistence`, `epic::planning`, `epic::prioritization`, `epic::quality`, `epic::semester`, `epic::setup`, `epic::tasks`, `epic::views`, `optional`, `type::documentation`, `type::feature`, `type::infrastructure`, `type::planning`, `type::testing`.
|
| 2. **Epics** (Group → Plan → Epics → New epic): paste the title, paste the description block, and add the label.
|
| 3. **Issues** (Project → Issues → New issue): paste the title and the description block. The `/estimate` and `/label` lines at the bottom are GitLab quick actions, so they set the time estimate and labels when you save. Then set the **Epic** in the issue sidebar.
|
| - Every issue goes in the team's task-manager project, **except** the Planning Phase issues, which go in **Grade Tracking Application**.
|
| 4. **Merge request** (Grade Tracking Application): create branch `docs/requirements-v2`, upload the SRS .docx to `docs/`, and open an MR titled *Requirement documentation: System Specifications v2* with `Closes #<Requirement documentation issue number>` in its description.
|
|
|
| ## Summary
|
|
|
| | # | Epic | Issues | Man-hours |
|
| |---|---|---|---|
|
| | 1 | Planning Phase | 3 | 24 |
|
| | 2 | Data Model & Persistence | 6 | 29 |
|
| | 3 | First-Run Setup & Course Settings | 3 | 14 |
|
| | 4 | Task Lifecycle Management | 8 | 28 |
|
| | 5 | Categories & Priority Levels | 3 | 12 |
|
| | 6 | Task Views & Display | 6 | 15 |
|
| | 7 | Prioritization & Alerts | 5 | 16 |
|
| | 8 | Console Interface & Input Validation | 3 | 15 |
|
| | 9 | Semester Lifecycle | 2 | 7 |
|
| | 10 | Build, Quality & Maintainability | 6 | 27 |
|
| | 11 | Optional Enhancements | 6 | 25 |
|
| | | **Total** | **51** | **212** |
|
|
|
| ---
|
|
|
| ## Epic 1: Planning Phase
|
|
|
| **Labels:** `epic::planning`
|
|
|
| **Description:**
|
|
|
| ~~~markdown
|
| ## Overview
|
| Requirements gathering, specification, review, and backlog setup for the PCC Student Task Manager.
|
|
|
| ## Scope
|
| - Second-revision System Specifications document (SRS v2)
|
| - Requirements validation follow-up with stakeholders
|
| - GitLab epics/issues aligned to the SRS, with man-hour estimates
|
|
|
| ## Requirements covered
|
| FR-014, FR-017, FR-023, FR-025, FR-028
|
|
|
| ## Work breakdown
|
| | Issue | Requirements | Man-hours |
|
| |---|---|---|
|
| | Requirement documentation | — | 15 |
|
| | Create epics and issues aligned to requirements | — | 5 |
|
| | Resolve Part 4A requirements-validation questions | FR-014, FR-017, FR-023, FR-025, FR-028 | 4 |
|
| | **Total** | | **24** |
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
| ~~~
|
|
|
| ### 1.1 Requirement documentation
|
|
|
| **Project:** Grade Tracking Application · **Epic:** Planning Phase · **Estimate:** 15 h · **Labels:** `type::documentation`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Refine the initial System Specifications into a second version using instructor feedback, and commit it to the repository via merge request.
|
|
|
| ## Requirements implemented
|
| _Process work; no product requirement._
|
|
|
| ## Implementation notes
|
| - Source: *PCC Task Manager - System Specifications - Team 5.docx* (revisions 2026-09-27, 2026-10-03, 2026-10-04, 2026-10-05).
|
| - Functional requirements are numbered FR-001 to FR-037 (FR-032 to FR-037 optional); non-functional requirements NFR-001 to NFR-020.
|
| - Estimate basis: 5 members x ~3 h (drafting, two review meetings, revisions).
|
|
|
| ## Acceptance criteria
|
| - [ ] SRS v2 incorporates instructor feedback
|
| - [ ] Every requirement has a unique ID
|
| - [ ] Document committed on a feature branch and attached to a merge request
|
| - [ ] Merge request reviewed by at least one other team member
|
|
|
| ## Estimate
|
| **15 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ## Requirements traceability matrix
|
| | Requirement | Epic | Issue(s) |
|
| |---|---|---|
|
| | FR-001 | First-Run Setup & Course Settings | First-run setup wizard |
|
| | FR-002 | Data Model & Persistence | Data file format and serializer; Load data file on startup (CRLF/LF tolerant); Atomic save after every change |
|
| | FR-003 | Data Model & Persistence | Save-failure notification, retry, and alternate path |
|
| | FR-004 | Data Model & Persistence; Task Lifecycle Management | Define Task and CourseSettings data structures; Quick-add a task from a name only |
|
| | FR-005 | Data Model & Persistence; First-Run Setup & Course Settings; Task Lifecycle Management | Define Task and CourseSettings data structures; Store and edit course information; Edit any user-entered task field |
|
| | FR-006 | Task Lifecycle Management | Soft-delete with confirmation and restore |
|
| | FR-007 | Task Lifecycle Management | Log an already-completed task |
|
| | FR-008 | Task Views & Display | Single-task detail view; Current, completed, and all-task lists; Show/hide completed and deleted tasks |
|
| | FR-009 | Prioritization & Alerts | Next-task ranking algorithm |
|
| | FR-010 | Prioritization & Alerts; Task Views & Display | Remaining-work total; Main-screen next task and remaining-time summary |
|
| | FR-011 | Prioritization & Alerts | Due-soon and overdue alert banner |
|
| | FR-012 | Console Interface & Input Validation | Validated input helpers with re-prompt |
|
| | FR-013 | Task Lifecycle Management | Quick-add a task from a name only; Full task entry (due date, category, priority, estimate) |
|
| | FR-014 | Data Model & Persistence; Planning Phase; Task Lifecycle Management | Resolve Part 4A requirements-validation questions; Define Task and CourseSettings data structures; Full task entry (due date, category, priority, estimate) |
|
| | FR-015 | Categories & Priority Levels; Semester Lifecycle | User-defined task categories; Carry over categories and priority levels to the new semester |
|
| | FR-016 | Categories & Priority Levels | Category default priority with per-task override |
|
| | FR-017 | Categories & Priority Levels; Planning Phase; Semester Lifecycle | Resolve Part 4A requirements-validation questions; User-defined priority levels; Carry over categories and priority levels to the new semester |
|
| | FR-018 | Data Model & Persistence; First-Run Setup & Course Settings | Define Task and CourseSettings data structures; Store and edit course information |
|
| | FR-019 | Task Views & Display | Current, completed, and all-task lists |
|
| | FR-020 | Data Model & Persistence; Task Lifecycle Management | Define Task and CourseSettings data structures; Task status and explicit-only completion |
|
| | FR-021 | Semester Lifecycle; Task Lifecycle Management | Task status and explicit-only completion; Complete course: archive the semester data file |
|
| | FR-022 | Task Views & Display | Show/hide completed and deleted tasks |
|
| | FR-023 | Data Model & Persistence; Planning Phase; Task Lifecycle Management | Resolve Part 4A requirements-validation questions; Define Task and CourseSettings data structures; Completion timestamp with custom override |
|
| | FR-024 | Task Lifecycle Management | Log an already-completed task |
|
| | FR-025 | Planning Phase; Prioritization & Alerts | Resolve Part 4A requirements-validation questions; Next-task ranking algorithm; Ranking algorithm test cases |
|
| | FR-026 | Prioritization & Alerts | Next-task ranking algorithm; Ranking algorithm test cases |
|
| | FR-027 | Prioritization & Alerts | Overdue label |
|
| | FR-028 | Planning Phase; Semester Lifecycle | Resolve Part 4A requirements-validation questions; Complete course: archive the semester data file; Carry over categories and priority levels to the new semester |
|
| | FR-029 | Data Model & Persistence | Dynamic task collection (unlimited tasks) |
|
| | FR-030 | First-Run Setup & Course Settings | Central Time date/time utilities |
|
| | FR-031 | Console Interface & Input Validation | Main menu loop and command dispatch |
|
| | FR-032 | Optional Enhancements | Sort and filter by category, priority, and status |
|
| | FR-033 | Optional Enhancements | Completed-work summary |
|
| | FR-034 | Optional Enhancements | Log actual time spent against the estimate |
|
| | FR-035 | Optional Enhancements | Latest-start-time warning |
|
| | FR-036 | Optional Enhancements | Subtasks and phases via task links |
|
| | FR-037 | Optional Enhancements | Mass and recurring task entry |
|
| | NFR-001 | Build, Quality & Maintainability; Data Model & Persistence | Atomic save after every change; Acceptance test plan and execution |
|
| | NFR-002 | Build, Quality & Maintainability; Data Model & Persistence | Save-failure notification, retry, and alternate path; Acceptance test plan and execution |
|
| | NFR-003 | Build, Quality & Maintainability; Task Lifecycle Management | Quick-add a task from a name only; Acceptance test plan and execution |
|
| | NFR-004 | Console Interface & Input Validation | Validated input helpers with re-prompt |
|
| | NFR-005 | Console Interface & Input Validation | Customizable menu |
|
| | NFR-006 | Build, Quality & Maintainability; Data Model & Persistence | Load data file on startup (CRLF/LF tolerant); Performance verification |
|
| | NFR-007 | Build, Quality & Maintainability; Task Views & Display | Current, completed, and all-task lists; Performance verification |
|
| | NFR-008 | Build, Quality & Maintainability; Data Model & Persistence | Atomic save after every change; Performance verification |
|
| | NFR-009 | Build, Quality & Maintainability | Acceptance test plan and execution |
|
| | NFR-010 | Build, Quality & Maintainability | Project skeleton and GCC build script; Acceptance test plan and execution |
|
| | NFR-011 | Data Model & Persistence | Load data file on startup (CRLF/LF tolerant) |
|
| | NFR-012 | Build, Quality & Maintainability | Coding standards: naming and function comments; README and user guide |
|
| | NFR-013 | Build, Quality & Maintainability | Coding standards: naming and function comments |
|
| | NFR-014 | Build, Quality & Maintainability | Project skeleton and GCC build script; GitLab CI warning gate |
|
| | NFR-015 | Console Interface & Input Validation | Main menu loop and command dispatch |
|
| | NFR-016 | Task Views & Display | Consistent task row formatter |
|
| | NFR-017 | Task Lifecycle Management | Default due date and notification |
|
| | NFR-018 | Prioritization & Alerts | Main-screen next task and remaining-time summary |
|
| | NFR-019 | Task Lifecycle Management | Soft-delete with confirmation and restore |
|
| | NFR-020 | Task Views & Display | Empty-list messages |
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 15h
|
| /label ~"type::documentation"
|
| ~~~
|
|
|
| ### 1.2 Create epics and issues aligned to requirements
|
|
|
| **Project:** Grade Tracking Application · **Epic:** Planning Phase · **Estimate:** 5 h · **Labels:** `type::planning`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Break the SRS into GitLab epics (systems) and issues (implementation work), each with a man-hour estimate and requirement traceability.
|
|
|
| ## Requirements implemented
|
| _Process work; no product requirement._
|
|
|
| ## Implementation notes
|
| - Every FR/NFR ID must be referenced by at least one issue.
|
| - Estimates are total man-hours (2 people x 1 h = 2 h).
|
|
|
| ## Acceptance criteria
|
| - [ ] One epic per major subsystem
|
| - [ ] Each issue lists the requirement IDs it implements
|
| - [ ] Each issue has a time estimate set
|
|
|
| ## Estimate
|
| **5 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 5h
|
| /label ~"type::planning"
|
| ~~~
|
|
|
| ### 1.3 Resolve Part 4A requirements-validation questions
|
|
|
| **Project:** Grade Tracking Application · **Epic:** Planning Phase · **Estimate:** 4 h · **Labels:** `type::planning`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Get answers from Dr. Sparks on the five open validation questions and fold the answers back into the SRS.
|
|
|
| ## Requirements implemented
|
| - **FR-014** — The system shall allow students to input an estimated completion time for a task, which is user-specified, defaults to 0, and may be 0 for reminder-only tasks (for example, “bring calculator”).
|
| - **FR-017** — The system shall allow students to define their own priority levels.
|
| - **FR-023** — The system shall record the date and time a task was completed and shall allow the student to enter a custom completion date and time.
|
| - **FR-025** — The system shall indicate which task the student should work on next, ranked by: (1) due date and time first, (2) the student’s priority level, (3) estimated completion time as a slight adjustment.
|
| - **FR-028** — The system shall provide a “complete course” option that archives the semester’s file, so the next launch starts a new semester.
|
|
|
| ## Implementation notes
|
| - Reminder-only (0 h) tasks: ranked with work tasks or shown separately?
|
| - Optional notes/description field per task?
|
| - Mark tasks completed after the due date as "completed late"?
|
| - Number/order of priority levels: student-defined or built-in?
|
| - Do categories and priority levels carry over to the next semester?
|
|
|
| ## Acceptance criteria
|
| - [ ] All five questions answered and recorded
|
| - [ ] SRS updated with a new revision row
|
| - [ ] Affected issues updated
|
|
|
| ## Estimate
|
| **4 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 4h
|
| /label ~"type::planning"
|
| ~~~
|
|
|
| ---
|
|
|
| ## Epic 2: Data Model & Persistence
|
|
|
| **Labels:** `epic::persistence`
|
|
|
| **Description:**
|
|
|
| ~~~markdown
|
| ## Overview
|
| In-memory data model and the on-disk data file: structures, file format, load/save, crash safety, and failure recovery. Reliability is the top-ranked NFR category, so this epic is foundational.
|
|
|
| ## Scope
|
| - Task and course-settings structures
|
| - Unbounded task storage
|
| - Data file format, loader and saver
|
| - Atomic saves and save-failure recovery
|
|
|
| ## Requirements covered
|
| FR-002, FR-003, FR-004, FR-005, FR-014, FR-018, FR-020, FR-023, FR-029, NFR-001, NFR-002, NFR-006, NFR-008, NFR-011
|
|
|
| ## Work breakdown
|
| | Issue | Requirements | Man-hours |
|
| |---|---|---|
|
| | Define Task and CourseSettings data structures | FR-004, FR-005, FR-014, FR-018, FR-020, FR-023 | 4 |
|
| | Dynamic task collection (unlimited tasks) | FR-029 | 3 |
|
| | Data file format and serializer | FR-002 | 6 |
|
| | Load data file on startup (CRLF/LF tolerant) | FR-002, NFR-006, NFR-011 | 6 |
|
| | Atomic save after every change | FR-002, NFR-001, NFR-008 | 5 |
|
| | Save-failure notification, retry, and alternate path | FR-003, NFR-002 | 5 |
|
| | **Total** | | **29** |
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
| ~~~
|
|
|
| ### 2.1 Define Task and CourseSettings data structures
|
|
|
| **Project:** Task manager project · **Epic:** Data Model & Persistence · **Estimate:** 4 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Define the C structs for a task and for course/settings data, shared by every other module.
|
|
|
| ## Requirements implemented
|
| - **FR-004** — The system shall create a task from a name alone.
|
| - **FR-005** — The system shall allow any user-entered field of a task to be updated after it has been created.
|
| - **FR-014** — The system shall allow students to input an estimated completion time for a task, which is user-specified, defaults to 0, and may be 0 for reminder-only tasks (for example, “bring calculator”).
|
| - **FR-018** — The system shall store the course information (student name, course name, course number, instructor) once, so the student does not need to re-enter it.
|
| - **FR-020** — The system shall allow students to mark a task status as not started, in progress, or completed.
|
| - **FR-023** — The system shall record the date and time a task was completed and shall allow the student to enter a custom completion date and time.
|
|
|
| ## Implementation notes
|
| - Task: id, name, category id, priority id, due date/time, estimate (minutes), status enum, completed-at, hidden/deleted flag, created-at.
|
| - CourseSettings: student name, course name, course number, instructor, semester end date, menu config.
|
| - Store times as `time_t` (UTC) and convert to Central Time only for input/output.
|
|
|
| ## Acceptance criteria
|
| - [ ] Header compiles cleanly under -Wall -Wextra
|
| - [ ] Every field has a comment
|
| - [ ] Reviewed by one other member
|
|
|
| ## Estimate
|
| **4 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 4h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 2.2 Dynamic task collection (unlimited tasks)
|
|
|
| **Project:** Task manager project · **Epic:** Data Model & Persistence · **Estimate:** 3 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Growable array (`realloc`, doubling) holding tasks, with add/find-by-id/remove helpers.
|
|
|
| ## Requirements implemented
|
| - **FR-029** — The system shall support an unlimited number of tasks.
|
|
|
| ## Implementation notes
|
| - No compile-time cap on task count.
|
| - Allocation failure is reported, never silently ignored.
|
|
|
| ## Acceptance criteria
|
| - [ ] 10,000 tasks can be added and listed
|
| - [ ] No leaks under a simple add/remove loop
|
|
|
| ## Estimate
|
| **3 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 3h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 2.3 Data file format and serializer
|
|
|
| **Project:** Task manager project · **Epic:** Data Model & Persistence · **Estimate:** 6 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Specify a versioned, line-oriented text format for settings, categories, priority levels, and tasks, and write it out.
|
|
|
| ## Requirements implemented
|
| - **FR-002** — The system shall save all tasks and settings to a data file and load them on startup.
|
|
|
| ## Implementation notes
|
| - First line holds a format version so future changes can migrate old files.
|
| - Escape delimiter characters inside task names.
|
| - Document the format in the README.
|
|
|
| ## Acceptance criteria
|
| - [ ] Round-trip save then load reproduces identical data
|
| - [ ] Format documented
|
|
|
| ## Estimate
|
| **6 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 6h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 2.4 Load data file on startup (CRLF/LF tolerant)
|
|
|
| **Project:** Task manager project · **Epic:** Data Model & Persistence · **Estimate:** 6 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Parse the data file at launch, accepting both Windows (CRLF) and Linux (LF) line endings.
|
|
|
| ## Requirements implemented
|
| - **FR-002** — The system shall save all tasks and settings to a data file and load them on startup.
|
| - **NFR-006** — The system shall launch without a noticeable delay.
|
| - **NFR-011** — The system shall correctly read data files that use either Windows or Linux line endings.
|
|
|
| ## Implementation notes
|
| - Strip a trailing `\r` from every line before parsing.
|
| - Missing file means first run, which triggers the setup wizard.
|
| - Malformed lines: report the line number and skip, keeping the rest of the data.
|
|
|
| ## Acceptance criteria
|
| - [ ] Files saved with CRLF and with LF both load correctly
|
| - [ ] Startup with 1,000 tasks shows no noticeable delay
|
|
|
| ## Estimate
|
| **6 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 6h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 2.5 Atomic save after every change
|
|
|
| **Project:** Task manager project · **Epic:** Data Model & Persistence · **Estimate:** 5 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Save immediately after every create/update/delete, using write-to-temp, flush, then rename so a crash never corrupts the last good file.
|
|
|
| ## Requirements implemented
|
| - **FR-002** — The system shall save all tasks and settings to a data file and load them on startup.
|
| - **NFR-001** — The system shall not lose any previously saved tasks if the program terminates unexpectedly.
|
| - **NFR-008** — The system shall save changes to the data file within one second after a task is created, updated, or deleted.
|
|
|
| ## Implementation notes
|
| - Write `tasks.dat.tmp`, `fflush` + `_commit`/`fsync`, then replace `tasks.dat` (on Windows, `MoveFileEx` with `MOVEFILE_REPLACE_EXISTING`).
|
| - Keep the previous file as `tasks.dat.bak`.
|
|
|
| ## Acceptance criteria
|
| - [ ] Killing the process mid-save leaves a loadable file
|
| - [ ] Save completes within 1 s of the change
|
|
|
| ## Estimate
|
| **5 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 5h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 2.6 Save-failure notification, retry, and alternate path
|
|
|
| **Project:** Task manager project · **Epic:** Data Model & Persistence · **Estimate:** 5 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| When a save fails, tell the user why, retry once, and if that fails keep the data in memory and prompt for an alternate save path.
|
|
|
| ## Requirements implemented
|
| - **FR-003** — The system shall notify the user when a save fails and retry the save. If the retry fails, it shall keep the in-memory data and offer an alternate path.
|
| - **NFR-002** — The system shall recover from a failed save and tell the user what happened.
|
|
|
| ## Implementation notes
|
| - Report the `strerror(errno)` text in plain language.
|
| - The alternate path is remembered for the rest of the session.
|
|
|
| ## Acceptance criteria
|
| - [ ] Read-only or locked data file triggers the notify, retry, alternate-path flow
|
| - [ ] No data is lost during the flow
|
|
|
| ## Estimate
|
| **5 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 5h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ---
|
|
|
| ## Epic 3: First-Run Setup & Course Settings
|
|
|
| **Labels:** `epic::setup`
|
|
|
| **Description:**
|
|
|
| ~~~markdown
|
| ## Overview
|
| First-run wizard, stored course information, and Central Time date/time handling used across the application.
|
|
|
| ## Scope
|
| - Setup wizard
|
| - Course info stored once and editable
|
| - Central Time conversion utilities
|
|
|
| ## Requirements covered
|
| FR-001, FR-005, FR-018, FR-030
|
|
|
| ## Work breakdown
|
| | Issue | Requirements | Man-hours |
|
| |---|---|---|
|
| | First-run setup wizard | FR-001 | 5 |
|
| | Store and edit course information | FR-018, FR-005 | 3 |
|
| | Central Time date/time utilities | FR-030 | 6 |
|
| | **Total** | | **14** |
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
| ~~~
|
|
|
| ### 3.1 First-run setup wizard
|
|
|
| **Project:** Task manager project · **Epic:** First-Run Setup & Course Settings · **Estimate:** 5 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| On first launch (no data file), prompt for student name, course name, course number, instructor, and semester end date.
|
|
|
| ## Requirements implemented
|
| - **FR-001** — The system shall, on the first run, present a setup wizard that captures the student’s name, course name and number, instructor, and semester end date.
|
|
|
| ## Implementation notes
|
| - Uses the validated input helpers.
|
| - Semester end date must be in the future.
|
|
|
| ## Acceptance criteria
|
| - [ ] Wizard appears only when no data file exists
|
| - [ ] Entered values persist and are not asked again
|
|
|
| ## Estimate
|
| **5 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 5h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 3.2 Store and edit course information
|
|
|
| **Project:** Task manager project · **Epic:** First-Run Setup & Course Settings · **Estimate:** 3 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Course information is entered once, shown in the header, and can be edited from a settings menu.
|
|
|
| ## Requirements implemented
|
| - **FR-018** — The system shall store the course information (student name, course name, course number, instructor) once, so the student does not need to re-enter it.
|
| - **FR-005** — The system shall allow any user-entered field of a task to be updated after it has been created.
|
|
|
| ## Acceptance criteria
|
| - [ ] Course info appears in the program header
|
| - [ ] Edits are saved immediately
|
|
|
| ## Estimate
|
| **3 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 3h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 3.3 Central Time date/time utilities
|
|
|
| **Project:** Task manager project · **Epic:** First-Run Setup & Course Settings · **Estimate:** 6 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Parse, format, and compare dates/times in US Central Time, including the daylight-saving changeover.
|
|
|
| ## Requirements implemented
|
| - **FR-030** — The system shall use Central Time for all dates and times.
|
|
|
| ## Implementation notes
|
| - MinGW's C runtime does not understand IANA zone names, so implement the US DST rule (2nd Sunday of March to 1st Sunday of November) over UTC `time_t`.
|
| - Single input format (e.g. `YYYY-MM-DD HH:MM`) with a date-only shortcut.
|
|
|
| ## Acceptance criteria
|
| - [ ] Unit tests cover dates either side of both DST transitions
|
| - [ ] All displayed times are Central
|
|
|
| ## Estimate
|
| **6 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 6h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ---
|
|
|
| ## Epic 4: Task Lifecycle Management
|
|
|
| **Labels:** `epic::tasks`
|
|
|
| **Description:**
|
|
|
| ~~~markdown
|
| ## Overview
|
| Creating, editing, completing, deleting, and restoring tasks, including retroactive logging of completed work.
|
|
|
| ## Scope
|
| - Quick add and full add
|
| - Edit any field
|
| - Status and explicit completion
|
| - Soft delete and restore
|
| - Default due date
|
|
|
| ## Requirements covered
|
| FR-004, FR-005, FR-006, FR-007, FR-013, FR-014, FR-020, FR-021, FR-023, FR-024, NFR-003, NFR-017, NFR-019
|
|
|
| ## Work breakdown
|
| | Issue | Requirements | Man-hours |
|
| |---|---|---|
|
| | Quick-add a task from a name only | FR-004, FR-013, NFR-003 | 4 |
|
| | Full task entry (due date, category, priority, estimate) | FR-013, FR-014 | 5 |
|
| | Edit any user-entered task field | FR-005 | 5 |
|
| | Soft-delete with confirmation and restore | FR-006, NFR-019 | 4 |
|
| | Task status and explicit-only completion | FR-020, FR-021 | 3 |
|
| | Completion timestamp with custom override | FR-023 | 3 |
|
| | Log an already-completed task | FR-007, FR-024 | 2 |
|
| | Default due date and notification | NFR-017 | 2 |
|
| | **Total** | | **28** |
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
| ~~~
|
|
|
| ### 4.1 Quick-add a task from a name only
|
|
|
| **Project:** Task manager project · **Epic:** Task Lifecycle Management · **Estimate:** 4 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Create a task by typing only its name; all other fields take defaults.
|
|
|
| ## Requirements implemented
|
| - **FR-004** — The system shall create a task from a name alone.
|
| - **FR-013** — The system shall allow students to create a new task.
|
| - **NFR-003** — The system shall allow the user to add a new task in no more than three menu selections/prompts.
|
|
|
| ## Implementation notes
|
| - Path: main menu, then Add, then name: three prompts at most.
|
|
|
| ## Acceptance criteria
|
| - [ ] Task created with a name only in 3 prompts or fewer
|
| - [ ] Defaults applied and shown in the confirmation
|
|
|
| ## Estimate
|
| **4 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 4h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 4.2 Full task entry (due date, category, priority, estimate)
|
|
|
| **Project:** Task manager project · **Epic:** Task Lifecycle Management · **Estimate:** 5 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Optional extended entry for due date/time, category, priority override, and estimated time (defaults to 0; 0 means a reminder-only task).
|
|
|
| ## Requirements implemented
|
| - **FR-013** — The system shall allow students to create a new task.
|
| - **FR-014** — The system shall allow students to input an estimated completion time for a task, which is user-specified, defaults to 0, and may be 0 for reminder-only tasks (for example, “bring calculator”).
|
|
|
| ## Implementation notes
|
| - Every field can be skipped to accept its default.
|
|
|
| ## Acceptance criteria
|
| - [ ] Estimate defaults to 0 and accepts 0
|
| - [ ] Category default priority is pre-filled
|
|
|
| ## Estimate
|
| **5 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 5h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 4.3 Edit any user-entered task field
|
|
|
| **Project:** Task manager project · **Epic:** Task Lifecycle Management · **Estimate:** 5 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Select a task, then pick a field to change; the change is validated and saved.
|
|
|
| ## Requirements implemented
|
| - **FR-005** — The system shall allow any user-entered field of a task to be updated after it has been created.
|
|
|
| ## Acceptance criteria
|
| - [ ] Each user-entered field can be edited
|
| - [ ] Invalid edits are rejected with a re-prompt
|
|
|
| ## Estimate
|
| **5 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 5h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 4.4 Soft-delete with confirmation and restore
|
|
|
| **Project:** Task manager project · **Epic:** Task Lifecycle Management · **Estimate:** 4 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Deleting hides the task after a y/n confirmation; hidden tasks can be listed and restored.
|
|
|
| ## Requirements implemented
|
| - **FR-006** — The system shall soft-delete a task (hide it) and allow restoring it.
|
| - **NFR-019** — The system shall ask for confirmation before deleting a task.
|
|
|
| ## Implementation notes
|
| - Tasks are never physically removed from the data file.
|
|
|
| ## Acceptance criteria
|
| - [ ] Delete asks for confirmation
|
| - [ ] Deleted task disappears from default lists
|
| - [ ] Restore brings it back unchanged
|
|
|
| ## Estimate
|
| **4 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 4h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 4.5 Task status and explicit-only completion
|
|
|
| **Project:** Task manager project · **Epic:** Task Lifecycle Management · **Estimate:** 3 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Status is Not Started, In Progress, or Completed, and only an explicit student action changes it.
|
|
|
| ## Requirements implemented
|
| - **FR-020** — The system shall allow students to mark a task status as not started, in progress, or completed.
|
| - **FR-021** — The system shall ensure that a task is only completed by an explicit student action; it is never auto-completed or auto-deleted.
|
|
|
| ## Implementation notes
|
| - No code path auto-completes or auto-deletes a task (including overdue tasks and the course archive).
|
|
|
| ## Acceptance criteria
|
| - [ ] Status can be set to each of the three values
|
| - [ ] Overdue tasks remain incomplete until the student acts
|
|
|
| ## Estimate
|
| **3 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 3h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 4.6 Completion timestamp with custom override
|
|
|
| **Project:** Task manager project · **Epic:** Task Lifecycle Management · **Estimate:** 3 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Record the current Central Time when a task is completed, and let the student enter a different completion date/time.
|
|
|
| ## Requirements implemented
|
| - **FR-023** — The system shall record the date and time a task was completed and shall allow the student to enter a custom completion date and time.
|
|
|
| ## Acceptance criteria
|
| - [ ] Completed-at defaults to now
|
| - [ ] Custom completed-at is accepted and validated
|
|
|
| ## Estimate
|
| **3 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 3h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 4.7 Log an already-completed task
|
|
|
| **Project:** Task manager project · **Epic:** Task Lifecycle Management · **Estimate:** 2 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Create a task directly in the Completed state with a completion time, for work done earlier.
|
|
|
| ## Requirements implemented
|
| - **FR-007** — The system shall allow a task to be entered directly as already completed, with a completion time.
|
| - **FR-024** — The system shall allow students to create a task that is already completed to log work that was done earlier.
|
|
|
| ## Acceptance criteria
|
| - [ ] Task appears only in the completed list
|
| - [ ] Completion time is stored as entered
|
|
|
| ## Estimate
|
| **2 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 2h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 4.8 Default due date and notification
|
|
|
| **Project:** Task manager project · **Epic:** Task Lifecycle Management · **Estimate:** 2 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| When no due date is given, assign a default and tell the student which date was used.
|
|
|
| ## Requirements implemented
|
| - **NFR-017** — The system shall notify the user when a task is assigned a default due date.
|
|
|
| ## Implementation notes
|
| - Proposed default: semester end date. The SRS does not yet specify the default, so confirm it under the Planning Phase validation issue.
|
|
|
| ## Acceptance criteria
|
| - [ ] A message names the default date that was assigned
|
|
|
| ## Estimate
|
| **2 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 2h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ---
|
|
|
| ## Epic 5: Categories & Priority Levels
|
|
|
| **Labels:** `epic::categories`
|
|
|
| **Description:**
|
|
|
| ~~~markdown
|
| ## Overview
|
| Student-defined task categories and priority levels, with per-category default priorities.
|
|
|
| ## Scope
|
| - Priority level CRUD and ordering
|
| - Category CRUD
|
| - Category default priority with task override
|
|
|
| ## Requirements covered
|
| FR-015, FR-016, FR-017
|
|
|
| ## Work breakdown
|
| | Issue | Requirements | Man-hours |
|
| |---|---|---|
|
| | User-defined priority levels | FR-017 | 5 |
|
| | User-defined task categories | FR-015 | 4 |
|
| | Category default priority with per-task override | FR-016 | 3 |
|
| | **Total** | | **12** |
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
| ~~~
|
|
|
| ### 5.1 User-defined priority levels
|
|
|
| **Project:** Task manager project · **Epic:** Categories & Priority Levels · **Estimate:** 5 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Create, rename, reorder, and delete priority levels; the order defines rank for the next-task algorithm.
|
|
|
| ## Requirements implemented
|
| - **FR-017** — The system shall allow students to define their own priority levels.
|
|
|
| ## Implementation notes
|
| - Block deleting a level that tasks still use, or reassign those tasks first.
|
| - Seed defaults: High / Medium / Low.
|
|
|
| ## Acceptance criteria
|
| - [ ] Levels can be added, renamed, reordered, and deleted
|
| - [ ] Ranking uses the new order immediately
|
|
|
| ## Estimate
|
| **5 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 5h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 5.2 User-defined task categories
|
|
|
| **Project:** Task manager project · **Epic:** Categories & Priority Levels · **Estimate:** 4 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Create, rename, and delete categories instead of a fixed list of task types.
|
|
|
| ## Requirements implemented
|
| - **FR-015** — The system shall allow students to define their own task categories instead of a fixed list of types.
|
|
|
| ## Implementation notes
|
| - Seed defaults: Homework, Quiz, Test, Project, Reminder.
|
|
|
| ## Acceptance criteria
|
| - [ ] Categories can be added, renamed, and deleted
|
| - [ ] Tasks show their category name
|
|
|
| ## Estimate
|
| **4 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 4h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 5.3 Category default priority with per-task override
|
|
|
| **Project:** Task manager project · **Epic:** Categories & Priority Levels · **Estimate:** 3 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Each category may carry a default priority applied to new tasks; any task can override it.
|
|
|
| ## Requirements implemented
|
| - **FR-016** — The system shall allow a category to have a default priority, which the student can override on any task.
|
|
|
| ## Acceptance criteria
|
| - [ ] New task inherits its category's default
|
| - [ ] Override persists after save/load
|
|
|
| ## Estimate
|
| **3 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 3h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ---
|
|
|
| ## Epic 6: Task Views & Display
|
|
|
| **Labels:** `epic::views`
|
|
|
| **Description:**
|
|
|
| ~~~markdown
|
| ## Overview
|
| All read-only presentation: task detail, the current/completed/all lists, visibility toggles, consistent formatting, and the remaining-work total.
|
|
|
| ## Scope
|
| - Detail view
|
| - Three lists
|
| - Show/hide completed and deleted
|
| - Consistent row format
|
| - Empty-list messages
|
| - Remaining work
|
|
|
| ## Requirements covered
|
| FR-008, FR-010, FR-019, FR-022, NFR-007, NFR-016, NFR-020
|
|
|
| ## Work breakdown
|
| | Issue | Requirements | Man-hours |
|
| |---|---|---|
|
| | Consistent task row formatter | NFR-016 | 3 |
|
| | Single-task detail view | FR-008 | 2 |
|
| | Current, completed, and all-task lists | FR-008, FR-019, NFR-007 | 4 |
|
| | Show/hide completed and deleted tasks | FR-008, FR-022 | 3 |
|
| | Empty-list messages | NFR-020 | 1 |
|
| | Remaining-work total | FR-010 | 2 |
|
| | **Total** | | **15** |
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
| ~~~
|
|
|
| ### 6.1 Consistent task row formatter
|
|
|
| **Project:** Task manager project · **Epic:** Task Views & Display · **Estimate:** 3 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| One function that prints a task row with name, category, due date, status, priority, and estimated time in fixed-width columns.
|
|
|
| ## Requirements implemented
|
| - **NFR-016** — The system shall display tasks in a consistent format, showing each task name, type, due date, status, priority, and estimated time.
|
|
|
| ## Implementation notes
|
| - Every list view uses this function.
|
|
|
| ## Acceptance criteria
|
| - [ ] All lists share identical columns
|
| - [ ] Long names are truncated cleanly
|
|
|
| ## Estimate
|
| **3 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 3h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 6.2 Single-task detail view
|
|
|
| **Project:** Task manager project · **Epic:** Task Views & Display · **Estimate:** 2 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Show every field of one selected task.
|
|
|
| ## Requirements implemented
|
| - **FR-008** — The system shall show all fields of one task and list all tasks, with options to show or hide completed and hidden tasks, plus a separate completed list.
|
|
|
| ## Acceptance criteria
|
| - [ ] All fields, including completed-at, are shown
|
|
|
| ## Estimate
|
| **2 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 2h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 6.3 Current, completed, and all-task lists
|
|
|
| **Project:** Task manager project · **Epic:** Task Views & Display · **Estimate:** 4 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Three list commands: current (incomplete), completed, and all.
|
|
|
| ## Requirements implemented
|
| - **FR-008** — The system shall show all fields of one task and list all tasks, with options to show or hide completed and hidden tasks, plus a separate completed list.
|
| - **FR-019** — The system shall allow students to view three lists: current (incomplete) tasks, completed tasks, and all tasks.
|
| - **NFR-007** — The system shall remain responsive while displaying or updating the student’s tasks.
|
|
|
| ## Acceptance criteria
|
| - [ ] Each list shows the correct subset
|
| - [ ] Lists render instantly with 1,000 tasks
|
|
|
| ## Estimate
|
| **4 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 4h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 6.4 Show/hide completed and deleted tasks
|
|
|
| **Project:** Task manager project · **Epic:** Task Views & Display · **Estimate:** 3 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Toggles controlling whether completed and soft-deleted tasks appear in the all-tasks list.
|
|
|
| ## Requirements implemented
|
| - **FR-008** — The system shall show all fields of one task and list all tasks, with options to show or hide completed and hidden tasks, plus a separate completed list.
|
| - **FR-022** — The system shall allow students to hide and unhide completed tasks.
|
|
|
| ## Implementation notes
|
| - Toggle state persists in settings.
|
|
|
| ## Acceptance criteria
|
| - [ ] Both toggles work independently
|
| - [ ] State survives a restart
|
|
|
| ## Estimate
|
| **3 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 3h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 6.5 Empty-list messages
|
|
|
| **Project:** Task manager project · **Epic:** Task Views & Display · **Estimate:** 1 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Print a friendly message (e.g. "No completed tasks yet.") instead of an empty table.
|
|
|
| ## Requirements implemented
|
| - **NFR-020** — The system shall display a message instead of an empty list when there are no tasks to show.
|
|
|
| ## Acceptance criteria
|
| - [ ] Every list view has an empty-state message
|
|
|
| ## Estimate
|
| **1 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 1h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 6.6 Remaining-work total
|
|
|
| **Project:** Task manager project · **Epic:** Task Views & Display · **Estimate:** 2 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Sum the estimated time of all incomplete, non-deleted tasks and display it in hours and minutes.
|
|
|
| ## Requirements implemented
|
| - **FR-010** — The system shall total the estimated time of uncompleted tasks (remaining work).
|
|
|
| ## Acceptance criteria
|
| - [ ] Total excludes completed and deleted tasks
|
| - [ ] Total updates after every change
|
|
|
| ## Estimate
|
| **2 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 2h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ---
|
|
|
| ## Epic 7: Prioritization & Alerts
|
|
|
| **Labels:** `epic::prioritization`
|
|
|
| **Description:**
|
|
|
| ~~~markdown
|
| ## Overview
|
| The next-task recommendation algorithm, overdue handling, and due-soon/overdue alerts shown without any background process.
|
|
|
| ## Scope
|
| - Ranking comparator
|
| - Overdue labeling
|
| - Alert banner
|
| - Main-screen summary
|
|
|
| ## Requirements covered
|
| FR-009, FR-010, FR-011, FR-025, FR-026, FR-027, NFR-018
|
|
|
| ## Work breakdown
|
| | Issue | Requirements | Man-hours |
|
| |---|---|---|
|
| | Next-task ranking algorithm | FR-009, FR-025, FR-026 | 6 |
|
| | Ranking algorithm test cases | FR-025, FR-026 | 3 |
|
| | Overdue label | FR-027 | 1 |
|
| | Due-soon and overdue alert banner | FR-011 | 4 |
|
| | Main-screen next task and remaining-time summary | NFR-018, FR-010 | 2 |
|
| | **Total** | | **16** |
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
| ~~~
|
|
|
| ### 7.1 Next-task ranking algorithm
|
|
|
| **Project:** Task manager project · **Epic:** Prioritization & Alerts · **Estimate:** 6 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Comparator for `qsort`: overdue first, then earliest due date/time, then student priority rank, with estimated time as a slight adjustment.
|
|
|
| ## Requirements implemented
|
| - **FR-009** — The system shall indicate the next task to work on through an algorithm defining order of importance.
|
| - **FR-025** — The system shall indicate which task the student should work on next, ranked by: (1) due date and time first, (2) the student’s priority level, (3) estimated completion time as a slight adjustment.
|
| - **FR-026** — The system shall rank overdue tasks at the top of the list when choosing the next task.
|
|
|
| ## Implementation notes
|
| - Tie-break on estimate (shorter first) only when due date and priority are equal.
|
| - Handling of 0-hour reminder tasks follows the Part 4A answer.
|
|
|
| ## Acceptance criteria
|
| - [ ] Documented rule set in code comments
|
| - [ ] Recommended task matches the hand-ranked expected order in test cases
|
|
|
| ## Estimate
|
| **6 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 6h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 7.2 Ranking algorithm test cases
|
|
|
| **Project:** Task manager project · **Epic:** Prioritization & Alerts · **Estimate:** 3 h · **Labels:** `type::testing`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Table-driven tests covering overdue, same-due-date, priority ties, and zero-estimate tasks.
|
|
|
| ## Requirements implemented
|
| - **FR-025** — The system shall indicate which task the student should work on next, ranked by: (1) due date and time first, (2) the student’s priority level, (3) estimated completion time as a slight adjustment.
|
| - **FR-026** — The system shall rank overdue tasks at the top of the list when choosing the next task.
|
|
|
| ## Acceptance criteria
|
| - [ ] At least 10 cases pass
|
| - [ ] Tests run from the build script
|
|
|
| ## Estimate
|
| **3 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 3h
|
| /label ~"type::testing"
|
| ~~~
|
|
|
| ### 7.3 Overdue label
|
|
|
| **Project:** Task manager project · **Epic:** Prioritization & Alerts · **Estimate:** 1 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Mark overdue incomplete tasks with a visible `[OVERDUE]` tag in every list.
|
|
|
| ## Requirements implemented
|
| - **FR-027** — The system shall mark overdue tasks with a visible label.
|
|
|
| ## Acceptance criteria
|
| - [ ] Tag appears on every overdue incomplete task and on no others
|
|
|
| ## Estimate
|
| **1 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 1h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 7.4 Due-soon and overdue alert banner
|
|
|
| **Project:** Task manager project · **Epic:** Prioritization & Alerts · **Estimate:** 4 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Check due dates at startup and after every command, and print a short alert banner. No background thread or service.
|
|
|
| ## Requirements implemented
|
| - **FR-011** — The system shall show due-soon and overdue alerts at startup and with each command output with no background process.
|
|
|
| ## Implementation notes
|
| - Due-soon window: 48 h (make it a constant).
|
|
|
| ## Acceptance criteria
|
| - [ ] Banner appears at launch and after each command when applicable
|
| - [ ] No banner when nothing is due
|
|
|
| ## Estimate
|
| **4 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 4h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 7.5 Main-screen next task and remaining-time summary
|
|
|
| **Project:** Task manager project · **Epic:** Prioritization & Alerts · **Estimate:** 2 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Show the recommended next task and the total remaining estimated time above the menu.
|
|
|
| ## Requirements implemented
|
| - **NFR-018** — The system shall show the recommended next task and the total estimated time.
|
| - **FR-010** — The system shall total the estimated time of uncompleted tasks (remaining work).
|
|
|
| ## Acceptance criteria
|
| - [ ] Summary refreshes after every command
|
|
|
| ## Estimate
|
| **2 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 2h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ---
|
|
|
| ## Epic 8: Console Interface & Input Validation
|
|
|
| **Labels:** `epic::interface`
|
|
|
| **Description:**
|
|
|
| ~~~markdown
|
| ## Overview
|
| Menu-driven console interface, customizable menu, and the shared input-validation layer.
|
|
|
| ## Scope
|
| - Menu loop and dispatch
|
| - Customizable menu
|
| - Validated input helpers
|
|
|
| ## Requirements covered
|
| FR-012, FR-031, NFR-004, NFR-005, NFR-015
|
|
|
| ## Work breakdown
|
| | Issue | Requirements | Man-hours |
|
| |---|---|---|
|
| | Main menu loop and command dispatch | FR-031, NFR-015 | 4 |
|
| | Customizable menu | NFR-005 | 5 |
|
| | Validated input helpers with re-prompt | FR-012, NFR-004 | 6 |
|
| | **Total** | | **15** |
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
| ~~~
|
|
|
| ### 8.1 Main menu loop and command dispatch
|
|
|
| **Project:** Task manager project · **Epic:** Console Interface & Input Validation · **Estimate:** 4 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Console main loop that prints the header, alerts, summary, and menu, then dispatches the selected command.
|
|
|
| ## Requirements implemented
|
| - **FR-031** — The system shall present a menu of available actions.
|
| - **NFR-015** — The system shall have a console-based interface.
|
|
|
| ## Implementation notes
|
| - Table of `{label, handler}` entries so the menu can be customized.
|
|
|
| ## Acceptance criteria
|
| - [ ] Every feature is reachable from the menu
|
| - [ ] Clean exit saves data
|
|
|
| ## Estimate
|
| **4 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 4h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 8.2 Customizable menu
|
|
|
| **Project:** Task manager project · **Epic:** Console Interface & Input Validation · **Estimate:** 5 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Let the student reorder and hide menu items. The layout persists in settings, and a reset option restores defaults.
|
|
|
| ## Requirements implemented
|
| - **NFR-005** — The system shall have a customizable menu.
|
|
|
| ## Implementation notes
|
| - Settings and Exit can never be hidden.
|
|
|
| ## Acceptance criteria
|
| - [ ] Reordered menu persists after restart
|
| - [ ] Reset restores defaults
|
|
|
| ## Estimate
|
| **5 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 5h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 8.3 Validated input helpers with re-prompt
|
|
|
| **Project:** Task manager project · **Epic:** Console Interface & Input Validation · **Estimate:** 6 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Reusable readers for integers in range, non-empty strings, menu choices, yes/no, and Central Time dates, each printing a clear error and re-prompting.
|
|
|
| ## Requirements implemented
|
| - **FR-012** — The system shall validate all inputs.
|
| - **NFR-004** — The system shall display a clear error message and re-prompt when input is invalid.
|
|
|
| ## Implementation notes
|
| - Read whole lines with `fgets` and parse them; never use bare `scanf`.
|
| - Handle EOF gracefully.
|
|
|
| ## Acceptance criteria
|
| - [ ] Garbage, empty, and out-of-range input re-prompts with a specific message
|
| - [ ] No input can crash the program
|
|
|
| ## Estimate
|
| **6 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 6h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ---
|
|
|
| ## Epic 9: Semester Lifecycle
|
|
|
| **Labels:** `epic::semester`
|
|
|
| **Description:**
|
|
|
| ~~~markdown
|
| ## Overview
|
| End-of-course archiving so the next launch starts a fresh semester.
|
|
|
| ## Scope
|
| - Complete-course archive
|
| - Carry-over decision
|
|
|
| ## Requirements covered
|
| FR-015, FR-017, FR-021, FR-028
|
|
|
| ## Work breakdown
|
| | Issue | Requirements | Man-hours |
|
| |---|---|---|
|
| | Complete course: archive the semester data file | FR-028, FR-021 | 4 |
|
| | Carry over categories and priority levels to the new semester | FR-015, FR-017, FR-028 | 3 |
|
| | **Total** | | **7** |
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
| ~~~
|
|
|
| ### 9.1 Complete course: archive the semester data file
|
|
|
| **Project:** Task manager project · **Epic:** Semester Lifecycle · **Estimate:** 4 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| The "Complete course" command, after confirmation, renames the data file to a dated archive; the next launch runs the setup wizard.
|
|
|
| ## Requirements implemented
|
| - **FR-028** — The system shall provide a “complete course” option that archives the semester’s file, so the next launch starts a new semester.
|
| - **FR-021** — The system shall ensure that a task is only completed by an explicit student action; it is never auto-completed or auto-deleted.
|
|
|
| ## Implementation notes
|
| - Archive name: `tasks_<course>_<YYYY-MM-DD>.dat`.
|
| - Tasks are archived as-is, never auto-completed.
|
|
|
| ## Acceptance criteria
|
| - [ ] Archive file exists and is loadable
|
| - [ ] Next launch starts a new semester
|
|
|
| ## Estimate
|
| **4 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 4h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ### 9.2 Carry over categories and priority levels to the new semester
|
|
|
| **Project:** Task manager project · **Epic:** Semester Lifecycle · **Estimate:** 3 h · **Labels:** `type::feature`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Depending on the Part 4A answer, offer to copy categories and priority levels into the new semester's file.
|
|
|
| ## Requirements implemented
|
| - **FR-015** — The system shall allow students to define their own task categories instead of a fixed list of types.
|
| - **FR-017** — The system shall allow students to define their own priority levels.
|
| - **FR-028** — The system shall provide a “complete course” option that archives the semester’s file, so the next launch starts a new semester.
|
|
|
| ## Implementation notes
|
| - Blocked by the Part 4A validation issue.
|
|
|
| ## Acceptance criteria
|
| - [ ] Behavior matches the stakeholder answer
|
|
|
| ## Estimate
|
| **3 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 3h
|
| /label ~"type::feature"
|
| ~~~
|
|
|
| ---
|
|
|
| ## Epic 10: Build, Quality & Maintainability
|
|
|
| **Labels:** `epic::quality`
|
|
|
| **Description:**
|
|
|
| ~~~markdown
|
| ## Overview
|
| Build tooling, coding standards, CI, performance verification, and acceptance testing across all requirements.
|
|
|
| ## Scope
|
| - GCC build for the Windows lab machines
|
| - Coding standards and reviews
|
| - CI warning gate
|
| - Performance and acceptance testing
|
| - User documentation
|
|
|
| ## Requirements covered
|
| NFR-001, NFR-002, NFR-003, NFR-006, NFR-007, NFR-008, NFR-009, NFR-010, NFR-012, NFR-013, NFR-014
|
|
|
| ## Work breakdown
|
| | Issue | Requirements | Man-hours |
|
| |---|---|---|
|
| | Project skeleton and GCC build script | NFR-010, NFR-014 | 4 |
|
| | Coding standards: naming and function comments | NFR-012, NFR-013 | 3 |
|
| | GitLab CI warning gate | NFR-014 | 3 |
|
| | Performance verification | NFR-006, NFR-007, NFR-008 | 3 |
|
| | Acceptance test plan and execution | NFR-001, NFR-002, NFR-003, NFR-009, NFR-010 | 10 |
|
| | README and user guide | NFR-012 | 4 |
|
| | **Total** | | **27** |
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
| ~~~
|
|
|
| ### 10.1 Project skeleton and GCC build script
|
|
|
| **Project:** Task manager project · **Epic:** Build, Quality & Maintainability · **Estimate:** 4 h · **Labels:** `type::infrastructure`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Module layout (`main.c`, `task.c`, `storage.c`, `ui.c`, `timeutil.c`, `rank.c`) plus a Makefile/batch script building with MinGW GCC on the Windows lab machines.
|
|
|
| ## Requirements implemented
|
| - **NFR-010** — The system shall be a console-based C application that runs on the Windows lab computers and compiles with GCC.
|
| - **NFR-014** — The system shall compile with no warnings using the -Wall and –Wextra compiler flags.
|
|
|
| ## Implementation notes
|
| - Flags: `-std=c11 -Wall -Wextra`.
|
|
|
| ## Acceptance criteria
|
| - [ ] Builds from a clean checkout on a lab machine with one command
|
|
|
| ## Estimate
|
| **4 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 4h
|
| /label ~"type::infrastructure"
|
| ~~~
|
|
|
| ### 10.2 Coding standards: naming and function comments
|
|
|
| **Project:** Task manager project · **Epic:** Build, Quality & Maintainability · **Estimate:** 3 h · **Labels:** `type::documentation`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Write CONTRIBUTING.md (naming conventions, purpose comment required on every function) and a merge-request review checklist.
|
|
|
| ## Requirements implemented
|
| - **NFR-012** — The system shall use meaningful names for variables and functions, so the source code can be understood by another developer.
|
| - **NFR-013** — The system shall include a comment for every function stating its purpose.
|
|
|
| ## Acceptance criteria
|
| - [ ] Standards document merged
|
| - [ ] MR template includes the checklist
|
|
|
| ## Estimate
|
| **3 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 3h
|
| /label ~"type::documentation"
|
| ~~~
|
|
|
| ### 10.3 GitLab CI warning gate
|
|
|
| **Project:** Task manager project · **Epic:** Build, Quality & Maintainability · **Estimate:** 3 h · **Labels:** `type::infrastructure`
|
|
|
| ~~~markdown
|
| ## Summary
|
| CI job that compiles with `-Wall -Wextra -Werror` and runs the unit tests on every merge request.
|
|
|
| ## Requirements implemented
|
| - **NFR-014** — The system shall compile with no warnings using the -Wall and –Wextra compiler flags.
|
|
|
| ## Acceptance criteria
|
| - [ ] MR pipeline fails on any warning
|
| - [ ] Pipeline passes on main
|
|
|
| ## Estimate
|
| **3 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 3h
|
| /label ~"type::infrastructure"
|
| ~~~
|
|
|
| ### 10.4 Performance verification
|
|
|
| **Project:** Task manager project · **Epic:** Build, Quality & Maintainability · **Estimate:** 3 h · **Labels:** `type::testing`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Generate a 1,000-task data file and time startup, list rendering, and save.
|
|
|
| ## Requirements implemented
|
| - **NFR-006** — The system shall launch without a noticeable delay.
|
| - **NFR-007** — The system shall remain responsive while displaying or updating the student’s tasks.
|
| - **NFR-008** — The system shall save changes to the data file within one second after a task is created, updated, or deleted.
|
|
|
| ## Acceptance criteria
|
| - [ ] Startup under 1 s
|
| - [ ] Save within 1 s of a change
|
| - [ ] Results recorded in the issue
|
|
|
| ## Estimate
|
| **3 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 3h
|
| /label ~"type::testing"
|
| ~~~
|
|
|
| ### 10.5 Acceptance test plan and execution
|
|
|
| **Project:** Task manager project · **Epic:** Build, Quality & Maintainability · **Estimate:** 10 h · **Labels:** `type::testing`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Write one test case per FR/NFR and run the full suite on a lab machine, offline. Estimate covers 2 people x 5 h.
|
|
|
| ## Requirements implemented
|
| - **NFR-001** — The system shall not lose any previously saved tasks if the program terminates unexpectedly.
|
| - **NFR-002** — The system shall recover from a failed save and tell the user what happened.
|
| - **NFR-003** — The system shall allow the user to add a new task in no more than three menu selections/prompts.
|
| - **NFR-009** — The system shall not require an internet connection to create, update, or view tasks.
|
| - **NFR-010** — The system shall be a console-based C application that runs on the Windows lab computers and compiles with GCC.
|
|
|
| ## Implementation notes
|
| - Includes forced-kill crash test (NFR-001) and network-disabled run (NFR-009).
|
|
|
| ## Acceptance criteria
|
| - [ ] Every requirement ID has a test case
|
| - [ ] All core tests pass
|
| - [ ] Results attached
|
|
|
| ## Estimate
|
| **10 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 10h
|
| /label ~"type::testing"
|
| ~~~
|
|
|
| ### 10.6 README and user guide
|
|
|
| **Project:** Task manager project · **Epic:** Build, Quality & Maintainability · **Estimate:** 4 h · **Labels:** `type::documentation`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Build instructions, data file location and format, and a walkthrough of every menu command.
|
|
|
| ## Requirements implemented
|
| - **NFR-012** — The system shall use meaningful names for variables and functions, so the source code can be understood by another developer.
|
|
|
| ## Acceptance criteria
|
| - [ ] New team member can build and use the app from the README alone
|
|
|
| ## Estimate
|
| **4 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 4h
|
| /label ~"type::documentation"
|
| ~~~
|
|
|
| ---
|
|
|
| ## Epic 11: Optional Enhancements
|
|
|
| **Labels:** `epic::optional`, `optional`
|
|
|
| **Description:**
|
|
|
| ~~~markdown
|
| ## Overview
|
| Optional requirements FR-032 to FR-037. These are scheduled only after all core epics are complete.
|
|
|
| ## Scope
|
| - Sort/filter
|
| - Completed-work summary
|
| - Actual time logging
|
| - Latest-start warning
|
| - Subtasks
|
| - Recurring entries
|
|
|
| ## Requirements covered
|
| FR-032, FR-033, FR-034, FR-035, FR-036, FR-037
|
|
|
| ## Work breakdown
|
| | Issue | Requirements | Man-hours |
|
| |---|---|---|
|
| | Sort and filter by category, priority, and status | FR-032 | 5 |
|
| | Completed-work summary | FR-033 | 2 |
|
| | Log actual time spent against the estimate | FR-034 | 4 |
|
| | Latest-start-time warning | FR-035 | 2 |
|
| | Subtasks and phases via task links | FR-036 | 6 |
|
| | Mass and recurring task entry | FR-037 | 6 |
|
| | **Total** | | **25** |
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
| ~~~
|
|
|
| ### 11.1 Sort and filter by category, priority, and status
|
|
|
| **Project:** Task manager project · **Epic:** Optional Enhancements · **Estimate:** 5 h · **Labels:** `type::feature`, `optional`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Sort and filter options on the list views.
|
|
|
| ## Requirements implemented
|
| - **FR-032** — The system shall allow students to sort or filter tasks by category, priority, and status.
|
|
|
| ## Acceptance criteria
|
| - [ ] Filters combine
|
| - [ ] Sort is stable
|
|
|
| ## Estimate
|
| **5 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 5h
|
| /label ~"type::feature" ~"optional"
|
| ~~~
|
|
|
| ### 11.2 Completed-work summary
|
|
|
| **Project:** Task manager project · **Epic:** Optional Enhancements · **Estimate:** 2 h · **Labels:** `type::feature`, `optional`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Show the count and total estimated hours of completed tasks.
|
|
|
| ## Requirements implemented
|
| - **FR-033** — The system shall show how much work the student has already completed.
|
|
|
| ## Acceptance criteria
|
| - [ ] Summary matches the completed list
|
|
|
| ## Estimate
|
| **2 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 2h
|
| /label ~"type::feature" ~"optional"
|
| ~~~
|
|
|
| ### 11.3 Log actual time spent against the estimate
|
|
|
| **Project:** Task manager project · **Epic:** Optional Enhancements · **Estimate:** 4 h · **Labels:** `type::feature`, `optional`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Add time-spent entries per task and show the remaining time versus the estimate.
|
|
|
| ## Requirements implemented
|
| - **FR-034** — The system shall allow students to log actual time spent on a task and show the time remaining against the estimate.
|
|
|
| ## Acceptance criteria
|
| - [ ] Over-estimate shown as negative remaining
|
|
|
| ## Estimate
|
| **4 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 4h
|
| /label ~"type::feature" ~"optional"
|
| ~~~
|
|
|
| ### 11.4 Latest-start-time warning
|
|
|
| **Project:** Task manager project · **Epic:** Optional Enhancements · **Estimate:** 2 h · **Labels:** `type::feature`, `optional`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Warn when now is later than the due time minus the estimated time for an incomplete task.
|
|
|
| ## Requirements implemented
|
| - **FR-035** — The system shall warn the student when the latest start time for a task has passed (due time minus estimated time).
|
|
|
| ## Acceptance criteria
|
| - [ ] Warning appears in the alert banner
|
|
|
| ## Estimate
|
| **2 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 2h
|
| /label ~"type::feature" ~"optional"
|
| ~~~
|
|
|
| ### 11.5 Subtasks and phases via task links
|
|
|
| **Project:** Task manager project · **Epic:** Optional Enhancements · **Estimate:** 6 h · **Labels:** `type::feature`, `optional`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Link a task to a parent task and show children indented under the parent.
|
|
|
| ## Requirements implemented
|
| - **FR-036** — The system shall support phases or subtasks by linking one task to another.
|
|
|
| ## Implementation notes
|
| - Prevent cycles.
|
|
|
| ## Acceptance criteria
|
| - [ ] Parent shows child progress
|
|
|
| ## Estimate
|
| **6 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 6h
|
| /label ~"type::feature" ~"optional"
|
| ~~~
|
|
|
| ### 11.6 Mass and recurring task entry
|
|
|
| **Project:** Task manager project · **Epic:** Optional Enhancements · **Estimate:** 6 h · **Labels:** `type::feature`, `optional`
|
|
|
| ~~~markdown
|
| ## Summary
|
| Create N tasks on a weekly or daily pattern (e.g. every Monday for 3 weeks).
|
|
|
| ## Requirements implemented
|
| - **FR-037** — The system shall support mass or recurring entries (for example, every Monday for three weeks).
|
|
|
| ## Acceptance criteria
|
| - [ ] Generated due dates are correct across DST
|
|
|
| ## Estimate
|
| **6 man-hours** (total across everyone working on it; 2 people x 1 h = 2 h).
|
|
|
| ---
|
| Source: *PCC Task Manager - System Specifications - Team 5.docx*
|
|
|
| /estimate 6h
|
| /label ~"type::feature" ~"optional"
|
| ~~~
|