[SL-230] Address TA feedback on Problem Statement Goals + Development Plan

docs/DevelopmentPlan/DevelopmentPlan.tex

@@ -23,7 +23,7 @@
 \textbf{Date} & \textbf{Developer(s)} & \textbf{Change}\\
 \midrule
 2025-09-22 & All & Initial draft of development plan.\\
-... & ... & ...\\
+2025-11-18 & Prerna & Address TA feedback on deliverable\\
 \bottomrule
 \end{tabularx}
 \end{table}
@@ -95,19 +95,47 @@ \section{Team Communication Plan}
 
 \section{Team Member Roles}
 
-\begin{enumerate}
-    \item \textbf{Leader/Researcher: Farhan} \\
-    Responsibilities: Leading team discussions with open-ended questions found through preliminary research and guiding team direction through points of discussion to achieve goals.
-    \item \textbf{Organizer: Ali} \\
-    Responsibilities: Keeping the team on track for project milestones and deadlines with task delegation and reminders, scheduling team meetings and supervisor meetings, reviewing GitHub issues and ensuring tasks are updated and closed.  \\
-    \item \textbf{Reviewer: Abyan}
-    Responsibilities: Preparing final versions of deliverables and proofreading documents to ensure consistency and accuracy as well as making sure the quality of work meets team standards by conducting reviews on final submissions. \\
-    \item \textbf{Notetaker/Meeting chair: Prerna} 
-    Responsibilities: Gathering important information from lectures and tutorials and recording meeting notes to record and summarize project progress. \\
-    \item \textbf{Troubleshooter: Mahad}
-    Responsibilities: Help resolve issues and challenges faced by the team from research to GitHub and analyze problems and criteria to figure out solutions.
-\end{enumerate}
-\noindent\textbf{*} Roles are subject to change based on evolving project needs and further assessment on each team members strengths.
+\paragraph{Farhan — Technical Lead \& Research Lead}
+\begin{itemize}
+    \item Oversees the high-level technical direction for the features assigned to our team (payments, sign-ups, RBAC).
+    \item Conducts research on Stripe integration, authentication, and architectural patterns needed for our modules.
+    \item Guides team decisions that involve deeper backend complexity, and supports others during technical design reviews.
+    \item Coordinates with other teams (A and C) to ensure compatibility of API contracts and shared architecture.
+\end{itemize}
+
+\paragraph{Ali — Project Coordinator \& Backend Developer}
+\begin{itemize}
+    \item Manages project milestones, deadlines, meeting schedules, and documentation updates.
+    \item Responsible for backend development tasks related to event creation flows, capacity management, and RBAC endpoints.
+    \item Ensures cross-team synchronization on API specifications and helps maintain the shared Postgres/Drizzle schemas.
+    \item Maintains clarity between our team’s features and features owned by other teams.
+\end{itemize}
+
+\paragraph{Abyan — Frontend Lead \& Documentation Reviewer}
+\begin{itemize}
+    \item Leads UI development for the attendee and organizer interfaces related to the features our team owns.
+    \item Designs React component structures for registration flows, dashboards, and check-in pages.
+    \item Conducts final reviews for deliverables to ensure consistent tone, formatting, clarity, and quality.
+    \item Works with Ali and Farhan to ensure frontend and backend contract alignment.
+\end{itemize}
+
+\paragraph{Prerna — Meeting Chair, Requirements Lead \& Testing Coordinator}
+\begin{itemize}
+    \item Documents stakeholder needs, requirements, and edge cases within our team’s scope.
+    \item Maintains high-quality meeting minutes and outlines weekly priorities.
+    \item Coordinates testing plans (unit + integration) for the modules our team owns.
+    \item Ensures alignment with user needs by validating that features match problem statement expectations.
+\end{itemize}
+
+\paragraph{Mahad — DevOps \& Troubleshooting Lead}
+\begin{itemize}
+    \item Responsible for GitHub Actions pipelines, CI setup, linting/formatting configuration, and deployment scripts.
+    \item Troubleshoots cross-team issues involving repositories, merging conflicts, environment configuration, and Docker.
+    \item Supports backend debugging and helps resolve environment-level blockers.
+\end{itemize}
+
+
+\noindent Roles are subject to change based on evolving project needs and further assessment on each team members strengths.
 
 
 
@@ -180,19 +208,35 @@ \section{Project Decomposition and Scheduling}
 
 \section{Proof of Concept Demonstration Plan}
 
-The primary risks of the project are as follows.
+\subsection*{The Primary Risks Addressed by the POC are as follows:}
+
 \begin{itemize}
