30장. 요구사항 상태와 생명주기

요구의 합의 상태, 구현 작업 상태와 검증 결과를 분리하고 상태 전이의 권한·증거·이력을 정의한다.

이번 장에서 해결할 질문

학습 목표

• “요구의 제안·분석·승인·구현·검증·폐기 상태와 이력을 어떻게 관리하는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
• 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.

핵심 개념

요구사항 상태는 보기 좋은 진행률 라벨이 아니다. ‘검토 중’이나 ‘승인됨’이라는 말이 어떤 증거와 권한을 뜻하는지 정하지 않으면 팀마다 같은 상태를 다르게 해석하고, 준비되지 않은 요구가 설계나 구현으로 넘어간다. 상태 전이상태 전이정해진 사건·조건·권한에 따라 요구사항이 한 상태에서 다른 상태로 바뀌는 일이다.는 다음 행동을 허용하는 통제 규칙이다.

이 장에서는 요구의 합의·검토·승인·기준선·변경 상태와 전이 조건을 정의한다. 역할별 권한과 필요한 증거, 되돌림과 보류 조건을 연결해 병목과 미결정을 드러내고, 실제 진행 상황을 왜곡하지 않는 상태 관리 방법을 다룬다.

1. 요구사항 상태를 구분한다

다음 세 대상을 분리한다.

승인된 요구라도 구현 작업은 시작 전일 수 있고, 구현됐더라도 시험 실패로 충족 증거가 없을 수 있다. 반대로 프로토타입이 있어도 요구가 승인된 것은 아니다. 하나의 “80% 완료” 값으로 이 차이를 숨기지 않는다.

상태 이름은 조직마다 달라도 된다. 중요한 것은 의미, 진입·종료 조건, 책임, 허용 행동과 필요한 기록이다. IIBA의 요구사항 생명주기 관리는 추적·유지·우선순위·변경평가·승인을 요구와 설계 정보의 생명주기 활동으로 다룬다. IREB CPRE 공식 자료의 강의계획서와 온라인 용어집은 조직 용어와 상태 개념을 맞출 때 참조할 수 있다. 특정 도구의 기본 워크플로를 표준처럼 복사하지 않는다.

이 책에서 사용할 요구사항 상태 모델 후보는 다음과 같다.

화살표는 가능한 경로일 뿐 자동 전이를 뜻하지 않는다. 예컨대 동료 검토가 끝났다고 요구가 자동 승인되지 않는다. 검토 결함이 해소되고, 사용자 필요 확인과 정책 결정이 완료되며, 권한 있는 사람이 특정 버전을 승인해야 한다. 반대로 오탈자 수정처럼 의미가 바뀌지 않는 편집은 전체 승인 흐름을 되돌리지 않을 수 있다. 프로젝트가 변경 등급과 재검토 범위를 정한다.

상태 정의표는 상태명보다 더 중요하다.

이 표에서 “구현 추적”과 “충족 검증”을 요구의 상태로 사용할지, 별도 병렬 속성으로 둘지는 조직이 선택할 수 있다. 한 요구가 여러 구성요소와 릴리스에서 구현될 때 단일 상태만으로는 정보가 손실된다. 이 경우 요구의 통제 상태는 승인으로 유지하고, 실현·검증 상태를 할당별로 별도 관리하는 편이 낫다. 상태 모델은 보고 편의보다 실제 의사결정을 정확히 표현해야 한다.

전이에는 사건, 조건, 권한과 행위를 둔다.

자동화는 조건을 검사하고 통지할 수 있지만 정책 승인이나 위험 수용을 대신하지 않는다. 모든 필드가 채워지면 상태가 자동으로 승인되는 규칙은 권한과 내용 판단을 생략한다. 반면 보류 만료 알림, 존재하지 않는 추적 대상 검사, 승인되지 않은 버전의 구현 사용 차단은 자동화하기 좋다.

변경·보류·폐기는 정상 생명주기의 일부다. 뒤로 가는 화살표를 실패로 표시하면 팀은 상태를 되돌리지 않고 실제와 다른 완료를 유지하게 된다. 새로운 정책·근거·결함이 나오면 통제된 재분석이 품질을 지키는 정상 행동이다.

