"요구사항"은 특정 계약이나 기타 필수 사양에 따라 제품, 서비스 또는 결과가 보유해야 하는 조건이나 기능을 의미합니다.

프로젝트 팀은 세 가지 프로세스를 반복합니다.

스폰서와 고객 담당자는 두 프로세스를 반복합니다.

프로젝트 범위가 정의, 개발, 모니터링, 통제 및 검증되는 방법을 설명하는 프로젝트 또는 프로그램 관리 계획의 구성 요소입니다.

1. 프로젝트 헌장의 정보

2. 프로젝트 관리 계획에서 승인된 하위 계획

3. 조직 프로세스 자산의 이력 정보

4. 관련 비즈니스 환경 요인

조직의 품질 정책, 방법 및 표준이 프로젝트에 구현되는 방식은 프로젝트 및 제품 범위가 관리되는 방식에 영향을 미칩니다.

평가, 요구사항 수집, 프로젝트 및 제품 범위 세부화, 제품 생성, 범위 검증 및 범위 제어를 위한 다양한 방법

프로젝트 범위가 정의, 개발, 모니터링, 통제 및 검증되는 방법을 설명하는 프로젝트 관리 계획의 구성 요소입니다.

1. 프로젝트 범위 기술서 개발(범위 정의)

2. 상세한 프로젝트 범위 기술서를 기반으로 WBS 생성(WBS 생성)

3. 완료된 프로젝트 결과물의 공식 승인(범위 확인)

4. 범위 기준(통제 범위)을 승인하고 유지하는 방법 결정

요구사항을 분석, 문서화 및 관리하는 방법을 설명하는 프로젝트 관리 계획의 필수적인 부분입니다.

1. 다양한 요구 사항 활동을 계획, 추적 및 보고하는 방법

2. 변경 시작 방법, 영향 분석 방법, 추적성, 추적 및 보고 수행 방법, 변경 승인 권한과 같은 구성 관리 활동

3. 요구사항 우선순위 지정 프로세스

4. 측정할 지표와 이를 사용하는 이유

5. 추적 매트릭스에 어떤 요구사항 속성이 포함될지 반영합니다.

특정 계약이나 기타 필수 사양에 따라 제품, 서비스 또는 결과가 가져야 하는 조건 또는 기능

스폰서, 고객 및 기타 이해관계자의 요구와 기대를 정량화하고 문서화했습니다.

이러한 요구사항을 충분히 자세하게 조사, 분석 및 문서화하고 프로젝트 실행이 시작되면 측정할 범위 기준선에 이를 포함합니다.

작업분류체계(WBS)의 기초가 되며 비용, 일정, 품질 및 조달 계획의 기초가 됩니다.

세부 요구사항을 공식화하는 데 사용됩니다(단계별 개선).

요구 사항 활동에 대한 이해 관계자 참여를 평가하고 조정하기 위해 계획에서 이해 관계자 커뮤니케이션 요구 사항과 참여 수준을 이해합니다.

가상 로그

교훈 등록

이해관계자 등록

기존 문서를 분석하고 요구사항과 관련된 정보를 파악하여 요구사항을 획득합니다.

먼저 브레인스토밍한 다음 투표하고 순위를 매기세요.

숨겨진 욕구를 발견할 수 있음

주요 이해관계자를 모아 요구 사항을 정의하기 위해 주제 워크숍과 함께 사용됩니다.

실제로 제품을 제조하기 전에 의도한 제품의 프로토타입을 구축하고 요구 사항에 대한 조기 피드백을 요청하는 것을 말합니다.

미니어처, 컴퓨터로 생성된 2차원 및 3차원 모델, 모형 또는 시뮬레이션

악슈어

스토리보드

다양한 단일 요구사항이 프로젝트 관련 비즈니스 요구사항(상위 수준 요구사항)을 어떻게 충족하는지 설명

명확하고(측정 및 테스트 가능), 추적 가능하고, 완전하고, 조정되고, 주요 이해관계자에 의해 인식되는 요구사항

1. 비즈니스 요구 사항

2. 이해관계자 요구

3. 솔루션 요구 사항

4. 전환 및 준비 요구 사항

5. 프로젝트 요구사항

6. 품질 요구 사항

소스의 제품 요구사항을 요구사항을 충족하는 결과물에 연결하는 양식

각 요구 사항을 비즈니스 목표 또는 프로젝트 목표에 연결하면 각 요구 사항에 비즈니스 가치가 있는지 확인하는 데 도움이 됩니다.

프로젝트 수명 주기 전반에 걸쳐 요구 사항을 추적하는 방법을 제공하여 요구 사항 문서의 각 승인된 요구 사항이 프로젝트 종료 시 구현되고 전달되도록 돕습니다.

