Product
범위: 특징, 기능
완료여부: 요구사항
요구사항: 기술, 보안, 성관

Project
범위: 일(Work)
완료여부: 프로젝트 관리계획서(baseline)
요구사항: 비즈니스, 프로젝트 관리 인수인계

=============================================

5.1 요구사항 수집
I: Charter, 이해관계자 등록부
T: 인터뷰, 핵심 그룹, 심층 워크샵, 집단창의력, 집단의사결정, 설문, 관찰, 프로토타입
O: 요구사항 문서, 요구사항 관리계획서, 요구사항 추적 매트릭스

관찰, 프로토타입은 요구사항이 명확하지 않을 때
프로토타입: 모형 제공 – 조기피드백 확보, 점진적 구체화

요구사항 기준선 확정 요건: 명확성, 추적가능성, 완전성, 일관성, 수용가능수준

요구사항 추적 매트릭스: 요구사항을 각각의 요인에 연결, 제품범위에 대한 변경을 관리하는데 유용

5.2 범위 정의
I: Charter, 요구사항 문서, OPA
T: Expert Jgmt, 제품분석, 대안식별, 심층워크샵
O: 프로젝트 범위기술서, 프로젝트 문서 갱신 

요구사항을 범위로 옮길때: 분할과 정복
프로젝트 범위기술서: 제약사항과 가정

5.3 WBS 생성
I: 프로젝트 범위기술서, 요구사항 문서, OPA
T: 분할
O: WBS, WBS사전, 범위기준선, 프로젝트 문서 갱신

주요한 프로젝트 인도물과 프로젝트 작업을 구성요소들로 분할한다.
분할: 식별, 검증(원가,시간), 재식별, 상향식(중복/누락) 검증

요구사항 -> 범위기술서 -> WBS (고객과) -> Activity (내부적으로) 

WBS
산출물 지향적으로 집단화
All the Work, Only the Work
고객과 의사 결정 용도
Code of Account
Work Package가 최하위 수준
Sub PJT에서는 분할 가능

WBS사전: 인수기준

범위기준선: 프로젝트 범위기술서, WBS, WBS사전
내부/외부 의사결정의 기준임

Work Package의 생성 룰
– 80시간 (2주): WP당 최대 기간
– 40시간 (1주): WP당 최소 기간
– 3~6개월: Rolling Wave Plan

3개월 단위로 만들 

각 제약요소의 단위
범위: Work Package
일정: Activity
원가: Chart of Account / Control Account (비용항목코드)

Activity < Work Package < Chart of Account
                           planning pkg가 있음

WBS종류
CWBS: contractual WBS
OBS: organizational – 수행 조직도
RBS: resource – 인적자원관리
BOM: bill of materials – 제조업

RAM: OBS + WBS 책임할당 매트릭스

5.4 범위 검증
I: 프로젝트 관리계획서, 요구사항 문서, 확인된 인도물
T: 검사
O: 인수된 인도물, 변경 요청, 프로젝트 문서 갱신

인도물의 인수를 공식화 (서명)
(1) 이해 관계자들로부터 프로젝트 범위를 공식적으로 인정받는 프로세스이다.
(2) 모든것이 이상없이 만족스럽게 완성되었는가를 확실히 하기 위해 
인도물, 작업결과물을 검토하는 것이 필요하다.

범위검증
주체: 고객 / 목적: 인도물의 인수여부 / 결과: 인수된 인도물 
품질검증
주체: QA / 목적: 결함제거(품질기준 준수여부) / 결과: 확인된 인도물
-> 공통점: 실제 output을 보고, product oriented

 
5.5 범위 통제
일정/원가/품질 통제와 통합되어 수행한다.

I: 프로젝트 관리 계획서, 작업 성과 정보, 요구사항 문서, 요구사항 추적 매트릭스, OPA
T: 차이 분석
O: 작업 성과 측정치, OPA갱신, 변경 요청, 프로젝트 관리계획서 갱신, 프로젝트 문서 갱신

변경통제 시스템: 문서작업, 추적 시스템, 승인 단계를 포함하는 범위 변경에 사용되는 일련의 절차