10장. 요구사항 분석

수집한 후보에서 중복·누락·모순·모호성과 실현 가능성 문제를 찾아 의사결정 가능한 분석 결과로 바꾼다.

이번 장에서 해결할 질문

학습 목표

• “도출한 요구 후보에서 누락·모순·중복·실현 가능성 문제를 어떻게 찾는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
• 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.

핵심 개념

도출에서 모은 인터뷰 답변, 관찰 기록, 규정과 로그는 아직 승인된 요구사항이 아니다. 서로 다른 표현이 같은 필요를 가리킬 수 있고, 그럴듯한 요청 사이에 누락·모순·실현 가능성 문제가 숨어 있을 수 있다. 수집한 문장을 곧바로 명세에 옮기면 출처의 불확실성까지 확정된 사실처럼 굳어진다.

이 장에서는 요구 후보의 중복·누락·모순·모호성·실현 가능성과 가정을 대조해 의사결정 가능한 상태로 바꾼다. 후보의 의미와 관계를 구조화하고, 근거가 부족하거나 권한 있는 결정이 필요한 쟁점은 숨기지 않은 채 다음 도출·협상·검토로 연결한다.

1. 도출과 분석의 차이

3부에서 모은 인터뷰 답변, 관찰 기록, 규정과 로그는 곧바로 승인할 요구사항이 아니다. 그것은 출처가 있는 요구 후보다. 도출은 필요한 정보를 발견하고 확인하는 활동이고, 분석은 후보의 의미·경계·관계를 따져 의사결정 가능한 상태로 바꾸는 활동이다. 둘은 순서대로 한 번씩 끝나는 단계가 아니다. 분석하다 근거가 비거나 뜻이 갈리면 다시 도출하고, 새 답을 받으면 다시 분석한다.

이 차이를 무시하면 목소리가 큰 이해관계자의 표현이 사실처럼 굳는다. “학생에게 결과를 즉시 보여 줘야 한다”는 답변을 그대로 요구로 채택하면 즉시의 기준도, 결과가 접수인지 승인인지도, 외부 규칙 서비스가 늦을 때의 상태도 모른다. 분석은 이를 UR-001UR-001 · 사용자 요구신청 가능 강좌와 결과·사유 확인 / 사용자., QR-001QR-001 · 품질 요구합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다., IR-001IR-001 · 인터페이스 요구자격·운영 흐름.과 연결해 다음을 묻는다.

• 어떤 필요와 목표를 지원하는가?
• 출처는 누구이며 어떤 사실·규정·수치가 뒷받침하는가?
• 용어와 적용 조건은 무엇인가?
• 다른 후보와 같거나 의존하거나 충돌하는가?
• 정상·경계·예외·실패 상황에서도 의미가 유지되는가?
• 현재 기술·일정·예산과 조직 역량 안에서 실현하고 검증할 수 있는가?
• 누가 확인·결정해야 하며 현재 상태는 무엇인가?

IEEE Computer Society의 SWEBOK Guide v4.0a는 요구사항 분석을 기본 분석, 품질 서비스 제약의 경제성, 형식 분석, 충돌 처리로 나누고, 요구사항 활동이 반복적이라는 점을 다룬다. 2026년 8월 공개된 최신판이라는 사실은 참고 기준의 시점을 알려 줄 뿐, 이 책의 사례 결정을 대신하지 않는다. ISO/IEC/IEEE 29148도 요구사항 공학의 생명주기 프로세스와 정보 항목을 다룬다. 이 판은 2024년에 재확인되어 현재 발행본이지만 2026년 현재 개정 예정 상태이므로, 실제 조직 표준에 적용할 때 판 상태를 다시 확인해야 한다.

분석 결과는 문장이 매끈한 요구 목록이 아니라 판단 흔적이 있는 작업 집합이다. 최소한 후보 ID, 원문, 해석, 출처, 연결 목표, 발견 결함, 영향, 확인 질문, 담당자, 상태를 남긴다. 예를 들어 ASM-001ASM-001 · 가정결과를 알 수 없는 상태에서 발생하는 반복 제출이 수동 재처리 증가에 유의미하게 기여한다는 미확인 가정이다.은 “반복 제출이 수동 재처리의 주요 원인이다”라는 가정이다. 로그 정의와 기준선이 확인되지 않았으므로 BR-001BR-001 · 업무 요구목표값과 투자 범위. 사업 후원자·교무 책임자.의 확정 근거가 아니라 검증 대기 항목이다.

