Masterarbeit/Ergebnisse/Ergebnisse 03/NEXUS_DOCUMENTATION/NEW_DISCOVERED_USECASES_FROM_SCREENSHOTS.md

New Use-Cases Discovered from Screenshots - CentronNexus Live Analysis

Date: 2025-11-24 Source: Live screenshot analysis from 5 authenticated CentronNexus modules Backend: https://erp.c-entron.de/demo Data Samples Analyzed: 10+ customers, 7+ tickets, comprehensive UI patterns

---

Overview

This document details 9 new sub-use-cases discovered through visual analysis of authenticated screenshots from CentronNexus. Each use-case extends existing documented functionality with specific features and workflows that were not explicitly documented in the main USE_CASES.md file.

---

TICKET MANAGEMENT ENHANCEMENTS

UC-3.2.1: Advanced Ticket Filtering with Dual-Tier System

Use Case Details

ID: 3.2.1 Category: Ticket Management Base UseCase: 3.2 Ticket-Liste Complexity: Medium Priority: High

Description

Users can apply multiple filter criteria using a dual-tier filtering system:

• "Nur" (Only): Positive filters - show tickets matching these criteria
• "Auch" (Also): Inclusive filters - additionally include tickets matching these criteria

This allows complex filtering like: "Show open high-priority tickets AND also show all tickets from customer X" or "Show my assigned tickets BUT exclude test tickets."

Business Value

• Faster ticket discovery for specific scenarios
• Reduced need for multiple searches
• Support for complex reporting queries
• Improves productivity for technicians switching between ticket subsets

User Roles

• Primary: Technicians, Support Agents
• Secondary: Team Leads, Managers
• Tertiary: Customers (if enabled)

Actors

1. Technician/Support Agent
   - Can apply multiple filters
   - Can combine "Nur" and "Auch" filters
   - Can save filter combinations

2. System
   - Evaluates filter combinations
   - Returns matching ticket set
   - Persists filter preferences

Preconditions

• User is authenticated
• User has Ticket-Liste access rights
• At least 2 filter criteria are available

Main Flow

1. User navigates to Ticket-Liste
2. User opens filter panel
3. User selects "Nur" (Only) filters:
   - Status: "offen" (Open)
   - Priority: "hoch" (High)
4. User selects "Auch" (Also) filters:
   - Category: "Test"
5. System applies both filter sets
6. System displays combined results
7. User can save this filter combination for future use

Alternate Flows

AF1: Clear and Reset Filters

1. User clicks filter reset button
2. System clears all "Nur" and "Auch" selections
3. System displays all tickets (with standard defaults)

AF2: Save Filter Combination

1. User applies "Nur" and "Auch" filters
2. User clicks "speichern" (Save)
3. System prompts for filter name
4. System saves combination to user preferences
5. Combination appears in sidebar for quick access

AF3: Load Saved Filter

1. User sees saved filter in sidebar
2. User clicks saved filter name
3. System applies all associated filter criteria
4. System displays filtered ticket set

Postconditions

• Filtered ticket list is displayed
• All matching tickets are visible
• Filter state is preserved for session
• Optionally saved for future use

Data Requirements

Input:

• Filter criteria selections
• Filter combination logic (AND/OR)
• User preferences storage

Output:

• Filtered ticket dataset
• Count of matching tickets
• Applied filter summary

UI Elements Involved

• Sidebar filter categories
• Toggle switches for "Nur"/"Auch"
• Checkboxes for filter values
• Save button
• Filter reset button
• Applied filters indicator

Technical Considerations

Backend Requirements:

• Dynamic query building from filter combinations
• Efficient filtering on large ticket sets
• Filter preference persistence (user settings)
• Real-time result count updates

Performance:

• Client-side: Filter UI response < 100ms
• Server-side: Query execution < 500ms for 10,000 tickets
• Cache saved filter combinations

Edge Cases

• User selects conflicting "Nur"/"Auch" criteria (e.g., "Nur: open" and "Auch: closed")
  • Resolution: System treats as union of both sets
• Very large result sets (10,000+ tickets)
  • Resolution: Implement pagination/virtual scrolling
• Empty result sets
  • Resolution: Show "No tickets match filters" message

Related Use Cases

• 3.2 Ticket-Liste (parent)
• 3.2.3 Ticket Search (search within filters)
• 3.1 Ticket-Details (drill down from filtered list)

Testing Scenarios

1. T1: Apply single "Nur" filter - verify results show only matching tickets
2. T2: Apply both "Nur" and "Auch" filters - verify combined results
3. T3: Save filter combination - verify retrieval and re-application
4. T4: Clear filters - verify all tickets display
5. T5: Apply conflicting filters - verify system behavior
6. T6: Search within filtered set - verify interaction
7. T7: Change sort order on filtered set - verify independence