-    \item The ability to seamlessly integrate the system architecture components (i.e. frontend, backend, mobile app, database, APIs etc.).
-    \item The ability of end users to intuitively use all features as intended.
+    \item \textbf{Architectural Integration Risk}: The ability to seemlessly integrate frontend, backend, database, and shared APIs and interacting smoothly across teams.
+    \item \textbf{Inter-Team Merge Risk}: Conflicting implementations across teams must not break shared components
+    \item \textbf{Usability Risk}: End users must be able to use all features intuitively without confusion.
+    \item \textbf{Payment Processing Risk}: Stripe configuration, webhooks, and error handling must work reliably.
+    \item \textbf{Role-Based Access Risk}: RBAC must enforce correct permissions before more complex features depend on it.
+    \item \textbf{Capacity Management Risk}: Bus/table sign-ups must prevent overbooking in a real-time environment.
+    .
 \end{itemize}
 
-\noindent The proof-of-concept demonstration overcoming these risks will consist of.
+\subsection*{POC Demonstration overcoming these risks will consist of:}
 
+The POC will demonstrate:
 \begin{itemize}
     \item A minimal but functional demo showcasing the different architecture layers working cohesively.
+    \item A minimal working registration-to-payment workflow.
+    \item A functional RBAC setup with two sample roles (attendee and organizer).
+    \item A prototype of bus/table sign-ups controlling capacity in the shared database.
     \item A walkthrough showing a general end-user workflow (i.e. registering for events, paying for events, creating events, etc.).
+
 \end{itemize}
 
+\noindent The POC is not a feature-complete product; rather, it is a validation that the
+riskiest parts of the architecture can be implemented and merged successfully
+across teams. A failed POC signals that core architecture, dependencies, or
+integrations need revision before full implementation begins.
+
 \section{Expected Technology}
 
 \subsubsection*{Languages \& Frameworks} 

docs/ProblemStatementAndGoals/ProblemStatement.tex

@@ -25,7 +25,7 @@
 \textbf{Date} & \textbf{Developer(s)} & \textbf{Change}\\
 \midrule
 2025-09-20 & Prerna Prabhu  & Initial draft of Problem Statement and Goals\\
-... & ... & ...\\
+2025-11-17 & Prerna Prabhu & Addressed TA feedback, updated project deliverables and added security and privacy considerations \\
 \bottomrule
 \end{tabularx}
 \end{table}
@@ -34,25 +34,69 @@ \section{Problem Statement}
 
 \subsection{Problem}
 The McMaster Engineering Society (MES) organizes large-scale events such as Fireball Formal, Graduation Formal,
- and Pub Nights, often drawing several hundred attendees. Currently, registration, ticketing, waiver collection,
- and check-in processes are fragmented across multiple platforms (Google Forms, spreadsheets, Discord, Instagram,
- etc.). This lack of centralization increases the administrative burden on student organizers and creates a
- confusing, inconsistent experience for attendees.
+ and Pub Nights, each involving several hundred students. Currently, registration, ticketing, waiver collection,
+ and check-in processes are fragmented across multiple platforms including Google Forms, spreadsheets, Discord
+ announcements, Instagram posts, and manual bookkeeping methods. This fragmentation leads to duplicated work,
+ lost information, inconsistent communication, and significant administrative overhead for student organizers,
+creaing a confusing, inconsistent experience for attendees.
 \\
-\\Students struggle to:
+\\Attendees struggle to:
 \begin{itemize}
-    \item Access clear, consolidated event information.
-    \item Register efficiently for events and related logistics (tables, buses).
-    \item Receive timely updates or reminders.
+    \item Access clear, accurate, and consolidated event information.
+    \item Register efficiently for events and related logistics (tables, buses, waivers) in a single place.
+    \item Receive timely notifications, updates, confirmations, or reminders.
 \end{itemize}
 Organizers struggle to:
 \begin{itemize}
-    \item Manage ticket sales, waitlists, and attendee data in one place.
-    \item Track accessibility/dietary requirements effectively.
+    \item Track ticket sales, waivers, waitlists, registrations, and attendee data across multiple platforms.
+    \item Manage accessibility/dietary information effectively.
     \item Minimize repetitive manual effort across multiple tools.
+    \item Avoid manual errors and overbooking.
+    \item Maintain clear audit trails for finance, risk, and reporting.
 \end{itemize}
