48장. 설계로 전환

명세 후보를 설계 탐색 입력으로 사용해 기능·데이터·인터페이스 책임을 할당하되 미정 정책을 확정하지 않는다.

이번 장에서 해결할 질문

학습 목표

• “합의된 요구를 화면·서비스·데이터·시험 설계로 어떻게 넘기는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
• 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.

핵심 개념

요구사항 명세는 설계의 입력이지만 설계 해답 자체는 아니다. 요구 문장을 화면·서비스·데이터 구조에 기계적으로 대응시키면 공통 책임과 품질 트레이드오프를 놓치고, 아직 결정되지 않은 정책을 기술 선택으로 몰래 확정할 수 있다. 설계는 요구를 만족하는 대안을 탐색해야 한다.

이 장에서는 47장의 명세 후보를 바탕으로 기능·데이터·인터페이스 책임을 설계 요소에 할당한다. 대안과 결정 근거, 요구와의 추적 관계를 기록하고 미정 정책을 열린 항목으로 유지해, 검토 가능한 설계 후보를 만드는 과정을 보여 준다.

1. 요구를 설계 입력으로 해석한다

설계 전환의 입력은 요구 문장만이 아니다. 목표 G-01G-01 · 목표목표가 필요를 유발, 효과는 측정 전., 업무 목표 BR-001BR-001 · 업무 요구목표값과 투자 범위. 사업 후원자·교무 책임자., 사용자·시스템 요구 UR-001UR-001 · 사용자 요구신청 가능 강좌와 결과·사유 확인 / 사용자.과 SR-001SR-001 · 시스템 요구멱등 처리 항목.을 먼저 읽는다. 여기에 기능 요구 FR-001–FR-005FR-001–FR-005FR-001: 학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다. · FR-002: 인증·대상·신청 기간과 요청 형식을 확인해 신청 의도를 고유 식별자로 접수하고 접수 결과를 제공한다는 기능 요구다. · FR-003: 인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다. · FR-004: 같은 신청 의도를 다시 보내도 복수 승인이나 좌석 변동을 만들지 않고 기존 신청 상태에 연결한다는 기능 요구다. · FR-005: 신청·판정 이력., 품질 요구 QR-001–QR-011QR-001–QR-011QR-001: 합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다. · QR-002: 핵심 업무 99.9% 가용 후보. · QR-003: 동시 신청 경쟁. · QR-004: 기준 요청량 2배 후보. · QR-005: 다른 학생 객체 접근. · QR-006: 대표 사용자는 신청·상태 과업과 공개 사유의 다음 행동을 합의한 성공 기준으로 이해해야 한다 · QR-007: 적용 접근성 기준 미정. · QR-008: 승인된 규칙 변경의 영향받는 요구·설계·시험·계약·운영 자료를 추적하고 정한 시간 안에 갱신·검증할 수 있어야 한다 · QR-009: 권한 있는 역할은 판정·상태 변화를 원천·주체·입력·규칙 버전까지 재현할 수 있어야 한다 · QR-010: 정의된 장애에서 안전 상태를 보존하고 합의된 목표 안에 재평가·복구·대사할 수 있어야 한다 · QR-011: 목적에 필요한 최소 개인정보만 처리하고 승인된 접근·보존·파기·공개 범위를 적용해야 한다, 데이터 요구 DR-001–DR-006DR-001–DR-006DR-001: 학생·강좌 ID, 요청 시각, 판정 결과와 사유, 적용 규칙 버전, 최종 상태 변경을 연결해 보존한다는 데이터 요구다. · DR-002: 신청과 요청·판정·상태 변경을 고유 식별자로 연결한다 · DR-003: 학생·강좌·규칙 입력의 원천과 기준 시점을 판정에 연결한다 · DR-004: 현재 상태와 변경 이력이 모순되지 않게 유지한다 · DR-005: 데이터별 목적·접근·보존·파기 기준을 적용한다 · DR-006: 이관 전후 건수·관계·핵심 값과 이력을 대사할 수 있게 한다, 인터페이스 요구 IR-001–IR-006IR-001–IR-006IR-001: 자격·운영 흐름. · IR-002: 주체 인증·세션 정보. · IR-003: 학생·강좌·이수 원천. · IR-004: 규칙 결과·사유·버전 제공. · IR-005: 최소 정보·재시도·공식 조회 연결. · IR-006: 합의 형식·전달., 규칙 RULE-001–RULE-005RULE-001–RULE-005RULE-001: 신청자가 적용되는 선수과목의 동시 이수·대체·면제·성적 시점 조건을 충족해야 한다는 업무 규칙 후보다. · RULE-002: 승인으로 계산되는 학점 합계가 학생에게 적용되는 최대 신청 학점을 넘지 않아야 한다는 업무 규칙 후보다. · RULE-003: 시간 충돌 판정. · RULE-004: 분반의 승인된 수강 등록 수가 적용되는 정원을 넘지 않아야 한다는 업무 규칙이다. · RULE-005: 우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다는 미확정 업무 규칙 후보다., 상태 모델, 수용 조건, 가정과 쟁점을 함께 놓는다. 특히 ASM-002ASM-002 · 가정규칙 버전 제공 여부 미확인., ASM-003ASM-003 · 가정처리 보류가 좌석을 점유하는가?, ISS-001ISS-001 · 미결 쟁점우선 배정 조건과 정원 초과 금지가 충돌할 때 마지막 좌석의 승자를 어떻게 정할지 남아 있는 정책 쟁점이다., CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다.은 미해결이므로 설계가 그 빈칸을 몰래 채우면 안 된다. 입력 상태를 먼저 고정한다.