---

UC-3.2.2: Ticket List Customization and Layout Persistence

Use Case Details

ID: 3.2.2 Category: Ticket Management Base UseCase: 3.2 Ticket-Liste Complexity: Medium Priority: Medium

Description

Users can customize which columns are displayed in the ticket list table and save these layout preferences. This allows each user to have a personalized view focused on the data most relevant to their role.

Business Value

• Reduced cognitive load by showing only relevant columns
• Role-specific views (e.g., technician vs manager)
• Faster data scanning with relevant information visible
• Professional appearance with clean, focused interface

User Roles

• Primary: All ticket list users (Technicians, Support Agents, Managers, Customers)
• Secondary: Admin users (setting default layouts)

Actors

1. User
   - Can select/deselect columns
   - Can reorder columns
   - Can resize columns
   - Can save layout
   - Can load saved layouts

2. System
   - Persists layout preferences
   - Applies layout on page load
   - Maintains column metadata

Preconditions

• User is viewing Ticket-Liste
• At least 1 column must remain visible

Main Flow

1. User clicks "Layout" or "View Options" button
2. System shows column selection dialog/panel
3. User checks/unchecks columns to customize view:
   - Toggle "Kundennummer" (Customer Number)
   - Toggle "Erstellt am" (Created Date)
   - Toggle "Fällig z..." (Due Date)
   - Others as applicable
4. User can drag columns to reorder (optional)
5. User clicks "speichern" (Save) button
6. System persists layout to user preferences
7. Layout is applied immediately
8. Layout persists across sessions

Alternate Flows

AF1: Reset to Default Layout

1. User clicks "Reset Layout" button
2. System shows confirmation dialog
3. User confirms reset
4. System restores default column set
5. System applies default layout

AF2: Multiple Saved Layouts

1. User creates layout "Technical View" (tech-focused columns)
2. User creates layout "Manager View" (summary-focused columns)
3. User can switch between layouts quickly
4. System labels layouts with descriptive names

AF3: Export Current Layout

1. User right-clicks layout name
2. User selects "Export Settings"
3. System generates layout configuration file
4. User can share with team members

Postconditions

• Custom layout is displayed
• Layout is saved to user profile
• Layout persists across sessions
• Other users are not affected

Data Requirements

Input:

• Column visibility preferences
• Column order sequence
• Column width preferences
• Layout name (if saved multiple layouts)

Output:

• Customized ticket list display
• Saved layout configuration
• Layout switcher interface (if multiple layouts)

UI Elements Involved

• "Layout" or "View Options" button
• Column selection checklist
• Drag-and-drop column reordering
• Column width resize handles
• "speichern" (Save) button
• "Reset to Default" button
• Layout selector dropdown (if multiple layouts supported)

Technical Considerations

Backend Requirements:

• User preference storage (column visibility, order, width)
• Layout versioning (schema changes)
• Default layout management
• Performance impact on page load

Frontend:

• Column metadata storage
• Persistent table state
• Responsive column widths
• Column resize interactions

Performance:

• Layout retrieval on page load < 100ms
• Column reordering/resizing smooth at 60fps
• Storage: ~1KB per layout

Edge Cases

• User deletes all columns (prevented - at least 1 required)
• Screen resolution change (responsive columns)
• Table data changes (column headers update automatically)
• Columns added/removed by system update
  • Resolution: Auto-add new columns to default position, keep hidden if not in saved preference

Related Use Cases

• 3.2 Ticket-Liste (parent)
• 3.2.1 Advanced Ticket Filtering (works with layout)
• 3.2.3 Ticket Search (works with layout)

Testing Scenarios

1. T1: Select columns and save - verify retrieval
2. T2: Reorder columns - verify order persistence
3. T3: Resize columns - verify width persistence
4. T4: Reset to default - verify restoration
5. T5: Create multiple layouts - verify switching
6. T6: Login/logout - verify layout persistence
7. T7: Customize on different screen sizes - verify responsiveness

---

UC-3.2.3: Full-Text Ticket Search

Use Case Details

ID: 3.2.3 Category: Ticket Management Base UseCase: 3.2 Ticket-Liste Complexity: Low-Medium Priority: High

Description

Users can search for tickets using a full-text search field "In Liste suchen..." (Search in list) that searches across visible ticket fields in real-time, providing instant search results.

Business Value

• Fast ticket lookup without navigating multiple views
• Reduces time to find specific tickets
• Improves user satisfaction
• Alternative to filter-based search

User Roles