도출과 분석의 경계는 “새 정보를 듣는가, 기존 정보를 생각하는가”가 아니다. 분석 중 이해관계자에게 모순을 설명하고 추가 답을 얻을 수도 있다. 핵심은 산출물의 상태다. 발견한 말은 원문과 출처를 보존하고, 분석가의 해석과 결정권자의 합의를 섞지 않는다.

2. 중복 요구사항

중복은 둘 이상의 후보가 같은 필요·행동·결과를 전부 또는 일부 반복하는 상태다. 같은 단어가 나온다고 중복은 아니며, 다른 문장도 같은 의미일 수 있다. 학생의 “신청이 됐는지 알려 달라”, 상담원의 “접수 번호를 조회할 수 있어야 한다”, 운영자의 “동일 요청을 구분할 키가 필요하다”는 표현은 UR-001UR-001 · 사용자 요구신청 가능 강좌와 결과·사유 확인 / 사용자.과 FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다.의 서로 다른 관점을 말할 수 있다. 하나로 합치기 전에 주체·조건·결과·근거를 비교해야 한다.

중복을 진단할 때는 네 가지를 본다.

1. 같은 업무 결과를 요구하는가?
2. 적용 대상과 조건이 같은가?
3. 한 후보가 다른 후보를 완전히 포함하는가?
4. 서로 다른 추상 수준이나 관점 때문에 함께 남아야 하는가?

UR-001UR-001 · 사용자 요구신청 가능 강좌와 결과·사유 확인 / 사용자.은 학생이 결과와 사유를 볼 수 있어야 한다는 사용자 요구다. FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다.은 시스템이 규칙을 평가하고 승인 식별자 또는 거절 사유 코드를 반환한다는 소프트웨어 요구다. 둘은 관련되지만 중복이 아니다. 반면 “승인되면 신청 번호를 보여 준다”와 “성공한 신청은 접수 식별자를 응답한다”가 같은 조건·대상·결과를 가리킨다면 대표 후보 하나로 통합할 수 있다.

통합할 때 원문을 삭제하지 않는다. 대표 항목 아래에 별칭과 출처를 모두 연결하고, 각 출처가 강조한 차이를 메모한다. 그래야 나중에 “신청 번호”가 단순 화면 메시지인지 DR-001DR-001 · 데이터 요구학생·강좌 ID, 요청 시각, 판정 결과와 사유, 적용 규칙 버전, 최종 상태 변경을 연결해 보존한다는 데이터 요구다.과 이어지는 영구 식별자인지 확인할 수 있다. 반대로 중복을 그대로 두면 같은 기능을 여러 번 산정하거나 한 문장만 바꾸어 불일치가 생긴다.

판단 질문은 간단하다. 하나를 제거해도 출처, 이해관계자 관점, 조건, 검증 기준과 추적 관계가 손실되지 않는가? 손실된다면 병합하지 말고 관계를 표시한다. 손실되지 않는다면 대표 항목, 흡수된 항목, 통합 근거와 검토자를 기록한다.

3. 누락 요구사항

누락은 알고 있는 문장에 단어가 빠진 것만 뜻하지 않는다. 목표를 달성하는 데 필요한 행동·데이터·품질·인터페이스·예외·운영 책임 중 후보 집합에 없는 것이 누락이다. 빈칸은 문서만 읽어서는 보이지 않으므로 여러 관점과 흐름을 대조해야 한다.

수강신청 핵심 흐름을 신청 전 확인 → 제출 → 규칙 판정 → 정원 반영 → 결과 통지 → 조회·복구로 놓고 기존 ID를 배치해 보자. FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다.은 판정과 결과를, UR-001UR-001 · 사용자 요구신청 가능 강좌와 결과·사유 확인 / 사용자.은 조회 가능한 결과를, IR-001IR-001 · 인터페이스 요구자격·운영 흐름.은 규칙 서비스 실패 시 보류를 다룬다. 그러나 다음 질문에는 아직 답이 없다.

