요구 식별자·상태·변경 이력 관리

핵심 요약

요구를 이름이나 문서 위치만으로 관리하면 유사 요구를 구분하기 어렵고 변경 전후를 추적할 수 없다. 고유 식별자, 출처, 소유자, 상태, 버전, 우선순위, 기준선 포함 여부와 변경 이력을 구조적으로 관리해야 한다. 상태는 처리 단계, 버전은 내용의 식별 가능한 판, 변경 이력은 무엇이 왜 누구의 승인으로 바뀌었는지를 나타낸다.

학습 목표

• 요구 식별자와 필수 관리 속성의 목적을 설명한다.
• 상태·버전·기준선·변경 이력을 서로 구분한다.
• 허용 상태 전이와 승인 조건을 사례에 적용한다.
• 변경 기록만 남기는 것과 영향 분석·변경 관리를 수행하는 것의 차이를 판정한다.

1. 관리 대상과 속성

1.1 고유 식별자

요구의 제목이나 문장이 바뀌어도 동일 요구의 생명주기를 연결하는 식별 값이다. 식별자는 중복되지 않고 안정적이어야 하며, 조직·유형·연도 등을 코드에 포함하더라도 의미가 바뀔 때마다 식별자를 재사용하지 않는다.

1.2 핵심 속성

• 기본: 식별자, 제목, 설명, 유형
• 책임·근거: 요청자, 소유자, 출처, 관련 업무, 등록일
• 판단: 중요도, 우선순위, 제약, 수용 기준
• 통제: 상태, 버전, 기준선, 승인자, 승인일
• 이력: 변경 전후, 변경 사유, 요청자, 영향 요약, 결정, 적용 버전

필드는 조직에 따라 다를 수 있으나 ‘누가 왜 무엇을 요청했고 현재 어떤 판단 상태인지’를 재구성할 수 있어야 한다.

1.3 상태와 상태 전이

상태는 요구의 처리 위치를 나타낸다. 예: 등록→분석 중→검토 중→승인→구현 중→검증 완료→종료 또는 반려·보류·폐기. 조직은 허용 전이, 전이 권한, 필수 조건을 정한다. 승인 요구를 작성자가 바로 폐기하거나, 반려 이유 없이 승인으로 전환하는 흐름은 통제되지 않은 상태 전이이다.

1.4 버전과 기준선

버전은 요구 내용의 식별 가능한 판을 구분한다. 기준선은 특정 범위의 요구 집합을 검토·승인하여 이후 비교와 변경 통제의 기준으로 설정한 상태이다. 모든 버전이 기준선은 아니며 작업 버전과 승인 기준선이 동시에 존재할 수 있다.

1.5 변경 이력

변경 일시만 기록하는 것으로 충분하지 않다. 전후 내용, 사유, 요청자, 영향 대상, 검토 결과, 승인자, 적용 버전과 관련 결정 근거를 남겨야 감사와 재검토가 가능하다.

2. 상태·버전·이력 비교

‘승인’은 상태가 될 수 있고, ‘2.1’은 버전이며, ‘BL-3에 포함’은 기준선 관계이다. 한 요구가 버전 2.1, 승인 상태, 기준선 BL-3 포함이라는 세 정보를 동시에 가질 수 있다.

3. 변경 기록 흐름

변경 요청 등록
  - 대상 요구 ID, 변경 사유, 제안 내용
        ↓
형식·중복 확인 및 담당자 지정
        ↓
영향 요약과 검토 의견 기록
        ↓
승인/반려/보류 결정
        ↓
새 버전 작성·검증
        ↓
기준선 반영 여부와 적용 시점 기록
        ↓
관련자 통보·이력 보존

이 단원은 기록 구조와 상태 통제를 다룬다. 요구-모델-테스트의 양방향 연결과 누락·과잉 검증은 82600017에서, 변경 영향 분석과 변경관리 전체 절차의 독립 학습 필요성은 신규 단원 후보에서 다룬다.

4. 관리 사례

상황: 요구 IR-015의 보존 기간이 1년에서 5년으로 바뀌었다. 담당자는 기존 문장을 덮어쓰고 상태를 그대로 ‘승인’으로 유지했다.

문제

• 이전 기준과 변경 사유를 확인할 수 없다.
• 5년 보존이 모델, 저장 용량, 개인정보 정책, 시험에 미치는 영향이 기록되지 않았다.
• 승인된 기준선과 작업 중 변경안을 구분할 수 없다.

권장 처리: 변경 요청을 기존 ID와 연결해 등록하고, 새 버전을 작성해 영향과 승인 근거를 기록한다. 승인 전에는 작업 상태로 유지하고, 승인 후 적용 기준선과 시점을 명시한다. 기존 버전은 폐기하지 않고 이력으로 보존한다.

5. 비교와 구분

시험 판단 포인트

• 식별자는 요구의 내용·제목 변경에도 생명주기를 연결하며 재사용하지 않는다.
• 상태는 처리 단계, 버전은 내용 판, 기준선은 승인된 비교 기준, 변경 이력은 전후와 근거이다.
• 상태 전이는 허용 경로·권한·필수 조건을 가져야 한다.
• 승인 기준선을 직접 덮어쓰지 않고 작업 버전과 승인 버전을 구분한다.
• 변경 이력을 남겼다고 영향 분석과 양방향 추적성 검증까지 완료된 것은 아니다.

자주 틀리는 부분

• 우선순위를 상태로 표현하거나 버전 번호로 승인 여부를 추측하지 않는다.
• 폐기된 요구의 식별자를 새 요구에 재사용하지 않는다.
• 변경 일시만 저장하면 충분한 변경 이력이라고 판단하지 않는다.
• 추적성 상세를 이 단원에 과도하게 포함해 82600017과 중복하지 않는다.