설계자는 이 입력을 세 종류로 나눈다. 반드시 지켜야 할 불변조건불변조건처리 순서나 설계 대안이 달라져도 언제나 참으로 유지되어야 하는 보호 조건이다., 대안을 비교할 품질 자극, 사실 확인 전에는 정할 수 없는 정책이다. 예를 들어 규칙 연계 실패를 자동 승인으로 바꾸지 않는 것은 IR-001IR-001 · 인터페이스 요구자격·운영 흐름.의 안전 불변조건이다. 상태 조회 p95 2초는 부하·데이터·측정 경계를 정해야 하는 품질 목표 후보다. 처리 보류가 좌석을 점유하는지는 ASM-003ASM-003 · 가정처리 보류가 좌석을 점유하는가?이므로 설계 선호로 결정할 정책이 아니다. 이 구분이 있어야 미결 사항을 구현 편의로 확정하지 않는다.

첫 설계 활동은 요구를 기능 책임으로 묶는 일이다. 화면이나 서비스 이름부터 정하지 않고 사용자가 얻는 결과, 상태를 바꾸는 업무 효과, 변경 이유와 실패 의미를 기준으로 기능 후보를 둔다.

기능 사이의 핵심 흐름은 FLOW-ENR-01FLOW-ENR-01 · 사용 흐름신청·보류·우선 배정·이의의 시간 순서가 달라지는가?로 관리한다. 학생이 강좌를 찾고 신청 의도를 제출하면 FEAT-ENROLL-01FEAT-ENROLL-01 · 기능 묶음신청 접수·좌석 반영.이 유효 요청을 고유 ID로 접수한다. FEAT-ELIGIBILITY-01FEAT-ELIGIBILITY-01 · 기능 묶음신청 자격 판정.은 고정된 입력 기준선과 승인된 규칙 버전으로 판정을 시도한다. 판정 결과와 좌석 반영 결과가 안전성 기준을 충족하면 신청 상태에 반영하고, FEAT-STATUS-01FEAT-STATUS-01 · 기능 묶음신청 상태·사유 조회.이 그 결과를 제공한다. 알림은 그 뒤의 보조 반응이다. 규칙 연계가 실패하거나 응답이 무효이거나 시간 초과하면 승인으로 건너뛰지 않고 원인 코드가 있는 처리 보류로 간다.