• 보류가 정원을 점유하는가?
• 같은 학생·강좌의 반복 요청은 같은 신청으로 볼 것인가?
• 알림 실패와 판정 실패는 어떻게 구분하는가?
• 신청 뒤 학적이나 강좌 정보가 바뀌면 어느 시점의 규칙을 쓰는가?
• 보류가 끝나지 않을 때 누가 재평가하고 종료하는가?
• 장애 지원이나 승인된 예외는 어떤 권한과 근거로 적용하는가?

이 목록은 곧바로 새 요구사항이 아니다. 누락 후보와 질문이다. 정책 답변 없이 “보류는 30초 후 자동 취소한다”고 채우면 누락을 발견한 것이 아니라 설계를 발명한 셈이다.

누락 탐색에는 다음 대조가 유용하다.

누락 여부는 “목록이 길다”로 판단하지 않는다. 목표-흐름-상태-데이터-인터페이스-품질을 오가며 끊긴 연결을 찾고, 최소 증거와 결정권자를 붙였는지가 기준이다.

4. 모순된 요구사항

모순은 같은 조건에서 함께 참이 될 수 없는 요구 후보들 사이의 관계다. “정원을 한 명도 초과하지 않는다”와 “정원이 차도 졸업예정자를 추가 승인한다”가 같은 강좌·같은 시점·같은 정원 정의를 사용한다면 모순이다. 하지만 졸업예정자용 별도 정원이 정책으로 존재한다면 적용 조건이 다른 두 규칙일 수 있다. 어느 한쪽을 삭제하기 전에 용어, 조건, 권한과 이해관계를 분리해야 한다.

모순은 문장끼리만 생기지 않는다.

• 행동 모순: 승인해야 한다와 거절해야 한다.
• 수치 모순: 최대 18학점과 최대 21학점.
• 시간 모순: 선착순 접수 시각과 추첨 마감 시각을 동시에 결정 기준으로 사용.
• 데이터 모순: 학사정보의 확정 정원과 학과 임시표의 정원을 각각 진실의 원천으로 취급.
• 품질 모순: 모든 판정을 실시간 검증하면서 외부 장애에도 지연 없이 항상 확정 응답.
• 권한 모순: 학과가 정원을 즉시 변경할 수 있으나 교무처 사전 승인 없이는 변경 불가.

분석가는 ISS-001ISS-001 · 미결 쟁점우선 배정 조건과 정원 초과 금지가 충돌할 때 마지막 좌석의 승자를 어떻게 정할지 남아 있는 정책 쟁점이다. 같은 쟁점으로 양쪽을 보존한다.

모순 해결은 표현을 절충하는 일이 아니다. “가능하면 정원을 지키되 졸업예정자를 고려한다”는 문장은 충돌을 숨긴다. 먼저 실제로 겹치는 조건을 확인하고, 정책 우선순위·대안·영향·결정권자를 14장14장. 요구사항 충돌과 협상동시에 만족할 수 없는 요구를 근거와 권한에 따라 어떻게 협상하는가?페이지로 이동에서 다룰 수 있도록 기록한다.

5. 모호한 요구사항

모호성은 한 표현을 합리적인 독자들이 서로 다르게 이해할 수 있는 정도다. “빠르게”, “편리하게”, “실시간”, “적절한”, “대부분” 같은 말이 대표적이지만, 익숙한 명사도 위험하다. 수강신청 사례에서 신청, 접수, 승인, 배정, 처리 완료를 섞으면 학생은 버튼을 누른 시점을, 운영자는 정원 반영 시점을 완료로 볼 수 있다.

QR-001QR-001 · 품질 요구합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다.의 “상태 조회 p95 2초”는 단순히 숫자가 있어도 완전하지 않다. 측정 시작·끝, 부하와 데이터 규모, 캐시 여부, 오류 요청 포함, 관측 지점이 없으면 팀마다 다른 시험을 통과시킬 수 있다. 현재는 “정의된 부하 시험 환경”이라는 경계가 있지만 그 환경이 아직 구체화되지 않았으므로 목표 후보 상태를 유지한다.

