Requirement Engineering

# Interview: club president (20 min)
Goal: how events are organised today
## Opening (2 min)
- Thank, explain the purpose, ask to take notes
## Context (5 min)
1. Walk me through the last event you ran.
2. How did students sign up? What went wrong?
3. How many events per month? How many seats?
## Needs (8 min)
4. What do you check before announcing an event?
5. What happens when an event is full?
6. What do you need to know after the event?
7. Which student data do you really need?
## Wrap-up (5 min)
8. What would make you stop using the app?
9. Who else should we talk to?
- Summarise the top 3 needs, agree next contact

# Interview: event organiser (20 min)
Goal: understand check-in at the door
## Context (6 min)
1. Describe check-in at your last event.
2. How long was the queue? How many helpers?
3. What do you do with walk-ins?
## Needs (8 min)
4. What must you see when a student arrives?
5. What if the Wi-Fi in the hall is down?
6. When do you need the attendance list?
## Probing (4 min)
7. You said "quick": how many seconds is quick?
8. Can you show me the sheet you use today?
## Wrap-up (2 min)
9. Anything I should have asked but did not?

Feature: US-02 Register for an event
  As a student
  I want to register for an event
  So that I am sure of a seat

  Scenario: Place available
    Given event "Arduino 101" has capacity 30
    And 29 students are registered for it
    When student "e20210001" registers
    Then the registration status is Registered
    And the event has 0 free places

  Scenario: Event full
    Given event "Arduino 101" has 30 of 30 registered
    When student "e20210002" registers
    Then the registration is rejected
    And the message is "Event full"

  Scenario: Already registered
    Given student "e20210001" is registered
    When student "e20210001" registers again
    Then the registration is rejected
    And the message is "Already registered"

Feature: US-04 Cancel a registration
  Scenario: Cancel in time
    Given the event starts on 2026-10-15 at 17:00
    And student "e20210001" is Registered
    When the student cancels on 2026-10-14 at 16:59
    Then the status becomes Cancelled
    And one place is freed

  Scenario: Too late to cancel
    Given the event starts on 2026-10-15 at 17:00
    When the student cancels on 2026-10-14 at 17:01
    Then the cancellation is rejected
    And the message is "Cancellation closed"

Feature: US-07 Check in at the door
  Scenario: Registered student arrives
    Given student "e20210001" is Registered
    When the organiser scans the student card
    Then the status becomes CheckedIn
    And the confirmation appears within 1 second

Given sets up the state, When is one action, Then is an observable result. Concrete values (30 seats, 16:59 vs 17:01) test the boundary of the rule.

UC-02  Register for an event
Primary actor: Student            Level: user goal
Stakeholders: Student (wants a seat), Organiser
  (wants an accurate head count)
Precondition: the student is logged in
Trigger: the student opens an event page
Main success scenario:
  1. Student selects Register on the event.
  2. System checks that the event is in the future.
  3. System checks that the student is not registered.
  4. System checks that a place is free.
  5. System records the Registration as Registered
     and reduces the free places by one.
  6. System shows a confirmation and schedules a
     reminder 24 hours before the start.
Alternative flows:
  2a. The event is in the past:
      System shows "Event already started"; ends.
  3a. The student is already registered:
      System shows the existing registration; ends.
  4a. The event is full:
      4a1. System offers the waiting list (Should).
      4a2. Student accepts: status Waitlisted; ends.
      4a3. Student declines: the use case ends.
Postcondition: the student holds at most one
  Registration for the event.

• A use case describes how an actor reaches one goal with the system, as a numbered dialogue (Cockburn, Writing Effective Use Cases, 2001).
• Actor: a role outside the system (student, organiser, the clock for reminders).
• Precondition: what must be true before; postcondition: what is guaranteed after success.
• Main success scenario: the happy path, 3 to 9 steps, alternating actor and system.
• Alternative flows are numbered after the step where they branch: 4a branches at step 4 when the condition "event is full" holds.
• Each step says what happens, never which button or class does it.

# ITC Club Hub · Software Requirements Specification
Version 0.3 · 2026-10-13 · Team Angkor

## 1 Introduction
### 1.1 Purpose
States the requirements of Club Hub release 1 for the team,
the client (Student Affairs Office) and the testers.
### 1.2 Scope
Approved clubs publish events; students register, cancel
and check in. Out of scope: payments, chat, room booking.
### 1.4 Definitions
Registration: a student's reserved place in one Event.
Check-in: recording that a registered student attended.

## 3 Specific requirements
### 3.2 Functions
- FR-01 The system shall let only an Approved club
  publish an Event with title, start, location, capacity.
- FR-03 The system shall reject a registration when the
  number of Registered students equals the capacity.
- FR-05 The system shall reject a registration for an
  event whose start time has passed.
### 3.4 Performance
- NFR-01 Check-in shall confirm within 1 s for 95 % of
  scans when 100 students check in within 10 min.
### 3.7 Security and privacy
- NFR-06 The phone number shall be optional and visible
  only to organisers of events the student joined.

• shall marks a binding requirement; avoid "should" and "may" in requirement text, they hide whether it is mandatory.
• One requirement per id; ids are never reused, even after deletion.
• Versions and dates on top; the file lives in Git next to the code.

Scenario: Event full
  Given event "Arduino 101" has 30 of 30 registered
  When student "e20210002" registers
  Then the registration is rejected
  And the message is "Event full"

• Given becomes the arrange part: build the objects in the stated state.
• When becomes exactly one call on the class under test.
• Then becomes the assertions; no assertion, no test.
• The test name comes from the traceability matrix: RegistrationService_RejectsWhenEventFull is TEST(RegistrationService, RejectsWhenEventFull).

// tests/registration_service_test.cpp
#include <gtest/gtest.h>
#include <chrono>
#include <string>
#include "clubhub/registration_service.hpp"
#include "in_memory_repositories.hpp"

using namespace clubhub;
using namespace std::chrono;

// FR-03 · US-02 · scenario "Event full"
TEST(RegistrationService, RejectsWhenEventFull) {
    // Given event "Arduino 101" has 30 of 30 registered
    InMemoryEventRepository events;
    InMemoryRegistrationRepository registrations;
    const auto start = sys_days{2026y / October / 15} + 17h;
    events.save(Event{"E-01", "Arduino 101", start, 30});
    for (int i = 0; i < 30; ++i) {
        registrations.save(
            Registration{"E-01", "s" + std::to_string(i)});
    }
    RegistrationService service{events, registrations};
    const auto now = start - days{3};

    // When student "e20210002" registers
    // Then the registration is rejected with "Event full"
    EXPECT_THROW(service.registerStudent("E-01", "e20210002", now),
                 EventFullError);
    EXPECT_EQ(registrations.countRegistered("E-01"), 30u);
}