21장. 기능 요구사항

수강신청의 기능을 접수·판정·조회·중복 방지·취소 책임으로 분해하고 사건·상태·규칙과 연결한다.

이번 장에서 해결할 질문

학습 목표

• “시스템이 제공해야 할 동작과 예외를 기능 요구사항으로 어떻게 명확히 하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
• 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.

핵심 개념

기능 요구사항은 사용자가 누르는 버튼의 목록이 아니다. 하나의 수강신청 동작 안에도 접수, 규칙 판정, 좌석 반영, 결과 조회, 중복 방지와 취소처럼 서로 다른 시스템 책임이 얽혀 있다. 책임을 제대로 나누지 않으면 정상 흐름은 보여도 장애와 재시도에서 데이터가 어긋난다.

이 장에서는 수강신청 기능을 사건·처리·상태·업무 규칙 관점에서 분해해 기능 요구사항으로 정리한다. 각 기능의 입력과 결과, 선후 관계와 예외를 연결하고, 사용자 목표를 유지하면서도 구현과 시험에 할당할 수 있는 단위를 만드는 방법을 다룬다.

1. 기능이란 무엇인가

기능 요구사항은 특정 조건이나 사건에서 시스템이 수행해야 하는 관찰 가능한 행동과 결과를 정의한다. “수강신청 기능을 제공한다”처럼 기능 이름만 적는 것이 아니라 무엇을 입력받아 어떤 규칙으로 판정하고 어떤 상태·정보를 만들어야 하는지 밝힌다. 화면, API, 배치 작업은 기능을 실현하는 수단이나 접점일 수 있지만 기능 자체와 같지 않다.

20장20장. 모델로 표현하는 요구사항경계·상태·순서·데이터·결정의 질문에 맞는 모델을 어떻게 선택하는가?페이지로 이동의 모델에는 신청 제출, 규칙 평가, 승인·거절·보류, 정원 반영, 판정 기록과 결과 조회가 있었다. 이를 기능 관점으로 읽으면 다음 질문이 생긴다.

• 어떤 사건이 행동을 시작하는가?
• 필요한 입력과 그 유효성·기준 시점은 무엇인가?
• 시스템은 어느 업무 규칙으로 어떤 판정을 해야 하는가?
• 외부에서 관찰할 출력과 상태 변화는 무엇인가?
• 실패·동시 요청·중복 요청에서는 어떤 안전 결과가 필요한가?
• 누가 어떤 상태의 기능을 사용할 권한이 있는가?

기능 요구와 인접 유형을 구분한다. “신청 상태를 제공한다”는 기능 요구이고, “p95 2초 이내에 제공한다”는 성능 요구 QR-001QR-001 · 품질 요구합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다.이다. “결과에 규칙 버전을 기록한다”는 데이터 요구 DR-001DR-001 · 데이터 요구학생·강좌 ID, 요청 시각, 판정 결과와 사유, 적용 규칙 버전, 최종 상태 변경을 연결해 보존한다는 데이터 요구다.이며, “규칙 서비스가 제공하는 판정 형식과 오류 코드를 해석한다”는 인터페이스 요구다. 한 업무 결과에는 네 유형이 함께 필요하지만 한 문장에 뒤섞으면 책임과 검증이 흐려진다.

이 장에서는 기존 FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다.을 상위 기능 요구로 유지하고, 분석을 위한 하위 후보를 만든다. 아직 정책 출처와 승인 상태가 확인되지 않은 항목은 확정 요구가 아니다.

좋은 기능 목록은 메뉴 목록이 아니라 목표부터 예외까지 이어지는 행동 집합이다. ISO/IEC/IEEE 29148은 2026년 현재 발행된 요구사항 공학 표준으로 요구 정보 항목과 형식 지침을 제공하며 개정 작업이 진행 중이다. 적용할 판본과 확인 날짜를 기준선에 남긴다.

기능 집합의 완전성은 기능 수로 판정하지 않는다. 신청을 예로 들면 조회·제출·판정·결과·취소가 있다는 사실만으로 부족하다. 각 기능이 어떤 상태에서 시작해 어느 상태로 끝나는지, 중간 실패가 다른 기능에 어떤 영향을 주는지 이어져야 한다. 승인 기능은 정원 반영과 판정 기록 없이 독립적으로 완료될 수 없고, 결과 조회는 상태 원천과 사유 공개 규칙이 없으면 신뢰할 수 없다.