-The absence of a centralized system reduces event memorability, increases missed opportunities, and 
-wastes volunteer time that could be spent on event quality rather than administration.
+Ultimately, the absence of a centralized and reliable platform reduces event quality, increases volunteer workload,
+and creates stress for both attendees and organizers.
+
+\subsection{Project Deliverables}
+
+This capstone project is part of a larger multi-team initiative to build a full
+MES event management platform. Three teams (A, B, and C) are jointly developing
+different components of the system. The deliverables listed in this document
+reflect the specific scope assigned to our team, and does not represent the
+entirety of the platform being built across all groups.\\
+
+\noindent The main objective of our team is to deliver event functionality related to:
+
+\begin{itemize}
+    \item registration and ticketing,
+    \item secure payment processing,
+    \item RBAC/FBAC permissions for organizers,
+    \item bus and table capacity-based sign-ups,
+    \item analytics relevant to the features we own.
+\end{itemize}
+
+\noindent This section explicitly captures the deliverables our team is responsible
+for within the broader multi-team project. It clarifies boundaries,
+dependencies, and expectations while ensuring alignment with the overall MES
+platform architecture.
+
+\subsection{Additional Considerations}
+
+Because this system handles personal and financial information, security and privacy are major concerns.
+The system must ensure responsible handling of:
+\begin{itemize}
+    \item student personal details,
+    \item dietary and accessibility information,
+    \item financial transactions,
+    \item check-in data.
+\end{itemize}
+\noindent All features must meet MES expectations for confidentiality and reliability.\\
+
+\noindent The project will primarily deliver a web-based platform with a mobile-first attendee experience, though a
+standalone mobile app may be explored if time allows. Integration with other university systems (e.g., Outlook
+calendar integrations, single sign-on) is not within our team's direct scope, but the design allows for potential
+future compatibility.
+
 
 \subsection{Inputs and Outputs}
 
@@ -117,44 +161,43 @@ \section{Goals}
 
 \paragraph{Centralized Registration \& Ticketing}
 \begin{itemize}
-    \item \textbf{Description:} The platform must consolidate ticket purchasing, registration, and RSVPs into one place.
-    \item \textbf{Justification:} This eliminates confusion caused by scattered tools and ensures students always have access to the latest event information.
+    \item To reduce administrative overhead for MES organizers by 40\% (measured through reported time spent on registration tasks) by consolidating ticketing, RSVPs, and event details into one platform, in order to eliminate confusion caused by fragmented tools.
 \end{itemize}
 
-\paragraph{Payment Integration}
+\paragraph{Secure Payment Integration}
 \begin{itemize}
-    \item \textbf{Description:} Provide secure and flexible payment options (Stripe, Square, PayPal).
-    \item \textbf{Justification:} Enables students to pay quickly with widely used systems while reducing cash-handling risks for organizers.
+    \item To enable reliable, PCI-compliant payments for MES events with a transaction failure rate below 5\% during peak sales, in order to provide safe, trusted, and audit-friendly financial workflows.
 \end{itemize}
 
+
 \paragraph{Role-Based Access Control (RBAC/FBAC)}
 \begin{itemize}
-    \item \textbf{Description:} Implement granular permissions so organizers only see\slash manage the tools relevant to their role.
-    \item \textbf{Justification:} Reduces errors, ensures security, and improves efficiency in large event teams.
+    \item To reduce organizer errors caused by misconfigured access by at least 60\% (tracked through internal issue reports) by implementing RBAC/FBAC, in order to ensure secure and efficient administrative workflows.
 \end{itemize}
 
 \paragraph{Bus \& Table Sign-ups}
 \begin{itemize}
-    \item \textbf{Description:} Allow attendees to reserve buses and tables with automatic capacity tracking.
-    \item \textbf{Justification:} Simplifies logistics and avoids overbooking, replacing spreadsheets and manual coordination.
+\item To eliminate overbooking incidents (target: 0 occurrences) and reduce logistics coordination time by 50\% by providing automated holds, allocations, and real-time capacity validation.
 \end{itemize}
 
 \paragraph{Notifications \& Reminders}
 \begin{itemize}
-    \item \textbf{Description:} Send push notifications and reminders for registrations, updates, and cancellations.
-    \item \textbf{Justification:} Improves event memorability, prevents missed opportunities, and reduces no-shows.
+    \item To decrease attendee no-shows by 20\% (measured across comparable MES events) by sending automated notifications, confirmations, and reminders.
+\end{itemize}
+
+\paragraph{Analytics \& Reporting Tools}
+\begin{itemize}
+    \item To reduce MES executive reporting time by 70\% by providing dashboards for finances, demographics, accessibility data, and ticket metrics, enabling more informed planning.
 \end{itemize}
 
-\paragraph{Analytics \& Reporting}
+\paragraph{Attendee User Experience}
 \begin{itemize}
-    \item \textbf{Description:} Provide organizers with real-time dashboards on sales, demographics, and waitlists.
-    \item \textbf{Justification:} Supports decision-making, improves resource allocation, and helps executives evaluate event success.
+    \item To achieve an 85\% or higher satisfaction score in pilot testing by delivering a mobile-first interface that is accessible, intuitive, and easy to navigate.
 \end{itemize}
 
-\paragraph{Attendee Experience}
+\paragraph{Security and Privacy}
 \begin{itemize}
-    \item \textbf{Description:} Ensure the platform is mobile-first, intuitive, and accessible.
-    \item \textbf{Justification:} Reduces barriers to use, supports inclusivity, and maximizes student engagement.
+    \item To protect student personal, accessibility, and financial information with zero security/privacy incidents during the pilot period, in order to maintain trust and meet MES and university expectations for confidentiality and responsible data handling.
 \end{itemize}
 
 \section{Stretch Goals}