31장. 요구사항에서 기능으로
요구사항을 기능·흐름·화면·API로 전환하면서 일대일 대응을 피하고 각 설계 후보의 기여 범위를 기록한다.
이번 장에서 해결할 질문
학습 목표
학습 목표- “상위 요구를 사용자 가치가 보존되는 기능 단위로 어떻게 분해하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
- 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.
핵심 개념
요구사항에서 기능으로 넘어간다는 말은 요구 문장을 메뉴 이름으로 바꾸는 일이 아니다. 하나의 요구가 여러 기능과 품질·데이터·인터페이스 책임에 걸칠 수 있고, 여러 요구가 하나의 기능 안에서 함께 실현되기도 한다. 일대일 대응을 강요하면 상위 목적이나 공통 규칙이 사라진다.
이 장에서는 목표와 사용자 과업을 확인하고 시스템 책임을 응집된 기능 단위로 묶는다. 재사용할 업무 규칙과 데이터·인터페이스 제약을 분리하면서 요구와 기능의 다대다 관계다대다 관계하나의 요구가 여러 기능에, 하나의 기능이 여러 요구에 기여하는 연결 방식이다.를 기록해, 설계·구현·시험에 할당할 수 있는 구조를 만든다.
1. 요구에서 기능으로 전환하는 원칙
9부에서 만든 관리 정보가 출발점이다. FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다. 같은 안정된 ID, 후보 상태와 버전, G-01G-01 · 목표목표가 필요를 유발, 효과는 측정 전.부터 시험 항목까지의 추적 관계, 미결 ISS-001ISS-001 · 미결 쟁점우선 배정 조건과 정원 초과 금지가 충돌할 때 마지막 좌석의 승자를 어떻게 정할지 남아 있는 정책 쟁점이다., ASM-001–ASM-003ASM-001–ASM-003ASM-001: 결과를 알 수 없는 상태에서 발생하는 반복 제출이 수동 재처리 증가에 유의미하게 기여한다는 미확인 가정이다. · ASM-002: 규칙 버전 제공 여부 미확인. · ASM-003: 처리 보류가 좌석을 점유하는가?, 변경 요청 CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다.을 함께 가져온다. 다만 현재 원고의 요구들은 실제 이해관계자 승인을 받은 기준선이 아니다. 이 장의 FEAT·FLOW·SCR·API·DATA·TC 식별자는 교육용 설계 후보이며, 실제 개발 착수를 승인하는 산출물이 아니다.
IIBA의 Requirements Analysis and Design Definition은 필요를 요구와 설계 대안으로 점진적·반복적으로 전환하는 활동을 다룬다. 요구는 필요한 결과와 제약을 설명하고, 설계는 그것을 충족할 방법을 선택한다. 기능 분해는 그 경계에 있으며 선택 근거와 상향 추적을 보존해야 한다.
먼저 기능 목록을 보지 말고 상위 연결을 읽는다.
BR-001BR-001 · 업무 요구목표값과 투자 범위. 사업 후원자·교무 책임자.의 첫 30분 수동 재처리 50% 감소, QR-001QR-001 · 품질 요구합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다.의 상태 조회 p95 2초는 모두 기준선과 환경이 확인되지 않은 후보 목표다. 기능을 도출할 수는 있지만 이 숫자를 승인된 수용 기준으로 넘기지 않는다. RULE-005RULE-005 · 업무 규칙우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다는 미확정 업무 규칙 후보다.와 CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다.도 정책 미결이므로 기능 설명에 졸업 예정자 우선 배정을 확정해 넣지 않는다.
사용자 목표를 한 문장으로 쓰면 “학생이 자신의 조건에서 신청 가능한 강좌를 찾아 신청하고, 판정 상태와 사유를 이해하며 필요하면 취소한다”가 된다. 이 목표에는 검색, 상세 확인, 제출, 규칙 평가, 좌석 반영, 결과 조회, 취소와 회복이 포함된다. 화면 순서가 아니라 사용자 결과와 시스템 책임으로 나눈다.
기능 후보를 찾는 질문은 다음과 같다.
- 사용자가 독립적으로 달성하려는 결과는 무엇인가?
- 시스템이 원자적으로 보장해야 할 업무 결과는 무엇인가?
- 어떤 규칙이 여러 흐름에서 재사용되며 누가 소유하는가?
- 어떤 상태·데이터를 공식 기준으로 삼아야 하는가?
- 외부 실패·중복·늦은 응답에서 별도 책임이 필요한가?
- 기능을 따로 바꾸거나 시험하고 운영할 이유가 있는가?
이 질문으로 만든 기능 구조 후보는 다음과 같다.
| 기능 ID 후보 | 이름 | 사용자·업무 결과 | 주요 입력 | 책임 경계 |
|---|---|---|---|---|
FEAT-CATALOG-01FEAT-CATALOG-01 · 기능 묶음강좌 탐색과 판단 정보 제공. |
강좌 탐색 | 조건에 맞는 강좌와 신청 판단에 필요한 정보 확인 | 학기, 검색·필터 조건, 학생 문맥 | 강좌 기준정보를 임의로 수정하지 않음 |
FEAT-ELIGIBILITY-01FEAT-ELIGIBILITY-01 · 기능 묶음신청 자격 판정. |
신청 자격 판정 | 적용 규칙과 기준 시점으로 승인·거절·보류 근거 생성 | 학적·이수·시간표·학점·강좌·규칙 | 좌석의 최종 반영과 분리 가능 |
FEAT-ENROLL-01FEAT-ENROLL-01 · 기능 묶음신청 접수·좌석 반영. |
신청 접수·좌석 반영 | 한 신청 의도를 식별하고 허용된 최종 효과 생성 | 학생, 강좌개설, 요청 ID, 판정 | 중복·동시성·수용량을 보장 |
FEAT-STATUS-01FEAT-STATUS-01 · 기능 묶음신청 상태·사유 조회. |
신청 상태·사유 조회 | 접수와 최종 판정을 구분해 다음 행동 확인 | 인증 주체, 신청 ID | 알림이 아닌 공식 상태 제공 |
FEAT-CANCEL-01FEAT-CANCEL-01 · 기능 묶음정책상 허용된 상태의 신청을 취소하고 늦은 판정과 좌석 복구를 조정하며 상태 이력을 유지하는 기능 후보다. |
신청 취소 | 허용된 상태의 신청 효과를 취소하고 이력 유지 | 학생, 신청 ID, 현재 버전 | 늦은 판정과 좌석 복구 조정 |
FEAT-NOTIFY-01FEAT-NOTIFY-01 · 기능 묶음상태 변경 보조 통지. |
결과 통지 | 판정 변경을 보조 채널로 알림 | 판정 사건, 공개 가능한 내용, 수신 참조 | 전달 실패가 판정 상태를 되돌리지 않음 |
FEAT-OPERATE-01FEAT-OPERATE-01 · 기능 묶음보류·예외 운영. |
보류·예외 운영 | 보류 적체·데이터 오류·재평가를 추적 | 원인, 신청·판정 ID, 운영 권한 | 정책을 운영자가 임의 변경하지 않음 |
이 목록은 화면 일곱 개를 뜻하지 않는다. FEAT-ELIGIBILITY-01FEAT-ELIGIBILITY-01 · 기능 묶음신청 자격 판정.은 사용자에게 독립 화면이 없을 수 있고, FEAT-STATUS-01FEAT-STATUS-01 · 기능 묶음신청 상태·사유 조회.은 목록과 상세 화면에 나뉠 수 있다. 반대로 하나의 화면에서 탐색·상세·신청 준비 기능을 조합할 수 있다. 기능은 사용자 가치와 시스템 책임의 단위이고 화면은 상호작용 설계다.
기능의 경계는 상태와 효과로 검토한다. FEAT-ENROLL-01FEAT-ENROLL-01 · 기능 묶음신청 접수·좌석 반영.이 접수·판정·알림·문의까지 모두 맡으면 실패 의미와 변경 책임이 섞인다. 접수 성공 후 규칙 서비스가 시간 초과할 수 있으므로 접수 상태와 판정 상태를 구분하고 IR-001IR-001 · 인터페이스 요구자격·운영 흐름.에 따라 안전 보류할 수 있어야 한다. FEAT-NOTIFY-01FEAT-NOTIFY-01 · 기능 묶음상태 변경 보조 통지.은 최종 판정 사건을 받아 전달하지만, 알림 성공 여부가 신청의 공식 상태는 아니다.
기능 사이의 기본 흐름 후보는 다음과 같다.
이를 FLOW-ENR-01FLOW-ENR-01 · 사용 흐름신청·보류·우선 배정·이의의 시간 순서가 달라지는가? 신청 생명주기 흐름 후보로 관리한다. 흐름은 단순 페이지 이동이 아니라 접수, 보류, 승인, 거절, 취소와 늦은 응답의 상태 전이를 포함한다. 강좌 수용량 대기열은 아직 승인된 범위가 아니다. 처리 중 보류와 좌석 부족 대기명단을 같은 “대기”로 만들지 않는다.
업무 규칙은 기능 안에 흩어 복사하지 않는다. RULE-001RULE-001 · 업무 규칙신청자가 적용되는 선수과목의 동시 이수·대체·면제·성적 시점 조건을 충족해야 한다는 업무 규칙 후보다. 선수과목, RULE-002RULE-002 · 업무 규칙승인으로 계산되는 학점 합계가 학생에게 적용되는 최대 신청 학점을 넘지 않아야 한다는 업무 규칙 후보다. 최대 학점, RULE-003RULE-003 · 업무 규칙시간 충돌 판정. 시간표 충돌, RULE-005RULE-005 · 업무 규칙우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다는 미확정 업무 규칙 후보다. 우선순위 배정 후보는 판정 기능에 할당하되 검색 안내, 신청 준비, 판정, 취소 후 재평가가 같은 정책 버전을 참조하게 한다.
| 규칙 | 소유·기준 후보 | 적용 기능 | 표현·사용 책임 | 미해결 |
|---|---|---|---|---|
RULE-001RULE-001 · 업무 규칙신청자가 적용되는 선수과목의 동시 이수·대체·면제·성적 시점 조건을 충족해야 한다는 업무 규칙 후보다. 선수과목 |
학사 정책 원문 | 탐색 안내, 자격 판정, 결과 설명 | 안내와 실제 판정의 버전 차이 표시 | 출처·예외 확인 |
RULE-002RULE-002 · 업무 규칙승인으로 계산되는 학점 합계가 학생에게 적용되는 최대 신청 학점을 넘지 않아야 한다는 업무 규칙 후보다. 최대 학점 |
학사 정책 원문 | 자격 판정, 취소 후 상태 | 기준 시점의 수강·신청 학점 사용 | 동시 신청 처리 |
RULE-003RULE-003 · 업무 규칙시간 충돌 판정. 시간 충돌 |
강좌 일정·정책 | 탐색 안내, 자격 판정 | 겹침 정의와 예외를 같은 규칙으로 사용 | 시간 경계 확인 |
RULE-005RULE-005 · 업무 규칙우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다는 미확정 업무 규칙 후보다. 우선순위 |
정책 결정 필요 | 좌석 배정 후보 | 화면·API가 내부 점수를 임의 노출하지 않음 | ISS-001ISS-001 · 미결 쟁점우선 배정 조건과 정원 초과 금지가 충돌할 때 마지막 좌석의 승자를 어떻게 정할지 남아 있는 정책 쟁점이다., CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다. |
규칙을 재사용한다는 말은 모든 기능이 규칙 엔진을 직접 호출한다는 설계 결정이 아니다. 하나의 정책 정의와 버전을 공유한다는 뜻이다. 호출 방식·캐시·동기 여부는 33장33장. 요구사항에서 시스템 설계로요구가 아키텍처 결정을 제약하는 지점과 설계 선택인 지점을 어떻게 구분하는가?페이지로 이동에서 대안을 비교한다. 검색 화면의 사전 안내는 사용 편의를 높일 수 있지만 최종 판정의 근거가 아니다.
요구-기능 매핑으로 누락과 과도한 기능을 검사한다.
| 요구 | 기능 후보 | 할당 의미 | 검토할 누락 |
|---|---|---|---|
FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다. |
FEAT-ELIGIBILITY-01FEAT-ELIGIBILITY-01 · 기능 묶음신청 자격 판정., FEAT-ENROLL-01FEAT-ENROLL-01 · 기능 묶음신청 접수·좌석 반영. |
규칙 결과와 최종 효과 조정 | 규칙 버전·보류·동시성 |
FR-002FR-002 · 기능 요구인증·대상·신청 기간과 요청 형식을 확인해 신청 의도를 고유 식별자로 접수하고 접수 결과를 제공한다는 기능 요구다. |
FEAT-ENROLL-01FEAT-ENROLL-01 · 기능 묶음신청 접수·좌석 반영. |
요청 ID로 유효 접수 생성 | 미접수·응답 유실·재조회 |
FR-003FR-003 · 기능 요구인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다. |
FEAT-STATUS-01FEAT-STATUS-01 · 기능 묶음신청 상태·사유 조회., FEAT-NOTIFY-01FEAT-NOTIFY-01 · 기능 묶음상태 변경 보조 통지. |
공식 조회와 보조 통지 분리 | 사유 공개·다음 행동 |
FR-004FR-004 · 기능 요구같은 신청 의도를 다시 보내도 복수 승인이나 좌석 변동을 만들지 않고 기존 신청 상태에 연결한다는 기능 요구다. |
FEAT-ENROLL-01FEAT-ENROLL-01 · 기능 묶음신청 접수·좌석 반영., FEAT-STATUS-01FEAT-STATUS-01 · 기능 묶음신청 상태·사유 조회. |
같은 의도의 중복 반영 방지·기존 결과 제공 | 동일성 키·보존 기간 |
FR-005FR-005 · 기능 요구신청·판정 이력. |
FEAT-CANCEL-01FEAT-CANCEL-01 · 기능 묶음정책상 허용된 상태의 신청을 취소하고 늦은 판정과 좌석 복구를 조정하며 상태 이력을 유지하는 기능 후보다., FEAT-ENROLL-01FEAT-ENROLL-01 · 기능 묶음신청 접수·좌석 반영. |
허용 취소와 좌석·늦은 판정 조정 | 취소 가능 상태·마감 |
IR-001IR-001 · 인터페이스 요구자격·운영 흐름. |
FEAT-ELIGIBILITY-01FEAT-ELIGIBILITY-01 · 기능 묶음신청 자격 판정., FEAT-OPERATE-01FEAT-OPERATE-01 · 기능 묶음보류·예외 운영. |
외부 실패에서 자동 승인 없이 보류·회복 | 재평가·종료 정책 |
QR-003QR-003 · 품질 요구동시 신청 경쟁. |
FEAT-ENROLL-01FEAT-ENROLL-01 · 기능 묶음신청 접수·좌석 반영. |
수용량 초과와 좌석 중복 반영 금지 | 마지막 좌석 동시 요청 |
DR-001DR-001 · 데이터 요구학생·강좌 ID, 요청 시각, 판정 결과와 사유, 적용 규칙 버전, 최종 상태 변경을 연결해 보존한다는 데이터 요구다. |
모든 판정·상태 기능 | 판정·사유·규칙 버전·상태 이력 | 기록 실패·보존·권한 |
매핑은 체크 표시보다 할당 의미를 써야 한다. FR-003FR-003 · 기능 요구인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다.을 알림 기능에만 연결하면 통지 유실 시 학생이 결과를 확인할 공식 경로가 사라진다. QR-003QR-003 · 품질 요구동시 신청 경쟁.을 데이터베이스 항목에만 연결하면 신청 기능의 동시성 책임이 모호해진다.
2. 요구와 기능의 대응 관계
기능에서 다음 산출물로 내려갈 추적 항목도 준비한다.
| 기능 | 흐름 | 화면 후보 | API 후보 | 데이터 후보 | 시험 후보 |
|---|---|---|---|---|---|
FEAT-CATALOG-01FEAT-CATALOG-01 · 기능 묶음강좌 탐색과 판단 정보 제공. |
FLOW-ENR-01FLOW-ENR-01 · 사용 흐름신청·보류·우선 배정·이의의 시간 순서가 달라지는가? |
SCR-CATALOG-01SCR-CATALOG-01 · 화면 설계조건에 맞는 강좌 탐색., SCR-COURSE-01SCR-COURSE-01 · 화면 설계강좌 선택, 신청 준비. |
API-CATALOG-01API-CATALOG-01 · API 설계강좌 검색·상세 제공. |
DATA-COURSE-01DATA-COURSE-01 · 데이터 설계학기·강좌개설·일정·수용량의 조회 표현. |
TC-CATALOG-01TC-CATALOG-01 · 시험 항목강좌 탐색과 상세 정보가 신청 가능 판단에 필요한 최신 정보를 제공하는지 확인하는 시험 후보다. |
FEAT-ENROLL-01FEAT-ENROLL-01 · 기능 묶음신청 접수·좌석 반영. |
FLOW-ENR-01FLOW-ENR-01 · 사용 흐름신청·보류·우선 배정·이의의 시간 순서가 달라지는가? |
SCR-REVIEW-01SCR-REVIEW-01 · 화면 설계제출 의도 확인., SCR-STATUS-01SCR-STATUS-01 · 화면 설계적용 사유와 정정 안내. |
API-ENROLL-01API-ENROLL-01 · API 설계신청 의도 접수. |
DATA-APPLICATION-01DATA-APPLICATION-01 · 데이터 설계신청 ID, 주체, 대상, 요청 ID, 현재 상태·버전. |
TC-DUP-001-01TC-DUP-001-01 · 시험 항목같은 신청 의도가 반복되거나 응답이 유실돼도 기존 신청에 연결되고 중복 처리가 생기지 않는지 확인하는 시험 후보다., TC-CAP-001-01TC-CAP-001-01 · 시험 항목마지막 좌석에 여러 신청이 동시에 들어와도 정원 초과와 복수 승인이 생기지 않는지 확인하는 시험 후보다. |
FEAT-STATUS-01FEAT-STATUS-01 · 기능 묶음신청 상태·사유 조회. |
FLOW-ENR-01FLOW-ENR-01 · 사용 흐름신청·보류·우선 배정·이의의 시간 순서가 달라지는가? |
SCR-STATUS-01SCR-STATUS-01 · 화면 설계적용 사유와 정정 안내. |
API-STATUS-01API-STATUS-01 · API 설계공식 상태·사유 조회. |
DATA-DECISION-01DATA-DECISION-01 · 데이터 설계학적 기준·우선 근거 재현. |
TC-FR-003-01TC-FR-003-01 · 시험 항목정상·보류·거절·인가 결과 확인. |
FEAT-CANCEL-01FEAT-CANCEL-01 · 기능 묶음정책상 허용된 상태의 신청을 취소하고 늦은 판정과 좌석 복구를 조정하며 상태 이력을 유지하는 기능 후보다. |
FLOW-ENR-01FLOW-ENR-01 · 사용 흐름신청·보류·우선 배정·이의의 시간 순서가 달라지는가? |
SCR-CANCEL-01SCR-CANCEL-01 · 화면 설계취소 의도 확인., SCR-STATUS-01SCR-STATUS-01 · 화면 설계적용 사유와 정정 안내. |
API-CANCEL-01API-CANCEL-01 · API 설계허용 상태의 취소. |
신청·판정 상태 이력 | TC-CAN-001-01TC-CAN-001-01 · 시험 항목판정 중 취소와 늦은 승인 응답이 경합할 때 더 새로운 유효 상태를 보존하는지 확인하는 시험 후보다. |
FEAT-ELIGIBILITY-01FEAT-ELIGIBILITY-01 · 기능 묶음신청 자격 판정. |
판정 하위 흐름 | 직접 화면 없음 가능 | API-RULE-01API-RULE-01 · API 설계규칙 평가 연계. |
규칙 입력·판정 참조 | TC-RULE-001-01TC-RULE-001-01 · 시험 항목선수과목 조건의 충족·미충족·경계 사례에서 유효한 결과와 사유가 기록되는지 확인하는 시험 후보다., TC-IR-001-01TC-IR-001-01 · 시험 항목규칙 연계의 실패·무효·시간 초과·늦은 응답에서 자동 승인 없이 원인 있는 보류와 이력이 남는지 확인하는 시험 후보다. |
모든 ID는 후보이며 32장32장. 요구사항에서 화면으로요구사항에서 화면 흐름·상태·오류·접근성 기준을 어떻게 도출하는가?페이지로 이동–34장34장. 요구사항에서 시험으로요구사항의 수용 기준을 실행 가능한 시험 조건으로 어떻게 전환하는가?페이지로 이동에서 책임과 검증 방법을 구체화한다. 화면·API·데이터가 반드시 일대일이어야 하는 것은 아니다. 중요한 것은 각 하위 항목에서 상위 기능과 요구로 돌아갈 수 있고, 설계 대안이 바뀌어도 필요의 키가 유지되는 것이다.
기능 분해의 대안을 비교해 보자. 하나의 “수강신청” 기능으로 두면 목록은 단순하지만 접수·판정·좌석·통지의 실패와 책임을 독립 검증하기 어렵다. 반대로 모든 규칙·상태를 미세 기능으로 나누면 호출·운영 경계까지 미리 고정하고 추적 비용이 커진다. 이 사례에서는 사용자 결과와 원자적 업무 효과를 기준으로 중간 크기의 기능 후보를 두고, 컴포넌트 경계는 33장33장. 요구사항에서 시스템 설계로요구가 아키텍처 결정을 제약하는 지점과 설계 선택인 지점을 어떻게 구분하는가?페이지로 이동의 품질 시나리오와 대안 분석 뒤 결정하는 방식이 적절하다.
기능 후보마다 최소 명세 카드를 만들면 이름만 있는 목록을 피할 수 있다. FEAT-ENROLL-01FEAT-ENROLL-01 · 기능 묶음신청 접수·좌석 반영.의 예는 다음과 같다.
| 항목 | 내용 후보 |
|---|---|
| 목적 | 학생의 하나의 신청 의도를 식별해 접수하고 허용된 판정 결과·좌석 변경과 연결 |
| 촉발 | 인증된 학생이 정해진 신청 기간에 강좌개설을 제출 |
| 사전조건 | 권한, 학기·강좌 식별, 입력 형식과 기간을 확인할 수 있음 |
| 입력 | 학생 문맥, 강좌개설 ID, 요청 ID, 제출 기준 시점 |
| 정상 결과 | 신청 ID와 접수 상태, 즉시 판정이면 허용된 최종 상태·사유 |
| 대안 결과 | 규칙 미충족 거절, 연계 실패 보류, 기존 동일 요청 결과 반환 |
| 금지 결과 | 자동 승인, 수용량 초과, 같은 의도의 복수 최종 판정·좌석 반영 |
| 기준 데이터 | 신청·판정 상태와 좌석 변경 결과; 실제 저장 구조는 설계에서 선택 |
| 관련 요구 | FR-001–FR-004FR-001–FR-004FR-001: 학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다. · FR-002: 인증·대상·신청 기간과 요청 형식을 확인해 신청 의도를 고유 식별자로 접수하고 접수 결과를 제공한다는 기능 요구다. · FR-003: 인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다. · FR-004: 같은 신청 의도를 다시 보내도 복수 승인이나 좌석 변동을 만들지 않고 기존 신청 상태에 연결한다는 기능 요구다., QR-003QR-003 · 품질 요구동시 신청 경쟁., DR-001DR-001 · 데이터 요구학생·강좌 ID, 요청 시각, 판정 결과와 사유, 적용 규칙 버전, 최종 상태 변경을 연결해 보존한다는 데이터 요구다.·003, IR-001IR-001 · 인터페이스 요구자격·운영 흐름.·004 |
| 미결 항목 | 동일성 적용 기간, 보류 종료, RULE-005RULE-005 · 업무 규칙우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다는 미확정 업무 규칙 후보다., 취소와 경합 정책 |
카드는 API 계약이나 데이터 스키마가 아니다. 기능의 외부에서 관찰할 책임과 필요한 결정만 적는다. 예컨대 “메시지 큐에 넣는다”, “Redis로 잠근다”, “특정 DB 트랜잭션을 사용한다”는 설계 대안이다. 품질·외부 제약과 비교해 선택하기 전에는 기능 정의에 고정하지 않는다.
분해 과정에서는 입력부터 출력까지 한 번에 그리지 말고 사건과 상태를 교차한다.
| 사건 | 현재 상태 | 책임 기능 | 다음 상태 후보 | 확인할 경합 |
|---|---|---|---|---|
| 새 제출 | 없음 | FEAT-ENROLL-01FEAT-ENROLL-01 · 기능 묶음신청 접수·좌석 반영. |
접수 또는 비접수 | 같은 요청 재전송 |
| 규칙 결과 | 접수·판정 중 | FEAT-ELIGIBILITY-01FEAT-ELIGIBILITY-01 · 기능 묶음신청 자격 판정. |
승인 후보·거절·보류 | 취소·규칙 버전 변경 |
| 좌석 반영 | 승인 후보 | FEAT-ENROLL-01FEAT-ENROLL-01 · 기능 묶음신청 접수·좌석 반영. |
승인 또는 정책상 비승인 | 마지막 좌석 동시 요청 |
| 시간 초과 | 판정 중 | 자격 판정·운영 | 보류 | 늦은 성공·재평가 |
| 취소 요청 | 접수·보류·승인 | FEAT-CANCEL-01FEAT-CANCEL-01 · 기능 묶음정책상 허용된 상태의 신청을 취소하고 늦은 판정과 좌석 복구를 조정하며 상태 이력을 유지하는 기능 후보다. |
취소 또는 취소 불가 | 판정·좌석 반영과 동시 |
| 알림 실패 | 최종 판정 | FEAT-NOTIFY-01FEAT-NOTIFY-01 · 기능 묶음상태 변경 보조 통지. |
판정 유지 | 중복 통지·재시도 |
이 표에서 상태 전이 책임이 두 기능에 겹치면 조정 원칙이 필요하다. 최종 저장 위치나 트랜잭션 방식은 아직 정하지 않더라도 어떤 기능이 업무 결과를 소유하고 어떤 기능이 판정 제안을 제공하는지는 구분할 수 있다. 그렇지 않으면 양쪽이 각각 승인했다고 기록하거나 어느 쪽도 좌석 복구를 책임지지 않을 수 있다.
기능 분해는 변경 분석에도 사용한다. CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다.이 졸업 예정자 우선 정책을 제안하면 먼저 FEAT-ELIGIBILITY-01FEAT-ELIGIBILITY-01 · 기능 묶음신청 자격 판정.의 규칙 입력과 FEAT-ENROLL-01FEAT-ENROLL-01 · 기능 묶음신청 접수·좌석 반영.의 좌석 배정 책임이 영향을 받는다. FEAT-STATUS-01FEAT-STATUS-01 · 기능 묶음신청 상태·사유 조회.은 우선 적용 사유와 이의 경로를 설명해야 할 수 있고, FEAT-CATALOG-01FEAT-CATALOG-01 · 기능 묶음강좌 탐색과 판단 정보 제공.의 사전 안내는 실제 판정과 같은 정책 버전을 사용해야 한다. 반면 FEAT-NOTIFY-01FEAT-NOTIFY-01 · 기능 묶음상태 변경 보조 통지.의 전달 방식은 바뀌지 않을 수도 있다. 기능 관계가 있어도 실제 차이가 없으면 영향 없음 근거를 남긴다.
반대로 하위 설계에서 새 기능 요구가 올라올 수 있다. 운영자가 보류를 일괄 재처리할 도구가 필요하다는 분석이 나오면 FEAT-OPERATE-01FEAT-OPERATE-01 · 기능 묶음보류·예외 운영.의 범위를 기존 목표·업무 책임과 확인한다. 편의를 위해 추가한 관리자 기능이 학생 상태를 임의 수정하거나 감사 없이 정책을 우회한다면 상위 요구와 충돌한다. 설계 필요가 발견됐다는 이유로 자동 승인하지 않고 요구 후보로 되돌려 검증·확인한다.
검토자는 기능마다 다음을 묻는다.
- 상위 목표·요구와 직접 또는 파생 관계가 있는가?
- 이름이 구현 기술이 아니라 책임과 결과를 설명하는가?
- 한 기능 안에 독립적으로 바뀌는 두 정책·효과가 섞이지 않았는가?
- 기능 사이의 공식 상태, 호출 결과와 실패 책임이 분명한가?
- 정상뿐 아니라 중복·시간 초과·늦은 응답·취소가 포함되는가?
- 화면이 없는 기능과 화면을 공유하는 기능을 허용하는가?
- 미확인 규칙·후보 수치를 설계 사실로 굳히지 않았는가?
- 하위 화면·API·데이터·시험 항목에서 다시 상향 추적할 수 있는가?
3. 전환 산출물과 다음 단계
이 장에서 정리한 결과는 요구-기능 매핑표, 기능 분해도, 규칙 할당표, 하위 추적 항목 목록이다. 새 정보로 기능 경계가 바뀌면 ID·대체 관계와 영향을 기록하고, 요구 자체가 변했는지도 구분한다. 다음 장에서는 FLOW-ENR-01FLOW-ENR-01 · 사용 흐름신청·보류·우선 배정·이의의 시간 순서가 달라지는가?과 기능 후보를 학생의 검색·상세·신청·보류·결과·취소 접점으로 옮기되, 와이어프레임이 요구를 대신하지 않도록 화면 상태와 권한을 추적한다.
수강신청 사례에 적용
판단 기준과 흔한 오류
직접 해보는 실습
1. 대상 선택
현재 프로젝트 산출물 중 이 장의 질문과 관련된 항목 하나를 고른다.
2. 근거와 예외 표시
본문의 판단 질문으로 누락된 근거와 예외를 표시한다.
3. 다음 행동 기록
확인할 책임자, 필요한 최소 증거와 다음 행동을 기록한다.