요구사항 용어사전

요구사항을 작성·검토할 때 같은 용어를 같은 뜻으로 사용하도록 핵심 정의와 혼동하기 쉬운 지점을 정리한다.

권장 사용 순서

1. 대상 정하기

현재 작업에서 판단하거나 기록할 대상을 정한다.

2. 기준 적용하기

아래 기준과 예제를 적용하고, 확인되지 않은 항목은 따로 표시한다.

3. 결과 남기기

출처와 책임자, 다음 행동을 관련 산출물에 남긴다.

이 부록은 1–3장의 기본 개념, 25–26장의 검증·확인, 27–30장의 관리 활동을 읽거나 실제 요구를 작성·검토할 때 사용한다. 작성자는 초안에서 용어를 선택하고, 검토자는 같은 말이 장·화면·API·시험에서 같은 뜻인지 확인하며, 승인자는 기준선에 포함할 용어와 정의가 공신력 있는 출처에 근거하는지 확인한다. 아래 정의는 이 책의 용법이며 조직의 공식 용어집이 있다면 차이를 기록해 함께 관리한다.

2026년 8월 22일 확인 기준으로 ISO/IEC/IEEE 29148은 2024년에 현행성이 확인됐으나 개정 예정 단계다. IREB CPRE 용어집은 영어·한국어판 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 코드, 데이터 값, 시험 오라클과 운영 절차를 검색해 영향 여부를 기록한다. 처리 보류를 대기로 줄이는 변경처럼 짧은 문구 수정도 업무 의미를 바꾸면 정식 변경 대상이다.