--- title: "요구사항 정의서 예제" description: "대학 수강신청 사례로 요구사항 정의서의 구성과 항목 수준을 살펴보고 프로젝트에 맞게 조정할 기본 구조를 제공한다." --- 이 페이지에서 필요한 기준과 예제를 확인하세요. 본문을 복사해 새 산출물로 만들 필요는 없습니다. ## 권장 사용 순서 1. **1. 대상 정하기** 현재 작업에서 판단하거나 기록할 대상을 정한다. 2. **2. 기준 적용하기** 아래 기준과 예제를 적용하고, 확인되지 않은 항목은 따로 표시한다. 3. **3. 결과 남기기** 출처와 책임자, 다음 행동을 관련 산출물에 남긴다. ## 도구 본문 이 부록은 47장을 읽은 뒤 요구사항 정의서의 구조와 항목 수준을 정할 때 사용한다. 아래 `SRS-ENR-01`` v0.9`는 대학 수강신청 사례를 한 문서로 모은 **교육용 검토 후보**다. 실제 대학의 정책 원문·로그·인터뷰·승인자가 없으므로 기준선이나 개발 승인 문서가 아니다. 독자는 형식을 그대로 복사하기보다 프로젝트의 결정 질문과 위험에 맞춰 절을 줄이거나 보완해야 한다. ## 문서 통제 정보 | 항목 | 예제 값 | 작성 책임·검토 질문 | |---|---|---| | 문서 ID·버전 | `SRS-ENR-01`` v0.9` | 요구 관리 책임자 / 어느 기준선 후보인가? | | 제목 | 수강신청 결과·회복 개선 요구사항 정의서 | 요구 책임자 / 해결책보다 범위·목적이 드러나는가? | | 상태 | 검토 후보, 미승인 | 승인 권한자 / 증거와 실제 상태가 일치하는가? | | 대상 시점 | 다음 학기 후보 | 정책·프로젝트 책임자 / 발효·출시 일정이 실제로 있는가? | | 작성 근거 | `PBR-ENR-01`, `ELI-PLAN-01`, `ANL-IN-01`, `ANL-DEF-01` | 출처가 합성·미수집임을 표시했는가? | | 주요 검토 역할 | 학생, 교무·학사 정책, 운영, 설계, 시험, 보안·개인정보·접근성, 외부 연계 | 한 역할이 다른 역할의 권한을 대신하지 않는가? | | 제외 변경 | `CR-003` 졸업예정자 우선권 | 정책·근거 미완료로 보류됐는가? | ## 목적과 범위 이 문서의 목적은 결과를 알 수 없어 반복 제출이 생길 수 있는 수강신청 흐름에서 신청 접수·판정·상태·사유·중복·취소와 외부 실패에 관한 요구를 검토할 수 있게 표현하는 것이다. `G-01`은 다음 학기에 결과를 알 수 없어 생기는 반복 제출과 수동 재처리를 줄이고, 신청 결과를 설명하며 문제가 생겼을 때 회복할 수 있게 만드는 방향 후보다. `BR-001`은 첫 30분 수동 재처리를 이전 학기보다 50% 줄인다는 후보 목표이나 실제 기준선·분모·측정 계약이 없다. | 범위 포함 | 범위 제외·미확인 | |---|---| | 강좌 탐색과 신청 판단에 필요한 정보 | 교육과정·강좌 개설 정책의 전면 개편 | | 신청 의도 접수와 고유 ID | 등록금·수납·장학 업무 | | 학사 규칙·강좌 상태 판정과 결과·사유 | 실제 졸업예정자 우선권 `CR-003` | | 중복 안전, 상태 조회, 허용 취소 | 좌석 대기명단 정책·기능 | | 규칙 실패의 처리 보류·재평가 후보 | 운영자의 근거 없는 수동 승인 | | 인증·학사·규칙·알림·파일 연계 요구 | 특정 제품·DB·메시지 브로커 확정 | 시스템 경계 안에는 신청 접수·상태 조정·판정 결과 통일·본인 상태 제공·취소·감사 가능한 운영 책임이 있다. 인증, 학사정보, 규칙, 알림과 파일 이관은 외부 연계 후보다. 외부가 결과를 제공해도 내부는 입력 유효성, 시간 제한, 인가, 상태 전이와 안전 결과를 책임진다. ## 이해관계자와 용어 | 역할 | 주요 관심·지식 | 결정·확인 범위 후보 | |---|---|---| | 학생 | 신청 결과·사유·다음 행동, 접근 가능한 사용 | 자신의 과업·표현 확인, 정책 승인 아님 | | 교무·학사 정책 책임자 | 선수·학점·시간·정원·예외 | 공식 규칙·시행 버전·정책 승인 | | 학생지원·운영자 | 보류·정정·문의·재처리·대사 | 운영 가능성, 허용 조치·감사 검토 | | 설계·개발 책임자 | 기능 경계·계약·데이터·품질 전술 | 실현 가능성·설계 결정, 정책 대행 금지 | | 시험·QA | 수용 조건·환경·오라클·증거 | 검증 충분성, 요구 승인과 구분 | | 보안·개인정보·접근성 책임자 | 인가·최소 처리·보존·과업 접근 | 해당 보호 기준·잔여 위험 검토 | | 외부 제공자 | 인증·학사·규칙·알림 계약 | 제공 범위·SLA·버전·오류 의미 | 핵심 용어는 부록 A를 따른다. `접수됨`은 신청 의도가 내구성 있게 식별됐다는 뜻이며 `승인됨`과 다르다. `처리 보류`는 안전한 판정이 끝나지 않은 상태이고 좌석 부족 `대기명단`이 아니다. 교과목은 교육과정 단위, 분반은 특정 학기·시간·정원으로 개설된 제공 단위다. ## 가정·쟁점·결정 상태 | ID | 내용 | 현재 상태 | 기준선 영향 | |---|---|---|---| | `ASM-001` | 반복 제출이 수동 재처리의 유의한 원인이다 | 미확인 | `BR-001` 인과·투자 판단 차단 | | `ASM-002` | 규칙 서비스가 판정에 필요한 규칙 버전을 제공한다 | 미확인 | 감사·재현 설계 조건부 | | `ASM-003` | 처리 보류 신청은 좌석을 점유하지 않는다 | 미확인 | 좌석·취소·재평가 설계 차단 | | `ASM-004` | 직전 학기 첫 30분 자료가 다음 학기 목표와 비교 가능한 기준선이다 | 미확인 | `BR-001` 기준값·성과 판정 조건부 | | `ISS-001` | 우선 배정과 정원 초과 금지의 충돌·마지막 좌석 판정 | 미해결 | 승자 오라클·배정 설계 차단 | | `DEC-001` | 정원·우선 처리의 결정 후보 | 제안됨, 보류 | 승인된 설계로 사용 금지 | | `CR-003` | 졸업예정자 우선 신청 정책 제안 | 추가 정보 요청과 보류 | 현 요구·설계 후보 변경 없음 | ## 상위 요구 | ID | 명세 후보 | 상태·근거 | |---|---|---| | `G-01` | 다음 학기에 결과를 알 수 없어 생기는 반복 제출·수동 재처리를 줄이고, 신청 결과를 설명하며 문제가 생겼을 때 회복할 수 있게 한다 | 방향 후보, 실제 문제 기준선 없음 | | `BR-001` | 다음 학기 첫 30분 수동 재처리를 이전 학기보다 50% 줄인다 | 후보 수치, 측정 계약 없음 | | `UR-001` | 학생은 신청 가능한 강좌와 자신의 신청·거절 결과 및 공개 가능한 사유를 확인할 수 있어야 한다 | 실제 사용자 확인 전 | | `SR-001` | 시스템은 자격·선수과목·시간 충돌·최대 학점·정원과 승인된 우선 조건을 평가하고 결과·사유를 제공해야 한다 | 규칙 원문·우선 조건 미확인 | `SR-001`의 “승인된 우선 조건”은 `CR-003`이 승인됐다는 뜻이 아니다. 공식 근거와 시행 버전이 확인된 조건만 적용한다는 자리다. ## 기능 요구 | ID | 요구 문장 후보 | 검증·미결 | |---|---|---| | `FR-001` | 시스템은 유효한 신청에 대해 적용 기준 시점의 학생·분반·학사 규칙과 강좌 상태를 평가하고, 승인되면 신청 승인 식별자를, 거절되면 안정된 거절 사유를 기록·제공해야 한다 | 규칙 결정표·경계·경합, `ISS-001` | | `FR-002` | 시스템은 인증·대상·신청 기간과 요청 형식을 확인해 신청 의도를 고유 요청·신청 식별자로 접수하고 접수 결과를 제공해야 한다 | 접수는 승인 아님, 응답 유실 | | `FR-003` | 인증된 학생은 자신의 신청 ID로 접수·현재 판정 상태, 공개 가능한 사유, 마지막 갱신 시각과 가능한 다음 행동을 조회할 수 있어야 한다 | `TC-FR-003-01`, 공개 정책·성능 환경 | | `FR-004` | 동일 신청 의도의 재전송은 여러 신청 승인이나 좌석 변동을 만들지 않고 기존 신청 상태와 연결돼야 한다 | `TC-DUP-001-01`, 동일성·보존 창 | | `FR-005` | 인증된 학생은 정책상 허용된 상태·기간의 자신의 신청을 취소할 수 있고, 시스템은 취소 결과와 정원·상태 후속 변화를 일관되게 기록해야 한다 | `TC-CAN-001-01`, 허용 상태·경합 | 금지 결과는 기능 문장과 함께 읽는다. 권한 있는 판정 없이 등록을 성립시키지 않고, 규칙 실패를 승인으로 바꾸지 않으며, 같은 의도의 중복 처리·정원 초과·다른 학생 정보 공개·늦은 응답의 최신 상태 덮어쓰기를 허용하지 않는다. ## 품질 요구 | ID | 품질 요구 후보 | 주요 미결·검증 | |---|---|---| | `QR-001` | 합의된 피크 환경에서 자신의 상태 조회 응답시간은 후보 p95 2초 이하여야 한다 | `DEF-003`, `PT-STATUS-001` 미실행 | | `QR-002` | 본 신청 기간에 정의된 핵심 업무는 후보 99.9% 가용해야 한다 | 기능·창·외부 의존 미정 | | `QR-003` | 동시·중복·재시작·부분 실패에도 복수 승인, 정원 초과와 모순 상태를 만들지 않아야 한다 | 경합·장애 주입·대사 | | `QR-004` | 기준 요청량의 후보 2배에서도 승인된 성능·오류·신뢰성 기준을 유지해야 한다 | 기준량·자원·비용 미정 | | `QR-005` | 인증·인가되지 않은 주체와 다른 학생 객체의 조회·변경을 거부하고 사건을 기록해야 한다 | 객체 인가·세션·API 시험 | | `QR-006` | 대표 사용자는 신청·상태 과업과 공개 사유의 다음 행동을 합의한 성공 기준으로 이해해야 한다 | 실제 표본·기준선 없음 | | `QR-007` | 핵심 신청·상태 과업은 적용 WCAG 기준과 지원 보조기술·키보드에서 차단 없이 이용 가능해야 한다 | 대상 기술·브라우저·당사자 평가 | | `QR-008` | 승인된 규칙 변경의 영향받는 요구·설계·시험·계약·운영 자료를 추적하고 정한 시간 안에 갱신·검증할 수 있어야 한다 | 시간 목표·조직 기준 없음 | | `QR-009` | 권한 있는 역할은 판정·상태 변화를 원천·주체·입력·규칙 버전까지 재현할 수 있어야 한다 | 검색 목표·변조 통제 없음 | | `QR-010` | 정의된 장애에서 안전 상태를 보존하고 합의한 목표 안에 재평가·복구·대사할 수 있어야 한다 | 복구·데이터 손실·적체 목표 없음 | | `QR-011` | 목적에 필요한 최소 개인정보만 처리하고 승인된 접근·보존·파기·공개 범위를 적용해야 한다 | 법·조직 정책·기간 확인 전 | ## 데이터·인터페이스 요구 | 범주 | ID | 의무 후보 | |---|---|---| | 데이터 | `DR-001` | 학생·강좌 ID, 요청 시각, 결과, 사유, 규칙 버전과 최종 상태 변경을 판정 기록에 연결 | | 데이터 | `DR-002` | 신청과 요청·판정·상태 변경을 고유 식별자로 연결 | | 데이터 | `DR-003` | 학생·강좌·규칙 입력의 원천과 기준 시점을 판정에 연결 | | 데이터 | `DR-004` | 현재 상태와 변경 이력을 모순 없이 유지 | | 데이터 | `DR-005` | 데이터별 목적·접근·보존·파기 기준 적용 | | 데이터 | `DR-006` | 이관 전후 건수·관계·핵심 값과 이력을 대사 가능하게 유지 | | 인터페이스 | `IR-001` | 규칙 실패·무효·시간 초과 시 자동 승인 없이 원인 코드 처리 보류와 재평가 제공 | | 인터페이스 | `IR-002` | 인증 주체·역할·만료 정보를 권한 판정에 사용할 수 있게 교환 | | 인터페이스 | `IR-003` | 학적·이수·강좌 데이터의 원천·기준 시점·변경 식별 | | 인터페이스 | `IR-004` | 판정 요청 ID, 결과·사유, 규칙 버전·유효성 연결 | | 인터페이스 | `IR-005` | 통지 요청·전달 결과를 신청 판정과 구분해 추적 | | 인터페이스 | `IR-006` | 파일 이관의 형식·검증·대사·재처리 계약 정의 | ## 업무 규칙 | ID | 규칙 후보 | 확인할 경계 | |---|---|---| | `RULE-001` | 적용되는 선수 조건을 충족해야 한다 | 동시 이수·대체·면제·성적 시점 | | `RULE-002` | 승인으로 계산되는 학점 합계가 적용 최대 신청 학점을 넘지 않아야 한다 | 재수강·초과 승인·보류 포함 여부 | | `RULE-003` | 시간표가 겹치는 두 분반의 수강 등록은 함께 성립할 수 없다 | 부분 겹침·비동기·예외 | | `RULE-004` | 승인된 수강 등록 수는 적용 정원을 넘지 않아야 한다 | 정원 변경·예약석·우선 배정·경합 | | `RULE-005` | 우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다 | 대상·강좌·기간·동순위·예약석·예외 | 다섯 규칙 모두 공식 원문·예외·시행 버전이 없는 후보다. `CR-003`은 `RULE-005`의 현행 내용이 아니라 별도 변경 요청이며 `RULE-004`의 정원 한도 영향도 재검증해야 한다. ## 유스케이스와 상태 모델 | 필드 | `UC-REG-01` 후보 | |---|---| | 목표 | 학생이 특정 분반에 신청하고 현재 판정 결과·사유를 확인 | | 주 행위자 | 인증된 학생 | | 지원 행위자 | 인증·학사·강좌·규칙 서비스, 알림·운영 역할 | | 성공 보장 | 승인된 경우 하나의 등록 효과와 재현 가능한 판정 기록 | | 최소 보장 | 근거 없는 승인·중복 처리·권한 외 공개 없이 현재 상태 추적 가능 | ```text 제출 의도 → 접수됨 → 판정 중 ├─ 승인됨 → 정책상 허용 시 취소됨 ├─ 거절됨 └─ 처리 보류 → 재평가 중 → 승인됨 / 거절됨 / 다시 보류 ``` 기본 흐름은 제출, 유효 접수·신청 ID 생성, 입력 자료의 기준 시점 식별, 승인된 규칙 평가, 결과·사유 기록과 본인 상태 조회다. 중복 요청은 기존 신청에 연결한다. 규칙을 판정할 수 없으면 처리를 보류하고, 인증이 만료되면 기존 상태를 훼손하지 않은 채 중단한다. 응답이 유실되면 신청 ID로 다시 조회하며, 취소나 늦은 판정이 생기면 더 최근 상태를 유지한다. ## 수용 조건과 품질 시나리오 | ID | Given | When | Then | 상태 | |---|---|---|---|---| | `AC-FR-001-01` | 유효 학생·분반·승인 규칙 입력 | 신청 판정 | 규칙별 결과·사유·버전과 하나의 최종 상태 기록 | 규칙 원문 전 후보 | | `AC-FR-004-01` | 같은 의도의 기존 신청 | 같은 요청 재수신 | 새로운 승인 결과나 좌석 변동 없이 기존 상태 연결 | 동일성 창 미정 | | `AC-IR-001-01` | 규칙 실패·무효·시간 초과 | 판정 시도 | 자동 승인 없이 원인 보류·재평가 추적 | 종료 목표 미정 | | `AC-FR-005-01` | 취소 가능한 자신의 신청 | 취소 요청 | 취소 상태·후속 좌석·이력 일치 | 정책 미정 | | 품질 시나리오 | 자극·환경 | 기대 반응·측정 후보 | 연결 | |---|---|---|---| | `QAS-PERF-01` | 합의 피크에서 본인 상태 조회 | 상태·사유·갱신 시각, p95 2초 후보와 오류·신선도 보호 | `FR-003`, `QR-001`, `QR-005` | | `QAS-REC-01` | 판정 중 규칙 실패·무효·시간 초과 | 자동 승인 0, 원인 보류, 재평가 추적 | `IR-001`, `QR-003`, `QR-010` | | `QAS-AUTH-01` | 다른 학생 신청 ID로 직접 접근 | 내용 비공개·상태 불변·안전한 사건 기록 | `QR-005`, `QR-011` | | `QAS-CAP-01` | 마지막 좌석 동시 신청 | 정원 초과·중복 처리 0건, 결과·근거 대사 | `RULE-004`, `QR-003`, `ISS-001` | ## 추적·검토·승인 대표 하향 경로는 `FR-003`` → ``FEAT-STATUS-01`` → ``FLOW-ENR-01`` → ``SCR-STATUS-01`` → ``API-STATUS-01`` → ``DATA-DECISION-01`` → ``TC-FR-003-01`이다. 시험 ID는 실행 결과가 아니며, 현재 구현·환경·실행 증거는 없다. | 검토 역할 | 검토 대상 | 현재 결과 | |---|---|---| | 요구 책임자 | 정확성·완전성·일관성·상태 | 후보 문서 구성, 열린 결함 유지 | | 학사 정책 소유자 | `RULE-001–RULE-005`, `ISS-001`, `CR-003` | 실제 원문·결정 없음 | | 학생·운영 | `UC-REG-01`, 상태·사유·회복 | 실제 참여자 확인 없음 | | 설계·외부 제공자 | 기능 할당·계약·데이터·실현 가능성 | `DES-ENR-01`` v0.1` 후보 | | QA·전문 검토자 | 수용·품질·보안·개인정보·접근성 | 시험·평가 미실행 | 따라서 문서 상태는 `검토 후보`로 유지한다. 승인하려면 공식 정책·실제 도출 자료·열린 가정과 쟁점의 결정, 측정 계약, 역할별 검토와 정확한 버전에 대한 승인 기록이 필요하다. ## 프로젝트용 기본 구조 1. 문서 통제: ID·버전·상태·목적·대상 기준선·변경 이력 2. 배경과 목표: 문제·현재 기준·목표·측정·근거 3. 범위와 맥락: 포함·제외·외부 책임·시스템 경계 4. 이해관계자와 용어: 역할·권한·용어집 5. 가정·제약·위험·쟁점·결정 6. 요구 구조: 업무·이해관계자·사용자·시스템·소프트웨어 요구 7. 기능·품질·데이터·인터페이스·규칙 8. 유스케이스·상태·결정표·데이터·맥락 모델 9. 수용 조건·검증 방법·확인 시나리오 10. 추적, 우선순위, 릴리스·적용 범위 11. 검토 의견·미해결·조건·승인 기록 각 절에는 목적, 필요한 입력, 작성·검토·결정 역할과 완료 조건을 둔다. 비어 있는 절을 억지로 채우지 말고 적용 불가 근거 또는 후속 책임을 기록한다. ## 관련 학습 이 도구와 관련된 개념과 판단 근거를 복습합니다. 이 도구와 관련된 개념과 판단 근거를 복습합니다. 이 도구와 관련된 개념과 판단 근거를 복습합니다. 이 도구와 관련된 개념과 판단 근거를 복습합니다. ## 이 도구를 사용하는 가이드 이 도구를 실제 업무에서 어떤 순서로 쓰는지 확인합니다. 이 도구를 실제 업무에서 어떤 순서로 쓰는지 확인합니다.