승인된 요구에 변경 요청이 들어와도 기존 기준선은 즉시 무효가 되지 않는다. CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다.이 제출되면 RULE-005RULE-005 · 업무 규칙우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다는 미확정 업무 규칙 후보다.와 관련 요구의 상태를 변경 분석으로 표시하고 RULE-004RULE-004 · 업무 규칙분반의 승인된 수강 등록 수가 적용되는 정원을 넘지 않아야 한다는 업무 규칙이다.의 영향 재검증을 예약할 수 있지만, 현재 운영·설계가 사용하는 이전 승인 버전은 결정 전까지 유지된다. 요청이 승인되면 새 요구 버전과 기준선을 만들고, 반려되면 기존 버전을 유지하며, 보류되면 재개 조건과 위험을 관리한다.

현재 원고의 실제 상태와 교육용 가상 이력을 분리해야 한다. FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다., RULE-004RULE-004 · 업무 규칙분반의 승인된 수강 등록 수가 적용되는 정원을 넘지 않아야 한다는 업무 규칙이다., RULE-005RULE-005 · 업무 규칙우선 배정 기간에는 자격이 확인된 대상의 지정 분반을 일반 신청보다 먼저 평가한다는 미확정 업무 규칙 후보다., CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다.은 실제 학사 이해관계자·정책 결정권자가 승인하지 않았으므로 모두 후보 또는 분석 전 상태다. 다음 표는 생명주기를 설명하기 위한 가상 이력이며 실제 사건이 아니다.

이 가상 이력에서도 FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다. ID는 바뀌지 않는다. 내용이 바뀌면 버전이 증가하고, CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다.과 결정 기록이 연결된다. 기존 시험 결과가 새 버전에 유효한지는 차이 분석으로 정한다. 새 명명 규칙에 맞춘다는 이유로 재번호화해 과거 링크를 끊지 않는다.

2. 상태 이력과 전이 규칙

보류에는 반드시 재개 조건이 있어야 한다. “나중에 검토”만 적으면 사실상 방치다. CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다.의 보류 후보라면 졸업 지연·수요 자료 확보, 정책 결정권자 지정, 데이터 원천 가능성 확인, 다음 학기 적용 판단 마감일처럼 관찰 가능한 조건을 둔다. 보류 동안 발생할 학생·운영 위험과 임시 절차의 소유자도 기록한다. 만료 시 재평가해 재개·추가 연장·폐기 중 결정한다.

폐기도 삭제가 아니다. 필요가 사라졌거나 다른 요구로 대체돼도 과거 기준선, 구현·시험·운영 기록이 해당 ID를 가리킬 수 있다. 폐기 사유, 결정자, 효력 시점, 영향받는 릴리스, 대체 ID와 데이터·기능 제거 여부를 남긴다. 폐기된 번호는 재사용하지 않는다. 운영 중인 이전 릴리스에 요구가 남아 있다면 적용 범위를 버전·릴리스별로 표현한다.

상태 정보를 회의와 대시보드에 사용할 때 개수만 세지 않는다. “승인 80건, 완료 60건”은 중요한 위험을 숨길 수 있다. 다음 질문이 더 유용하다.

• 분석·보류 상태에 합의한 기간보다 오래 머문 고위험 요구는 무엇인가?
• 출처·결정권자·검증 방법 없이 승인된 항목은 없는가?
• 구현됐지만 승인 버전과 다르거나 충족 증거가 없는 요구는 무엇인가?
• 시험은 통과했지만 사용자 확인·운영 인계가 끝나지 않은 항목은 무엇인가?
• 변경 분석 중인데 이전 기준선과 새 제안이 섞여 사용되는 곳은 없는가?
• 폐기 요구를 참조하는 활성 설계·API·시험·매뉴얼은 무엇인가?
• 조건부 승인·위험 수용의 만료가 지났는데 닫히지 않은 항목은 무엇인가?