이 흐름은 페이지 이동을 그린 것이 아니라 업무 상태 전이를 그린 것이다. 접수됨은 승인됨이 아니고, 외부 장애로 생긴 처리 보류는 좌석 부족 학생을 순서대로 배정하는 대기명단이 아니다. 대기명단은 현재 확인된 범위에 없다. 보류가 좌석에 미치는 영향도 ASM-003ASM-003 · 가정처리 보류가 좌석을 점유하는가?이 열려 있으므로 도표에 점유 또는 비점유를 넣지 않는다. 전이마다 촉발 사건, 권한, 입력과 규칙 버전, 전후 상태, 사유와 요청 ID를 기록할 수 있어야 한다.

흐름을 사용자 접점으로 내리면 화면 후보가 된다. 화면은 요구를 새로 만드는 곳이 아니라 상태와 행동을 사용자가 이해하고 회복할 수 있도록 표현하는 곳이다.

SCR-STATUS-01SCR-STATUS-01 · 화면 설계적용 사유와 정정 안내.은 이 설계의 의미 보존 지점이다. 신청 ID, 접수와 최종 판정의 구분, 현재 상태, 공개 가능한 사유, 마지막 갱신 시각과 가능한 다음 행동을 제공한다. 색만으로 상태를 구분하지 않고 텍스트와 프로그램적으로 인식 가능한 의미를 함께 제공한다. 상태 조회에 실패했을 때 이전 값을 최신처럼 보이지 않게 하고, 표시한다면 마지막 확인 시각과 최신성 한계를 명시한다. 알림을 받지 못해도 이 화면에서 공식 상태를 찾을 수 있어야 한다.

화면 시안이 매끄러워도 요구를 손상할 수 있다. 제출 직후 성공 색상과 “완료”만 표시하면 접수와 승인을 섞는다. 보류를 “대기”라고 줄이면 대기명단과 혼동한다. 내부 예외 문자열을 사유로 보여 주면 개인정보·보안과 이해 가능성을 해친다. 졸업예정자 배지나 우선순위를 넣으면 미승인 CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다.을 화면이 먼저 확정한다. 따라서 시안 검토는 아름다움뿐 아니라 상태 의미, 권한, 회복, 접근성과 상향 추적을 본다.

화면 뒤의 계약은 API 후보로 구체화한다. API는 화면 필드의 운반 통로가 아니라 책임 경계 사이에서 성공, 실패, 중복, 시간 초과, 버전 충돌의 의미를 합의하는 계약이다.

API-ENROLL-01API-ENROLL-01 · API 설계신청 의도 접수.에는 인증 주체, 강좌개설 ID, 요청 ID와 필요한 제출 문맥이 들어간다. 요청 ID의 적용 범위와 보존 기간, 같은 키에 다른 본문이 왔을 때의 충돌 처리, 응답 유실 후 재조회 방법을 계약해야 한다. “재시도 가능”을 단순히 다시 실행한다는 뜻으로 쓰면 안 된다. 서버가 첫 요청을 이미 반영했는데 응답만 유실될 수 있으므로 같은 의도는 기존 신청 ID와 상태로 돌아가야 한다.

API-STATUS-01API-STATUS-01 · API 설계공식 상태·사유 조회.은 사람용 문구와 안정된 상태·사유 코드를 구분한다. 공개 문구는 지역화하거나 개선할 수 있지만 상태 전이와 시험 오라클이 의존하는 코드 의미는 버전 관리한다. 내부 사유와 공개 사유의 분리는 QR-005QR-005 · 품질 요구다른 학생 객체 접근., QR-011QR-011 · 품질 요구목적에 필요한 최소 개인정보만 처리하고 승인된 접근·보존·파기·공개 범위를 적용해야 한다과 이어진다. 지원 문의가 필요하면 개인정보가 섞인 예외 대신 안전한 상관 ID를 제공한다. 캐시를 후보로 사용하더라도 승인·좌석·최종 상태의 공식 원천을 대체하지 않는다.