또한 제품 범위 변경을 관리하기 위한 프레임워크를 제공합니다.

1. 비즈니스 요구 사항, 기회, 목표 및 목적

2. 프로젝트 목적

3. 프로젝트 범위 및 WBS 결과물

4. 제품 디자인

5. 제품 개발

6. 테스트 전략 및 테스트 시나리오

7. 상위 요구사항부터 세부 요구사항까지

고유 식별자, 요구 사항에 대한 텍스트 설명, 요구 사항을 포함하는 이유, 소유자, 소스, 우선 순위, 버전, 현재 상태 및 상태 날짜

가상 로그

요구사항 문서

위험 등록부

프로젝트 헌장에 명시된 요구 사항과 목표를 달성하기 위한 다양한 접근 방식을 평가합니다.

요구 사항, 일정, 예산, 리소스 등의 기준을 설정하여 프로젝트 및 제품 범위를 구체화하는 의사 결정 매트릭스의 도움으로 시스템 분석 방법을 사용하는 기술입니다.

전달될 제품의 목적, 특성 및 기타 측면을 설명하기 위해 제품 또는 서비스에 대한 질문 및 답변을 포함하여 제품 및 서비스를 정의하는 데 사용됩니다.

높은 수준의 제품 또는 서비스 설명을 의미 있는 결과물로 변환

제품 분해, 수요 분석, 시스템 분석, 시스템 엔지니어링, 가치 분석, 가치 엔지니어링 등

프로젝트 범위, 주요 결과물, 가정 및 제약 조건에 대한 설명

프로젝트 및 제품 범위를 포함한 전체 범위를 문서화하고, 프로젝트 결과물을 자세히 설명하며, 프로젝트 범위에 대한 프로젝트 이해관계자 간의 합의를 나타냅니다.

1. 제품군 설명

2. 결과물

3. 허용 기준

일대일 대응

4. 프로젝트 제외

5. 가정

6. 제약

프로젝트 헌장

범위 설명

내용이 일부 겹치는 부분은 있지만, 디테일의 정도는 전혀 다릅니다

이는 프로젝트 팀이 프로젝트 목표를 달성하고 필요한 결과물을 생성하기 위해 수행해야 하는 모든 작업 범위를 계층적으로 분류한 것입니다.

활동 자체가 아닌 활동의 결과인 작업 산출물이나 결과물을 의미합니다.

작업분류체계의 가장 낮은 수준의 구성요소를 작업 패키지라고 하며, 여기에는 계획된 작업이 포함됩니다.

작업 패키지는 작업 진행을 조정하고 예측하고 감독하고 통제하기 위해 관련 활동을 분류합니다.

가장 작은 결과물입니다

요구사항 문서

프로젝트 범위 설명

정의

작업 패키지

분해 정도

WBS를 만드는 방법

1. 결과물 및 관련 작업 식별 및 분석(분류가 필요한 결과물 및 작업 식별)

2. 작업분류체계(WBS)의 구성 및 구성 방법 결정(분류 구조 결정)

3. 하향식 및 레이어별 분해(Top-down 단계별 분해)

4. WBS 구성요소에 대한 식별 코드 개발 및 할당(Identify WBS Components)

5. 산출물이 적절한 정도로 분해되었는지 확인(분해 정도가 적절한지 확인)

구조 유형

WBS의 상위 수준 구성 요소를 분해한다는 것은 각 결과물이나 구성 요소를 검증 가능한 제품, 서비스 또는 결과인 가장 기본적인 구성 요소로 분해하는 것을 의미합니다.

민첩한 접근 방식이나 적응형 접근 방식을 사용하는 경우 작업분류체계는 개요, 조직도 또는 계층 구조를 설명하는 기타 형식을 취할 수 있습니다.

다양한 결과물을 다양한 수준으로 분해할 수 있습니다.

장점과 단점에 대한 자세한 분석

1. WBS는 전달 지향적이어야 합니다.

2. WBS는 프로젝트 범위에 적합해야 합니다.

3. WBS의 기본 계층은 계획 및 제어를 지원해야 합니다.

4. 단 한 사람만이 WBS(독립적 책임 원칙)의 요소를 책임져야 합니다.

5. WBS는 4~6레이어에서 관리되어야 합니다.

6. WBS에는 프로젝트 관리 작업(관리는 프로젝트의 특정 작업의 일부이기 때문에)과 하도급 작업이 포함되어야 합니다.

7. WBS를 준비하려면 모든 (핵심) 프로젝트 이해관계자의 참여가 필요합니다.

8. WBS는 정적이지 않습니다.

9. 8/80 원칙