모호성을 찾을 때 다음 부분에 표시한다.

• 주체: 누가 또는 무엇이 수행하는가?
• 촉발 조건: 언제 시작되는가?
• 대상과 범위: 어느 학생·강좌·기간·상태인가?
• 동작과 결과: 무엇을 하고 무엇이 관찰되는가?
• 수량과 단위: 얼마나, 어디서, 어떤 분포로 측정하는가?
• 예외와 실패: 판단할 수 없거나 외부가 늦으면 무엇이 되는가?
• 용어: 같은 단어가 한 문서에서 같은 뜻인가?

모호함을 제거한다며 지나치게 일찍 설계를 넣지 않는다. “빠르게 보여 준다”를 “Redis에서 2초 안에 조회한다”로 고치면 측정 기준과 구현 선택을 섞는다. 먼저 사용자가 견딜 수 있는 결과 지연과 업무 피해를 밝히고, 구현 대안은 설계로 분리한다.

검토 기준은 작성자가 설명할 수 있는가가 아니다. 서로 다른 검토자가 같은 사례를 같은 결과로 판정하고, 시험자가 관찰 지점과 합격 조건을 정할 수 있는가이다. 구체적인 문장 품질은 15장15장. 좋은 요구사항을 작성하는 법한 문장을 구현·시험·검토할 수 있는 요구사항으로 어떻게 작성하는가?페이지로 이동–16장16장. 좋은 요구사항의 품질정확성·명확성·완전성·일관성·검증 가능성을 어떤 증거로 판단하는가?페이지로 이동에서 다시 다룬다. 이 장에서는 모호성 위치와 필요한 결정만 찾는다.

6. 실행 불가능한 요구사항

실행 불가능성은 단지 개발자가 어렵다고 느끼는 상태가 아니다. 현재 알려진 물리·기술·법률·정책·일정·예산·운영 능력 안에서 요구를 실현하거나 객관적으로 확인할 수 없다는 근거가 있는 상태다. 어렵고 비싼 요구와 불가능한 요구를 구분해야 한다.

“모든 신청을 지연 없이 처리하고 어떤 장애에서도 항상 정확한 확정 결과를 제공한다”는 후보는 의심해야 한다. 외부 학사 규칙 서비스가 응답하지 않으면 최신 규칙을 확인할 수 없고, IR-001IR-001 · 인터페이스 요구자격·운영 흐름.은 잘못된 자동 승인을 막기 위해 보류를 선택한다. 여기서 무한 가용성과 즉시 확정을 동시에 약속할 수는 없다. 대신 허용할 상태, 지연, 복구와 데이터 일관성의 선택지를 만든다.

실현 가능성 검토는 다음 증거를 요구한다.

근거가 부족하면 즉시 ‘불가능’으로 폐기하지 않고 실현 가능성 미확인으로 표시한다. 목표를 낮추기 전에 필요를 되묻고 대안을 찾는다. 예컨대 “항상 즉시 확정”의 필요가 결과 불안 해소라면 접수·판정 중·승인·거절 상태와 다음 행동을 확실히 보여 주는 대안이 목적을 더 안전하게 달성할 수 있다.

7. 해결책으로 위장한 요구사항

“푸시 알림을 도입한다”, “규칙을 마이크로서비스로 만든다”, “대기열에 Kafka를 쓴다”는 해결책 후보다. 해결책 자체가 나쁜 것은 아니다. 다만 왜 필요한지, 어떤 결과를 보호하는지 밝히지 않으면 더 단순하거나 안전한 대안을 비교할 수 없다. 요구와 설계의 경계는 문장 형태가 아니라 선택의 여지가 남아 있는가에 있다.

해결책을 발견하면 수단에서 필요로 한 단계 올라간다.