• Primary: All ticket list users
• Secondary: Customers (if enabled)

Actors

1. User
   - Types search query
   - Reviews search results
   - Clicks result to view ticket

2. System
   - Performs full-text search
   - Returns results in real-time
   - Highlights search terms

Preconditions

• User is viewing Ticket-Liste
• At least 1 ticket exists

Main Flow

1. User navigates to Ticket-Liste
2. User clicks search field "In Liste suchen..."
3. User types search query (e.g., "printer problem")
4. System filters tickets in real-time
5. System displays matching tickets below search field
6. System highlights search term in results
7. User clicks matching ticket from results
8. System navigates to ticket details

Alternate Flows

AF1: Search Within Filtered Results

1. User applies filters (e.g., "Open tickets only")
2. User types search query in search field
3. System searches only within filtered set
4. System displays matching tickets from filtered set

AF2: Clear Search

1. User clicks "X" button in search field
2. System clears search query
3. System returns to full ticket list (or filtered list if filters applied)

AF3: Search Suggestions

1. User starts typing search query
2. System shows auto-complete suggestions:
   - Recent searches
   - Popular search terms
   - Suggested ticket fields
3. User clicks suggestion
4. System performs search for suggested term

Postconditions

• Filtered list of matching tickets is displayed
• Search state is displayed (query visible in field)
• User can navigate to matching tickets

Data Requirements

Input:

• Search query string
• Current filter state (if applicable)
• Current column set (if applicable)

Output:

• Filtered ticket list
• Result count
• Highlighted matches
• Search result metadata

UI Elements Involved

• Search input field with placeholder "In Liste suchen..."
• Clear ("X") button
• Search result indicators
• Result counter ("5 tickets found")
• Highlighted search terms
• Search history (optional)

Technical Considerations

Search Scope:

• Ticket number
• Ticket title/subject
• Customer name
• Ticket description
• Tags/categories

Performance:

• Real-time search (< 200ms latency)
• Index-backed search for large ticket sets
• Client-side filtering for small datasets
• Debounce search input (wait 300ms after typing stops)

Edge Cases:

• Search query with special characters (escape/sanitize)
• Empty search query (show all results)
• Very broad search results (10,000+ matches)
  • Resolution: Show top 100, offer refining search
• Search query with wildcards or regex
  • Resolution: Support if backend allows, otherwise literal search

Related Use Cases

• 3.2 Ticket-Liste (parent)
• 3.2.1 Advanced Ticket Filtering (complementary)
• 3.2.2 Ticket List Customization (works with layout)

Testing Scenarios

1. T1: Search for partial ticket number - verify matching tickets
2. T2: Search for customer name - verify results
3. T3: Search with multiple keywords - verify "AND" logic
4. T4: Search within filtered results - verify scope
5. T5: Clear search - verify return to full list
6. T6: Search with special characters - verify handling
7. T7: Empty search field - verify all results

---

CUSTOMER MANAGEMENT ENHANCEMENTS

UC-8.1.1: Advanced Customer Search

Use Case Details

ID: 8.1.1 Category: Customer Management Base UseCase: 8.1 Kundendaten Complexity: Low-Medium Priority: High

Description

Users can search for customers using the "Kunden suchen..." (Customer search) field, which performs full-text search across customer data fields including company name, contact person, address, and phone number.

Business Value

• Rapid customer lookup
• Reduces time to find customer information
• Enables quick customer-related ticket creation
• Improves customer service response time

User Roles

• Primary: Support staff, Sales team, Admin
• Secondary: Technicians (for ticket assignment)

Actors

1. User
   - Enters search query
   - Reviews search results
   - Selects customer

2. System
   - Performs customer search
   - Returns matching customers
   - Highlights matches

Preconditions

• User has access to Kunden-Übersicht
• At least 1 customer record exists

Main Flow

1. User navigates to Kunden-Übersicht
2. User clicks search field "Kunden suchen..."
3. User types search query (e.g., "ABC GmbH" or "Werner")
4. System searches customer fields in real-time:
   - Firmenname (Company name)
   - Ansprechpartner (Contact person)
   - Straße (Street address)
   - Kundennummer (Customer number)
   - Telefon (Phone number)
5. System displays matching customers below search field
6. System highlights search term in results
7. User clicks matching customer
8. System displays customer details

Alternate Flows

AF1: Search by Phone Number

1. User types partial phone number (e.g., "28359")
2. System searches phone field
3. System returns matching customer
4. User selects customer

AF2: Search by Contact Person Name

1. User types contact person name (e.g., "Werner Brösel")
2. System searches "Ansprechpartner" field
3. System returns customers with matching contact
4. User selects customer

