누구에게 어떤 방법으로 확인했고, 합의한 요구가 결과물과 검증에 연결됐는지를 본다.
인터뷰는 개인의 맥락을 깊이 듣기 좋고, 관찰은 말로 드러내지 못하는 실제 일을 볼 수 있다. 워크숍은 해석 차이를 함께 풀 수 있고, 설문은 넓은 집단의 경향을 확인하기 좋다. 프로토타입은 모호한 기대를 구체적인 반응으로 바꾼다. 한 방법을 모든 요구에 똑같이 적용하지 않는다.
요구는 기능뿐 아니라 성능·보안·규제·전환·운영 조건을 포함한다. 출처·우선순위·수용 기준·변경 상태와 담당자를 연결하면 누락과 과도한 추가를 발견할 수 있다. 요구 추적 매트릭스는 번호가 있다는 사실보다 추적 가능한 관계가 중요하다.
아래 가상 추적 사례에서 요구·작업·지정 검증·결과물 버전을 연결한다. 실행한 시험의 통과율과 요구별 검증 완료는 분모가 다르며, 사용 목적 적합성·공식 수용·Scrum의 Done도 각각 확인한다.
생각을 정리하는 순서
- 1대상과 업무 맥락을 찾는다
- 2필요에 맞는 도출 기법을 조합한다
- 3요구·결과·검증을 추적한다
비교해서 이해하기
| 개념 | 설명 | 확인할 점 |
|---|---|---|
| 요구 도출 · Elicitation | 이해관계자의 필요·조건을 다양한 방법으로 발견하고 명확히 하는 활동. | 질문지를 보내는 한 가지 기법과 동일하지 않다. |
| 관찰 · Observation | 실제 업무 수행과 제약을 보며 필요를 찾는 방법. | 설명된 절차와 실제 행동의 차이를 드러낸다. |
| 촉진 워크숍 · Facilitated workshop | 여러 관점을 함께 검토하고 합의를 돕는 협업 방식. | 목소리 큰 사람의 요구만 채택하는 회의가 아니다. |
| 비기능 요구 · Nonfunctional requirement | 성능·보안·신뢰성처럼 어떻게 동작해야 하는지의 조건. | 고객이 직접 클릭하는 기능만이 요구가 아니다. |
| 요구 추적 매트릭스 · RTM | 요구 출처→목표→산출물→시험·수용을 연결하는 기록. | 연결을 갱신하지 않으면 번호 목록에 머문다. |
예제로 따라가기
가상 예제: 승인 화면은 완성됐지만 현장에서는 대리 승인 권한 때문에 못 쓴다.
승인자뿐 아니라 대리인·감사·운영의 실제 업무를 관찰한다.
역할과 예외 경로를 요구·산출물·수용 시험에 연결한다.
새 요구인지 원래 필요의 누락인지와 승인 상태를 구분해 관리한다.
시험이 전부 통과해도, 미검증 요구가 남을 수 있어요.
가상 신청 서비스의 승인된 요구 집합은 v1.2, 확인한 결과물은 B-07입니다. 아래 네 요구와 각 요구의 지정 검증 항목이 이번 예제의 전체 범위라고 가정합니다. 실제 회사 자료·Jira 연결·접근성 인증 사례가 아닙니다.
앞으로는 “어떤 증거로 이 요구를 확인할까?”, 뒤로는 “이 시험·작업은 어떤 필요 때문에 존재할까?”를 묻습니다. 연결은 갱신할 관계이며 일회성 순서도가 아닙니다. 사용자 목적에 대한 확인은 설계·개발 중에도 반복할 수 있습니다.
숫자 셋의 분모부터 읽어 보세요.
두 번째 비율은 실행한 자동 시험만 분모에 넣었습니다. 미실행 자동 시험 1건과 수동 확인은 포함하지 않았습니다. 첫 번째는 연결의 존재, 세 번째는 이 사례가 지정한 요구별 검증 완료입니다. 서로 다른 지표를 평균 내어 “전체 품질 점수”로 만들지 않습니다. 1/4는 모든 위험이25% 해결됐다는 뜻도 아닙니다.
재시도 중복 신청 방지
- 필요의 출처
- SRC-01 · 신청자 관찰
- 업무 목적
- 불안정한 응답 때문에 다시 눌러도 같은 요청이 중복 접수되지 않게 한다.
- 항목별 확인 기준
- 같은 요청 키에는 신청 한 건만 만들고, 다른 요청 키는 별도 신청으로 처리한다.
- T-01a 같은 키 재시도 (자동)통과
- T-01b 응답 시간 초과 후 재시도 (자동)통과
- T-01c 같은 키 동시 요청 (자동)통과
- T-01d 다른 키의 별도 신청 (자동)통과
증거 묶음 · 요구v1.2 / 결과물B-07 / 지정 검증 4/4 완료. 미실행은 통과도 실패도 아닙니다.
유효한 위임의 단건 승인
- 필요의 출처
- SRC-02 · 승인 업무 워크숍
- 업무 목적
- 승인자 부재 중에도 합의된 위임 범위에서 단건 업무를 처리한다.
- 항목별 확인 기준
- 유효 기간의 지정 대리인만 단건 승인하며, 다른 사람과 만료된 위임은 허용하지 않는다.
- T-02a 기간 내 지정 대리인 허용 (자동)통과
- T-02b 다른 사람의 요청 거절 (자동)통과
- T-02c 만료 위임 거절 (자동)미실행
증거 묶음 · 요구v1.2 / 결과물B-07 / 지정 검증 2/3 완료. 미실행은 통과도 실패도 아닙니다.
키보드로 신청 완료
- 필요의 출처
- SRC-03 · 사용자 업무 관찰
- 업무 목적
- 마우스 없이도 정해진 신청 흐름을 끝낼 수 있게 한다.
- 항목별 확인 기준
- 합의한 브라우저·입력 자료에서 키보드만으로 항목 입력·오류 수정·제출·결과 확인이 가능하다.
- T-03 합의한 흐름을 키보드로 점검 (수동)미실행
증거 묶음 · 요구v1.2 / 결과물B-07 / 지정 검증 0/1 완료. 미실행은 통과도 실패도 아닙니다.
운영 인계와 복구 연습
- 필요의 출처
- SRC-04 · 운영자 인터뷰
- 업무 목적
- 오류 발생 시 담당자가 복구 절차와 연락 경로를 사용할 수 있게 한다.
- 항목별 확인 기준
- 합의한 인계 문서를 검토하고 모의 오류를 대상으로 복구 연습 결과를 남긴다.
- T-04a 인계 문서 검토 (수동)통과
- T-04b 합의한 모의 복구 연습 (수동)미실행
증거 묶음 · 요구v1.2 / 결과물B-07 / 지정 검증 1/2 완료. 미실행은 통과도 실패도 아닙니다.
서로 다른 질문을 같은 “통과”로 합치지 않기
Verification · 명세 적합성
정해진 요구에 맞게 만들어졌는지 증거를 확인합니다. 시험만이 아니라 분석·검사·시연도 목적에 맞는 방법이 될 수 있습니다. 결과물·요구·환경·방법의 버전을 함께 봅니다.
Validation · 사용 목적 적합성
의도한 사용자와 환경에서 실제 목적에 맞는지 확인합니다. 자동 시험 통과만으로 이 판단을 끝내지 않습니다. 여기서는 NASA의 product validation 의미로 사용하며 프로젝트의 공식 범위 수용과 같은 명칭으로 취급하지 않습니다.
Acceptance · 합의된 인수 판단
이 사례의 합의 조건·결과물·남은 이슈를 정해진 권한자가 확인하고 기록하는 판단입니다. 구체적인 권한과 절차는 프로젝트의 합의에 따릅니다. 이 예제는 계약상 권리나 법적 효력을 해석하지 않습니다.
Done · Scrum의 공통 품질 기준
Scrum을 적용할 때 완료 정의는 Increment의 품질 기준입니다. 충족하지 않은 작업을 완료된 Increment로 세지 않습니다. Sprint Review는 결과·변화를 함께 검토해 다음 적응을 논의하는 자리이며 출시를 위한 고정 승인 관문으로 두지 않습니다. 일반 프로젝트의 인수 절차와 구분합니다.
변경 요청이 오면 연결을 따라 영향을 찾아요.
CR-01 · 대량 승인도 추가해 주세요. 기존 합의는 지정 대리인의 단건 승인입니다. 새 요청이 기존 요구의 해석·누락인지 추가 범위인지 먼저 문서와 당사자에게 확인합니다. 아래는 추가 범위로 확인됐다는 가정입니다.
- 영향 후보 찾기
요구 R-02의 위임·승인 동작과 R-04의 운영 대응부터 추적합니다. 화면·설계·자료·오류 처리·검증·운영 문서와 다른 요구의 영향도 확인합니다. 이 목록은 완전한 영향 분석 결과가 아닌 시작점입니다.
- 권한과 접근법에 맞게 결정
승인된 기준선의 변경은 정한 변경 결정 경로로 보냅니다. 적응형 백로그의 우선순위 조정도 예산·계약·품질 제약을 자동 변경하지는 않습니다. 모든 조직에 NASA의 CCB 구조를 그대로 요구하는 것은 아닙니다.
- 승인된 변경과 증거 버전 갱신
승인되면 요구·설계·작업·시험·수용 기록의 관계를 갱신합니다. 기존 B-07/v1.2의 증거를 새 버전의 완료 근거로 자동 승계하지 않습니다. 영향을 받은 검증과 회귀 범위를 정하고, 재사용 가능한 증거는 근거를 기록합니다.
자료를 보고 판단해 보기
비채점 적용 연습 · 기존 채점 문제와 별개입니다.
자동 시험 통과율100%인데 왜 R-02는 미완료인가요?
6/6은 실행된 자동 시험만의 통과율입니다. R-02의 필수 만료 위임 검증 T-02c가 실행되지 않았습니다. 요구별 지정 검증 완료율의 분모는4개 요구이고, 모두 끝난 것은R-01뿐이라1/4입니다.
T-02c가 미실행이면 결함이라고 보고할까요?
지금 확정할 수 있는 것은 검증 공백입니다. 결과가 없으니 통과도 결함도 단정하지 않습니다. 실행 조건·담당·시점을 정하고 결과에 따라 결함 수정이나 다른 조치를 판단합니다.
새 작업에 요구의 부모 링크가 없으면 바로 삭제할까요?
연결 누락인지, 설계·운영에서 정당하게 도출된 필요인지, 승인 없이 더한 범위인지 먼저 확인합니다. 목적·근거·결정 권한을 추적하고 기록을 고칩니다. 링크가 없다는 사실만으로 작업의 가치나 불필요성을 확정하지 않습니다.
Done이면 인수와 출시도 자동 완료인가요?
Scrum의 Done은 공통 품질 기준 충족을 나타냅니다. 이 프로젝트의 인수 권한·별도 출시 준비·운영 조건은 해당 합의로 확인합니다. Sprint Review를 일률적인 출시 승인 관문으로 삼거나, 인수 대기를 이유로 미완료 작업을 Done이라고 바꾸지 않습니다.
품질과 공식 수용 →완료와 피드백 →변경 통제 →품질 갈등 대화 →
출처·판본·적용 범위
- NASA SE Handbook · 6.2 Requirements Management
요구 출처·양방향 추적·변경 영향·승인된 기준선과 검증 결과 연결을 참고. Rev2의 NTRS 발행 기록은2017-02-17, 웹 절 갱신은2023-07-26로 구분.2026-10-27 원문 확인. NASA의 단계·승인 조직을 모든 소프트웨어 프로젝트의 의무 절차로 적용하지 않음.
- NASA SE Handbook · 2.4 Verification and Validation
제품이 명세를 충족하는지와 의도한 환경에서 목적에 맞는지를 구분하는 설명 참고. 웹 페이지 갱신2025-01-09,2026-10-27 §2.4 원문 확인. NASA의 product validation을 PMP의 공식 범위 수용이나 계약 승인과 같은 뜻으로 사용하지 않음.
- GOV.UK Service Manual · Writing user stories
사용자·필요·목적과 항목별 수용 기준·증거 연결을 참고. 페이지 발행2016-02-16·갱신2016-05-23, 이력의 최초 지침2016-01-05는 별도로 기록.2026-10-27 원문 확인. 양식이나 예제를 복제하지 않은 창작 사례이며 특정 국가의 서비스 지침을 PMP 공식 규칙으로 제시하지 않음.
- Scrum Guide · November2020
2026-10-27 공식 영문 원문의 Increment·완료 정의·Sprint Review를 확인. 특정 프레임워크의 규칙이며 인수 계약 전체를 정의하지 않습니다.
관계도·요구·검증 목록·비율·변경 요청·연습 해설은 독립 창작입니다. 정해진4개 요구와 지정 검증만을 다루며 실제 서비스의 검증 완전성·PMP 합격을 보장하지 않습니다.
사용자는 절차를 정확히 설명하지 못하지만 반복 예외 처리를 한다. 특히 유용한 방법은?
내 말로 정리하기
보안 비기능 요구 한 개를 수용 시험까지 연결해 보자.
이 수업의 용어
- Elicitation
- 이해관계자의 필요·조건을 다양한 방법으로 발견하고 명확히 하는 활동.
- Observation
- 실제 업무 수행과 제약을 보며 필요를 찾는 방법.
- Facilitated workshop
- 여러 관점을 함께 검토하고 합의를 돕는 협업 방식.
- Nonfunctional requirement
- 성능·보안·신뢰성처럼 어떻게 동작해야 하는지의 조건.
- RTM
- 요구 출처→목표→산출물→시험·수용을 연결하는 기록.