---
title: "47장. 요구사항 명세"
description: "분석 결과를 검토 가능한 요구사항 명세로 묶고 기능·품질·데이터·인터페이스와 열린 결함을 함께 제시한다."
---
{/* v3:question */}
## 이번 장에서 해결할 질문
분석 결과를 문장·시나리오·모델과 수용 기준으로 어떻게 명세하는가?
{/* v3:objectives */}
## 학습 목표
학습 목표
- “분석 결과를 문장·시나리오·모델과 수용 기준으로 어떻게 명세하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
- 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.
{/* v3:concepts */}
## 핵심 개념
분석 결과를 표에 옮긴다고 좋은 요구사항 명세가 완성되지는 않는다. 서로 다른 독자가 같은 범위와 동작, 품질, 데이터와 인터페이스 책임을 이해하려면 문장과 모델, 용어와 열린 결함이 하나의 일관된 구조를 이뤄야 한다. 승인되지 않은 가정을 확정된 요구처럼 포장해서도 안 된다.
이 장에서는 46장의 분석 구조를 검토 가능한 명세 후보로 조립한다. 기능·품질·데이터·인터페이스 요구와 공통 규칙을 식별자와 출처에 연결하고, 미결정·보류 항목과 검증 방법을 함께 제시해 기준선 검토가 가능한 형태를 만든다.
### 1. 검토 가능한 명세 구조를 만든다
이 사례의 요구사항 정의서 `SRS-ENR-01`` v0.9`는 **검토 후보**다. 실제 대학의 정책 원문, 사용자 확인, 목표 기준선과 승인자가 없으며 `DEF-001`, `DEF-003`, `DEF-004`, `ASM-001–ASM-004`, `ISS-001`이 열려 있다. 형식이 완성돼 보여도 `v1.0 승인 기준선`이라고 부르지 않는다.
명세의 목적·독자·범위부터 적는다.
| 항목 | `SRS-ENR-01`` v0.9` 후보 |
|---|---|
| 목적 | 신청 가능 정보, 접수·판정·상태·취소와 실패 회복을 일관되게 명시하고 설계·시험 입력 제공 |
| 주요 독자 | 학사·사업·사용자 대표, 분석·UX·아키텍처·개발·시험·운영·보안·개인정보와 외부 연계 책임자 |
| 상위 근거 | `PBR-ENR-01`, `G-01`, `BR-001`, `UR-001`, `SR-001`, 합성 도출 자료 |
| 포함 | `FR-001–FR-005`, 관련 `QR-001–QR-011`, `DR-001–DR-006`, `IR-001–IR-006`, 규칙·수용 조건·모델 |
| 제외·보류 | 좌석 대기명단, `CR-003` 우선권, 확인되지 않은 이관·알림 확대, 미정 정책·수치 |
| 상태 | 교육용 검토 후보; 실제 이해관계자 승인·계약·기준선 아님 |
문서 구조는 사용 목적에 맞춘다. 서론에는 목적·범위·정의·참조·승인 상태를, 맥락에는 사용자·외부 경계·가정·제약을 둔다. 요구 목록에는 기능·품질·데이터·인터페이스 요구를, 보조 모델에는 유스케이스·상태·규칙·품질 시나리오를 둔다. 마지막에는 수용 조건, 추적, 열린 결함·쟁점과 변경 절차를 둔다. 같은 규칙을 여러 절에 복사하지 않고 기준 항목을 참조한다.
각 요구는 본문 한 문장 외에도 관리 속성을 가진다. 문장만 복사한 별도 목록이 생기면 어느 버전·상태가 공식인지 알 수 없으므로 하나의 요구 레코드를 여러 보기에서 참조한다.
| 속성 | 기록 목적 | `FR-001` 예시 후보 |
|---|---|---|
| 안정된 ID·제목 | 링크와 대화에서 식별 | `FR-001`, 학사 규칙 기반 신청 판정 |
| 본문·용어 버전 | 정확한 의무와 적용 정의 | `v0.9`, `TERM-*`, `RULE-*` 참조 |
| 출처·근거 | 누가 왜 필요로 하는지 | `SR-001`, 정책·도출 자료; 공식 원문 미확인 |
| 상태·소유자 | 후보·검토·승인·보류와 결정 책임 | 검토 후보, 학사 정책 소유자 지정 필요 |
| 우선순위·릴리스 | 구현 순서와 적용 범위 | 핵심 후보, 실제 릴리스 미정 |
| 가정·쟁점·위험 | 불확실성과 승인 차단 조건 | `ASM-002`, `ISS-001`, `RSK-REQ-01` |
| 검증·확인 | 시험·검사·분석·사용자 확인 | `AC-FR-001-*`, 규칙·경합·사용자 시나리오 |
| 상·하위 관계 | 목표·설계·시험 양방향 추적 | `SR-001`, 같은 계층의 요구와 설계 항목 |
요구 상태를 문서 버전과 혼동하지 않는다. `SRS-ENR-01`` v0.9` 안에서도 어떤 항목은 수정 확인 후보이고 어떤 항목은 보류일 수 있다. 문서 파일을 배포했다고 모든 행이 승인되는 것은 아니다. 기준선에는 포함 요구의 정확한 버전, 유예·제외·열린 위험과 각 승인 역할이 함께 있어야 한다.
참조 자료 목록에도 공식성과 날짜를 둔다. `SRC-POL-01`은 원문이 확보되지 않았고 `SRC-LOG-01`은 값이 미수집이며 `SRC-STU-01`은 합성 기록이다. 이런 자료를 단순 “참고문헌”으로 나열하면 실제 증거처럼 보인다. `공식성`, `현행성`, `접근 위치`, `적용 범위`, `확인자`, `한계`를 기록하고 폐기된 문서는 요구 근거에서 분리한다.
사용하는 핵심 용어는 42장의 정의와 일치시킨다. 교과목은 교육과정 단위, 분반은 특정 학기·시간·정원으로 개설된 제공 단위다. 신청은 학생의 승인 의도와 처리 생명주기이고, 수강 등록은 권한 있는 승인으로 성립한 학생-분반 관계 후보다. 처리 보류는 안전한 판정이 끝나지 않은 상태이며 좌석 대기명단이 아니다. 이 정의가 화면·API·데이터·시험에서 달라지면 명세 결함이다.
상위 요구는 하위 기능의 존재 이유를 설명한다.
| ID | 명세 후보 | 근거·상태 |
|---|---|---|
| `G-01` | 다음 학기에 결과를 알 수 없는 상태와 관련한 반복 제출·수동 재처리를 줄이고 신청을 설명·회복 가능하게 한다 | 방향 후보, 실제 문제 기준선 없음 |
| `BR-001` | 다음 학기 첫 30분 수동 재처리를 이전 학기보다 50% 줄인다 | 측정 계약·투자 승인 전 |
| `UR-001` | 학생은 신청 가능한 강좌와 자신의 신청·거절 결과 및 공개 가능한 사유를 확인할 수 있어야 한다 | 실제 사용자 확인 전 |
| `SR-001` | 시스템은 자격·선수과목·시간 충돌·최대 학점·정원·승인된 우선 조건을 평가하고 결과와 사유를 제공해야 한다 | 우선 조건·규칙 출처 미확인 |
`SR-001`의 “승인된 우선 조건”은 `CR-003`을 승인했다는 뜻이 아니다. 현행성과 공식성이 확인된 규칙만 적용한다는 뜻이다. 정책이 없으면 우선권 로직을 만들지 않는다. `BR-001`도 수치가 있어 보이지만 분모·기준 학기·사건 정의가 없으므로 인수 기준으로 쓰지 않는다.
핵심 기능 요구는 주체·조건·반응과 예외 경계를 유지한다.
| ID·제목 | 명세 문장 후보 | 주요 연결·미결 |
|---|---|---|
| `FR-001` 학사 규칙 기반 신청 판정 | 시스템은 유효한 신청에 대해 적용 기준 시점의 학생·분반·학사 규칙과 강좌 상태를 평가하고, 승인되면 신청 승인 식별자를, 거절되면 안정된 거절 사유를 기록·제공해야 한다 | `RULE-001–RULE-005`, `DR-001–DR-003`, `IR-003–IR-004`, `ISS-001` |
| `FR-002` 신청 접수 | 시스템은 인증·대상·신청 기간과 요청 형식을 확인해 신청 의도를 고유 요청·신청 식별자로 접수하고 접수 결과를 제공해야 한다 | 접수는 승인 아님, `DR-002`, `IR-002` |
| `FR-003` 결과·상태 조회 | 인증된 학생은 자신의 신청 ID로 접수·현재 판정 상태, 공개 가능한 사유, 마지막 갱신 시각과 가능한 다음 행동을 조회할 수 있어야 한다 | `UR-001`, `UI-001`, `QR-001`, 공개 정책 미정 |
| `FR-004` 중복 안전 | 동일 신청 의도의 재전송은 복수의 신청 승인·좌석 반영 효과를 만들지 않고 기존 신청 상태와 연결돼야 한다 | 동일성·시간 창 미정, `QR-003`, `DR-002–DR-004` |
| `FR-005` 취소 | 인증된 학생은 정책상 허용된 상태·기간의 자신의 신청을 취소할 수 있고, 시스템은 취소 결과와 정원·상태 후속 변화를 일관되게 기록해야 한다 | 늦은 판정·재배정·예외 권한 미정 |
한 문장에 모든 세부를 억지로 넣지 않는다. `FR-001`의 규칙별 조건은 규칙 카탈로그와 결정표에, 성능·접근성은 `QR`에, 입력·응답 계약은 `IR`과 API 설계에 둔다. 단, 참조가 없어도 핵심 의무와 실패 결과를 오해하지 않을 정도의 문맥은 유지한다.
기능 요구는 금지 결과도 함께 읽는다.
- 권한 있는 승인 결정 없이 수강 등록을 성립시키지 않는다.
- 규칙 실패·무효·시간 초과를 승인으로 변환하지 않는다.
- 동일 신청 의도가 복수의 최종 효과를 만들지 않는다.
- 다른 학생의 신청·사유를 조회하거나 변경하지 않는다.
- 취소·더 새로운 상태를 늦은 판정 응답이 덮지 않는다.
- 승인된 정원 정책을 넘는 수강 등록을 만들지 않는다.
마지막 항목은 `RULE-004`의 실제 출처·예외가 확인된 범위에서 적용한다. 누가 마지막 좌석을 얻는지는 `ISS-001`이 해결돼야 하지만 정원 초과 금지와 배정 순서는 구분할 수 있다.
품질 요구는 이름이 아니라 자극·환경·반응·측정으로 명시한다.
| ID | 품질 요구 후보 | 검증·상태 |
|---|---|---|
| `QR-001` 성능 | 합의된 피크 부하 환경에서 자신의 신청 상태 조회 응답시간은 후보 p95 2초 이하여야 한다 | 부하·데이터·경계·오류 기준 미정, `DEF-003` |
| `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` 개인정보 | 목적에 필요한 최소 개인정보만 처리하고 승인된 접근·보존·파기·공개 범위를 적용해야 한다 | 법·조직 정책·기간 미정 |
표의 모든 수치는 후보라는 한계를 반복해서 표시한다. 99.9%나 2배가 업계 관행처럼 보여도 현재 서비스의 손실·비용·외부 계약에 맞는지는 모른다. 보호 불변조건과 개인정보·접근성 의무는 인기나 성능 목표로 낮추지 않는다.
대표 품질 시나리오는 여러 표의 의미를 하나로 묶는다.
| 시나리오 | 출처·자극 | 환경·대상 | 반응·측정 후보 | 연결 |
|---|---|---|---|---|
| `QAS-PERF-01` | 인증된 학생이 자신의 상태 조회 | 합의 피크 부하, 상태 조회 경로 | 본인 상태·사유·갱신 시각, p95 2초 후보와 오류·신선도 보호 | `FR-003`, `QR-001`, `QR-005`, `DR-004` |
| `QAS-REC-01` | 규칙 실패·무효·시간 초과 | 신청 판정 중 | 자동 승인 0, 원인 코드 보류, 재조회·재평가 추적 | `IR-001`, `QR-003`, `QR-010`, `DR-001` |
| `QAS-AUTH-01` | 다른 학생의 신청 ID로 직접 접근 | 인증된 악의·오류 요청 | 내용 비공개·변경 없음·안전한 사건 기록 | `QR-005`, `QR-011`, `FR-003` |
| `QAS-CAP-01` | 마지막 좌석에 동시 신청 | 같은 공식 상태·규칙 버전 | 정원 초과·중복된 승인·좌석 반영 없음, 결과·근거 대사 | `RULE-004`, `QR-003`, `ISS-001` |
시나리오의 수치가 비어 있으면 품질 이름으로 덮지 않는다. `QAS-REC-01`의 최대 보류 시간·재평가 처리량은 `DEF-001`로, `QAS-CAP-01`의 예상 승자는 `ISS-001`로 돌아간다. 지금 검증할 수 있는 것은 자동 승인 금지와 정원 초과 금지 같은 안전 조건이지 미정 정책의 승자가 아니다.
데이터 요구는 판정의 의미와 재현·생명주기를 정의한다.
| ID | 데이터 요구 후보 | 상태·연결 |
|---|---|---|
| `DR-001` | 학생·강좌 ID, 요청 시각, 결과, 사유, 규칙 버전과 최종 상태 변경을 판정 기록에 둔다 | 규칙 버전은 `ASM-002` 확인 전 |
| `DR-002` | 신청과 요청·판정·상태 변경을 고유 식별자로 연결한다 | 멱등·상관 경계 후보 |
| `DR-003` | 학생·강좌·규칙 입력의 원천과 기준 시점을 판정에 연결한다 | 일관성·재현 입력 |
| `DR-004` | 현재 상태와 변경 이력이 모순되지 않게 유지한다 | 덮어쓰기·늦은 응답 금지 |
| `DR-005` | 데이터별 목적·접근·보존·파기 기준을 적용한다 | 정책 미정, `DEF-004` |
| `DR-006` | 이관 전후 건수·관계·핵심 값과 이력을 대사할 수 있게 한다 | 실제 이관 범위 확인 전 |
데이터 항목 자체보다 공식 원천과 기준 시점이 중요하다. 현재 잔여 좌석만 저장해 과거 판정을 재현할 수 없거나, 모든 학적 정보를 스냅숏으로 무기한 복사하면 각각 감사·개인정보 요구를 해친다. 원천 참조, 필요한 판정 스냅숏, 파생 현재 상태와 변경 이력을 구분한다.
이 장의 명세 구조를 한 문서에서 살펴보고 프로젝트용 빈 구조로 전환하려면 부록 E. 요구사항 정의서 예제를 사용할 수 있다. 예제는 교육용 검토 후보이므로 실제 조직의 승인 기준선으로 간주하지 않는다.
### 2. 데이터·인터페이스·품질을 명세한다
인터페이스 요구는 화면 API뿐 아니라 조직·외부 서비스 경계의 의미와 실패 계약을 다룬다.
| ID | 인터페이스 요구 후보 | 상태·안전 결과 |
|---|---|---|
| `IR-001` | 규칙 서비스가 실패·무효·시간 초과이면 자동 승인하지 않고 원인 코드가 있는 처리 보류로 기록하며 재평가할 수 있어야 한다 | 보류 종료·좌석 정책 미해결 |
| `IR-002` | 인증 주체·역할·만료 정보를 권한 판정에 사용할 수 있게 교환한다 | 역할 매핑·장애 책임 확인 전 |
| `IR-003` | 학적·이수·강좌 데이터의 원천·기준 시점·변경을 식별한다 | 계약·신선도 확인 전 |
| `IR-004` | 규칙 판정 요청 ID, 결과·사유, 규칙 버전과 유효성을 연결한다 | `ASM-002` 확인 전 |
| `IR-005` | 통지 요청과 전달 결과를 신청 판정과 구분해 추적한다 | 알림은 공식 상태를 바꾸지 않음 |
| `IR-006` | 파일 이관의 형식·검증·대사·재처리 계약을 정의한다 | 실제 파일 연계 범위 확인 전 |
계약에는 제공·소비 주체, 인증·인가, 스키마·코드·단위·널, 기준 시점, 버전, 시간 제한·용량, 중복·순서, 오류·재시도, 개인정보, 변경 통보·운영 연락과 시험을 포함한다. 이 절은 특정 프로토콜이나 제품을 요구하지 않는다.
업무 규칙은 기능 문장과 분리하되 판정에서 빠지지 않게 연결한다.
| ID | 규칙 후보 | 확인할 예외·경계 |
|---|---|---|
| `RULE-001` | 학생은 적용되는 선수 조건을 충족해야 한다 | 동시 이수·대체·면제·성적 시점 |
| `RULE-002` | 승인으로 계산되는 학점 합계가 적용 최대 신청 학점을 넘지 않아야 한다 | 재수강·초과 승인·보류 포함 여부 |
| `RULE-003` | 시간표가 겹치는 두 분반의 수강 등록은 함께 성립할 수 없다 | 부분 겹침·비동기 수업·예외 |
| `RULE-004` | 승인된 수강 등록 수는 적용 정원을 넘지 않아야 한다 | 정원 변경·예약석·우선 배정·경합 |
| `RULE-005` | 우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다 | 대상·강좌·기간·동순위·예약석·예외 |
다섯 규칙 모두 공식 원문·예외·시행 버전이 없는 후보다. `CR-003`은 `RULE-005`의 현행 내용이 아니며 별도 변경 요청이고, 승인되더라도 `RULE-004`의 정원 한도는 별도로 재검증한다. 결정표는 조건 조합을 보여 줄 수 있지만 정책이 비어 있는 셀을 임의 결과로 채우지 않는다.
명세 문장은 유스케이스 `UC-REG-01`로 시간 순서와 예외를 보완한다.
| 필드 | 유스케이스 후보 |
|---|---|
| 목표 | 학생이 특정 분반에 신청하고 현재 판정 결과·사유를 확인 |
| 주 행위자 | 인증된 학생 |
| 지원 행위자 | 인증·학사·강좌·규칙 서비스, 알림·운영 역할 |
| 선행조건 | 신청 기간·대상 분반·권한과 필요한 원천 사용 가능성; 세부 정책 미확정 |
| 성공 보장 | 승인된 경우 하나의 수강 등록 효과와 재현 가능한 결정 기록 |
| 최소 보장 | 실패해도 근거 없는 승인·중복 처리 결과·권한 외 공개 없음, 현재 상태 추적 가능 |
기본 흐름은 다음과 같다.
1. 학생이 분반과 신청 의도를 제출한다.
2. 시스템은 인증·대상·기간·요청 형식과 동일 요청 여부를 확인하고 신청 ID로 접수한다.
3. 학생·분반·규칙 입력의 원천과 기준 시점을 식별한다.
4. `RULE-001–RULE-005`의 적용 가능한 승인된 버전으로 자격·학점·시간·정원을 평가한다.
5. 승인되면 하나의 승인 효과와 식별자를, 거절되면 안정된 공개 사유를 기록한다.
6. 학생은 자신의 현재 상태·사유·갱신 시각과 다음 행동을 조회한다.
7. 통지가 있다면 판정과 별도로 전달 결과를 추적한다.
대안·예외 흐름은 최소한 다음을 포함한다.
| 흐름 | 촉발 | 결과 후보 | 연결 |
|---|---|---|---|
| `A1` 중복 요청 | 동일 의도·요청이 다시 수신됨 | 새 효과 없이 기존 신청·상태 제공 | `FR-004`, `DR-002–DR-004` |
| `A2` 규칙 거절 | 유효 판정이 규칙 미충족 | 거절·공개 사유·다른 선택/문의 | `FR-001`, `FR-003`, `RULE` |
| `E1` 판정 불가 | 규칙 실패·무효·시간 초과 | 자동 승인 없이 처리 보류·원인·재평가 | `IR-001`, `DEF-001` |
| `E2` 인증 만료 | 주체·권한을 확인할 수 없음 | 요청 중단·재인증, 기존 상태 훼손 없음 | `IR-002`, `QR-005` |
| `E3` 응답 유실 | 접수 뒤 연결이 끊김 | 요청 ID로 상태 조회, 재전송돼도 중복 처리 없음 | `FR-003–FR-004` |
| `E4` 취소·늦은 판정 | 취소와 판정 응답이 경합 | 더 새로운 유효 상태를 늦은 결과가 덮지 않음 | `FR-005`, `DR-004` |
상태 모델도 같은 의미를 표현해야 한다.
접수됨은 승인됨이 아니고 처리 보류는 좌석 대기명단이 아니다. 전이마다 촉발 사건, 권한, 입력·규칙 버전, 전후 상태와 금지 결과를 `DR-001–DR-004`로 기록한다. 재평가 종료와 보류가 좌석에 미치는 영향은 모델에 빈칸으로 남겨 `DEF-001`, `ASM-003`을 가리킨다.
수용 조건은 예시와 시험 오라클을 제공하지만 미정 정책을 창작하지 않는다.
| 수용 조건 | Given | When | Then | 상태 |
|---|---|---|---|---|
| `AC-FR-001-01` | 유효한 학생·분반·승인 규칙 입력 | 신청을 판정 | 규칙별 결과·사유·버전과 하나의 최종 상태 기록 | 규칙 원문 전 후보 |
| `AC-FR-001-02` | 하나 이상의 승인 규칙 미충족 | 판정 완료 | 승인 효과 없이 거절·안정된 공개 사유 | 복수 실패 우선 사유 미정 |
| `AC-FR-004-01` | 같은 의도의 기존 신청이 있음 | 같은 요청을 재수신 | 승인·좌석 반영이 중복되지 않고 기존 상태에 연결 | 동일성 기준 미정 |
| `AC-FR-005-01` | 취소 가능한 자신의 승인 신청 | 취소 요청 승인 | 취소 상태·정원 후속·이력 일치 | 가능 상태·시점 미정 |
| `AC-IR-001-01` | 규칙 실패·무효·시간 초과 | 판정 시도 | 자동 승인 없이 원인 코드 보류·재평가 추적 | 종료 목표 미정 |
`QR-001`의 수용 조건에는 동시 사용자, 요청률·혼합, 데이터 규모, 워밍업·캐시, 측정 경계, 표본·백분위 계산, 오류율·신선도·인가를 포함해야 한다. 조건이 없으므로 현재는 시험 설계 입력이지 계약 합격 기준이 아니다. `QR-003`은 마지막 좌석·동시 요청·중복·재시작·부분 실패에서 승인·좌석·결정·감사 데이터를 대사한다.
명세 검증은 항목별 검사와 산출물 간 일관성을 함께 본다.
| 검증 관점 | 표본 질문 | 발견 시 돌아갈 곳 |
|---|---|---|
| 정확성 | 원문 정책·사용자 필요의 의무와 예외를 보존하는가? | [45장](/learn/workshop/chapter-45) 출처·권한 확인 |
| 완전성 | 정상·거절·보류·중복·취소·인가·복구가 있는가? | [46장](/learn/workshop/chapter-46) 누락 분석 |
| 일관성 | 문장·유스케이스·상태·규칙·수용 조건의 결과가 같은가? | 해당 모델·결정 기록 |
| 명확성 | 주체·대상·조건·반응·단위·용어가 해석 가능한가? | 용어사전·문장 정제 |
| 실현 가능성 | 외부 계약·데이터·비용과 운영 능력으로 가능한가? | [41장](/learn/context-future/chapter-41) ASR·대안, 공급 협의 |
| 검증 가능성 | 관찰 환경·오라클·판정 주체가 있는가? | 수용 조건·정책 결정 |
| 추적성 | 목표·출처와 설계·시험 후보를 양방향으로 찾는가? | [49장](/learn/workshop/chapter-49) 관계 모델 |
동료검토 결과 후보는 실제 회의를 본뜬 상태표로만 사용한다.
| 검토 항목 | 판단 후보 | 근거·후속 |
|---|---|---|
| 접수와 판정 구분 | 명세상 일관 | `FR-002–FR-003`, 상태 모델, 실제 사용자 확인 전 |
| 알림과 공식 상태 | 수정 반영 후보 | `IR-005`를 보조 전달로 분리 |
| 안전 보류 | 조건부 명세 가능 | `IR-001`; `DEF-001`, `ASM-003` 미해결 |
| 성능 목표 | 기준선 불가 | `QR-001`, `DEF-003` 측정 계약 필요 |
| 감사·개인정보 | 조건부 | `DR-005`, `QR-009–QR-011`, 보존 정책 필요 |
| 우선권 | 명세 제외·보류 | `CR-003`, `ISS-001`, 공식 근거 없음 |
확인 활동은 독자별로 다른 자료를 사용하되 같은 요구 버전을 본다. 학생은 `UC-REG-01`과 상태 프로토타입으로 목표·표현·회복을, 학사 책임자는 규칙 결정표와 예외로 정책 정확성을, 운영자는 장애·보류·대사 시나리오로 회복 가능성을 확인한다. 시험 담당자는 오라클·환경·관찰을, 보안·개인정보 책임자는 인가·공개·보존을, 외부 제공자는 계약·버전·오류를 검토한다.
| 확인 게이트 | 입력 | 가능한 결과 | 남길 증거 |
|---|---|---|---|
| 사용자 확인 | 과업·상태·사유 프로토타입 | 확인·수정·대표성 부족 | 참여 맥락·관찰·수정·반례 |
| 정책 확인 | 규칙 원문·결정표·쟁점 | 승인·조건부·보류·반려 | 조항·권한·시행·예외·이의 |
| 기술·운영 검토 | 품질·연계·데이터 시나리오 | 실현 가능·실험 필요·제약 충돌 | 대안·비용·위험·실험 계획 |
| 검증 검토 | AC·환경·시험 후보 | 오라클 충분·결함·미정 | 결함 ID·수정·잔여 위험 |
| 기준선 결정 | 포함 요구·결함·확인 결과 | 승인·조건부·보류 | 버전·서명 역할·조건·만료 |
조건부 승인은 결함을 숨기는 용어가 아니다. 승인 범위, 충족해야 할 조건, 임시 통제, 책임자·기한과 미이행 결과가 있어야 한다. `DEF-001`처럼 업무 결과를 결정하지 못하는 항목은 단순 문서 보완 조건으로 넘길 수 없고 관련 기능의 기준선 편입을 막을 수 있다.
명세 변경은 검토 의견을 즉석 덮어쓰지 않는다. 수정 제안, 영향받는 ID·모델·시험, 결정자와 반영 버전을 기록한다. 의미 없는 오탈자, 의미를 명확히 하는 변경, 정책·범위 변경은 서로 다른 통제가 필요하다. `CR-003`을 “문장 보완”으로 `RULE-005`에 넣는 것은 허용하지 않는다.
기준선 통과 조건 후보는 범위 일치, 출처의 공식성, 결함 처리, 실현·시험 가능성, 역할별 확인과 버전 재현을 본다. 현재는 중대 미해결 항목이 있고 실제 승인자도 없으므로 `BL-ENR-01`을 승인했다고 표시할 수 없다. `SRS-ENR-01`` v0.9`는 다음 장의 **설계 탐색 입력**으로만 사용할 수 있고, 미해결 정책에 의존하는 설계는 결정을 확정하지 않는다.
48장에는 이 버전과 열린 항목을 함께 넘긴다. 설계자는 `FR-003`의 상태 제공, `IR-001`의 안전 보류, `QR-003`의 불변조건을 구체화할 수 있지만 보류 좌석·우선 배정·성능 규모를 임의 확정할 수 없다. 설계에서 새로운 제약과 파생 요구가 나오면 명세에 역으로 제안하고 승인 전에는 별도 후보 상태를 유지한다.
### 3. 기준선 후보를 설계로 넘긴다
{/* v3:case */}
## 수강신청 사례에 적용
수강신청 사례의 결정·근거·남은 쟁점을 47장에서 다룬 기준으로 구분한다.
{/* v3:criteria */}
## 판단 기준과 흔한 오류
:::warning[판단하기 전에 확인]
- 결정이 확인 가능한 출처와 근거를 가지고 있는가?
- 구현·검증·변경에 필요한 다음 행동과 책임자가 분명한가?
:::
{/* v3:practice */}
## 직접 해보는 실습
1. **1. 대상 선택**
현재 프로젝트 산출물 중 이 장의 질문과 관련된 항목 하나를 고른다.
2. **2. 근거와 예외 표시**
본문의 판단 질문으로 누락된 근거와 예외를 표시한다.
3. **3. 다음 행동 기록**
확인할 책임자, 필요한 최소 증거와 다음 행동을 기록한다.
{/* v3:summary */}
## 핵심 요약
:::success[이 장에서 가져갈 기준]
분석 결과를 검토 가능한 요구사항 명세로 묶고 기능·품질·데이터·인터페이스와 열린 결함을 함께 제시한다.
:::
{/* v3:next */}
## 관련 도구와 다음 경로
바로 사용할 수 있는 점검표와 예제를 확인합니다.
학습 순서에 따라 다음 판단 주제로 이어갑니다.