AF3: Search with Geographic Location

1. User types city name (e.g., "Bremen")
2. System searches Stadt (City) field
3. System returns customers in that city
4. User selects customer

Postconditions

• Matching customers are displayed
• User can select customer to view details
• Search state is preserved

Data Requirements

Input:

• Search query string
• Current filter state (active/inactive)

Output:

• Filtered customer list
• Result count
• Highlighted search terms

UI Elements Involved

• Search field "Kunden suchen..." with placeholder
• Clear button
• Search results display
• Result counter
• Highlighted search terms
• Customer link/selection

Technical Considerations

Search Scope:

• Company name (Firmenname)
• Contact person (Ansprechpartner)
• Street address (Straße)
• Postal code (PLZ)
• City (Stadt)
• Phone (Telefon)
• Customer number (Kundennummer)
• Matchcode

Performance:

• Real-time search (< 200ms)
• Index-backed search for large customer base
• Debounce: 300ms after typing stops
• Cache customer search results

Edge Cases:

• Duplicate customer entries
• Partial address matches
• Phone number formatting variations
• Empty search (show all active/inactive based on filter)

Related Use Cases

• 8.1 Kundendaten (parent)
• 8.1.2 Customer Status Management (works with status filter)
• 3.2 Ticket-Liste (linked when creating tickets)

Testing Scenarios

1. T1: Search by company name - verify exact/partial matches
2. T2: Search by contact person name - verify results
3. T3: Search by city/postal code - verify location search
4. T4: Search by phone number - verify number search
5. T5: Search returns multiple matches - verify sorting
6. T6: Search with special characters - verify handling
7. T7: Case-insensitive search - verify "ABC" matches "abc"

---

UC-8.1.2: Customer Status Management with Filtering

Use Case Details

ID: 8.1.2 Category: Customer Management Base UseCase: 8.1 Kundendaten Complexity: Low Priority: Medium

Description

Users can toggle between viewing active and inactive customers using the "aktive Kunden" (Active customers) filter switch. This allows management of customer lifecycle while preserving historical data through soft-delete patterns.

Business Value

• Manage customer lifecycle without data loss
• Separate active business from historical records
• Support dormant/inactive customer scenarios
• Compliance with data retention policies
• Flexible customer status management

User Roles

• Primary: Admin, Sales management
• Secondary: Support staff
• Tertiary: Technicians (read-only active customers)

Actors

1. User/Admin
   - Toggles active/inactive filter
   - Can mark customers as inactive
   - Can reactivate customers

2. System
   - Filters customer list by status
   - Manages customer status field
   - Logs status changes

Preconditions

• User has access to Kunden-Übersicht
• At least 1 active customer exists
• User has rights to change customer status

Main Flow

1. User navigates to Kunden-Übersicht
2. System displays active customers by default
3. Toggle "aktive Kunden" is ON (showing active)
4. User can toggle switch OFF to see inactive customers
5. System displays inactive customers instead
6. User can toggle back ON to see active customers again
7. User can toggle ON and OFF to compare lists

Alternate Flows

AF1: Deactivate a Customer

1. User right-clicks on active customer in list
2. User selects "Deactivate" from context menu
3. System prompts for confirmation
4. User confirms deactivation
5. System marks customer as inactive (IsDeleted = true)
6. Customer disappears from active list
7. Customer appears in inactive list (if viewing)
8. System logs deactivation event

AF2: Reactivate a Customer

1. User toggles to show inactive customers
2. User finds customer to reactivate
3. User right-clicks inactive customer
4. User selects "Reactivate" from context menu
5. System marks customer as active (IsDeleted = false)
6. Customer disappears from inactive list
7. Customer reappears in active list
8. System logs reactivation event

AF3: Show All Customers (Admin Only)

1. Admin has additional "Show Archived" toggle
2. Admin toggles to see all customers (active + inactive)
3. System displays complete customer history
4. Admin can query/report on all customers

Postconditions

• Filtered customer list is displayed
• Filter state is preserved for session
• Status changes are logged to audit trail

Data Requirements

Input:

• Customer status (active/inactive)
• Filter toggle state
• Status change timestamp
• User who made change

Output:

• Filtered customer list
• Status indicator
• Change history/audit trail

UI Elements Involved

• Toggle switch "aktive Kunden" (ON/OFF)
• Status indicator per customer row
• Context menu (deactivate/reactivate)
• Confirmation dialog
• Status history view (optional)

Technical Considerations

Database:

• Customer.IsDeleted field
• Customer.DeletedDate field
• Customer.DeletedByI3D field (audit trail)
• Status-based query filtering

Data Integrity:

• Cannot delete customer if active tickets exist
• Linked ticket data remains queryable
• Historical reports include all customers
• Soft-delete pattern (no physical deletion)

Performance:

• Separate indexes on Customer.IsDeleted
• Efficient status toggle queries
• Change logging doesn't block UI

Edge Cases:

• Customer has active tickets
  • Resolution: Prevent deactivation, show warning
• Reactivate customer with duplicate name
  • Resolution: Allow (different record)
• Mass deactivation scenario
  • Resolution: Bulk deactivation feature

Related Use Cases

• 8.1 Kundendaten (parent)
• 8.1.1 Advanced Customer Search (works with status)
• 3.2 Ticket-Liste (tickets link to customers)

Testing Scenarios

1. T1: Toggle "aktive Kunden" ON - verify active customers display
2. T2: Toggle "aktive Kunden" OFF - verify inactive customers display
3. T3: Deactivate active customer - verify disappears from active list
4. T4: Reactivate inactive customer - verify appears in active list
5. T5: Deactivate customer with active tickets - verify warning
6. T6: Status change is logged to audit trail
7. T7: Page refresh preserves filter state

---

UC-8.1.3: Contact Person Management and Tracking

Use Case Details

ID: 8.1.3 Category: Customer Management Base UseCase: 8.1 Kundendaten Complexity: Medium Priority: Medium

Description

The system tracks and manages primary contact persons ("Ansprechpartner") for each customer, enabling better communication routing and relationship management. Support staff can assign and modify contact information.

Business Value

• Ensures correct communication with appropriate decision-makers
• Improves ticket routing accuracy
• Tracks relationship changes
• Supports multi-level communication
• Enables relationship continuity

User Roles

• Primary: Sales, Account management, Support
• Secondary: Admin, Technicians

Actors

1. Account Manager
   - Views contact person for customer
   - Updates contact person information
   - Tracks contact person changes

2. Technician
   - Views assigned contact person
   - May suggest contact person updates

3. System
   - Stores contact person per customer
   - Logs contact person changes
   - Routes tickets to contact person

Preconditions

• User has access to customer record
• User has rights to modify customer data
• At least 1 customer exists

Main Flow

1. User opens customer details page
2. System displays "Ansprechpartner" (Contact Person) field
3. System shows current contact person information:
   - Name
   - Phone
   - Email (if available)
4. User can click to edit contact person
5. User selects from existing contacts or adds new
6. User saves changes
7. System updates contact person record
8. System logs change in audit trail
9. Future tickets from/to this customer route to new contact

Alternate Flows

AF1: Add Multiple Contact Persons

1. User clicks "Add Contact" button
2. System adds new contact person field
3. User enters second contact person details
4. System marks one as "Primary"
5. System saves multiple contacts
6. System allows routing to any contact

AF2: Contact Person History

1. User clicks "Contact History" button
2. System displays timeline of contact person changes:
   - Date, old contact, new contact, changed by
3. User can view historical routing
4. User can revert to previous contact if needed

AF3: Contact Person Search

1. User starts typing contact name
2. System shows suggestions from:
   - This customer's past contacts
   - Other customers' contacts
   - Company directory
3. User selects from suggestions
4. System auto-fills contact details

Postconditions

• Contact person is updated
• Change is logged to audit trail
• New contact appears in system
• Tickets route to new contact if configured

Data Requirements

Input:

• Contact person name (Ansprechpartner)
• Contact person phone
• Contact person email
• Primary/secondary designation

Output:

• Updated customer record
• Contact history audit trail
• Contact verification status

UI Elements Involved

• Contact person display field
• Edit contact button
• Contact name input field
• Phone field
• Email field
• Primary/secondary radio buttons
• Add contact button
• Contact history button
• Suggestions dropdown

Technical Considerations

Database Schema:

• Customer.PrimaryContactI3D (FK to Contact)
• Contact table with name, phone, email
• Contact history audit trail
• Support for multiple contacts per customer

Data Integrity:

• Validate phone number format
• Validate email format
• Track all contact changes
• Support contact person lookup

Performance:

• Contact information fetched with customer
• Contact history limited to recent changes
• Efficient contact search/suggestions

Edge Cases:

• Contact person leaves company
  • Resolution: Mark as inactive, assign new contact
• Same contact person at multiple customers
  • Resolution: Support multiple references to same person
• Contact person email/phone changes
  • Resolution: Update versioning and history
• Delete contact person record
  • Resolution: Soft delete, preserve history

Related Use Cases

• 8.1 Kundendaten (parent)
• 3.1 Ticket-Details (contact routing)
• 8.3 Kundendetails (extended contact management)

Testing Scenarios