데이터 후보는 화면 표를 그대로 저장하는 구조가 아니라 업무 사실과 공식 원천을 나눈다.

현재 상태 한 열만 덮어쓰면 늦은 응답과 취소 경합을 설명하기 어렵다. 반대로 모든 원천 개인정보를 무기한 복제하면 QR-011QR-011 · 품질 요구목적에 필요한 최소 개인정보만 처리하고 승인된 접근·보존·파기·공개 범위를 적용해야 한다과 DR-005DR-005 · 데이터 요구데이터별 목적·접근·보존·파기 기준을 적용한다를 해친다. 신청 식별과 상태 이력, 판정에 실제 사용한 최소 입력 기준선, 원천 버전 참조, 파생 현재 상태를 구분한다. DATA-DECISION-01DATA-DECISION-01 · 데이터 설계학적 기준·우선 근거 재현.은 학생·강좌 ID, 요청 시각, 결과와 사유, 규칙 버전, 최종 상태 변경을 연결하되 ASM-002ASM-002 · 가정규칙 버전 제공 여부 미확인.가 확인되지 않았다는 사실을 메타데이터로 남긴다. 없는 규칙 버전을 임의 생성하지 않는다.

좌석 데이터의 공식 원천은 특히 조심해서 정한다. 탐색 화면의 잔여 좌석 캐시는 안내에 쓸 수 있어도 최종 승인 기준으로 사용할 수 없다. 마지막 좌석에 여러 요청이 들어오면 승인 기록과 좌석 반영 결과가 정원 초과 없이 일치해야 한다. 조건부 갱신, 직렬화, 예약, 배치 배정 같은 구현 대안은 ISS-001ISS-001 · 미결 쟁점우선 배정 조건과 정원 초과 금지가 충돌할 때 마지막 좌석의 승자를 어떻게 정할지 남아 있는 정책 쟁점이다.의 배정 정책과 실제 부하가 확인된 뒤 비교한다. 이 장에서는 누가 승자가 되는지 정하지 않고 “승인된 정원 초과 없음”과 “중복된 승인·좌석 반영 없음”을 불변조건으로 보존한다.

기능과 데이터를 논리적 컴포넌트 후보에 할당한다. 컴포넌트는 당장 별도 배포 서비스라는 뜻이 아니다. 변경 이유, 소유 상태와 실패 의미가 비슷한 책임의 경계다.

2. 기능과 데이터를 설계 후보에 할당한다

컴포넌트 경계는 다음 불변조건으로 검토한다. 동일 신청 의도는 재전송돼도 유효한 승인이나 좌석 반영이 중복되지 않는다. 규칙 실패나 무효 응답은 승인으로 해석하지 않는다. 늦은 응답은 더 새로운 취소나 판정 상태를 덮지 않는다. 알림 전달 결과는 신청 판정을 바꾸지 않는다. 운영 조치는 주체·사유·대상·전후 상태와 함께 감사된다. 하나라도 어느 책임이 지키는지 답할 수 없다면 설계 상자가 많아도 불완전하다.

외부 연계도 컴포넌트 호출선으로 끝내지 않는다. 인증 IR-002IR-002 · 인터페이스 요구주체 인증·세션 정보., 학사정보 IR-003IR-003 · 인터페이스 요구학생·강좌·이수 원천., 규칙 IR-004IR-004 · 인터페이스 요구규칙 결과·사유·버전 제공., 알림 IR-005IR-005 · 인터페이스 요구최소 정보·재시도·공식 조회 연결., 파일 이관 IR-006IR-006 · 인터페이스 요구합의 형식·전달.마다 제공자와 소비자, 공식 원천, 기준 시점, 시간 제한, 중복·순서, 오류 분류, 스키마 버전, 개인정보 등급, 변경 통보와 운영 연락을 계약해야 한다. 실제 계약은 아직 없으므로 이 항목들은 공급자 검토 체크리스트다. 성공 응답이라도 필수 필드와 규칙 버전이 없거나 알 수 없는 상태 코드라면 승인으로 정규화하지 않는다.