또한 시스템 책임과 사람의 업무를 구분한다. “교무 담당자가 오류를 해결한다”는 운영 절차이지 그대로 시스템 기능이 아니다. 시스템이 보류 신청을 식별해 담당 범위에 제공하고, 권한을 확인하며, 정정 사유와 이전·이후 상태를 기록해야 한다면 각각 기능 후보가 된다. 사람의 판단을 자동화할 것인지 지원할 것인지도 범위 결정으로 남긴다.

2. 이벤트

이벤트는 기능을 시작하거나 상태 전이를 일으키는 관찰 가능한 사건이다. 사용자의 제출, 정해진 시각 도달, 외부 응답 수신, 운영자 결정, 다른 상태의 확정이 이벤트가 될 수 있다. “신청 기간”은 지속 조건이고 “신청 기간이 시작됨”은 이벤트다.

수강신청의 이벤트와 기대 응답을 정리한다.

이벤트를 명세할 때 발생 주체, 식별자, 업무 시각, 중복·순서·유실 가능성과 적용 상태를 함께 본다. “메시지를 받으면 처리한다”라고만 쓰면 오래된 응답이 이미 취소된 신청을 승인할 수 있다. 응답이 어느 신청·판정 시도·규칙 버전에 해당하는지, 현재 상태에서 아직 유효한지 확인해야 한다.

외부 통지 성공은 신청 판정 사건과 분리한다. 승인 결과가 확정된 뒤 알림 전송이 실패하더라도 판정 자체를 거절로 바꾸지 않는다. 통지가 법·정책상 필수 전달이라면 전달 보장과 대체 조회 경로를 별도 기능·품질·인터페이스 요구로 정의한다.

3. 입력

입력은 기능이 판정과 결과를 만들기 위해 받는 정보다. 사용자가 입력한 필드뿐 아니라 인증 문맥, 학적·이수 기록, 강좌 상태, 적용 규칙 버전과 현재 시각도 입력이다. 입력 목록만 쓰지 말고 의미, 원천, 필수 여부, 유효성, 기준 시점과 오류 결과를 정한다.

입력 검증 실패와 업무 규칙 미충족을 구분한다. 강좌 ID 형식이 잘못된 것은 입력 오류이고, 유효한 강좌에 선수과목이 부족한 것은 정상 규칙 판정이다. 둘을 같은 “신청 실패”로 묶으면 학생의 다음 행동과 운영 통계가 왜곡된다.

입력 기준 시점도 기능 의미의 일부다. 학점은 요청 접수 시점, 판정 시작 시점, 승인 확정 시점 중 언제의 값인가? 규칙을 평가하는 동안 강좌 정원이 변하면 재평가하는가? 구현에서 스냅샷·잠금·충돌 탐지 중 무엇을 선택하든, 업무적으로 어떤 조합을 유효한 판정으로 인정할지 먼저 요구로 정해야 한다.

4. 처리

처리는 입력을 업무 결과로 바꾸는 시스템 행동이다. “검증한다”, “처리한다”, “고려한다”는 동사만으로는 완료를 판정할 수 없다. 어떤 규칙을 어떤 조건에 적용하고 성공·미충족·판정 불가를 어떻게 구분하는지 적는다.

FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다.의 처리 구조는 다음과 같다.

이 순서는 설명을 위한 논리 구조이지 구현 실행 순서를 강제하지 않는다. 평가 순서가 달라도 같은 입력 기준선에서 같은 최종 판정이 나와야 한다. 복수 거절 사유 중 하나만 제공한다면 사유 우선순위는 업무 결정이다. 모든 사유를 제공한다면 개인정보·정책 공개 범위와 재판정 시 일관성을 검토한다.

처리 요구는 알고리즘 세부보다 불변식과 관찰 결과를 중심으로 쓴다.

• 유효한 규칙 결과가 없으면 승인하지 않는다.
• 승인 수와 정책상 좌석 반영이 모순되지 않는다.
• 같은 신청에 모순되는 최종 상태를 만들지 않는다.
• 사용한 입력 기준 시점과 규칙 버전으로 판정을 재현할 수 있다.
• 일부 반영이 실패하면 학생에게 확정 결과를 제공하기 전에 안전 상태로 복구한다.

정원과 우선순위는 ISS-001ISS-001 · 미결 쟁점우선 배정 조건과 정원 초과 금지가 충돌할 때 마지막 좌석의 승자를 어떻게 정할지 남아 있는 정책 쟁점이다.이 해결되기 전까지 처리 로직을 확정할 수 없다. DEC-001DEC-001 · 의사결정정원·우선 처리의 결정 후보.은 승인된 정책 결정이 아니라 검토 중인 결정 기록 예시다. 기능 명세는 빈 정책을 임의 알고리즘으로 채우지 않고 결정 필요성을 노출해야 한다.

