--- title: "요구사항 용어사전" description: "요구사항을 작성·검토할 때 같은 용어를 같은 뜻으로 사용하도록 핵심 정의와 혼동하기 쉬운 지점을 정리한다." --- 이 페이지에서 필요한 기준과 예제를 확인하세요. 본문을 복사해 새 산출물로 만들 필요는 없습니다. ## 권장 사용 순서 1. **1. 대상 정하기** 현재 작업에서 판단하거나 기록할 대상을 정한다. 2. **2. 기준 적용하기** 아래 기준과 예제를 적용하고, 확인되지 않은 항목은 따로 표시한다. 3. **3. 결과 남기기** 출처와 책임자, 다음 행동을 관련 산출물에 남긴다. ## 도구 본문 이 부록은 1–3장의 기본 개념, 25–26장의 검증·확인, 27–30장의 관리 활동을 읽거나 실제 요구를 작성·검토할 때 사용한다. 작성자는 초안에서 용어를 선택하고, 검토자는 같은 말이 장·화면·API·시험에서 같은 뜻인지 확인하며, 승인자는 기준선에 포함할 용어와 정의가 공신력 있는 출처에 근거하는지 확인한다. 아래 정의는 이 책의 용법이며 조직의 공식 용어집이 있다면 차이를 기록해 함께 관리한다. 2026년 8월 22일 확인 기준으로 [ISO/IEC/IEEE 29148:2018](https://www.iso.org/standard/72089.html)은 2024년에 현행성이 확인됐으나 개정 예정 단계다. [IREB CPRE 용어집](https://cpre.ireb.org/en/downloads-and-resources/downloads#cpre-glossary)은 영어·한국어판 2.2.0을 제공한다. 표준이나 용어집의 문구를 그대로 복제하기보다 프로젝트에서 사용할 짧은 정의, 출처와 혼동 주의점을 관리한다. ## 핵심 용어 | 한국어 표제어 | 영어 | 이 책에서의 정의 | 혼동 주의 | |---|---|---|---| | 필요 | Need | 현재와 원하는 상태 사이에서 해결할 가치가 있는 차이 | 요청한 기능이나 해결책과 같지 않다 | | 목표 | Goal | 필요를 해결해 도달하려는 방향 또는 상태 | 기능 목록이 아니며 성공 판단 근거가 필요하다 | | 업무 목표 | Business Requirement | 조직이 변화로 달성하려는 측정 가능한 업무 결과 | 소프트웨어 동작 요구와 구분한다 | | 이해관계자 | Stakeholder | 시스템·변화·요구에 영향을 주거나 영향을 받는 개인·집단·조직 | 최종 사용자만 뜻하지 않는다 | | 이해관계자 요구 | Stakeholder Requirement | 특정 이해관계자 관점에서 필요한 결과와 제약 | 이해관계자의 발언을 그대로 옮긴 문장과 다르다 | | 사용자 요구 | User Requirement | 사용자가 맥락 안에서 달성해야 하는 과업·결과 | 화면이나 버튼 설계가 아니다 | | 시스템 요구 | System Requirement | 시스템 전체가 제공하거나 지켜야 하는 능력·품질·제약 | 소프트웨어만의 책임으로 제한하지 않는다 | | 소프트웨어 요구 | Software Requirement | 소프트웨어 구성요소에 할당된 기능·품질·데이터·인터페이스 의무 | 설계·코드 구조와 구분한다 | | 요구사항 | Requirement | 필요·목표를 충족하기 위해 시스템이나 변화가 제공하거나 준수해야 할 검증 가능한 진술 | 희망, 아이디어, 설계 선택과 같지 않다 | | 기능 요구 | Functional Requirement | 시스템이 제공할 결과·행동·데이터 처리·외부 상호작용에 관한 요구 | 메뉴나 모듈 이름만으로 쓰지 않는다 | | 품질 요구 | Quality Requirement | 성능·신뢰성·보안·사용성처럼 결과가 얼마나 잘 제공돼야 하는지 나타내는 요구 | ‘빠르게’, ‘안전하게’ 같은 형용사만으로는 부족하다 | | 제약 | Constraint | 허용되는 해결 공간을 제한하는 외부 의무·환경·결정 | 선호 기술을 사실상 요구로 포장하지 않는다 | | 업무 규칙 | Business Rule | 업무 판정·허용·금지·계산을 정하는 공식 규칙 | 기능 문장 속에 출처 없이 숨기지 않는다 | | 가정 | Assumption | 계획·분석을 진행하기 위해 참으로 놓았지만 아직 확인하지 않은 명제 | 확인된 사실이나 승인된 정책처럼 쓰지 않는다 | | 위험 | Risk | 불확실한 사건·조건이 목표나 결과에 영향을 줄 가능성 | 현재 발생한 문제·결함과 구분한다 | | 쟁점 | Issue | 상충·모호성·누락처럼 판단 또는 해결이 필요한 현재 문제 | 위험과 동일한 상태로 관리하지 않는다 | | 요구사항 도출 | Requirements Elicitation | 사람·문서·시스템·관찰에서 필요·제약·근거를 발견하고 확인하는 활동 | 인터뷰 한 번이나 ‘수집’만 뜻하지 않는다 | | 요구사항 분석 | Requirements Analysis | 후보를 분류·정제하고 관계·경계·충돌·우선순위·실현 가능성을 판단하는 활동 | 문장을 예쁘게 다듬는 일에 한정되지 않는다 | | 요구사항 명세 | Requirements Specification | 요구와 관련 정보를 검토·사용할 수 있는 표현으로 기록하는 활동과 산출물 | 특정 문서 서식 하나와 같지 않다 | | 요구사항 검증 | Requirements Verification | 요구 산출물이 정한 품질 기준에 맞게 잘 작성됐는지 확인하는 활동 | 올바른 제품을 만들었는지 보는 시스템 확인과 다르다 | | 요구사항 확인 | Requirements Validation | 요구가 실제 이해관계자 필요와 사용 목적에 맞는지 확인하는 활동 | 시험 실행 결과만으로 대체되지 않는다 | | 수용 조건 | Acceptance Criteria | 항목을 수용할 수 있는 관찰 가능한 조건과 판정 기준 | 테스트 절차 전체나 구현 방법과 같지 않다 | | 추적성 | Traceability | 필요·요구·설계·시험·결정 사이의 의미 있는 관계를 양방향으로 찾고 유지하는 능력 | 링크 개수나 ID 일치만 뜻하지 않는다 | | 기준선 | Baseline | 특정 목적에 사용하도록 권한 있는 검토·승인을 거쳐 변경 통제 아래 둔 버전 집합 | 최신 파일, 배포 폴더와 같지 않다 | | 변경 요청 | Change Request | 현재 기준선과 다른 결과를 제안하고 영향·대안·결정을 추적하는 관리 항목 | 접수되었다고 승인된 것은 아니다 | ## 모델·경계·증거 용어 | 한국어 표제어 | 영어 | 이 책에서의 정의 | 수강신청 사례 | |---|---|---|---| | 시스템 경계 | System Boundary | 시스템이 책임지는 부분과 외부 환경을 나누는 경계 | 신청 접수·상태는 내부, 학사 원천은 외부 연계 후보 | | 시스템 맥락 | System Context | 시스템과 관련 있는 사람·조직·외부 시스템·환경의 집합 | 학생, 교무처, 인증·학사·규칙·알림 서비스 | | 유스케이스 | Use Case | 행위자가 목표를 달성하는 기본·대안·예외 상호작용의 구조 | `UC-REG-01` 신청과 결과 확인 | | 상태 | State | 대상이 특정 시점에 갖는 업무 의미와 허용 전이 | 접수됨, 판정 중, 처리 보류, 승인, 거절, 취소 | | 처리 보류 | Processing Pending | 안전한 판정이 끝나지 않아 후속 처리·재평가가 필요한 상태 | 규칙 서비스 시간 초과 시 `IR-001` 결과 | | 대기명단 | Waitlist | 좌석 부족 시 승인된 정책에 따라 이후 배정을 기다리는 별도 업무 개념 | 현재 사례에서는 범위·정책 미확인 | | 인터페이스 | Interface | 두 책임 경계가 정보·제어·물리 상호작용을 교환하는 접점과 계약 | `API-RULE-01`, `IR-004` | | 출처 | Source | 요구·규칙·결정의 근거가 된 사람·문서·데이터·사건 | `SRC-POL-01`, `SRC-LOG-01` | | 근거 | Rationale | 요구나 결정이 필요한 이유와 선택 이유 | 목표와 정책 목적, 대안 선택 이유 | | 증거 | Evidence | 사실 주장이나 요구 충족 여부를 뒷받침하는 확인 가능한 자료 | 승인된 정책 원문, 인터뷰 기록, 운영 지표, 시험 결과 | | 검증 방법 | Verification Method | 요구 준수를 확인할 분석·검사·시연·시험의 종류 | `FR-003`은 기능·인가 시험 후보 | | 시험 오라클 | Test Oracle | 관찰 결과를 기대 결과와 비교해 합격을 판단하는 기준 | 미정 우선정책의 승자는 아직 오라클이 없다 | | 결정 기록 | Decision Record | 질문·대안·근거·결정·결과·재검토 조건을 보존한 기록 | `ADR-ENR-001`, `DEC-001` | | 회귀 요구 | Regression Requirement | 변경 뒤에도 유지해야 하는 기존 사용자 결과·규칙·불변조건 | `REG-ENR-001–REG-ENR-006` | ## 이 책에서 구분해 쓰는 짝 **필요와 해결책.** “결과를 알 수 없어 반복 제출한다”는 필요·문제 후보이고 “푸시 알림을 만든다”는 해결 후보이다. 알림 없이 공식 상태 조회를 개선하는 대안도 비교할 수 있어야 한다. **접수와 승인.** `FR-002`의 신청 접수는 의도를 고유 신청 ID로 보존했다는 뜻이다. `FR-001`의 승인은 적용 규칙에 따른 판정과 좌석 반영이 안전하게 끝났다는 뜻이다. 제출 응답을 ‘성공’이라고만 부르면 두 의미가 섞인다. **검증과 확인.** `TC-IR-001-01`은 규칙 연계가 실패했을 때 자동 승인이 이루어지지 않는지 검증한다. `VAL-SCN-01`은 처리 보류와 후속 안내가 학생·운영 목적에 맞는지 확인한다. 같은 요구에 연결돼도 증거 역할이 다르다. **요구와 설계.** `FR-003`은 자신의 상태·공개 사유·다음 행동을 조회할 필요를 표현한다. `SCR-STATUS-01`, `API-STATUS-01`, `DATA-DECISION-01`은 그 필요를 실현할 설계 후보들이다. 기술 선택을 요구사항인 것처럼 포장하지 않는다. **처리 보류와 대기명단.** 처리 보류는 판정 불가·미완료 상태다. 대기명단은 좌석 배정 정책이다. 이 책의 사례에서 대기명단은 확인되지 않았으므로 화면·API·시험에서 두 용어를 바꿔 쓰지 않는다. **후보와 기준선.** `SRS-ENR-01`` v0.9`는 검토 후보다. 실제 정책 소유자·사용자·운영자 승인과 원문이 없으므로 기준선이라고 부르지 않는다. 버전 번호가 있다는 사실도 승인 증거가 아니다. ## 영어·약어 색인 | 영어·약어 | 한국어 표제어 | 관련 본문 | |---|---|---| | AC, Acceptance Criteria | 수용 조건 | 17장, 47장, 부록 B·C | | ADR, Architecture Decision Record | 아키텍처 결정 기록 | 20장, 33장, 48장 | | Assumption | 가정 | 14장, 27장, 44–50장 | | Baseline | 기준선 | 29–30장, 47·50장 | | Constraint | 제약 | 14장, 41장 | | Elicitation | 요구사항 도출 | 7–9장, 45장, 부록 D | | Goal | 목표 | 4장, 44장 | | Need | 필요 | 1장, 4장 | | Requirement | 요구사항 | 1–3장 | | Stakeholder | 이해관계자 | 6장, 44장 | | Traceability | 추적성 | 28장, 49장, 부록 G | | Validation | 요구사항 확인 | 26장 | | Verification | 요구사항 검증 | 25장 | ## 프로젝트 용어 등록 양식 | 필드 | 필수 | 작성 내용 | 책임자 후보 | |---|---:|---|---| | 표제어·영어·약어 | 예 | 안정된 이름과 허용 표기 | 요구 관리 책임자 | | 짧은 정의 | 예 | 한 문장으로 범위와 구별점 | 업무·요구 책임자 | | 출처·버전·확인일 | 예 | 정책·표준·전문가·결정 기록 | 출처 소유자 | | 이 프로젝트의 용법 | 예 | 화면·API·데이터에서의 의미 | 관련 산출물 책임자 | | 동의어·금지 표현 | 예 | 검색용 별칭과 혼동 방지 | 요구 관리 책임자 | | 관련 ID | 선택 | 요구·규칙·모델·시험 | 각 항목 소유자 | | 상태·승인 | 예 | 후보·검토·승인·폐기와 결정권자 | 승인 권한자 | 용어를 추가하거나 바꿀 때는 정의만 고치지 않는다. 그 용어가 쓰인 요구 문장, 상태 모델, 화면 문구, API 코드, 데이터 값, 시험 오라클과 운영 절차를 검색해 영향 여부를 기록한다. `처리 보류`를 `대기`로 줄이는 변경처럼 짧은 문구 수정도 업무 의미를 바꾸면 정식 변경 대상이다. ## 관련 학습 이 도구와 관련된 개념과 판단 근거를 복습합니다. 이 도구와 관련된 개념과 판단 근거를 복습합니다. 이 도구와 관련된 개념과 판단 근거를 복습합니다. 이 도구와 관련된 개념과 판단 근거를 복습합니다.