상태 전이 이력은 감사와 사후 학습의 증거다. 단순히 누가 버튼을 눌렀는지보다 당시 사용한 요구 버전, 입력 자료, 검토·결정 기록, 조건과 영향을 복원할 수 있어야 한다. 변경 요청의 예상 영향과 실제 재작업·결함을 비교하면 다음 추정과 추적 규칙을 개선할 수 있다.

전이 권한표는 책임 충돌을 막는다.

같은 사람이 여러 역할을 맡을 수 있지만 역할과 권한은 기록한다. 작성자가 자기 요구를 혼자 승인하거나 구현자가 시험 통과만으로 업무 수용을 선언하지 않게 한다. 작은 프로젝트라면 회의체를 늘리기보다 결정 유형과 책임자를 간단히 명시한다.

상태 모델은 실제 사례로 정기 시험한다. 다음과 같은 사건 카드를 넣고 어느 전이가 가능한지, 누가 무엇을 확인해야 하는지 따라간다.

• 승인 요구에서 개인정보 위험이 새로 발견됐지만 출시 일정은 그대로인 경우
• 구현은 끝났으나 시험이 승인된 요구 버전이 아닌 이전 버전을 사용한 경우
• 외부 정책 문서가 개정됐지만 발효일과 적용 학기가 다른 경우
• 보류 요구의 자료는 들어왔으나 결정권자가 지정되지 않은 경우
• 폐기 요구를 운영 중인 이전 릴리스와 사용자 매뉴얼이 계속 참조하는 경우
• 긴급 우회 변경이 만료됐지만 새 기준선에 반영되지 않은 경우

이 질문에 답하려고 새 상태를 계속 늘리기보다 상태 속성, 병렬 작업·검증 상태, 조건과 관계로 표현할 수 있는지 먼저 본다. 상태가 지나치게 많으면 사람마다 다른 경로를 쓰고 보고가 부정확해진다. 반대로 제안·승인·완료 세 단계뿐이면 보류·변경·검증의 차이를 숨긴다. 실제 결정과 통제에 필요한 최소 상태를 유지한다.

상태 데이터의 품질도 요구사항처럼 검사한다. 현재 상태와 마지막 전이 이력이 일치하는지, 전이 전 조건과 권한이 있었는지, 동일 요구 버전이 양립할 수 없는 두 상태에 놓이지 않았는지, 자동화가 사람 결정을 건너뛰지 않았는지 확인한다. 기준선에는 상태 이름뿐 아니라 포함 버전과 승인 기록을 고정하고, 최신 관리대장에서는 이후 변경 분석·폐기 같은 후속 상태를 별도로 보여 준다.

3. 생명주기 운영 기준

이 장에서 정리한 결과는 상태 전이도, 상태 정의표, 전이 권한표, 상태 이력이다. 네 산출물은 같은 상태명과 조건을 사용해야 한다. 전이도에 있는 경로가 정의표에 없거나, 정의표의 승인 조건과 권한표의 결정자가 다르면 관리 체계 자체가 결함이다.

9부를 마치면 FR-001FR-001 · 기능 요구학생·분반·학사 규칙과 강좌 상태를 평가해 승인 또는 근거 있는 거절 결과를 기록하고 제공한다는 기능 요구다. 같은 안정된 ID와 속성, 목표에서 설계·시험 항목까지의 양방향 추적, CR-003CR-003 · 변경 요청졸업예정자의 필수 강좌 신청에 우선권을 적용하자는 제안으로, 정책·문제 자료와 공정성 기준이 부족해 보류된 변경 요청이다. 영향 분석과 변경 결정 구조, 기준선·상태 이력이 남는다. 10부는 이 정보를 입력으로 받아 REQ → Feature → Flow → Screen → API → Data → TC 연결을 구체화한다. 아직 정책·가정이 확인되지 않은 항목은 승인된 설계 입력으로 넘기지 않고, 미결 상태와 책임·결정 조건을 함께 전달한다.

수강신청 사례에 적용

판단 기준과 흔한 오류

직접 해보는 실습

핵심 요약

관련 도구와 다음 경로