품질 요구는 횡단 설계 결정의 근거가 된다. QR-001QR-001 · 품질 요구합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다.을 이유로 캐시를 넣을 수 있지만 최신성과 공식성을 함께 설계해야 한다. QR-003QR-003 · 품질 요구동시 신청 경쟁.은 요청 식별과 유일성, 원자적 상태 경계와 대사를 요구한다. QR-005QR-005 · 품질 요구다른 학생 객체 접근.와 QR-011QR-011 · 품질 요구목적에 필요한 최소 개인정보만 처리하고 승인된 접근·보존·파기·공개 범위를 적용해야 한다은 객체 수준 인가, 최소 공개와 감사 경계를 만든다. QR-007QR-007 · 품질 요구적용 접근성 기준 미정.은 화면 상태 메시지, 키보드 순서와 보조기술 확인을 설계에 넣는다. QR-010QR-010 · 품질 요구정의된 장애에서 안전 상태를 보존하고 합의된 목표 안에 재평가·복구·대사할 수 있어야 한다은 보류·재평가·격리·대사 절차를 정상 흐름과 같은 수준으로 다루게 한다.

신청 처리 방식은 동기식 일괄 처리, 완전 비동기 처리, 내구 접수와 분리 판정의 혼합 대안으로 비교한다. 동기식은 즉시 결과가 단순해 보이지만 외부 지연과 응답 유실의 불확실성을 전파한다. 완전 비동기는 부하 흡수와 재처리에 유리하지만 결과 지연, 순서·중복과 운영 복잡도가 크다. 혼합 방식은 접수 여부를 분명히 하고 제한 시간 안에 판정되지 않으면 보류로 넘길 수 있지만 상태·대사·재평가 운영이 필요하다.

현재 증거로는 혼합 방식을 우선 검토한다. 이것은 FR-002FR-002 · 기능 요구인증·대상·신청 기간과 요청 형식을 확인해 신청 의도를 고유 식별자로 접수하고 접수 결과를 제공한다는 기능 요구다., FR-003FR-003 · 기능 요구인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다., FR-004FR-004 · 기능 요구같은 신청 의도를 다시 보내도 복수 승인이나 좌석 변동을 만들지 않고 기존 신청 상태에 연결한다는 기능 요구다., IR-001IR-001 · 인터페이스 요구자격·운영 흐름., QR-010QR-010 · 품질 요구정의된 장애에서 안전 상태를 보존하고 합의된 목표 안에 재평가·복구·대사할 수 있어야 한다을 함께 설명하기 쉬운 제안이지 승인된 아키텍처가 아니다. 좌석 점유 시점, 허용 판정 지연, 피크 부하, 외부 SLA와 운영 역량이 확인되면 세 대안을 다시 비교한다. 모듈형 단일체인지 여러 서비스인지도 이 정보와 조직 경계·독립 배포 필요가 확인된 뒤 선택한다.

이 선택을 ADR-ENR-001ADR-ENR-001 · 아키텍처 결정 기록내구 접수·보류 구조 선택이 바뀌는가? 후보로 기록한다.

