호텔 관리 시스템 소프트웨어 요구사항 명세서 (SRS)¶

작성자: 페닐 데사니

---

목차¶

목차	페이지
1 서론	3
1.1 목적	3
1.2 범위	3
1.3 용어, 약어 및 축약어	4
1.4 개요	4
2 전반적 설명	4
2.1 제품 관점	4
2.1.2 소프트웨어 인터페이스	4
2.2 제품 기능	4
2.3 사용자 특성	5
2.4 요구사항 분배	5
2.5 가정 및 의존성	5
3 구체적 요구사항	6
3.1 외부 인터페이스	6
3.1.1 사용자 인터페이스	6
3.1.2 소프트웨어 인터페이스	6
3.1.3 하드웨어 인터페이스	6
3.1.4 통신 인터페이스	7
3.2 기능 요구사항	7
3.3 비기능 요구사항	9
3.3.1 성능 요구사항	9
3.3.2 논리적 데이터베이스 요구사항	9
3.3.3 설계 제약조건	10
3.3.4 표준 준수	10
3.3.5 신뢰성	10
3.3.6 가용성	10
3.3.7 보안	10
3.3.8 유지보수성	10
3.3.9 이식성	10

---

호텔 관리 시스템 소프트웨어 요구사항 명세서¶

---

1 서론¶

다음 섹션들은 호텔 관리 시스템(HMS)에 대한 소프트웨어 요구사항 명세서(SRS)의 개요를 제공합니다.

1.1 목적¶

본 소프트웨어 요구사항 명세서(SRS)는 호텔 관리 시스템(HMS)의 요구사항을 상세히 기술합니다.

이 문서는 HMS가 제공해야 할 기능과 특성을 명확히 이해할 수 있도록 하며, 시스템 설계·구현·테스트 단계의 기초 자료로 사용됩니다.

소프트웨어 엔지니어는 이 SRS를 바탕으로 기대되는 기능을 정확히 파악하여 시스템을 개발하고,

호텔 담당자는 결과물이 기대에 부합하는지 검증할 수 있습니다.

1.2 범위¶

개발될 소프트웨어는 주요 호텔 운영을 자동화하는 호텔 관리 시스템입니다.

첫 번째 하위 시스템은 예약 및 예약 관리 시스템으로, 객실 예약 현황을 관리합니다.

두 번째 하위 시스템은 식음료 판매 시스템으로, 투숙객 계정에 음식 요금을 청구합니다.

세 번째 하위 시스템은 종합 관리 및 자동화 시스템으로, 운영 보고서를 생성하고 하위 시스템 정보를 수정·관리합니다.

하위 시스템별 주요 사용자 유형은 고객 서비스 담당자(CSR)와 호텔 관리자입니다.

두 사용자 모두 예약 및 식음료 시스템에 접근할 수 있으며, 관리자만 종합 관리 시스템에 접근할 수 있습니다.

시스템 목표는 100실 규모로 확장된 호텔 운영 업무를 간소화하고,

사용자가 빠르고 정확하게 서비스를 제공받을 수 있도록 지원하는 것입니다.

1.3 용어, 약어 및 축약어¶

• SRS – 소프트웨어 요구사항 명세서
  
• HMS – 호텔 관리 시스템
  
• 주관적 만족도 – 시스템 사용자의 전반적 만족도
  
• 최종 사용자 – 시스템을 실제로 사용하는 호텔 직원 및 관리자
  

1.4 개요¶

SRS는 크게 두 부분으로 구성됩니다.

첫째, 전반적 설명(Overall Description)에서는 시스템 요구사항을 높은 수준에서 개괄합니다.

둘째, 구체적 요구사항(Specific Requirements)에서는 상세한 기능 및 비기능 요구사항을 기술합니다.

---

2 전반적 설명¶

이 섹션은 제품 및 요구사항에 영향을 미치는 일반적 요소를 설명합니다.

구체적 요구사항은 3장에 정의되어 있으며, 이 장은 그 배경과 맥락을 제공합니다.

2.1 제품 관점¶

HMS는 독립형 스탠드얼론 시스템으로, 외부 시스템과의 통합 없이 자체 기능만으로 운영됩니다.

2.1.1 하드웨어 인터페이스¶

시스템은 호텔 내 PC에 설치되어 운영됩니다.

2.1.2 소프트웨어 인터페이스¶

• 데이터베이스: MySQL
  
• 관리 정보: 객실, 고객 정보
  
