학술대회 시스템 요구사항 정의: 엑셀 운영 매뉴얼을 SRS로 변환

운영 매뉴얼과 엑셀 페이퍼워크를 시스템 요구사항(SRS) 초안으로 전환하는 단계

행사 당일 접수대 앞이 가장 붐비는 이유는 단 하나입니다. 사무국 직원이 노트북 화면의 엑셀과 참가자의 회원증을 번갈아 보며, 정회원인지 학생회원인지 수기로 확인하고 있기 때문입니다. 과거 행사의 수기 엑셀 관리 파일과 텍스트로만 된 사무국 매뉴얼은 사실상 완벽한 요구사항 정의서(SRS)의 뼈대입니다. 이 흩어진 페이퍼워크를 개발사가 이해할 수 있는 기능적 요구사항(FR)으로 번역하는 과정이 필요합니다.

엑셀 셀을 기능적 요구사항(FR)으로 번역하기

가장 먼저 할 일은 매뉴얼 내 '수작업'이 개입되는 모든 구간을 찾아내는 것입니다. 수기로 계산하던 시간과 노력을 시스템의 자동화 로직으로 치환하는 기준을 세워야 합니다.

현장 접수 지연 및 명찰 오발급 문제를 비기능적 요구사항(NFR)과 예외 처리로 변환

접수대 병목, 시스템 언어로 번역하기

개회식 30분 전, 로비에 인파가 몰리면 한 명당 처리 시간이 몇 초씩 누적된다. 명찰을 수동으로 찾고, 출결을 종이로 체크하고, 중복 입장을 눈으로 걸러내는 구조라면 인원을 아무리 보충해도 한계가 온다.

이 현상을 요구사항 명세서로 옮기면, 세 가지 비기능적 요구사항(NFR)이 도출된다.

• 입장 처리 속도: QR 스캔 후 3초 이내 출결 확정
• 데이터 무결성: 동일 QR 중복 스캔 자동 차단
• 자동 감사 기록: 입·퇴장 시간을 타임스탬프로 저장 — 보수교육 평점 인증 근거로 즉시 활용

"빠르게 처리해 달라"는 현장의 감정을 "3초 이내 응답"이라는 측정 가능한 조건으로 바꾸는 순간, 개발자와 운영자가 같은 기준으로 시스템을 검증할 수 있다.

대규모 집중을 예외 처리로 설계하기

참가자가 특정 시간대에 한꺼번에 몰리는 상황은 정상 케이스가 아니라 예외 케이스로 설계해야 한다. 선착순 세션 예약이 대표적이다.

수기 관리 툴의 한계 vs 확장 가능한 DB 스키마 설계 (표 포함)

엑셀 시트에 참가자 명단을 복사하고, 결제 완료 내역을 수작업으로 매칭해 본 적 있으신가요? 학회 규모가 조금만 커져도 엑셀은 데이터를 순식간에 단절시킵니다. 회원 등급, 논문 투고 현황, 결제 내역이 제각각 흩어지면 매번 서로 다른 파일을 뒤져야 하고, 데이터 불일치로 인한 누락과 중복이 발생하기 마련입니다.

여기서 확장 가능한 데이터베이스(DB) 스키마 설계가 필요해집니다. 학회명 기반 서브도메인(예: kadd.eregi.co.kr) 형태로 독립 포털을 운영하려면, 산재한 엑셀 데이터를 하나의 플랫폼에서 통합 관리하는 구조로 전환해야 합니다.

논문 모집부터 심사 위원 관리까지, 학술대회 특화 비즈니스 로직 반영 체크리스트

행사 참가자 수가 늘고 국제 학술대회 규모가 커질수록, 단순한 '폼 빌더' 형태의 등록 솔루션으로는 현장의 복잡한 업무를 감당하기 어렵습니다. 사무국이 엑셀로 관리하던 예외 처리와 수기 작업들을 시스템 요구사항(SRS)으로 넘기려면, 학술대회 특화 비즈니스 로직을 정확히 짚어내야 합니다.

일반 행사 등록 솔루션과 학회 특화 통합 솔루션의 핵심 차이는 다음과 같습니다.

이러한 차이를 엑셀 매뉴얼에서 시스템 구축 요구사항으로 옮기려면, 구체적인 운영 장면을 떠올리며 관리자 페이지의 권한과 화면을 설계해야 합니다.

관리자 페이지 필수 비즈니스 로직 점검

SRS 작성 마무리: 99.9% 가동률과 5,000명 검증된 운영 레퍼런스의 중요성

SRS 문서를 다 썼다고 끝이 아니다. 그 문서를 들고 개발사를 만나러 가는 순간부터가 진짜 판단의 시작이다. "이런 기능이 필요합니다"라고 말할 수는 있지만, "이 기능이 행사 당일에 어떻게 작동해야 합니다"까지 설득하려면 검증된 운영 레퍼런스가 필요하다.

레퍼런스가 왜 판단 기준이 되는가

. 이때 시스템이 버티느냐 멈추느냐는 SRS에 적어둔 요구사항이 아니라, 그 플랫폼이 실제로 몇 명을 처리해봤느냐로 결정된다.

e-Regi 플랫폼은 20회 이상의 행사 운영을 완료했고, 누적 참가자 5,000명 이상, 99. 9%의 서비스 가동률을 기록했다.