## A) Understanding and boundaries The product replaces scattered emails and duplicate spreadsheet entries with a responsive, online room request portal. Thirty adult members submit requests and view their own decisions. Five coordinators review all requests and approve or reject them. The fictional pilot expects 50 requests per week and five simultaneous users. **Facts** - First-product functions: member sign-in, room request creation, coordinator approval or rejection, private member status view, and submission confirmation email. - Requests contain a member identity, room, start time, and end time. - Approved bookings for the same room must never overlap. - An organization email provider and managed relational database already exist. - Request personal data must be deleted 90 days after the booking date. - Payments, public profiles, and offline use are excluded. - No delivery deadline, budget, or team expertise is supplied. **Assumptions** - None are treated as established requirements. Where alternatives matter, they are presented as conditional choices below. **Open technical decisions** - How member accounts are provisioned, verified, recovered, and disabled. - Whether the email provider also offers usable identity services. - Room list ownership and maintenance. - Booking timezone, daylight-saving handling, and whether adjacent bookings are allowed. - Whether requests may span multiple days. - Whether coordinators may decide their own requests. - Whether decisions can be reversed; editing and cancellation are unspecified and excluded from the baseline. - The retention reference date, especially for rejected and multi-day requests. - Backup retention and handling of restored personal data. **Recognizable contradictions** No direct contradiction exists. Two requirements need qualification: - Application database deletion alone does not resolve personal data retained in backups, emails, or logs. - “Member-only status view” is interpreted alongside the explicit rule: members see only their own requests; coordinators see all. ## B) Technical core requirements ### Data, inputs, outputs, and states | Item | Necessary information or behavior | |---|---| | Account | Stable identifier, name, email, active membership, role | | Room | Stable identifier and display name | | Request | Identifier, owner, room, start/end timestamps, status, submission timestamp | | Decision | Approving/rejecting coordinator and decision timestamp | | Email delivery | Submission event identifier, delivery state, retry information | | Retention | Defined deletion reference date and deletion eligibility | Request states: **pending → approved** or **pending → rejected**. Additional transitions require a separate decision. Inputs require server-side validation of room existence, valid timestamps, and end time after start time. Rules for past dates remain open. Outputs are the submission result, request status, coordinator review information, and confirmation email. ### Interfaces, authentication, and permissions Necessary interfaces are: - Browser to application over HTTPS. - Application to managed relational database. - Application or background worker to the existing email provider. - Application to an identity provider, if an external authentication option is selected. Authorization must be enforced on the server for every operation: | Action | Member | Coordinator | |---|---|---| | Create request | For own account | Membership behavior to be decided | | Read requests | Own only | All | | Approve/reject | No | Yes | | Assign roles | No | Provisioning mechanism remains open | The application must derive request ownership from the authenticated session, rather than trusting a submitted owner identifier. ### Booking integrity Approval must perform the conflict check and status change atomically. A separate “check availability, then save” sequence can permit overlapping approvals under concurrency. Two viable database approaches are: - A database-enforced temporal exclusion rule, if supported. - A transaction that locks the relevant room record, checks approved bookings, and writes the decision. Every approval path must follow this protocol. For illustration, if adjacent bookings are permitted, half-open intervals `[start, end)` allow one booking to begin exactly when another ends. That boundary rule requires confirmation. ### Security, privacy, and operation Context supports session protection, secure secret storage, restricted database credentials, minimal personal data in logs, and recoverable backups. The deletion process must cover request records and associated personal data in decision records, delivery queues, and diagnostic storage. Whether account names and emails have a separate retention purpose remains open. Legal applicability and the adequacy of the retention policy require appropriate expert review; this evaluation does not establish legal compliance. ## C) Two architecture variants ### 1. Simplest possible MVP architecture **Components and responsibilities** - One web application: responsive pages, authentication integration, authorization, validation, and coordinator decisions. - Existing relational database: accounts or identity references, rooms, requests, decisions, and email delivery records. - Lightweight background process: confirmation delivery and retention cleanup. - Existing email provider: outbound delivery. - Managed application hosting or an existing suitable runtime: deployment, HTTPS, process execution, and basic monitoring. **Data flow** 1. A member signs in. 2. The application validates the request and stores it as pending. 3. The same database transaction records an email delivery task. 4. A background process sends the confirmation and records the result. 5. A coordinator approves or rejects the request. 6. Approval uses database concurrency protection; conflicting approval attempts fail cleanly. 7. Members retrieve status through owner-filtered queries. 8. A scheduled process removes eligible personal data. The database email task avoids losing the confirmation when storage succeeds but the email provider is temporarily unavailable. Submission success and email delivery are tracked separately. **Stack example and selection criteria** Django with server-rendered responsive pages, using its database adapter for the existing relational engine. This is suitable if Python expertise exists and the application can use established session, form, and administrative facilities. Confirm that the existing database supports the chosen locking or constraint strategy. Framework choice should follow team capability and database compatibility. **Operating model, dependencies, and trade-offs** A single deployment with a small background process keeps operation straightforward. Dependencies are the database, identity mechanism, email provider, and hosting runtime. Limits include shared application failure scope and limited independent scaling. Neither is currently a demonstrated obstacle at the supplied pilot load. ### 2. Scalable architecture for justified growth **Components and responsibilities** - Multiple stateless instances of the same application behind a load balancer. - Shared identity/session mechanism. - Existing relational database, expanded only when measurements justify it. - Independently deployed workers reading a durable database outbox or queue. - Centralized operational monitoring. This remains a modular application; microservices are not justified by the brief. **Data flow** 1. Any application instance authenticates and validates a submission. 2. The database transaction stores the request and outbound event. 3. A worker claims the event and sends the email. 4. Coordinator decisions still use the same database integrity mechanism. 5. Workers run retention jobs with coordination that prevents duplicate conflicting work. **Stack example and selection criteria** The same Django application with independently scaled web and worker processes. Add a dedicated queue only if measured worker contention, delivery backlog, or scheduling requirements justify another dependency. Keeping the same application structure makes growth incremental. **Operating model, dependencies, and trade-offs** This supports independent web and background capacity and can reduce disruption during deployments. It also introduces shared session configuration, worker coordination, more deployment settings, and additional failure modes. Multiple application instances do not remove database contention. Actual database capacity and hosting availability requirements must be measured. ## D) Effort and phase plan | Phase | Main tasks | Prerequisites | Acceptance criteria | Risks | Relative effort | |---|---|---|---|---|---| | **1: Smallest usable MVP** | Sign-in, request form, owner-scoped status, coordinator review, atomic approval, confirmation delivery, basic retention job and deployment | Identity choice; room list; time rules; database access; email access; agreed retention behavior | Cross-member access denied; concurrent conflicting approvals yield one approval; confirmation retries work; eligible personal data is removed | Unclear identity integration; incorrect concurrency handling; unresolved deletion semantics | **Medium** | | **2: Stabilization** | Restore testing, backup deletion handling, monitoring, failed-email recovery, authorization regression checks, deployment and support procedures | Working MVP; representative pilot feedback; backup capabilities known | Restore succeeds; expired personal data is removed before restored service access; failed jobs are visible and recoverable | Restored data reappears; silent email failures; unclear operational ownership | **Medium** | | **3: Scaling or extension** | Measure bottlenecks; add instances or workers where justified; optimize queries; implement separately approved extensions | Evidence of capacity, availability, or functional need | Agreed performance and availability targets pass under representative testing; integrity remains intact | Added operational complexity without benefit | **Small–large**, depending on measured need | Identity capability, database engine, hosting environment, team expertise, testing expectations, and operational ownership are needed for a defensible delivery estimate. Backup handling should be investigated during Phase 1. It cannot remain unresolved when a real deployment is expected to satisfy the stated deletion requirement. ## E) Risks | Priority | Risk and cause | Impact | Early indicator | Concrete countermeasure | |---|---|---|---|---| | 1 | Concurrent approvals use a non-atomic conflict check | Double booking | Two overlapping requests both pass a concurrency test | Database constraint or room-locking transaction; test with separate concurrent connections | | 2 | Ownership checks depend on the interface or client-supplied identifiers | Exposure of another member’s data | Changing a request identifier reveals another record | Server-side owner scoping and explicit coordinator permissions; direct access tests | | 3 | Retention overlooks backups, logs, or email records | Personal data persists beyond intended retention | Expired records appear after restore or in diagnostics | Document storage locations; minimize copies; define backup expiry and restore-time cleanup | | 4 | Provider outage occurs after request storage | Missing or duplicate confirmation emails | Pending delivery records accumulate or retries duplicate mail | Transactional outbox, retry limits, delivery monitoring, and provider idempotency where available | | 5 | Time and boundary rules are undefined | Unexpected conflicts or incorrectly accepted bookings | Disagreement over adjacent bookings or daylight-saving examples | Agree explicit examples; use timezone-aware timestamps and tested overlap rules | | 6 | Account and role lifecycle lacks ownership | Former members retain access or coordinator permissions drift | Accounts remain active after membership changes | Assign provisioning responsibility and implement a verified disable/role-change procedure | Often underestimated work includes restoring backups safely, maintaining the room list, provisioning accounts, investigating failed email, and ensuring every database write path preserves booking integrity. ## F) Decision **Technical feasibility: high.** The functions are conventional, the pilot load is modest, and a relational database can provide the required consistency. Feasibility remains conditional on confirming database capabilities, identity integration, and retention handling. **Recommendation:** use the MVP architecture. The scalable variant has no demonstrated capacity benefit at the supplied load. Preserve a clean separation between request handling and background jobs so it can be adopted incrementally. **Five concrete starting steps** 1. Resolve identity ownership, room management, time boundaries, and retention reference dates. 2. Inspect the existing database and email provider capabilities. 3. Prove concurrency-safe approval and server-side access restrictions. 4. Build the complete submission → review → status workflow with durable email delivery. 5. Validate with representative members and coordinators, including deletion and restore exercises. **Measurable stop, change, or re-evaluation criteria** - **Stop pilot acceptance:** any cross-member disclosure or overlapping approved booking occurs. - **Change the database approach:** concurrency tests cannot reliably preserve the booking invariant. - **Re-evaluate retention:** expired personal data remains accessible after cleanup or restore. - **Change email handling:** retries lose confirmation events or cause uncontrolled duplicates. - **Re-evaluate architecture:** representative testing fails agreed response-time, backlog, or availability targets after straightforward fixes. - **Re-evaluate scope:** users cannot complete mandatory tasks without duplicate spreadsheet entry. Performance and availability thresholds must be agreed before they can become acceptance targets. ## G) Validation before development | Priority | Open point | Small validation activity | Expected result | |---|---|---|---| | 1 | Database can enforce booking integrity | Concurrently approve overlapping requests for one room using separate connections | Exactly one becomes approved; the other receives a conflict | | 2 | Access rules cover direct requests | Attempt to read another member’s request and invoke coordinator actions as a member | Every unauthorized attempt is denied without exposing request data | | 3 | Time rules match coordinator expectations | Review concrete adjacent, overlapping, multi-day, and daylight-saving examples | One agreed outcome for each example | | 4 | Identity and membership lifecycle are workable | Inspect provider capabilities and exercise account creation, recovery, disabling, and role changes | A supported flow exists with a named operational owner | | 5 | Confirmation survives provider failure | Simulate email failure after a successful submission, then recover | Request remains stored; delivery remains recoverable; retries are controlled | | 6 | Retention is technically achievable | Trace personal data locations and test cleanup plus backup restoration | Eligible personal data is removed or made inaccessible under the agreed policy | | 7 | Workflow replaces the current process | Have representative members and coordinators complete submission, review, and status-check tasks | Mandatory tasks complete without duplicate spreadsheet entry; remaining workarounds are recorded | The main recommendation is a single web application using the existing database and email provider, with atomic approval and durable background delivery. Resolve identity, booking-time rules, retention dates, and backup handling first; scale only when measured needs justify it.