활동: 이해 당사자의 요구 이해
이 활동은 이해 당사자가 제안된 솔루션으로부터 원하는 사항을 파악하려 노력하고 솔루션의 핵심 기능을 정의합니다.
확장: 이해 당사자의 요구 이해
설명작업분류 체계(WBS)팀 할당중간 산출물 사용법
목적
이 활동의 목적은 원하는 제품에 대한 정보를 수집하여 주요 프로젝트 이해 당사자의 요구를 이해하는 것입니다.
관계
상위 활동
설명

이 활동은 이해 당사자의 요구를 정확히 파악하기 위해 프로젝트의 이해 당사자로부터 정보를 수집 및 도출하는 것을 다룹니다(이해 당사자(stakeholder) 요청 도출 참조). 수집한 이해 당사자(stakeholder) 요청은 시스템의 상위 레벨 기능 정의에 대한 기본 입력으로 사용할 "관심 목록"으로 간주할 수 있습니다. 이에 대한 설명은 비전(비전 개발 참조)을 참조하십시오. 이해 당사자(stakeholder) 요청 도출 후 소프트웨어 요구사항의 스펙이 시작됩니다. 이에 대한 설명은 소프트웨어 요구사항 스펙(유스 케이스 모델유스 케이스보충 스펙 참조 가능)을 참조하십시오.

기본 목표는 인터뷰, 개선 요청요구사항 워크샵 등을 입력으로 사용하여 이해 당사자의 요청을 도출하는 것입니다. 기본 산출물은 우선순위가 정해진 기능과 기준 속성의 콜렉션으로, 이들은 시스템 정의 및 시스템의 범위 관리(시스템 정의, 시스템 범위 관리 참조)에 사용됩니다.

이 정보를 통해 비전을 정제하고 요구사항 속성을 더 잘 이해할 수 있습니다. 또한 이 활동을 규정하는 동안 유스 케이스액터의 관점에서 시스템의 기능적 요구사항을 논의하기 시작할 수 있습니다(액터 및 유스 케이스 찾기 참조). 유스 케이스 내에 적절하게 들어맞지 않는 요구사항은 보충 스펙(보충 스펙 개발 참조)에 기록해야 합니다. 

새 요구사항을 정의할 경우 이러한 요구사항 사이의 종속성(예: 추적성)을 문서화해야 합니다(종속성 관리 참조).

다른 중요 산출물은 팀 구성원 간에 공통 용어를 사용하여 커뮤니케이션을 용이하게 하는 갱신된 용어집입니다(공통 용어 갭처 참조).

특성
이벤트로 구동됨
다중 발생
진행 중임
선택사항
계획됨
반복 가능함
인력 구성

이해 당사자 요구를 이해하는데 참여한 프로젝트 구성원은 유능한 진행자여야 하며 정보 도출에 경험이 있어야 합니다. 물론, 대상 기술을 잘 알고 있는 것이 바람직하나 꼭 필요한 것은 아닙니다.

사용법
사용법 안내

이 활동은 주로 도입/인식(Inception) 및 정제(Elaboration) 단계(Phase) 동안 반복에서 수행되지만 범위 관리요구사항 변경 및 프로젝트 조건의 기타 변경사항에 대한 응답 시 필요에 따라 재검토할 수 있습니다.

핵심 고려사항

이 기능 패턴에서 수행되는 활동은 차례로 수행되지 않음에 유의하십시오. 사실 이러한 활동은 동시에 수행되는 경우가 많습니다. 예를 들어, 액터와 유스 케이스를 식별하는 동안(액터 및 유스 케이스 찾기) 특정 유스 케이스와 특성상 맞지 않는 요구사항을 발견할 수 있습니다. 이 경우 보충 스펙에서 해당 요구사항을 정의할 수 있습니다(보충 스펙 개발). 이와 반대로 유스 케이스에 특정되지 않는 요구사항(예: 시스템 전반의 요구사항)을 식별하는 동안 특정 유스 케이스에만 적용되는 요구사항이 발생할 수 있으며 이 경우에는 요구사항이 유스 케이스와 연관됩니다.