41장41장. 요구사항과 아키텍처품질 속성과 기술 제약을 아키텍처 판단 근거로 어떻게 연결하는가?페이지로 이동에서 사용한 ADR-ENR-01ADR-ENR-01 · 아키텍처 결정 기록규칙 서비스 지연 중 신청 의도를 먼저 보존할지와 판정 방식을 결정하기 위해 대안·근거·가정·위험·검증 방법을 기록하는 아키텍처 결정 후보다.은 이 질문을 처음 포착한 분석 카드였다. 번호가 비슷하다고 두 결정을 따로 운용하지 않는다. 그 카드는 설계 기록 ADR-ENR-001ADR-ENR-001 · 아키텍처 결정 기록내구 접수·보류 구조 선택이 바뀌는가?로 통합됐다는 매핑을 남기고 이후에는 ADR-ENR-001ADR-ENR-001 · 아키텍처 결정 기록내구 접수·보류 구조 선택이 바뀌는가?을 정식 후보 ID로 사용한다. 원 기록을 지우지 않고 통합됨 관계를 둬 검토 이력을 보존한다.

상태 조회 캐시는 ADR-ENR-002ADR-ENR-002 · 아키텍처 결정 기록상태 조회 캐시는 후보로 별도 관리한다. 후보로 별도 관리한다. 캐시는 검색·설명용 읽기 성능을 개선할 수 있지만 승인, 좌석과 최종 상태의 공식 원천을 대신하지 않는다. 허용 지연, 무효화 사건, 버전 비교, 오래된 상태 표시와 장애 시 우회 기준이 결정되지 않으면 적용하지 않는다. 이 결정은 QR-001QR-001 · 품질 요구합의된 피크 환경에서 본인 상태 조회의 성공 요청 p95 응답시간을 2초 이하로 유지한다는 미확정 품질 요구 후보다.만 보고 승인할 수 없고 FR-003FR-003 · 기능 요구인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다., DR-004DR-004 · 데이터 요구현재 상태와 변경 이력이 모순되지 않게 유지한다, QR-005QR-005 · 품질 요구다른 학생 객체 접근., QR-011QR-011 · 품질 요구목적에 필요한 최소 개인정보만 처리하고 승인된 접근·보존·파기·공개 범위를 적용해야 한다과 함께 검토해야 한다.

설계의 품질은 상향·하향으로 같은 뜻을 읽을 수 있는지 확인한다. 대표 사슬은 다음과 같다.

아래에서 위로 읽으면 DATA-DECISION-01DATA-DECISION-01 · 데이터 설계학적 기준·우선 근거 재현.의 공개 사유와 규칙 버전이 어떤 사용자 결과를 지원하는지 설명할 수 있다. API-STATUS-01API-STATUS-01 · API 설계공식 상태·사유 조회.을 없애거나 캐시로 바꾸려면 FR-003FR-003 · 기능 요구인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다.의 공식 상태, 최신성, 접근 통제와 시험이 어떻게 유지되는지 보여야 한다. 위에서 아래로 읽으면 FR-003FR-003 · 기능 요구인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다.에 화면만 있고 시험 후보나 공식 데이터가 빠진 결함을 찾을 수 있다.

주요 설계 묶음을 한 표로 대조하면 누락이 더 잘 보인다.

표가 일대일 대응을 강제하지는 않는다. 하나의 품질 요구는 여러 컴포넌트와 시험에 걸치고, 하나의 화면은 여러 기능을 조합한다. 중요한 것은 모든 하위 항목이 존재 이유와 검증 방법을 설명하며, 미승인 기능이 상향 근거 없이 생기지 않는 것이다. 예를 들어 운영 대시보드가 필요해 보여도 역할·허용 조치·감사·개인정보 요구를 먼저 요구 후보로 되돌려야 한다. 설계 편의를 사용자나 운영자의 승인된 필요로 가장하지 않는다.

