---
title: "3장. 요구사항의 종류와 수준"
description: "비즈니스부터 시스템·소프트웨어 수준까지 요구의 추상도를 나누고 기능·품질·데이터·인터페이스 책임을 연결한다."
---
{/* v3:question */}
## 이번 장에서 해결할 질문
비즈니스·사용자·시스템 요구와 기능·품질 요구는 어떤 수준에서 연결되는가?
{/* v3:objectives */}
## 학습 목표
학습 목표
- “비즈니스·사용자·시스템 요구와 기능·품질 요구는 어떤 수준에서 연결되는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
- 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.
{/* v3:concepts */}
## 핵심 개념
요구사항을 분류하는 방법은 하나가 아니다. 비즈니스에서 소프트웨어로 내려가는 추상 수준으로 나눌 수도 있고, 기능·품질·데이터·인터페이스처럼 내용으로 나눌 수도 있다. 출처, 우선순위, 상태, 법적 구속력도 별도의 분류 축이 된다. 이 축들을 한 줄의 목록으로 섞으면 같은 항목이 어디에 속하는지 불필요한 논쟁이 생긴다.
이 장에서는 두 축을 중심으로 요구사항을 정리한다. 첫째는 왜 필요한지에서 무엇을 구현할지로 구체화되는 수준 축이다. 둘째는 시스템이 만족해야 할 내용을 빠짐없이 살피는 유형 축이다. 대학 수강신청 사례를 사용해 상위 필요와 하위 요구가 어떻게 연결되는지, 분류가 실제로 어떤 검토 질문과 책임을 만들어 내는지 살펴본다.
### 1. 비즈니스 목표와 비즈니스 요구사항
비즈니스 목표는 조직이 도달하려는 상태와 변화의 방향을 말한다. 비즈니스 요구사항은 그 변화를 시작한 이유, 기대하는 성과와 조직 수준에서 만족해야 할 조건을 표현한다. [IIBA의 요구사항 분류](https://www.iiba.org/knowledgehub/the-business-analysis-standard/4-implementing-business-analysis/4-4-understanding-requirements-and-designs/)는 비즈니스 요구사항을 변화가 시작된 이유에 해당하는 목표·목적·성과의 진술로 설명한다. 조직 전체, 특정 업무 영역 또는 하나의 이니셔티브에 적용될 수 있다.
목표가 “수강신청 시작 시점의 혼란과 수작업 복구를 줄인다”라면 측정 가능한 비즈니스 요구사항 후보는 다음과 같이 만들 수 있다.
> `BR-001` 대학은 수강신청 시작 후 30분 동안 발생하는 수동 재처리 건수를 직전 학기 같은 기간 대비 50% 줄여야 한다.
이 책에서 **수동 재처리**는 `BR-001`이 측정하는 상위 용어다. 운영자가 결과 미확인·중복·판정 오류 때문에 수행하는 수동 확인, 정정, 취소와 복구를 하위 유형으로 기록한다. 본문에서 특정 행위를 가리킬 때는 수동 복구·수동 정정이라고 쓰되, `BR-001`의 성과를 말할 때는 수동 재처리와 그 하위 유형별 건수를 함께 본다.
여기서 30분과 50%는 사례를 진행하기 위한 가정이다. 실제 프로젝트에서는 어떤 재처리를 셀지, 직전 학기가 비교 가능한지, 자동 복구 건은 어떻게 분류할지 먼저 정해야 한다. 기준값과 측정 책임자가 없으면 숫자가 있어도 검증 가능한 목표가 되지 않는다.
비즈니스 요구사항은 기능 목록보다 먼저 “왜 이 변화에 투자하는가”를 붙잡는다. `BR-001`만으로 화면이나 API를 설계할 수는 없지만, 하위 요구의 필요성과 우선순위를 판단할 수 있다. 어떤 기능도 이 성과에 기여하지 않는다면 범위에서 제외할 근거가 생긴다. 반대로 성과에 필요한 업무 변화가 소프트웨어 밖에 있다면 교육, 정책, 인력과 절차도 함께 고려해야 한다.
### 2. 이해관계자 요구사항
이해관계자 요구사항은 비즈니스 요구를 달성하기 위해 특정 이해관계자나 집단의 필요가 어떻게 충족되어야 하는지를 표현한다. IIBA는 이를 비즈니스 요구와 해결책 요구 사이를 잇는 다리로 본다. 이해관계자는 사용자만이 아니다. 교무처, 학과 사무실, 교수, IT 운영팀, 정보보호 담당자, 장애학생지원센터, 감사 조직과 외부 학사 시스템 담당자도 각자의 필요와 제약을 가진다.
같은 비즈니스 목표를 두고도 관점은 다르다.
| 이해관계자 | 필요한 결과 | 우려하거나 지켜야 할 것 |
| --- | --- | --- |
| 학생 | 신청 가능 여부와 결과를 빠르고 분명하게 안다 | 불공정한 우선순위, 반복 요청, 접근성 |
| 교무처 | 학사 규칙을 일관되게 적용하고 예외를 통제한다 | 잘못 승인된 신청, 수동 복구, 민원 |
| 학과 사무실 | 전공·강좌별 정원과 예외 승인을 관리한다 | 권한 없는 변경, 근거 없는 증원 |
| IT 운영팀 | 폭주와 장애에도 상태를 관찰하고 복구한다 | 중복 처리, 데이터 불일치, 원인 추적 실패 |
| 정보보호 담당자 | 최소 권한과 개인정보 보호 기준을 지킨다 | 과도한 조회 권한, 민감정보 노출 |
이해관계자 요구사항은 모든 요청을 그대로 승인한 목록이 아니다. 서로 충돌할 수 있고, 같은 사람이 여러 역할을 가질 수도 있다. 학생의 빠른 결과 요구와 교무처의 엄격한 규칙 검증이 성능과 정확성 사이의 긴장을 만들 수 있다. 요구사항 담당자는 각 필요의 출처와 근거를 남기고, 충돌을 권한 있는 결정자에게 드러내야 한다.
확인할 것은 어떤 비즈니스 요구를 지원하는지, 어느 이해관계자 집단을 대표하는지, 반대 영향을 받는 집단은 없는지, 충족 여부를 누가 판단하는지다. 목소리가 큰 사람 한 명의 요청을 집단 전체의 필요로 일반화하지 않도록 실제 업무 자료와 다른 대표자의 증거를 함께 살핀다.
### 3. 사용자 요구사항
사용자 요구사항은 시스템을 직접 또는 간접으로 사용하는 사람이 자신의 목표를 달성하기 위해 할 수 있어야 하는 일을 사용자 관점에서 표현한다. 모든 분류 체계가 사용자 요구사항을 독립된 최상위 유형으로 두는 것은 아니다. 이 책에서는 이해관계자 요구사항 가운데 사용자 과업과 결과에 초점을 둔 실무적 하위 수준으로 사용한다.
1장에서 만든 항목을 다시 보자.
> `UR-001` 학생은 정해진 수강신청 기간에 자신이 신청할 수 있는 강좌를 확인하고, 신청 또는 거절 결과와 이유를 알 수 있어야 한다.
이 문장은 학생의 과업과 기대 결과를 표현하지만 화면 배치나 API 형식을 정하지 않는다. 또한 ‘학생’이라는 사용자 집단도 더 나눌 필요가 있다. 학부생, 대학원생, 교환학생, 졸업예정자, 접근성 지원이 필요한 학생에게 적용되는 정책과 사용 조건이 다를 수 있다.
사용자 요구사항은 사용자 스토리와 같은 하나의 문장 형식에 한정되지 않는다. 시나리오, 업무 흐름, 사용자 여정, 프로토타입과 함께 표현할 수 있다. 중요한 것은 사용자가 실제로 달성하려는 결과와 맥락을 보존하는 것이다. “신청 버튼을 제공한다”는 화면 기능보다 “자신이 신청할 수 있는 강좌를 판단하고 결과를 이해한다”는 과업이 상위에 있어야 다른 설계 대안을 비교할 수 있다.
검토 질문은 세 가지다. 이 문장은 특정 사용자 집단의 실제 목표를 말하는가, 정상 흐름뿐 아니라 실패와 예외에서 필요한 결과가 있는가, 사용자가 성공 여부를 자기 관점에서 확인할 수 있는가. 답하지 못하면 기능 이름을 사용자 요구로 바꿔 쓴 것일 수 있다.
### 4. 시스템 요구사항
시스템 요구사항은 관심 대상 시스템 전체가 만족해야 할 능력, 속성, 인터페이스와 제약을 표현한다. 여기서 시스템은 소프트웨어만 뜻하지 않는다. 사람, 업무 절차, 데이터, 하드웨어, 외부 서비스와 운영 환경이 함께 목적을 달성하는 사회기술적 체계일 수 있다. 수강신청 서비스의 성공은 웹 애플리케이션뿐 아니라 학사 규칙 관리, 예외 승인, 운영 감시와 학생 안내에 달려 있다.
`UR-001`을 지원하는 시스템 요구사항 후보는 다음과 같다.
> `SR-001` 수강신청 시스템은 신청을 확정하기 전에 학생 자격, 선수과목, 시간표 중복, 최대 학점, 강좌 정원과 적용 중인 우선순위 정책을 평가하고 승인 또는 거절 결과와 사유를 제공해야 한다.
이 수준에서는 전체 시스템이 책임질 결과를 말한다. 어떤 조건은 소프트웨어가 자동으로 평가하고, 어떤 예외는 교무 담당자가 승인할 수 있다. 외부 학사 시스템이 학생 자격을 제공하고, 운영 절차가 장애 중 보류 건을 재처리할 수도 있다. 시스템 요구사항을 곧바로 소프트웨어 요구사항으로 간주하면 사람과 절차, 외부 시스템에 배분해야 할 책임을 놓친다.
시스템 요구사항은 상위 필요를 구체화하면서도 아직 구성요소 간 책임 배분을 완전히 고정하지 않을 수 있다. 검토자는 시스템 경계가 명확한지, 시스템 밖의 행위자와 인터페이스가 드러나는지, 각 요구가 비즈니스·이해관계자 요구로 역추적되는지 확인한다.
### 5. 소프트웨어 요구사항
소프트웨어 요구사항은 시스템 요구사항 가운데 소프트웨어 구성요소에 배분된 능력, 속성, 데이터, 인터페이스와 제약을 표현한다. [SWEBOK Guide V4.0a](https://www.computer.org/education/bodies-of-knowledge/software-engineering/v4)는 시스템 요구사항과 소프트웨어 요구사항을 구분할 필요가 있는 경우가 있고, 소프트웨어 자체가 관심 대상 시스템인 경우에는 둘의 범위가 거의 겹칠 수도 있다고 설명한다. 따라서 이름보다 경계와 책임 배분이 중요하다.
`SR-001`에서 소프트웨어가 맡을 부분은 신청 요청 수신, 규칙 데이터 조회, 조건 판정, 결과 저장과 통지다. 교무 담당자의 예외 승인 정책 수립이나 장애 시 비상 업무 절차는 소프트웨어 밖의 책임일 수 있다. 이를 분리하면 자동화되지 않은 업무를 누락하지 않고, 소프트웨어 팀이 책임질 결과도 분명해진다.
소프트웨어 요구사항은 외부에서 직접 말한 요구만 있는 것이 아니다. 상위 요구와 설계 제약을 분석하는 과정에서 파생 요구사항(derived requirement)이 생긴다. 예를 들어 결과 사유를 감사해야 한다는 시스템 요구 때문에 정책 판본과 판정 입력을 저장하는 데이터 요구가 파생될 수 있다. 파생 요구는 출처가 없는 임의 기능이 아니다. 어떤 상위 결정과 분석에서 나왔는지 근거를 연결해야 한다.
소프트웨어 요구사항에는 경계 안에서 책임지고 시험할 수 있는 내용만 남겨야 한다. 하드웨어·사람·외부 시스템의 책임을 잘못 떠안지 않았는지, 상위 시스템 요구와 배분 근거가 연결되는지를 본다.
### 6. 기능 요구사항
기능 요구사항은 시스템이나 소프트웨어가 제공해야 할 관찰 가능한 동작과 결과를 표현한다. [IREB 용어집](https://cpre.ireb.org/en/downloads-and-resources/glossary)은 기능 요구사항을 시스템 기능이 제공해야 할 결과나 행동에 관한 요구로 설명한다. 기능 이름이 아니라 조건, 동작, 결과가 드러나야 검토할 수 있다.
`SR-001`에서 다음 기능 요구를 파생할 수 있다.
> `FR-001` 학생이 강좌 신청을 요청하면 소프트웨어는 현재 적용되는 학사 규칙과 강좌 상태를 사용해 신청 가능 여부를 판정하고, 승인 시 신청 식별자를 생성하며, 거절 시 사유 코드를 반환해야 한다.
이 문장에도 추가 분석이 필요하다. 동시에 여러 요청이 들어올 때 정원은 언제 차감되는지, 규칙 서비스가 응답하지 않으면 어떻게 하는지, 같은 요청이 반복되면 중복 신청을 막는지 정해야 한다. 기능 요구사항을 완전하게 만들겠다고 한 문장에 모든 예외를 넣기보다 관련 요구와 시나리오를 식별해 연결할 수 있다.
기능 요구의 완성도는 시작 사건과 사전 조건, 주체, 처리 결과, 오류·예외, 상태 변화, 후속 행위자로 판단한다. 각 기능은 자신이 만족시키는 사용자·시스템 요구와 연결한다. 연결되지 않는 기능은 필요성을 다시 묻고, 기능으로 내려오지 않은 상위 요구는 누락 가능성을 살핀다.
### 7. 비기능 요구사항
비기능 요구사항은 널리 쓰이지만 범위가 모호한 이름이다. 어떤 체계는 품질 요구와 제약을 함께 묶고, 어떤 체계는 성능·보안·사용성 같은 품질 특성만 가리킨다. IREB 용어집은 비기능 요구사항을 품질 요구 또는 제약으로 정의하고 성능을 품질 요구의 하위 범주로 다룬다. SWEBOK은 기능 요구와 비기능 요구를 구분하면서 기술 제약과 서비스 품질 제약을 세분한다.
이 책에서는 ‘비기능’이라는 말만 쓰고 끝내지 않는다. 측정하려는 품질이면 품질 요구사항으로, 해결 공간을 제한하면 제약사항으로 구체적으로 표시한다. 예를 들어 다음은 품질 요구사항 후보다.
> `QR-001` 기준 부하 시험 환경에서 학생이 신청 요청을 제출한 뒤 처리 상태를 조회할 때 응답시간의 95백분위는 2초 이하여야 한다.
2초와 시험 환경은 사례용 가정이며 실제로는 동시 사용자 수, 데이터 규모, 측정 구간, 제외할 오류를 함께 정의해야 한다. “빠르게”, “안전하게”, “사용하기 쉽게” 같은 표현만으로는 품질을 시험할 수 없다.
비기능 요구는 기능 옆의 부가 조건이 아니다. 성능, 가용성, 보안, 접근성이나 유지보수성은 아키텍처와 비용을 크게 바꿀 수 있다. 여러 기능에 공통으로 적용되므로 한 기능 아래에 숨기지 말고 적용 범위와 우선순위를 명시한다. 검토자는 품질의 조건·대상·측정값·측정 방법과 실패했을 때의 영향을 확인한다.
### 8. 인터페이스 요구사항
인터페이스 요구사항은 관심 대상과 외부 행위자나 시스템 사이에서 무엇이 오가고 어떤 규칙을 지켜야 하는지를 표현한다. 사용자 인터페이스뿐 아니라 API, 메시지, 파일, 장치, 조직 간 업무 인계도 대상이 될 수 있다. 화면 모양을 상세히 설계하기 전에 교환해야 할 정보, 시작 조건, 순서, 오류와 책임을 정의한다.
수강신청 소프트웨어는 학사정보 서비스에서 학생의 학적·선수과목·학점 원천 정보를 조회하고, 학사 규칙 판정 서비스에서 규칙 버전과 판정 결과를 받아야 한다. 정상 응답만 정의하면 외부 서비스 장애 때 임의 승인하거나 요청을 잃을 위험이 있다.
`IR-001`은 하나의 추적 묶음이지만 책임이 다른 두 하위 요구로 나눈다.
> `IR-001-C` 학사 규칙 판정 서비스는 합의된 시간 안에 요청 식별자, 규칙 버전, 판정 결과 또는 계약된 오류 정보를 반환해야 한다.
> `IR-001-R` 수강신청 소프트웨어는 합의된 시간 안에 유효한 판정 정보를 받지 못하면 신청을 자동 승인하지 않고 처리 보류 상태와 원인 코드를 기록·반환해야 한다.
앞 항목은 외부 경계의 계약이고 뒤 항목은 우리 제품의 회복·안전 동작이다. 이후 장에서 `IR-001`이라고 묶어 부를 때도 두 책임을 하나의 구현 책임으로 합치지 않는다.
좋은 인터페이스 요구사항은 상대 시스템, 교환 목적, 데이터 의미, 식별자, 시점과 순서, 용량, 인증·권한, 오류·재시도·중복 처리와 버전 호환을 다룬다. 특정 URL이나 JSON 필드 구조는 설계 단계에서 정할 수 있지만, 외부 계약이 이미 고정했다면 제약으로 요구사항에 포함할 수 있다.
인터페이스 경계에서는 양쪽 책임자가 같은 의미를 승인했는지 확인한다. 한쪽의 ‘학생 상태’가 다른 쪽에서는 휴학·수료·졸업을 다르게 포함할 수 있다. 연결 성공만 시험하지 말고 지연, 중복, 순서 변경, 부분 실패와 복구 후 재처리도 요구 수준에서 다룬다.
### 9. 데이터 요구사항
데이터 요구사항은 시스템이 필요로 하는 데이터의 의미, 구조, 품질, 생명주기와 보호 조건을 표현한다. 데이터베이스 테이블 설계와 같지 않다. 어떤 정보를 왜 수집하고 누가 책임지며 언제까지 보존하고 어떤 품질을 만족해야 하는지를 먼저 정한다.
신청 결과를 나중에 설명하려면 단순히 학생과 강좌의 연결만 저장해서는 부족하다.
> `DR-001` 각 신청 판정 기록에는 학생·강좌 식별자, 요청 시각, 결과, 사유 코드, 판정에 사용한 학사 규칙의 버전과 최종 상태 변경 시각이 포함되어야 한다.
이 요구는 `UR-001`의 결과 설명과 교무처의 감사 필요에서 파생된다. 저장 구조, 인덱스와 파티션은 설계 결정이지만 데이터 의미와 필수 속성, 정확성·완전성·최신성, 보존·삭제와 접근 권한은 요구사항에서 확인해야 한다.
데이터 요구에는 기준정보의 소유자, 동일 식별자의 의미, 유효 시점, 허용되는 결측과 중복, 이력 보존, 개인정보 최소 수집, 정정과 삭제 절차가 필요하다. 데이터가 여러 시스템을 오가면 원본과 복제본의 책임, 동기화 지연과 충돌 해결도 정한다. 기능이 동작해도 잘못된 데이터로 판단하면 사용자 필요를 충족하지 못한다.
### 10. 제약사항
제약사항은 기능·품질·데이터·인터페이스와 같은 내용 유형과 다른 축이다. 어느 수준에도 적용될 수 있으며 가능한 해결책을 제한한다. 법령, 계약, 조직 정책, 기존 시스템, 예산·일정, 물리 환경이나 승인된 기술 결정이 출처가 될 수 있다.
예를 들어 “기존 학사 시스템의 학생 식별자를 변경할 수 없다”는 제약은 데이터 요구와 인터페이스 설계에 영향을 준다. “대학의 통합 인증 체계를 사용해야 한다”는 제약은 사용자 흐름, 보안과 외부 연계에 영향을 준다. 제약을 별도 목록에만 두면 관련 요구를 검토할 때 놓치기 쉬우므로 영향을 받는 항목과 양방향으로 연결해야 한다.
제약사항의 강도도 구분한다. 법적 의무와 내부 선호를 같은 수준으로 취급하면 협상 가능한 선택을 불필요하게 닫는다. 출처, 승인자, 적용 범위, 유효 기간, 예외 절차와 위반 결과를 기록한다. 제약이 지나치게 비싸거나 상위 목표와 충돌하면 개발팀이 몰래 무시할 것이 아니라 권한 있는 사람이 대안과 위험을 검토해야 한다.
### 11. 전환 요구사항
전환 요구사항은 현재 상태에서 목표 상태로 옮겨 가는 동안 필요한 일시적인 능력과 조건이다. IIBA는 데이터 변환, 교육, 업무 연속성 등을 예로 들며 목표 상태가 자리 잡으면 더 이상 필요하지 않을 수 있다고 설명한다. 운영 제품의 영구 기능과 섞으면 출시 후에도 불필요한 기능을 유지하거나, 반대로 전환에 꼭 필요한 작업을 프로젝트 범위에서 빠뜨릴 수 있다.
수강신청 시스템을 교체할 때는 진행 중인 신청과 대기 순번을 옮기고, 기존·신규 시스템의 식별자를 대응시키며, 교무 담당자를 교육해야 한다. 전환 기간에 두 시스템을 함께 운영한다면 어느 쪽이 원본인지, 동기화 실패를 어떻게 발견하고 복구할지 정해야 한다. 전환 완료 조건과 되돌리기 기준도 필요하다.
전환 요구는 “데이터를 이관한다”로 끝내지 않는다. 대상 데이터와 기준 시점, 변환 규칙, 허용 오류, 검증 표본, 책임자, 소요 시간, 개인정보 처리, 실패 시 복구와 승인 기준을 포함한다. 전환이 끝나면 어떤 임시 권한·도구·인터페이스를 폐기할지도 정한다.
전환 요구에서는 목표 시스템의 지속 능력인지 전환 기간의 임시 조건인지, 완료와 폐기를 누가 판단하는지 분명히 한다. 이 요구도 상위 비즈니스 연속성 필요와 시험·운영 계획으로 추적되어야 한다.
### 12. 법률과 규제 요구사항
법률과 규제 요구사항이라는 이름은 내용 유형보다 출처를 강조한다. 법령, 행정 규칙, 감독기관 지침, 계약상 준수 기준과 조직 규정에서 기능·품질·데이터·인터페이스·제약 요구가 파생될 수 있다. 예를 들어 개인정보 관련 의무는 수집 항목, 접근 권한, 보존 기간, 기록, 통지와 삭제 절차에 여러 요구를 만든다.
법률 문구를 그대로 복사하면 시스템 동작이 자동으로 결정되는 것은 아니다. 적용되는 관할과 대상, 시행일, 예외, 해석 책임자를 확인하고 업무·기술 맥락에 맞는 요구로 전환해야 한다. 요구사항 작성자가 법적 판단을 대신해서는 안 된다. 법무·준법 책임자가 적용성과 해석을 승인하고, 원문 조항과 해석 기록을 요구사항에 연결해야 한다.
법률과 규제는 바뀔 수 있으므로 출처의 문서명, 조항, 판본 또는 공포·시행일, 확인 날짜를 기록한다. 링크만 남기면 페이지가 바뀌었을 때 당시 근거를 복원하기 어렵다. 여러 규정이 충돌하거나 적용 여부가 불분명하면 ‘개발 중 확인’이라는 메모로 묻어 두지 말고 미결정 항목과 책임자, 결정 기한으로 관리한다.
검토자는 어떤 의무에서 어떤 시스템 요구가 파생되었는지, 준수 증거를 무엇으로 남길지, 변경 감시 책임자가 누구인지 확인한다. 규정 준수는 마지막 검사에서 덧붙이는 품질이 아니라 초기 범위와 설계를 바꾸는 요구사항 출처다.
### 13. 요구사항은 계층을 가진다
요구사항 계층은 상위 필요를 하위의 구체적인 조건으로 연결한다. 위에 있을수록 목적과 성과에 가깝고, 아래로 갈수록 특정 시스템과 소프트웨어가 책임질 동작·품질·데이터·인터페이스가 분명해진다. 그러나 모든 조직이 같은 단계 이름을 써야 하는 것은 아니다. 중요한 것은 이름보다 각 수준의 책임, 입력과 출력, 추적 관계다.
이 책에서 사용할 기준 모델은 다음과 같다.
제약, 전환, 법률·규제는 이 계층의 한 층에만 갇히지 않는다. 비즈니스 수준의 법적 의무가 시스템 제약과 소프트웨어 데이터 요구로 구체화될 수 있다. 기능·품질·데이터·인터페이스 역시 소프트웨어 수준에서만 나타나는 절대 상자가 아니라 내용을 점검하기 위한 관점이다.
수강신청 사례의 일부 추적 사슬은 다음과 같다.
이 연결은 단순한 폴더 구조가 아니다. 위에서 아래로 내려가며 “이 목적을 만족하려면 무엇이 더 구체적으로 참이어야 하는가?”를 묻고, 아래에서 위로 올라가며 “이 기능과 데이터가 왜 필요한가?”를 묻는다. 구현이나 시험이 바뀌면 어느 요구에 영향을 주는지, 상위 정책이 바뀌면 어떤 하위 항목을 다시 검토해야 하는지도 찾을 수 있다.
계층에서는 연결의 종류까지 구분한다. 상위 요구를 더 자세히 쓰는 것은 구체화이고, 시스템 구성요소에 책임을 나누는 것은 할당이며, 분석이나 설계에서 새 조건을 발견하는 것은 파생이다. 이 관계를 모두 ‘하위 요구’라는 말로 뭉개면 변경 이유를 잃는다.
[ISO/IEC/IEEE 29148:2018](https://www.iso.org/standard/72089.html), SWEBOK, IREB와 IIBA는 서로 목적과 분류 기준이 다르다. 어느 하나를 유일한 정답으로 삼기보다 프로젝트의 책임 구조에 맞는 분류를 정하고 용어집에 기록해야 한다. 완료 기준은 모든 항목을 억지로 한 칸에 넣는 것이 아니다. 상위 필요에서 소프트웨어와 시험까지 근거를 따라갈 수 있고, 각 수준의 승인자와 검토 질문이 분명하면 된다.
1부에서 요구사항의 필요성, 개념 경계와 계층을 세웠다. 이제 “무엇을 요구사항이라 부를 것인가”에서 “그 요구사항의 출발점을 어디서 찾을 것인가”로 이동한다. 2부에서는 수강신청의 증상과 해결책을 잠시 내려놓고 문제, 목표, 업무와 이해관계자를 체계적으로 찾아간다.
{/* v3:case */}
## 수강신청 사례에 적용
수강신청 사례의 결정·근거·남은 쟁점을 3장에서 다룬 기준으로 구분한다.
{/* v3:criteria */}
## 판단 기준과 흔한 오류
:::warning[판단하기 전에 확인]
- 결정이 확인 가능한 출처와 근거를 가지고 있는가?
- 구현·검증·변경에 필요한 다음 행동과 책임자가 분명한가?
:::
{/* v3:practice */}
## 직접 해보는 실습
1. **1. 대상 선택**
현재 프로젝트 산출물 중 이 장의 질문과 관련된 항목 하나를 고른다.
2. **2. 근거와 예외 표시**
본문의 판단 질문으로 누락된 근거와 예외를 표시한다.
3. **3. 다음 행동 기록**
확인할 책임자, 필요한 최소 증거와 다음 행동을 기록한다.
{/* v3:summary */}
## 핵심 요약
:::success[이 장에서 가져갈 기준]
비즈니스부터 시스템·소프트웨어 수준까지 요구의 추상도를 나누고 기능·품질·데이터·인터페이스 책임을 연결한다.
:::
{/* v3:next */}
## 관련 도구와 다음 경로
바로 사용할 수 있는 점검표와 예제를 확인합니다.
학습 순서에 따라 다음 판단 주제로 이어갑니다.