• 객실 DB: 방 번호, 점유 여부
  
• 고객 DB: 이름, 인원 수, 지정 객실, 기본 요금(수정 가능), 연락처, 보장 여부, 신용카드 번호, 확인 번호, 자동 취소 일시, 예상/실제 체크인·체크아웃 정보, 미납 금액, 고객 피드백
  

2.2 제품 기능¶

주요 하위 시스템별 기능은 다음과 같습니다.

• 예약 및 예약 관리 시스템

  • 고객 정보 입력
    
  • 기본 객실 요금 조정 및 변경 사유 기록
    
  • 체크인 시 객실 상태 점유로 변경
    
  • 예약 수정 기능
    
  • 잔여 객실 없을 시 대기자 명단 등록 및 가용 시 알림
    
  • 체크아웃 시 청구 금액 표시 및 객실 상태 비점유로 변경
    
  • 예정 체크아웃 후 미체크아웃 시 추가 숙박 요금 청구 및 보고
    
  • 결제 기록 및 고객 피드백 입력
    

• 식음료 판매 시스템

  • 판매된 식음료 내역 추적
    
  • 결제 및 결제 수단 기록
    
  • 결제 미완료 시 객실로 청구
    
  • 레스토랑 및 룸서비스 예약 접수
    

• 종합 관리 및 자동화 시스템

  • 호텔 점유율·미래 점유율·객실 및 식음료 매출 보고서 생성
    
  • 예외 보고서(기본 요금·식음료 요금 변경 내역)
    
  • 객실·요금·메뉴·가격·사용자 프로필 추가·삭제·수정
    
  • 사용자 계정 생성 및 비밀번호 할당
    

2.3 사용자 특성¶

• 교육 수준: 낮음
  
• 시스템 사용 경험: 없음
  
• 기술 전문성: 거의 없음
  

2.4 요구사항 분배¶

시스템 알림 음성 및 시각 효과는 우선순위가 낮아 향후 단계로 이관됩니다.

2.5 가정 및 의존성¶

• 생성된 보고서는 저장할 의무 없음
  
• 신용카드 결제 기능은 포함되지 않음
  

---

3 구체적 요구사항¶

이 섹션은 설계자·테스터가 시스템을 설계·검증하는 데 필요한 상세 요구사항을 정의합니다.

3.1 외부 인터페이스¶

시스템은 표준 PC 입력·출력 장치를 사용합니다.

• 키보드
  
• 마우스
  
• 모니터
  
• 프린터
  

3.1.1 사용자 인터페이스¶

화면 이름	설명
로그인	CSR 또는 관리자 권한으로 시스템 접속
예약	예약 조회; 저장/업데이트; 취소; 수정; 요금 조정; 결제 타입/신용카드
체크인	고객 체크인(예약 여부 상관없음); 요금 조정; 특별 요청; 결제
체크아웃	고객 체크아웃; 청구서 생성
호텔 결제	객실·식음료 결제 수락
룸서비스/레스토랑	주문 생성; 수정; 조회; 취소; 식사요금 청구
고객 정보	고객 정보 추가/수정
객실 관리	객실 가용성 및 요금 관리
사용자 관리	사용자 생성/수정/삭제; 비밀번호 변경
식음료 메뉴 관리	메뉴 아이템 및 가격 생성/수정/삭제
보고서	보고서 조회; 저장; 삭제

3.1.2 소프트웨어 인터페이스¶

시스템은 Oracle 또는 Access 데이터베이스와 연동됩니다.

3.1.3 하드웨어 인터페이스¶

시스템은 Microsoft Windows 기반 환경에서 실행됩니다.

3.1.4 통신 인터페이스¶

독립형 제품으로 외부 통신 인터페이스는 필요하지 않습니다.

3.2 기능 요구사항¶

기능 요구사항은 예약·식음료·관리 세 영역으로 구분됩니다.

1. 예약/예약 관리¶

1.1 시스템은 예약 정보를 기록해야 한다.

1.2 시스템은 고객의 이름(이름 및 성)을 기록해야 한다.

1.3 시스템은 인원 수를 기록해야 한다.

1.4 시스템은 객실 번호를 기록해야 한다.

1.5 시스템은 기본 객실 요금을 표시해야 한다.

1.6 시스템은 기본 요금 변경 기능을 제공해야 하며, 변경 사유를 기록해야 한다.

1.7 시스템은 고객 전화번호를 기록해야 한다.

1.8 시스템은 객실 보장 여부를 표시해야 한다.