1. T1: View contact person for customer - verify display
2. T2: Edit contact person - verify update
3. T3: Add multiple contact persons - verify storage
4. T4: View contact history - verify audit trail
5. T5: Revert to previous contact - verify functionality
6. T6: Search existing contacts - verify suggestions
7. T7: Validate contact information - verify validation rules

---

DAILY PLANNING ENHANCEMENTS

UC-6.2.1: Daily Task Management

Use Case Details

ID: 6.2.1 Category: Daily Planning Base UseCase: 6.2 Mein Tag (MyDay) Complexity: Medium Priority: High

Description

Users can view, create, and manage tasks scheduled specifically for today. The system provides a focused, today-scoped view of work activities separate from the general ticket list, enabling users to focus on immediate priorities.

Business Value

• Improved focus on immediate work priorities
• Reduced context switching between today's work and all tickets
• Better time management
• Daily planning capability
• Work tracking for the current day

User Roles

• Primary: All staff (Technicians, Support agents, Managers)
• Secondary: Customers (if enabled for ticketed items)

Actors

1. Employee/Technician
   - Views today's tasks
   - Marks tasks complete
   - Creates new tasks for today
   - Reorders task priority

2. Manager
   - Views team's daily tasks
   - Adjusts daily assignments

3. System
   - Generates daily task view
   - Filters tickets/tasks for today
   - Tracks completion status

Preconditions

• User is authenticated
• User has work assigned for today or previous days

Main Flow

1. User navigates to "Mein Tag" (My Day) view
2. System displays today's scheduled tasks
3. System shows tasks from:
   - Tickets assigned to user with today's due date
   - Scheduled time blocks/activities
   - Personal tasks/reminders
4. Each task shows:
   - Task name/description
   - Estimated duration
   - Priority level
   - Related ticket/customer
5. User can mark task complete
6. System updates task status
7. User can create new task for today
8. System adds task to today's list

Alternate Flows

AF1: Add Task to Today

1. User clicks "Add Task" button
2. System shows new task form
3. User enters task description
4. User sets estimated duration
5. User selects priority (low/medium/high)
6. User clicks save
7. System adds task to today's list

AF2: View Yesterday's Tasks

1. User clicks "Yesterday" navigation
2. System displays yesterday's completed/incomplete tasks
3. User can see what was accomplished
4. User can move incomplete tasks to today

AF3: Drag Tasks to Reorder Priority

1. User sees task list in priority order
2. User drags task to new position
3. System reorders tasks
4. System updates priority ranking
5. New order persists across sessions

Postconditions

• Today's task list is displayed
• Tasks can be marked complete
• Task state is persisted
• New tasks are added to list

Data Requirements

Input:

• User ID
• Current date
• Task completion status
• Priority ranking
• Time estimates

Output:

• Filtered task list
• Completion percentage
• Time allocation summary
• Task history

UI Elements Involved

• Day navigation (Today, Yesterday, Tomorrow)
• Task list display
• Task checkbox (complete/incomplete)
• Add task button
• Priority indicator
• Time estimate display
• Drag-and-drop reordering
• Delete task button

Technical Considerations

Data Filtering:

• Filter tickets with due date = today
• Filter scheduled time blocks for today
• Filter personal tasks for today
• Combine from multiple sources

Performance:

• Task list load < 200ms
• Mark complete / update immediately
• Drag-and-drop smooth at 60fps

Edge Cases:

• 100+ tasks for a single day
  • Resolution: Implement search within today's tasks
• Tasks carried over from previous days (incomplete)
  • Resolution: Show overflow indicator, allow moving to today
• Task time estimates exceed 24 hours
  • Resolution: Show warning, allow for context

Related Use Cases

• 6.2 Mein Tag (parent)
• 6.1 Dashboard (displays "Mein Tag" summary)
• 4.1 Zeiterfassung (time tracking)
• 3.1 Ticket-Details (linked from tasks)

Testing Scenarios

1. T1: View today's tasks - verify correct date filtering
2. T2: Mark task complete - verify status update
3. T3: Create new task for today - verify addition to list
4. T4: Reorder tasks by priority - verify persistence
5. T5: View yesterday's tasks - verify navigation
6. T6: Move task from yesterday to today - verify update
7. T7: Multiple incomplete tasks - verify organization

---

UC-6.2.2: Time Block Planning

Use Case Details

ID: 6.2.2 Category: Daily Planning Base UseCase: 6.2 Mein Tag (MyDay) Complexity: Medium Priority: Medium

Description

Users can visualize their daily work as time blocks with specific durations, enabling visual time allocation planning. Time blocks represent scheduled work activities with start/end times or duration estimates.