그렇다고 모든 기술 제약을 제거하지 않는다. 기존 인증 서비스 재사용, 승인된 데이터 플랫폼, 접근성 표준, 법적 보존 규칙처럼 조직이 실제로 선택할 수 없는 조건은 제약 요구가 될 수 있다. 이때 출처, 적용 범위, 변경 권한과 만료 조건을 남긴다. “우리 팀이 익숙해서”와 “기관 표준으로 의무화되어 있어서”는 같은 제약이 아니다.

해결책 후보를 판정할 질문은 세 가지다. 이 수단이 없어도 필요를 만족하는 다른 방법이 있는가? 이 수단을 강제하는 권한 있는 근거가 있는가? 채택했을 때 가치·비용·위험을 어떤 기준으로 비교할 것인가? 답이 없으면 해결책을 요구사항으로 위장시키지 말고 대안 목록에 둔다.

8. 가정으로 숨어 있는 요구사항

가정은 증명하지 않았지만 계획과 판단에서 참으로 취급하는 전제다. “학사정보는 항상 최신이다”, “학생은 한 기기에서만 신청한다”, “졸업예정자 정의는 모든 학과가 같다”, “반복 제출이 수동 재처리의 주원인이다” 같은 말은 요구가 아니라 검증해야 할 전제다. 숨은 가정이 틀리면 그 위에 놓인 요구와 설계가 함께 무너진다.

가정은 다음 네 방향에서 찾는다.

• 문장에 생략된 조건: “물론”, “당연히”, “기존처럼” 뒤에 무엇이 있는가?
• 데이터와 외부 연계: 최신성·완전성·식별자·응답 순서를 무엇이라 전제하는가?
• 사람과 운영: 담당자가 항상 있고 즉시 판단할 수 있다고 보는가?
• 변화: 정책·학사 일정·정원·조직이 프로젝트 동안 고정이라고 보는가?

가정 목록은 메모장이 아니라 검증 계획이다.

가정이 확인되면 근거 있는 제약·규칙·요구 또는 단순 사실로 전환하고 출처를 연결한다. 틀리면 관련 요구와 범위를 다시 분석한다. 기한까지 확인할 수 없다면 발생 가능성과 영향을 평가해 위험으로 관리하고, 안전한 기본 동작과 재검토 조건을 결정한다. 예를 들어 ASM-002ASM-002 · 가정규칙 버전 제공 여부 미확인.가 확인되지 않으면 규칙 버전을 기록한다는 DR-001DR-001 · 데이터 요구학생·강좌 ID, 요청 시각, 판정 결과와 사유, 적용 규칙 버전, 최종 상태 변경을 연결해 보존한다는 데이터 요구다.을 구현할 수 있는지부터 다시 살펴야 한다.

분석 검토는 항목별 확인으로 끝내지 않는다. 서로 다른 출처가 같은 조건을 다르게 말하는지, 한 가정이 여러 요구를 동시에 떠받치는지, 닫히지 않은 쟁점이 범위·일정 결정을 가로막는지 집합 수준에서 본다. 검토자는 각 결함에 동의하는 것보다 이 결함을 해소하려면 어떤 증거와 권한이 필요한가를 확인한다. 결함이 남아 있어도 영향, 담당자, 기한과 안전한 임시 처리까지 정해졌다면 다음 분석 단계로 넘길 수 있다. 반대로 ‘나중에 확인’만 적힌 항목은 관리되는 불확실성이 아니다.

10장의 최종 산출물은 ‘깨끗해 보이는 목록’이 아니다. 다음과 같이 문제가 드러난 목록이다.

문법이 맞다고 분석이 끝난 것이 아니며, 실행 불가능성을 기술팀에 떠넘겨서도 안 된다. 분석이 끝났다고 말할 수 있는 최소 조건은 각 후보의 의미와 상태가 분리되고, 결함과 미확인 가정이 보이며, 문제를 풀 결정권자와 증거가 연결된 때다. 이제 이 후보들을 시스템 안에 모두 밀어 넣는 대신, 무엇을 이번 변화가 책임지고 무엇을 외부에 남길지 경계를 정해야 한다.

수강신청 사례에 적용

판단 기준과 흔한 오류

직접 해보는 실습

핵심 요약

관련 도구와 다음 경로