승인된 범위 기술서, WBS 및 해당 WBS 사전으로 공식적인 변경 관리 프로세스를 통해서만 변경될 수 있으며 비교의 기초로 사용됩니다.

프로젝트 범위, 주요 결과물, 가정 및 제약 조건에 대한 설명을 포함합니다.

프로젝트 팀이 프로젝트 목표를 달성하고 필요한 결과물을 생성하기 위해 수행해야 하는 전체 작업 범위를 계층적으로 분류한 것입니다.

범위, 예산, 일정을 통합하고 성과를 획득가치와 비교하여 측정하는 관리 통제점

포함하다

정의

효과

내용은 다음과 같습니다

품질 관리 프로세스는 일반적으로 범위 검증 프로세스보다 먼저 수행되지만 동시에 수행될 수도 있습니다.

산출물 전달에는 명확한 기준이 있어야 할 뿐만 아니라, 요구대로 완료되었는지, 산출물과 표준 사이에 명확한 연관성이 있는지에 대한 기준도 있어야 합니다.

스폰서는 프로젝트 범위, 프로젝트에서 완료할 제품 또는 서비스, 프로젝트 관련 결과물에 대해 공식적으로 동의해야 합니다.

프로젝트 팀은 결과물이 무엇인지 명확하게 이해해야 합니다.

위험이 발생할 경우 경영진이 프로젝트에 미치는 영향을 줄일 수 있는지 여부

프로젝트 진행, 자금 및 자원에 대한 범위의 영향을 나타냅니다. 이러한 요소가 조직의 허용 범위를 초과하는지 여부와 입력 및 출력이 합리적인지 여부를 나타냅니다.

프로젝트의 결과물이 제품이나 서비스를 완료하기에 충분한지 여부에 대한 우려

프로젝트 결과물이 충분하고 완료되어야 하는지, 시간, 자금, 자원이 충분한지, 주요 잠재적 위험과 준비된 솔루션이 충분한지 여부에 주의하세요.

범위 내 시간을 정의하여 작업 시간이 충분한지, 프로젝트 범위 내에 여러 작업이 있는지, 이러한 작업 간에 충돌이 있는지 확인하세요.

완료된 결과물이 공식적으로 승인되는 방법을 정의합니다.

프로젝트 요구 사항을 식별하는 방법을 설명합니다.

범위 기준을 실제 결과와 비교하여 변경, 시정 조치 또는 예방 조치가 필요한지 여부를 결정합니다.

요구사항 문서

요구 사항 추적 매트릭스

품질 보고서

교훈 등록

실제 합격 결과를 기록하고 요구사항 문서를 업데이트하세요.

사용된 승인 방법 및 결과를 포함하여 승인 결과를 기반으로 요구 사항 추적 매트릭스를 업데이트합니다.

프로젝트 및 제품 범위를 제어하는 ​​방법을 문서화했습니다.

프로젝트 요구 사항을 관리하는 방법을 문서화했습니다.

프로젝트 변경 관리를 위해 정의된 프로세스

어떤 구성 항목이 구성 항목인지, 어떤 구성 항목에 공식적인 변경 제어가 필요한지, 이러한 구성 항목에 대한 변경 제어 프로세스를 정의합니다.

범위 기준을 실제 결과와 비교하여 변경, 시정 조치 또는 예방 조치가 필요한지 여부를 결정합니다.

획득 가치 분석을 사용할 때 성과 측정 기준을 실제 결과와 비교하여 변경, 시정 조치 또는 예방 조치가 필요한지 여부를 결정합니다.

교훈 등록

요구사항 문서

요구 사항 추적 매트릭스

기준선을 실제 결과(작업 성과 데이터)와 비교하여 편차가 임계값 간격 내에 있는지 또는 시정 또는 예방 조치가 필요한지 여부를 결정합니다.

시간이 지남에 따라 프로젝트 성과를 검토하여 성과가 개선되거나 악화되는지 확인

수신된 변경 사항의 분류, 식별된 범위 편차 및 원인, 일정 및 비용에 대한 편차의 영향, 향후 범위 성능 예측을 포함합니다.

범위, 범위 설명, WBS 또는 WBS 사전에 대한 변경이 승인되면 범위 기준선에 대한 해당 변경이 필요합니다.

범위, 자원 또는 일정 예측에 대한 변경 승인 후 일정 기준선에 대한 해당 변경이 필요합니다.

범위, 리소스 또는 비용 추정에 대한 변경이 승인된 후 비용 기준선에 해당 변경이 적용되어야 합니다.

범위, 일정 성과 또는 비용 추정에 대한 변경 승인 후 성과 측정 기준선에 해당 변경이 필요합니다.

요구 사항 추가 또는 수정

요구사항 문서 변경