Business Value

• Visual time management
• Clear time allocation visibility
• Better utilization tracking
• Context switching reduction
• Prevents overallocation

User Roles

• Primary: Technicians, Support staff
• Secondary: Managers (team view)

Actors

1. Technician
   - Views time blocks for today
   - Creates time blocks
   - Adjusts time block duration
   - Views time utilization

2. System
   - Displays visual time block calendar
   - Tracks time allocation
   - Warns about conflicts

Preconditions

• User has tasks/tickets with duration estimates
• Current date is within working hours

Main Flow

1. User navigates to "Mein Tag" (My Day) view
2. System displays time-based calendar for today
3. System shows time blocks for:
   - Scheduled tasks (with duration)
   - Assigned tickets (with estimated time)
   - Time tracking entries (with logged time)
4. Each block shows:
   - Start time
   - Duration/end time
   - Task name
   - Color coding by category/priority
5. User can see gaps/free time
6. User can drag block to adjust time
7. System updates scheduling

Alternate Flows

AF1: Create Time Block Manually

1. User clicks on empty time slot
2. System shows time block creation form
3. User enters task name
4. User sets start time and duration
5. User sets priority/category
6. User saves block
7. System adds to calendar

AF2: View Time Utilization Summary

1. User views time blocks for day
2. System calculates utilization:
   - Total work time: 8 hours
   - Scheduled blocks: 6.5 hours
   - Free time: 1.5 hours
3. System displays utilization percentage
4. System shows overallocation warning if > 8 hours

AF3: Move/Resize Time Blocks

1. User sees time block on calendar
2. User drags block to new start time
3. System updates block start time
4. User can resize block handle to change duration
5. System updates duration
6. Changes persist to schedule

Postconditions

• Time blocks are displayed
• Visual calendar shows time allocation
• User can see free time
• Scheduling conflicts are visible

Data Requirements

Input:

• Task/ticket information
• Start time
• Duration
• Category/priority
• Resource requirements

Output:

• Visual time block calendar
• Utilization summary
• Conflict warnings
• Free time slots

UI Elements Involved

• Time-based calendar view (8am-6pm typical)
• Time blocks with color coding
• Block drag-and-drop
• Block resize handles
• Time slot labels
• Free time indicator
• Utilization summary
• Conflict warning badge

Technical Considerations

Calendar Display:

• Hour-based grid layout
• 15-minute or 30-minute slot granularity
• Visual conflict detection
• Responsive to screen size

Data Integration:

• Fetch all tasks/tickets for today
• Get time estimates from tickets
• Combine with time tracking data
• Calculate availability windows

Performance:

• Calendar render < 300ms
• Drag-and-drop smooth at 60fps
• Conflict detection real-time

Edge Cases:

• Overlapping time blocks
  • Resolution: Highlight conflict, prevent overlap
• Task duration > remaining day
  • Resolution: Show warning about overallocation
• No time blocks for day
  • Resolution: Show empty calendar, encourage planning
• Daylight saving transitions
  • Resolution: Handle correctly for clock changes

Related Use Cases

• 6.2 Mein Tag (parent)
• 6.2.1 Daily Task Management (task list view)
• 4.1 Zeiterfassung (time tracking)
• 4.2 Stoppuhren (timer integration)

Testing Scenarios

1. T1: View time blocks for today - verify calendar display
2. T2: Create time block manually - verify addition
3. T3: Drag time block to new time - verify update
4. T4: Resize time block duration - verify persistence
5. T5: View utilization summary - verify calculations
6. T6: Detect overlapping blocks - verify warning
7. T7: Free time slots visible - verify calculation

---

UC-6.2.3: Work Priority Management

Use Case Details

ID: 6.2.3 Category: Daily Planning Base UseCase: 6.2 Mein Tag (MyDay) Complexity: Low-Medium Priority: Medium

Description

Users can prioritize and reorder their daily work activities to focus on high-priority items first. The system supports drag-and-drop reordering, priority level assignment, and visual priority indicators.

Business Value

• Ensures high-priority work is completed first
• Reduces important items being overlooked
• Improves task completion rates
• Enables flexible priority adjustment
• Supports agile/dynamic work planning

User Roles

• Primary: Technicians, Support staff, All employees
• Secondary: Managers (overriding priorities)

Actors

1. Employee
   - Views task priorities
   - Reorders tasks
   - Sets priority levels
   - Focuses on high-priority items

2. Manager
   - Can override/force task priority
   - Can set team priorities

3. System
   - Tracks priority order
   - Persists priority ranking
   - Visually indicates priority

Preconditions

• User has multiple tasks for today
• At least 2 tasks available