설계 검토에서는 입력, 판단, 출력, 승인과 다음 인계를 구분한다. 입력은 SRS-ENR-01SRS-ENR-01 · 프로젝트 항목구조화된 검토 후보. v0.9와 미결 목록이다. 판단은 기능 경계, 상태 전이, API·데이터의 공식 원천, 컴포넌트 책임, 품질 전술과 대안 비교다. 출력은 DES-ENR-01DES-ENR-01 · 프로젝트 항목v0.1은 다음 장의 추적성 점검을 위한 교육용 후보로 유지한다. v0.1, 요구-설계 매핑, 화면·계약·데이터 카드, ADR-ENR-001ADR-ENR-001 · 아키텍처 결정 기록내구 접수·보류 구조 선택이 바뀌는가?·002 후보와 열린 질문 목록이다. 설계 책임자는 실현 가능성과 내부 일관성을 검토하고, 요구 책임자는 의미 보존을, 시험 책임자는 관찰 가능성을, 보안·개인정보·접근성 책임자는 횡단 제약을 검토한다. 학사 정책 소유자는 규칙과 미결 정책만 승인할 수 있다.

현재 설계가 요구 단계로 돌려보낼 질문도 명시한다.

이 질문들이 열려 있어도 설계 후보를 만들 수는 있다. 다만 선택을 확정하거나 개발 완료를 주장할 수는 없다. 현재 검토 결과는 조건부 진행이다. 자동 승인 금지, 중복 처리 금지, 권한 외 공개 금지, 정원 초과 금지, 상태·이력 모순 금지 같은 보호 조건은 유지한다. 누가 마지막 좌석을 얻는지, 보류가 좌석을 잡는지, 성능 목표를 어떤 환경에서 재는지, 데이터를 얼마나 보존하는지는 결정 전 빈칸으로 남긴다.

설계 승인 회의에 올릴 때는 그림 한 장만 보내지 않는다. 변경된 요구 버전, 대안과 탈락 근거, 불변조건, 위험, 미결 질문, 요구-설계-시험의 양방향 표본을 함께 제공한다. 각 검토 의견에는 작성자·시각·대상 버전·결정 역할·처리 결과를 남긴다. 실제 이해관계자와 정책 원문이 없는 이 사례에서는 어떤 역할도 실제 승인을 했다고 기록하지 않는다. DES-ENR-01DES-ENR-01 · 프로젝트 항목v0.1은 다음 장의 추적성 점검을 위한 교육용 후보로 유지한다. v0.1은 다음 장의 추적성 점검을 위한 교육용 후보로 유지한다.

다음 장의 입력은 이 설계 묶음과 47장47장. 요구사항 명세분석 결과를 문장·시나리오·모델과 수용 기준으로 어떻게 명세하는가?페이지로 이동의 요구 묶음이다. 49장49장. 추적 관계 구축프로젝트 산출물 사이에 변경 영향까지 설명하는 추적 관계를 어떻게 구축하는가?페이지로 이동에서는 요구와 설계 사이에 화살표가 있다는 사실만 확인하지 않고 관계의 종류와 방향, 버전, 책임자와 변경 사건을 점검한다. FR-003FR-003 · 기능 요구인증된 학생이 자신의 신청 상태, 공개 가능한 사유, 갱신 시각과 다음 행동을 조회할 수 있어야 한다는 기능 요구다.에서 TC-FR-003-01TC-FR-003-01 · 시험 항목정상·보류·거절·인가 결과 확인.까지 내려갔다가 다시 상위 목표로 돌아오는 대표 사슬, 고아 요구와 근거 없는 설계, 잘못된 관계를 찾아야 한다. 그 점검을 통과해야 50장50장. 요구사항 변경정책 변경을 접수한 뒤 영향분석·승인·반영·확인까지 어떻게 마무리하는가?페이지로 이동에서 변경 요청 하나가 어느 요구·화면·계약·데이터·시험에 영향을 주는지 과장 없이 계산할 수 있다.

3. 설계 탐색 결과를 추적으로 넘긴다

수강신청 사례에 적용

판단 기준과 흔한 오류

직접 해보는 실습

핵심 요약

관련 도구와 다음 경로