5. 출력

출력은 기능 수행 뒤 사용자나 다른 시스템이 관찰할 수 있는 정보·상태·사건이다. 화면 문구나 JSON 필드만이 아니라 승인된 신청, 거절 사유, 보류 원인, 정원 변화, 판정 기록과 후속 통지 사건이 포함된다.

출력은 상태와 사유를 사람이 이해할 수 있게 제공하면서 기계가 안정적으로 구분할 코드도 가져야 한다. 그러나 내부 오류·민감한 정책 데이터·다른 학생 정보를 그대로 노출해서는 안 된다. 사용자 메시지, 업무 사유 코드, 운영 진단 정보의 공개 범위를 분리한다.

통지 채널은 출력의 전달 수단이다. 알림이 실패해도 학생이 신청 내역에서 공식 현재 상태를 조회할 수 있어야 한다. 외부 알림 내용을 시스템의 유일한 상태 원천으로 삼지 않는다. 어떤 출력을 기준으로 삼을지 23장23장. 데이터 요구사항데이터의 의미·품질·생명주기·보호 책임을 요구사항으로 어떻게 다루는가?페이지로 이동의 데이터 요구와 24장24장. 인터페이스 요구사항시스템 경계를 넘는 계약과 실패 대응을 인터페이스 요구사항으로 어떻게 정의하는가?페이지로 이동의 계약에 연결한다.

6. 상태 변화

상태 변화는 기능이 업무 객체의 생명주기를 바꾸는 결과다. 20장20장. 모델로 표현하는 요구사항경계·상태·순서·데이터·결정의 질문에 맞는 모델을 어떻게 선택하는가?페이지로 이동의 후보 상태 접수, 판정 중, 보류, 승인, 거절, 취소를 그대로 사용한다. 기능 문장에 모델에 없는 완료, 실패, 등록됨을 새로 쓰면 같은 상태인지 확인할 수 없다.

상태 변경과 정원 반영이 일부만 성공했을 때의 복구 상태가 빠져 있다. 내부 기술 상태를 모두 업무 모델에 노출할 필요는 없지만, 학생에게 확정 결과를 주지 못하고 운영 개입이 필요한 상황은 식별 가능해야 한다. 보류가 규칙 판정 불가와 부분 반영 실패를 모두 뜻한다면 원인·복구 책임을 구분할 수 있는지 검토한다.

상태 전이마다 수행 주체, 시각, 원인 사건, 이전·이후 상태를 DR-001DR-001 · 데이터 요구학생·강좌 ID, 요청 시각, 판정 결과와 사유, 적용 규칙 버전, 최종 상태 변경을 연결해 보존한다는 데이터 요구다. 또는 하위 데이터 요구로 기록하면 추적과 복구가 가능해진다.

7. 예외 처리

예외 처리는 정상 결과를 만들 수 없을 때 안전한 상태, 설명, 복구와 책임을 정의하는 기능이다. “예외는 비기능”이라는 오해 때문에 개발자가 임의 오류 처리로 남기기 쉽지만, 보류·재평가·중복 방지·부분 실패 복구는 사용자가 관찰하는 기능 행동이다.

예외마다 재시도 가능 여부, 최대 지연이 아니라 업무 종료 조건을 먼저 정한다. 무한 재시도는 해결이 아니라 보류 누적이다. 학생이 언제 어떤 상태를 확인하고, 운영자가 언제 개입하며, 최종적으로 승인·거절·취소 중 어디로 끝나는지 필요하다.

예외 처리 요구는 22장22장. 비기능 요구사항성능·보안·사용성 같은 품질을 측정 가능한 조건으로 어떻게 표현하는가?페이지로 이동의 가용성·신뢰성·복구 수준과 24장24장. 인터페이스 요구사항시스템 경계를 넘는 계약과 실패 대응을 인터페이스 요구사항으로 어떻게 정의하는가?페이지로 이동의 타임아웃·재시도 계약을 소비한다. 기능은 실패 시 무엇을 할지 말하고, 품질 요구는 어느 시간·확률·손실 한도에서 할지 말한다.

8. 업무 규칙

업무 규칙은 조직이 어떤 사실과 조건에서 어떤 판단을 내려야 하는지 정의한다. 기능은 규칙을 적용해 결과를 만드는 책임이고, 규칙은 판정 내용이다. 규칙을 코드나 화면에만 숨기면 출처·발효일·예외·변경 영향을 검토할 수 없다.