Main Flow

1. User views "Mein Tag" task list
2. System displays tasks in current priority order
3. System uses visual indicators:
   - High: Red/bold header
   - Medium: Orange/normal header
   - Low: Gray/subtle header
4. User can drag task to new position
5. System reorders tasks
6. System updates priority ranking
7. New order persists across sessions
8. Tasks are completed in priority order

Alternate Flows

AF1: Set Priority Level

1. User right-clicks on task
2. User selects "Set Priority" from context menu
3. System shows priority options (High/Medium/Low)
4. User selects new priority level
5. System updates task priority
6. System may reorder task based on priority
7. System saves priority change

AF2: Auto-Sort by Priority

1. User clicks "Sort by Priority" button
2. System automatically reorders tasks:
   - High priority first
   - Medium priority second
   - Low priority last
3. Within same priority, maintains order
4. User can still manually reorder if desired

AF3: Pin Important Task

1. User right-clicks task
2. User selects "Pin to Top"
3. System moves task to very top (above priorities)
4. Task stays at top regardless of priority
5. User can unpin to remove special status

Postconditions

• Task priority order is updated
• Priority visualization is applied
• User can focus on high-priority items
• Priority changes persist

Data Requirements

Input:

• Task ID
• Priority level (High/Medium/Low)
• Priority order sequence

Output:

• Reordered task list
• Priority indicators
• Priority change history

UI Elements Involved

• Task list with drag-and-drop
• Priority color indicators
• Priority context menu
• Set priority dialog
• Sort by priority button
• Pin/unpin button
• Priority label per task

Technical Considerations

Priority Algorithms:

• Simple numeric priority field
• Support for tiebreakers (time, category)
• Drag-and-drop updates priority
• Maintains explicit order

Data Persistence:

• Store priority order per user per day
• Track priority changes in audit log
• Support priority history/undo

Performance:

• Drag-and-drop smooth at 60fps
• Priority reordering < 100ms
• Instant visual feedback

Edge Cases:

• Manager changes priority (override)
  • Resolution: Shows indicator of manager override
• Tasks added after priority set
  • Resolution: Insert at appropriate priority level
• Delete high-priority task
  • Resolution: Remove from order, next task becomes focus
• 50+ tasks with same priority
  • Resolution: Use secondary sort criteria

Related Use Cases

• 6.2 Mein Tag (parent)
• 6.2.1 Daily Task Management (task list)
• 6.2.2 Time Block Planning (time-based priority)

Testing Scenarios

1. T1: View task priority order - verify visualization
2. T2: Drag task to change priority - verify reordering
3. T3: Set priority level via context menu - verify update
4. T4: Auto-sort by priority - verify grouping
5. T5: Pin task to top - verify special handling
6. T6: Page refresh - verify priority persistence
7. T7: Multiple users - verify independent priorities

---

Summary Table: New Use-Cases

ID	Name	Base	Complexity	Priority	Type
3.2.1	Advanced Ticket Filtering	3.2	Medium	High	Enhancement
3.2.2	Ticket List Customization	3.2	Medium	Medium	Enhancement
3.2.3	Full-Text Ticket Search	3.2	Low-Med	High	Enhancement
8.1.1	Advanced Customer Search	8.1	Low-Med	High	Enhancement
8.1.2	Customer Status Management	8.1	Low	Medium	Enhancement
8.1.3	Contact Person Management	8.1	Medium	Medium	Enhancement
6.2.1	Daily Task Management	6.2	Medium	High	Enhancement
6.2.2	Time Block Planning	6.2	Medium	Medium	Enhancement
6.2.3	Work Priority Management	6.2	Low-Med	Medium	Enhancement

---

Recommendations for Implementation

High Priority (Implement First - High Business Value)

1. UC-3.2.3: Full-Text Ticket Search - Easy to implement, high user value
2. UC-3.2.1: Advanced Ticket Filtering - Enhances core functionality
3. UC-8.1.1: Advanced Customer Search - Essential for customer lookup
4. UC-6.2.1: Daily Task Management - Improves focus and productivity

Medium Priority (Implement Second)

1. UC-3.2.2: Ticket List Customization - Improves user experience
2. UC-8.1.2: Customer Status Management - Needed for lifecycle management
3. UC-6.2.3: Work Priority Management - Supports planning

Lower Priority (Implement Later or as Nice-to-Have)

1. UC-8.1.3: Contact Person Management - More complex, specialized use case
2. UC-6.2.2: Time Block Planning - Advanced feature for mature users

---

Generated: 2025-11-24 Source: Live screenshot analysis New Use-Cases: 9 detailed specifications Status: Ready for development planning