1.9 시스템은 각 예약에 고유 확인 번호를 생성해야 한다.

1.10 시스템은 미보장 예약에 대해 체크인 당일 18시까지 신용카드 정보 미제공 시 자동 취소해야 한다.

1.11 시스템은 예상 체크인 일시를 기록해야 한다.

1.12 시스템은 예상 체크아웃 일시를 기록해야 한다.

1.13 시스템은 고객 체크인 기능을 제공해야 한다.

1.14 시스템은 예약 수정 시 모든 정보를 재입력하지 않아도 수정할 수 있어야 한다.

1.15 시스템은 고객 체크아웃 기능을 제공해야 한다.

1.15.1 시스템은 청구 금액을 표시해야 한다.

1.15.2 고객 조회는 성 또는 객실 번호로 가능해야 한다.

1.15.3 시스템은 객실 상태를 비점유로 변경해야 한다.

1.15.4 시스템은 결제 내역을 기록해야 한다.

1.15.5 시스템은 결제 수단을 기록해야 한다.

1.16 시스템은 11시 이후 체크아웃 시 추가 숙박 요금을 청구해야 한다.

1.17 시스템은 보장 객실을 체크인 당일 18시 이후 미체크인 시 의무 결제 상태로 표시해야 한다.

1.18 시스템은 고객 피드백을 기록해야 한다.

2. 식음료¶

2.1 시스템은 호텔 내 모든 식음료 구매 내역을 추적해야 한다.

2.2 시스템은 식음료 결제 및 결제 수단을 기록해야 한다.

2.3 시스템은 현장 결제 미완료 시 객실로 청구해야 한다.

2.4 시스템은 레스토랑 및 룸서비스 예약을 접수해야 한다.

3. 관리¶

3.1 시스템은 지정 기간(과거·현재·미래 포함) 점유율을 조회해야 한다.

3.2 시스템은 지정 기간 점유율 예측을 조회해야 한다.

3.3 시스템은 지정 기간 객실 매출을 조회해야 한다.

3.4 시스템은 지정 기간 식음료 매출을 조회해야 한다.

3.5 시스템은 요금 변경 예외 보고서를 제공해야 한다.

3.6 시스템은 객실·요금·메뉴·가격·사용자 프로필 정보를 추가할 수 있어야 한다.

3.7 시스템은 객실·요금·메뉴·가격·사용자 프로필 정보를 삭제할 수 있어야 한다.

3.8 시스템은 객실·요금·메뉴·가격·사용자 프로필 정보를 수정할 수 있어야 한다.

3.9 시스템은 관리자가 사용자 비밀번호를 할당·변경할 수 있어야 한다.

3.3 비기능 요구사항¶

시스템 특성(성능·데이터베이스·제약·표준·신뢰성·가용성·보안·유지보수·이식성)을 정의합니다.

3.3.1 성능 요구사항¶

• UI 화면 로드 시간은 2초 이내여야 한다.
  
• 로그인 정보 검증은 5초 이내여야 한다.
  
• 쿼리 응답 시간은 5초 이내여야 한다.
  

3.3.2 논리적 데이터베이스 요구사항¶

• 예약 시스템: 고객 이름·주소·전화번호·인원 수·객실·요금·보장 여부·신용카드·확인 번호·자동 취소 일시·체크인·체크아웃 예상·실제 일시·피드백·결제 여부 및 유형·총 청구액
  
• 식음료: 식사 유형·항목·주문 내역·결제 유형(객실 청구/신용카드/수표/현금)
  

3.3.3 설계 제약조건¶

• 독립형 Windows 환경
  
• Java 언어 사용
  
• Access 또는 Oracle 데이터베이스
  

3.3.4 표준 준수¶

• 변수명 일관성 유지
  
• GUI 일관된 Look & Feel
  

3.3.5 신뢰성¶

• 납품 시 요구되는 신뢰성 요소 정의
  

3.3.6 가용성¶

• 정상 호텔 운영 시간 내 시스템 가용성 보장
  

3.3.7 보안¶

• CSR과 관리자는 로그인 화면에서 사용자 이름·비밀번호로 인증
  
• CSR은 예약·식음료 시스템 접근
  
• 관리자는 전 시스템 접근
  

3.3.8 유지보수성¶

• Java 객체지향 개발로 유지보수 용이성 확보
  

3.3.9 이식성¶

• Java Runtime과 Access가 설치된 모든 Windows 환경에서 실행 가능
  

---