왜 PI 문서는 구현 단계에서 다시 흔들릴까
PI 프로젝트가 끝나면 프로세스 맵, 역할 정의, 개선 과제, To-Be 시나리오가 정리됩니다. 그런데 실제 시스템 구축 단계에 들어가면 다시 질문이 생깁니다.
- 누가 어떤 조건에서 요청하는가
- 예외는 어디서 처리하는가
- 상태는 몇 단계로 바뀌는가
- 무엇을 기록으로 남겨야 하는가
즉, PI 산출물이 운영 방향은 보여주지만 시스템 구현 단위로 충분히 분해되지 않는 경우가 많습니다.
요구사항을 시스템화 관점으로 다시 써야 한다
PI 이후 시스템 구현으로 자연스럽게 이어지려면 요구사항은 최소한 아래 기준으로 정리돼야 합니다.
1. 역할
업무 주체를 사람 이름이 아니라 역할 기준으로 정리합니다.
2. 상태
업무가 어떤 단계로 바뀌는지 상태 전이를 정의합니다.
3. 권한
누가 조회, 수정, 승인, 예외 처리를 할 수 있는지 구분합니다.
4. 입력 데이터
어떤 데이터를 받아야 흐름이 시작되는지 명확히 합니다.
5. 증거
승인 근거, 첨부 문서, 로그, 코멘트 중 무엇을 남겨야 하는지 정의합니다.
실무에서 자주 빠지는 항목
아래 항목은 문서에는 있어도 구현 단계에서 종종 빠집니다.
- 반려 후 재제출 흐름
- 대결·대리 승인 조건
- 예외 처리 승인 기준
- 외부 사용자 접근 범위
- 알림과 마감 관리
이런 항목은 구현 말기에 추가되면서 일정과 품질을 동시에 흔듭니다.
좋은 요구사항 문서의 특징
좋은 요구사항 문서는 예쁜 표현보다 아래 질문에 답합니다.
- 누가 시작하는가
- 어디서 멈출 수 있는가
- 누가 책임지는가
- 무엇이 기록으로 남아야 하는가
- 어떤 상황이 예외인가
이 정도까지 정리돼야 PI 결과가 실제 플랫폼 구현으로 이어집니다.
결론
PI 이후 시스템화가 자주 끊기는 이유는 방향이 틀려서가 아니라, 구현 단위의 요구사항 구조가 부족해서입니다. 역할, 상태, 권한, 입력 데이터, 증거 기준으로 다시 정리하면 구축 단계의 재해석 비용을 크게 줄일 수 있습니다.