Stand Configuration
User Scenarios & Testing (mandatory)
User Story 1 - Sponsor Selects Base Package and Views Included Items (Priority: P1)
A sponsor logs into their assigned stand and views available stand packages (mapped from Nimlogix kits). If the sponsor has permission to select packages, they can choose their preferred package. If package selection permission is disabled for their stand, they view their pre-allocated package assigned by the organiser. All sponsors see included items with quantities, descriptions, and any mandatory components that cannot be changed.
Why this priority: This is the foundational capability - viewing and potentially selecting a base package is the starting point for all stand configuration. Without this, no other configuration can occur.
Independent Test: Can be fully tested by logging in as a sponsor, viewing available packages with pricing (if selection permission granted) or viewing pre-allocated package (if selection permission disabled), selecting one (if allowed), and verifying included items are displayed correctly. Delivers a functional package selection/viewing MVP.
Acceptance Scenarios:
- Given a sponsor is assigned to a stand with package selection permission enabled, When they access the stand configuration page, Then they see all available packages with names, descriptions, and total prices
- Given a sponsor is assigned to a stand with package selection permission disabled, When they access the stand configuration page, Then they see their pre-allocated package with name, description, and included items (no selection interface displayed)
- Given a sponsor views available packages (selection permission enabled), When they select a package (e.g., "3m x 2m Shell Scheme"), Then the package is assigned to their stand and all included items are displayed
- Given a sponsor has a package (either selected or pre-allocated), When they view non-configurable items (min = included = max), Then they see item names with locked quantities displayed as read-only
- Given a package has configurable options (min < max), When a sponsor views configuration categories, Then all configurable options are displayed with quantity controls between minimum and maximum
- Given a sponsor attempts to change their selected package (selection permission enabled), When they select a different package, Then the system warns about losing current configuration and allows confirmation before switching
- Given a sponsor has a pre-allocated package (selection permission disabled), When they attempt to change packages, Then no package selection interface is available and current package is locked
User Story 2 - Sponsor Configures Options Within Configuration Categories (Priority: P1)
A sponsor views available configuration categories (mapped from Nimlogix bolt-on groups), selects options per category where required, configures variable quantity items where allowed, and sees real-time pricing updates as they make selections.
Why this priority: Configuration option selection is core to the stand configuration workflow and must work immediately after package selection for a viable MVP.
Independent Test: Can be tested by selecting a package, viewing configuration categories, selecting options, adjusting quantities for variable items, and verifying pricing updates. Delivers functional configuration option selection.
Acceptance Scenarios:
- Given a sponsor has selected a package, When they view available configuration options, Then they see configuration categories (e.g., "Backwall AV", "Furniture", "Lighting") with options listed under each category
- Given a configuration category is single-select (e.g., "Backwall AV"), When a sponsor selects one option (e.g., "43 inch screen"), Then only that option is selected and other options in the category are deselected
- Given a configuration category is multi-select (e.g., "Extras"), When a sponsor selects multiple options (e.g., "Literature Holder" and "Bar Stool"), Then both options remain selected and can be configured independently
- Given a configuration option has included quantity of 2 and maximum of 5, When a sponsor adjusts the quantity from default 2 to 4, Then the quantity is validated against min/max limits and additional charge calculated for 2 extra units
- Given a sponsor configures options, When they view the pricing summary, Then they see base package price (includes all included quantities), additional charges for quantities above included, and total price
- Given a configuration option has included quantity greater than zero, When a sponsor views it, Then it shows included quantity as default with ability to adjust between minimum and maximum
User Story 3 - Organiser Configures Stand Package Permissions (Priority: P1)
An organiser views packages available for their event (provided by external system), configures package selection permissions per stand (allow sponsor to select packages or restrict to pre-allocated package), assigns packages to stands when permission is disabled, and makes packages available for sponsor use. Package data itself (items, configuration options, pricing) is read-only and managed by external system.
Why this priority: Without organisers being able to configure package selection permissions and assign packages, sponsors cannot access configuration. This is a critical prerequisite for the system.
Independent Test: Can be tested by viewing available packages, setting package selection permissions for individual stands, assigning packages to stands with disabled permission, and verifying sponsors see appropriate interface based on their permission. Delivers organiser package configuration MVP.
Acceptance Scenarios:
- Given an organiser is setting up an event, When they view available packages, Then they see packages provided by external system with names, descriptions, base prices, and included items (read-only)
- Given an organiser views package details, When they review configuration categories and options, Then they see all configuration categories with selection mode (single-select or multi-select) defined by external system (read-only)
- Given an organiser attempts to modify package data, When they try to edit package name, items, or configuration options, Then system prevents editing with message indicating data is managed by external system
- Given an organiser assigns a sponsor to a stand, When they enable package selection permission for that stand, Then the sponsor will see package selection interface with all available packages
- Given an organiser assigns a sponsor to a stand, When they disable package selection permission for that stand, Then the sponsor will only see their assigned package without selection interface
- Given an organiser has disabled package selection permission for a stand, When they assign a sponsor to that stand, Then they must assign a specific package to the stand from available packages
- Given an event has multiple stands, When an organiser configures package selection permissions, Then they can enable permission for some stands and disable it for others independently
- Given package data includes cost and pricing information, When organiser views package details, Then internal cost data is visible for reporting purposes but not displayed to sponsors
User Story 4 - Sponsor Saves Draft and Submits Configuration (Priority: P2)
A sponsor works on their stand configuration over multiple sessions, saves progress as a draft, receives confirmation of saved changes, returns later to continue editing, completes configuration, submits for review, and receives confirmation with submission deadline reminder.
Why this priority: Draft saving is essential for user experience but can be delivered after core configuration functionality works. Submission workflow is required before artwork management.
Independent Test: Can be tested by starting configuration, saving as draft, logging out, logging back in, resuming configuration, submitting, and verifying status transitions. Delivers complete configuration workflow.
Acceptance Scenarios:
- Given a sponsor is configuring their stand, When they save their progress, Then all selections (package, configuration options, quantities) are saved as a draft with timestamp
- Given a sponsor has saved a draft, When they return to the stand configuration page, Then their previous selections are restored and they can continue editing
- Given a sponsor completes their configuration, When they submit for review, Then status changes from "draft" to "submitted" and configuration becomes read-only
- Given a sponsor submits their configuration, When submission is confirmed, Then they receive confirmation message with submission deadline, organiser contact details, and next steps
- Given a configuration has been submitted, When an organiser reviews it, Then they see all selected items, quantities, pricing breakdown, and can approve or request changes
User Story 5 - Organiser Reviews and Approves Stand Configuration (Priority: P2)
An organiser views all submitted stand configurations for their event, filters by status and stand, reviews configuration details and pricing, approves configurations that meet requirements, requests changes with comments for incomplete configurations, and tracks approval status across all stands.
Why this priority: Approval workflow is important but secondary to the configuration creation process. Can be delivered after sponsors can submit configurations.
Independent Test: Can be tested by submitting multiple configurations as sponsor, logging in as organiser, viewing pending configurations, approving some, requesting changes on others, and verifying status updates. Delivers complete review workflow.
Acceptance Scenarios:
- Given an organiser manages an event, When they view stand configurations dashboard, Then they see all stands with status indicators (draft, submitted, approved, changes requested)
- Given an organiser selects a submitted configuration, When they review details, Then they see sponsor name, package selection, all configuration options with quantities, total pricing, and submission timestamp
- Given an organiser approves a configuration, When they confirm approval, Then status changes to "approved", sponsor is notified, and configuration triggers artwork requirement generation
- Given an organiser identifies issues, When they request changes, Then they provide comments, status changes to "changes requested", and sponsor receives notification with comments
- Given a sponsor receives change request, When they edit and resubmit, Then status changes back to "submitted" and organiser is notified of resubmission
Edge Cases
- What happens when an organiser disables package selection permission for a stand after sponsor has already selected a package? (Treat selected package as pre-allocated, lock it from further sponsor changes)
- What happens when an organiser enables package selection permission for a stand that previously had it disabled? (Unlock package for sponsor editing)
- What happens when a sponsor switches packages after configuring multiple options (with selection permission enabled)? (All configuration selections are cleared, user is warned before switch, pricing resets to new base package)
- How does system handle organiser attempting to change a pre-allocated package after sponsor has configured options? (Require confirmation, warn that option selections may become invalid if new package has different configuration categories, clear incompatible selections)
- What happens when an organiser changes package selection permission for multiple stands simultaneously? (System processes each stand independently, applying appropriate lock status changes)
- How does system handle configuration option with minimum quantity 1, included quantity 2, and maximum quantity 5? (Display with default quantity of 2, allow adjustment from 1-5, charge only for quantities above included 2)
- What happens when a configuration category has only one option? (For single-select categories: display as checkbox to include/exclude; for multi-select categories: same behavior as checkbox)
- What happens when external system updates package data after sponsors have already configured stands? (Existing submitted/approved configurations remain unchanged on previous version, draft configurations may be affected, new configurations use updated data)
- How does system handle size modifiers and metadata from external system? (Store modifiers for external system integration but don't expose to sponsor interface)
- What happens when a sponsor tries to submit configuration past the deadline? (System allows submission but marks as late, organiser receives notification, configuration requires explicit approval)
- How does system handle nested packages (kits containing other kits)? (Nested kits are treated as configuration options; if quantity is configurable, sponsors can adjust quantity between min/included/max; if quantity is locked, displayed as non-configurable item)
- How does system handle configuration option with included quantity of 0 (purely optional)? (Display with minimum quantity as default, all selected quantity incurs charges)
- What happens when sponsor selects quantity below included quantity? (System allows selection between minimum and included with no pricing adjustment; included quantity is already included in base package price, selecting less does not provide credit or discount)
- How does system handle concurrent editing when sponsor and organiser both modify configuration? (Last write wins for draft status, submitted/approved configurations are locked from sponsor editing until status reverts to draft)
- What happens when external system tries to update package data that is referenced by approved configurations? (Accept update but maintain version history, existing configurations reference previous version, new configurations use new version)
Requirements (mandatory)
Functional Requirements
Package Selection and Display
- FR-001: System MUST support package selection permission configuration per stand, allowing organisers to enable or disable sponsor's ability to select packages independently for each stand
- FR-002: System MUST display all available packages for a stand with package name, description, base price, and key features when package selection permission is enabled for that stand
- FR-003: System MUST display only the pre-allocated package (no selection interface) when package selection permission is disabled for that stand
- FR-004: System MUST allow sponsors to select one package per stand from available options when package selection permission is enabled for their stand
- FR-005: System MUST prevent sponsors from changing packages when package selection permission is disabled for their stand
- FR-006: System MUST display all non-configurable items (where min = included = max) for assigned package showing item name, locked quantity, and unit of measure
- FR-007: System MUST display configuration options with locked quantities (min = included = max) as non-editable items in package summary
- FR-008: System MUST warn sponsors before allowing package changes (when permission enabled) that will clear all current configuration selections and require confirmation
- FR-009: System MUST preserve and display Nimlogix kit ID, kit code, and kit description for integration purposes
Configuration Categories and Options
- FR-010: System MUST organize configuration options into configuration categories that map to external system bolt-on groups; options without an assigned category are grouped under "Other Options" or displayed as uncategorized list if no categorized options exist
- FR-011: System MUST enforce selection rules per configuration category as defined by external system - categories can be either single-select (mutually exclusive) or multi-select (allow multiple options)
- FR-012: System MUST support three quantity types for configuration options: minimum quantity (floor), included quantity (included in package), and maximum quantity (ceiling)
- FR-013: System MUST display included quantity as the default/starting quantity for configuration options included in package
- FR-014: System MUST allow sponsors to adjust quantities between minimum and maximum limits (inclusive)
- FR-015: System MUST validate configuration option quantity selections to ensure they are within minimum and maximum bounds
- FR-016: System MUST calculate additional charges only for quantities above included quantity using unit price multiplied by (selected quantity - included quantity); quantities at or below included incur no additional charges and provide no credits
- FR-017: System MUST preserve external system identifiers (bolt-on ID, bolt-on group, item code) for integration
Pricing and Calculations
- FR-018: System MUST calculate and display total configuration price as sum of base package price (which includes all included quantities) plus all additional configuration option charges (only for quantities above included)
- FR-019: System MUST update pricing in real-time as sponsors make selections and quantity adjustments
- FR-020: System MUST display pricing breakdown showing base package price (includes all included quantities regardless of sponsor's actual selection), additional quantity charges (only for quantities above included × unit price), and total; selecting quantities below included does not reduce price or provide credits
- FR-021: System MUST preserve unit cost and unit price for reporting but display only customer-facing prices to sponsors
- FR-022: System MUST calculate configuration option additional charges as: MAX(0, selected quantity - included quantity) × unit price; selecting quantities at or below included always results in zero additional charges (no credits or discounts applied)
Draft Saving and Session Management
- FR-023: System MUST auto-save draft configurations every 2 minutes while sponsor is actively editing
- FR-024: System MUST provide manual "Save Draft" action that confirms save with timestamp
- FR-025: System MUST restore all saved selections (package, configuration options, quantities) when sponsor returns to configuration
- FR-026: System MUST track configuration status transitions: draft → submitted → approved/changes requested → draft (if changes requested)
- FR-027: System MUST prevent concurrent editing conflicts by locking submitted/approved configurations from sponsor changes
Submission and Approval Workflow
- FR-028: System MUST allow sponsors to submit completed configurations for organiser review
- FR-029: System MUST change configuration status to "submitted" and make configuration read-only to sponsor upon submission
- FR-030: System MUST notify organiser when sponsor submits configuration for review
- FR-031: System MUST display submission confirmation to sponsor with deadline reminder, organiser contact details, and next steps
- FR-032: System MUST allow organisers to approve configurations, which changes status to "approved" and triggers artwork requirement generation
- FR-033: System MUST allow organisers to request changes with comments, which changes status to "changes requested" and notifies sponsor
- FR-034: System MUST allow sponsors to edit configurations after changes are requested, making status revert to "draft"
- FR-035: System MUST allow late submissions past deadline but mark them as late and require explicit organiser approval
Organiser Package Configuration and External Integration
- FR-036: System MUST allow organisers to configure package selection permission per stand, enabling or disabling sponsor's ability to select packages independently for each stand
- FR-037: System MUST require organisers to assign specific packages to stands when package selection permission is disabled for that stand
- FR-038: System MUST display available packages to organisers with all details (name, description, base price, items, configuration categories) in read-only view
- FR-039: System MUST prevent organisers from creating, editing, or deleting packages, items, or configuration options
- FR-040: System MUST accept package data from external system API including packages, configuration options, configuration categories, and all attributes (nested kits treated as configuration options)
- FR-041: System MUST store external system identifiers (kit ID, kit code, bolt-on ID, group identifier) and category selection mode for each package, category, and option provided by external system
- FR-042: System MUST store three quantity values for each configuration option: minimum quantity, included quantity (included in package), and maximum quantity
- FR-043: System MUST store cost data (unit cost for packages and options) alongside pricing for reporting and external system synchronization
- FR-044: System MUST store and enforce configuration rules (quantity constraints via min/included/max, category selection mode) as defined by external system
- FR-045: System MUST validate incoming package data from external system for required fields (package name, kit ID, base price, unit cost, quantity constraints) before accepting
- FR-046: System MUST make packages available for sponsor use (selection or pre-allocation) based on data provided by external system
- FR-047: System MUST maintain version history when package data is updated by external system, preserving existing stand configurations on previous package versions
- FR-048: System MUST store additional metadata (size modifiers) provided by external system for reporting without displaying to sponsors
- FR-049: System MUST allow external system to update package data which affects new configurations but preserves existing submitted/approved configurations
Organiser Review Dashboard
- FR-050: System MUST provide organisers with dashboard showing all stands for their event with status indicators and assigned packages (whether selected by sponsor or pre-allocated)
- FR-051: System MUST allow organisers to filter stand configurations by status (draft, submitted, approved, changes requested, late)
- FR-052: System MUST display configuration details for organiser review including sponsor name, package (selected or pre-allocated), all configuration options with quantities (included vs selected), pricing breakdown, and submission timestamp
- FR-053: System MUST track and display configuration submission timestamp, approval timestamp, and organiser who performed approval
- FR-054: System MUST provide approval actions (approve, request changes) with confirmation dialogs
Data Retention and Compliance
- FR-055: System MUST preserve all configuration data (package selections/allocations, configuration options, quantities, pricing, cost data, status history) for seven-year retention period
- FR-056: System MUST log all configuration changes with timestamp, user ID, and changed fields in audit log including package allocation actions by organisers
- FR-057: System MUST support soft deletes for stand configurations to maintain referential integrity with artwork and payment records
Key Entities
- Stand Configuration: Represents a sponsor's configuration for a specific stand, including assigned package (either selected by sponsor or pre-allocated by organiser), package selection permission flag (enabled/disabled), configuration option selections, quantities, total pricing, status (draft/submitted/approved/changes requested), submission timestamp, approval timestamp, and version reference to package data
- Package Allocation: Records organiser's pre-allocation of a specific package to a stand when package selection permission is disabled, including allocated package, allocated by organiser ID, allocation timestamp, and lock status
- Package: Represents a stand package configuration, including package name, description (may include details of non-configurable items), base price, unit cost (for reporting), external system identifiers (kit ID, kit code) for integration, list of available configuration categories, and publication status
- Configuration Category: Represents a grouping of related configuration options for package customisation, including category name, external group identifier for integration, display order, selection mode (single-select for mutually exclusive options, or multi-select for independent options), and list of configuration options
- Configuration Option: Represents any item associated with a package (both configurable and non-configurable), including option name, external identifiers (bolt-on ID, item code) for integration, category assignment (null if uncategorized), minimum quantity (cannot select less), included quantity (amount included in package), maximum quantity (cannot select more), unit price, unit cost (for reporting), size modifiers for external systems, and default selection indicator. Note: When min = included = max, the item is non-configurable (display-only with locked quantity). Options with null category are grouped together or displayed as uncategorized list
- Configuration Selection: Represents sponsor's choice within a configuration category, including selected option, chosen quantity, pricing calculation, and timestamp
- Package Version: Tracks changes to package data over time, preserving historical configurations when packages are modified, including version number, effective date, and snapshot of package/item/option data
Success Criteria (mandatory)
Measurable Outcomes
- SC-001: Sponsors can complete stand configuration from package selection through configuration option selection to submission in under 15 minutes for typical packages with 3-5 configuration categories
- SC-002: 90% of sponsors successfully select package, configure options, and submit configuration without requiring support assistance
- SC-003: Organisers can configure package selection permissions per stand and assign packages in under 10 minutes per event
- SC-004: System accurately calculates pricing for 100% of configurations with zero arithmetic errors in totals and line items
- SC-005: Draft configurations auto-save within 2 minutes of changes with 99% reliability
- SC-006: Configuration dashboard loads and displays up to 100 stands with status indicators in under 2 seconds
- SC-007: Real-time pricing updates appear within 500 milliseconds of configuration option selection or quantity adjustment
- SC-008: Organisers can review and approve/request changes on submitted configurations in under 5 minutes per stand
- SC-009: 95% of submitted configurations receive organiser response (approved or changes requested) within 48 hours
- SC-010: System supports concurrent editing by up to 50 sponsors configuring different stands without performance degradation
- SC-011: Configuration options display correctly regardless of complexity (nested kits treated as configuration options)
- SC-012: Configuration version history preserves 100% of historical configurations when package data is updated, with zero data loss
Assumptions (mandatory)
- External System Integration: Assumes external system (Nimlogix) will create and update all package data via portal API; portal does not pull data from external systems
- Package Data Management: Assumes all package data (packages, configuration options, configuration categories, pricing) is created and managed exclusively by external system; organisers have read-only access for viewing and configuration assignment purposes only
- Single Package Per Stand: Assumes each stand can have only one active package at a time; sponsors cannot mix and match base packages
- Package Selection Permission Default: Assumes default package selection permission is enabled; organisers must explicitly disable permission per stand if they want to restrict package selection
- Pre-allocation Timing: Assumes organisers pre-allocate packages before sponsors access configuration interface when permission is disabled; sponsors never see empty/unassigned stand when permission is disabled
- Category Selection Mode: Assumes configuration categories can be either single-select (mutually exclusive options) or multi-select (independent options); selection mode defined by external system per category
- Pricing Currency: Assumes all pricing is in GBP; multi-currency support would require separate specification
- Included Quantity Pricing: Assumes included quantity is always included in base package price regardless of actual sponsor selection; selecting quantities below included never provides credits or discounts to sponsor
- Auto-save Interval: Assumes 2-minute auto-save interval balances data safety with system performance; configurable by system administrator
- Nested Kit Handling: Assumes nested kits from external system are treated as configuration options; if quantity is configurable (min ≠ max), sponsors can adjust quantity; if locked (min = included = max), displayed as non-configurable item
- Internal Data Visibility: Assumes cost data is internal data not displayed to sponsors, only used for reporting and external system integration
- Late Submission Handling: Assumes late submissions are allowed but require explicit organiser approval rather than automatic rejection
- Configuration Lock Behavior: Assumes submitted/approved configurations are locked from sponsor editing to maintain approval integrity; changes requested status unlocks for editing
- Artwork Trigger: Assumes approved configuration status automatically triggers artwork requirement generation (handled by separate artwork management module)
- Metadata Storage: Assumes external system identifiers (kit ID, item code, bolt-on ID) and metadata (size modifiers, cost data) are stored for integration but not displayed to sponsors unless explicitly configured
- Concurrent Edit Resolution: Assumes last write wins for draft configurations; submitted/approved configurations prevent concurrent edits through status locking
- Permission Switching Impact: Assumes changing package selection permission after sponsors have configured stands is rare; when it occurs, existing configurations are preserved with appropriate lock status changes
Dependencies (mandatory)
Internal Dependencies
- Event management system: required for event context, sponsor assignments, and configuration deadlines
- User management system: required for authentication, sponsor/organiser role verification, and permission checks
- Notification system: required for submission confirmations, approval notifications, change request alerts, and deadline reminders
- Artwork management system: required for receiving trigger when configuration is approved to generate artwork requirements
- Audit logging system: required for tracking all configuration changes, status transitions, and approval actions
- Reporting system: required for accessing configuration data and pricing breakdowns
External Dependencies
- External system integration API: optional integration endpoint for external systems to create/update package data, query configurations, and sync stand details
- Pricing service: required for currency formatting and tax calculations if applicable
Constraints (mandatory)
Business Constraints
- Package data (packages, configuration options, configuration categories, pricing) is read-only for portal users; all changes must come from external system
- Portal users (organisers and sponsors) cannot create, edit, or delete packages - all package management is external
- Package selection permission is configured per stand - event can have mix of stands with permission enabled and disabled
- Package selection limited to one active package per stand at any time
- When permission is disabled for a stand, organisers must assign packages before sponsors can access configuration
- When permission is enabled for a stand, sponsors must select package before configuring options
- Configuration category selection mode (single-select or multi-select) enforced as defined by external system
- Configuration changes not allowed after submission unless organiser requests changes
- Approved configurations cannot be modified without reverting approval status
- Cost data must be preserved for reporting but not displayed to sponsors
- Late submissions past deadline require explicit organiser approval rather than automatic processing
- Configuration data must be retained for seven years for compliance and historical reference
- Package version changes must preserve existing configurations on historical versions
- Changing package selection permission after configurations exist requires organiser confirmation and may impact sponsor workflow
Technical Constraints
- Configuration options displayed as flat list (nested kits treated as individual configuration options)
- External system API calls for package data updates must complete within 30 seconds or be queued for async processing
- Auto-save interval set to 2 minutes minimum to balance data safety with server load
- Configuration dashboard pagination required for events with more than 100 stands
- Real-time pricing updates must complete within 500 milliseconds to maintain responsive user experience
- System designed to support up to 50 concurrent sponsors configuring stands without degradation
- Package data validation from external system must complete within 5 minutes for packages with up to 200 configuration options
- Configuration pricing calculations must be arithmetically accurate with zero rounding errors beyond standard currency precision (2 decimal places)
Open Questions
None - all requirements are specified with reasonable defaults documented in Assumptions section.