규칙에는 출처, 결정 권한자, 적용 범위, 입력, 조건, 결론, 예외, 발효·종료 시점과 버전을 둔다. “정원이 없으면 거절한다”와 “우선 대상은 승인한다”가 같은 좌석 집합에 적용되면 ISS-001ISS-001 · 미결 쟁점우선 배정 조건과 정원 초과 금지가 충돌할 때 마지막 좌석의 승자를 어떻게 정할지 남아 있는 정책 쟁점이다. 충돌이다. 분기 순서를 바꿔 조용히 해결하지 말고 정책 결정으로 되돌린다.

업무 규칙을 요구와 일대일로 복사하지 않는다. 한 규칙은 신청 전 안내, 실제 판정, 거절 사유, 재평가와 시험에 재사용될 수 있다. 규칙 카탈로그를 기준 정보로 두고 FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다.이 적용 책임을 참조하도록 한다.

9. 권한

권한은 누가 어떤 대상과 상태에서 기능을 실행하거나 정보를 볼 수 있는지 정의한다. 로그인 여부만 확인해서는 충분하지 않다. 역할, 데이터 범위, 객체 상태, 기간, 목적, 추가 승인과 감사가 함께 필요하다.

“관리자는 모든 신청을 수정할 수 있다”는 기능 요구는 과도하다. 판정 정정은 원래 상태를 덮어쓰는 것이 아니라 원인, 승인자, 이전·이후 상태를 남기는 별도 업무 사건이어야 할 수 있다. 실제 조직의 책임과 개인정보 정책을 확인한다.

권한 거절도 기능 결과다. 사용자가 다른 학생 ID를 바꿔 조회할 때 정보 존재 여부를 과도하게 노출하지 않고, 시도와 결과를 필요한 범위에서 기록해야 한다. 인증 방식·토큰 기술은 인터페이스와 설계에서 정하되 권한 판정의 업무 의미는 여기서 유지한다.

10. 기능 분해

기능 분해기능 분해큰 기능을 입력·처리·결과와 책임이 구별되는 더 작은 기능으로 나누는 활동이다.는 큰 목표를 독립적으로 이해·승인·변경·검증할 수 있는 행동으로 나누면서 전체 흐름을 잃지 않는 일이다. 화면별·컴포넌트별로 자르는 것이 아니라 이벤트, 판정, 상태 결과와 예외 책임을 기준으로 나눈다.

분해 결과를 이벤트–응답, 예외–권한 매트릭스로 교차 점검한다.

분해가 충분한지 묻는다.

• 모든 시작 사건에 정상·대안·예외 응답이 있는가?
• 각 출력이 상태·데이터 모델의 용어와 일치하는가?
• 기능 일부만 구현하거나 시험할 수 있다면 요구가 분리됐는가?
• 분리된 기능이 함께 UR-001UR-001 · 사용자 요구신청 가능 강좌와 결과·사유 확인 / 사용자.과 G-01G-01 · 목표목표가 필요를 유발, 효과는 측정 전.을 충족하는가?
• 기능마다 품질·데이터·인터페이스 요구가 연결되어 있는가?
• 정책 미확정 항목을 구현 세부로 숨기지 않았는가?

SWEBOK과 IREB CPRE 자료는 소프트웨어 요구의 분석·명세와 다양한 작업 산출물의 선택을 다룬다. 분류 이름을 외우는 것보다 기능을 입력–행동–결과–상태–예외로 검토하고 다른 요구 유형에 연결하는 일이 중요하다.

이 장에서 정리한 결과는 기능 분해도, 이벤트–응답표, 예외·권한 매트릭스와 FR-002–FR-005FR-002–FR-005FR-002: 인증·대상·신청 기간과 요청 형식을 확인해 신청 의도를 고유 식별자로 접수하고 접수 결과를 제공한다는 기능 요구다. · FR-003: 인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다. · FR-004: 같은 신청 의도를 다시 보내도 복수 승인이나 좌석 변동을 만들지 않고 기존 신청 상태에 연결한다는 기능 요구다. · FR-005: 신청·판정 이력. 후보다. 다음 장에서는 각 기능이 얼마나 빠르고 안정적이며 안전하고 사용 가능해야 하는지를 상황·자극·응답·측정치가 있는 품질 시나리오로 정한다.

수강신청 사례에 적용

판단 기준과 흔한 오류

직접 해보는 실습

핵심 요약

관련 도구와 다음 경로