타스크: 이해 당사자(stakeholder) 요청 도출
이 타스크는 이해 당사자(stakeholder)로부터 시스템에서 제공했으면 하는 내용에 대한 요청을 도출하는 방법을 설명합니다.
원칙: 요구사항
목적

이 타스크의 목적은 다음과 같습니다.

  • 프로젝트의 이해 당사자가 누구인지 이해합니다.
  • 시스템이 만족시켜야 하는 필요에 대한 요청을 수집합니다.
  • 이해 당사자(stakeholder) 요청의 우선순위를 결정합니다.
관계
기본 설명

프로젝트의 각 요청이 프로젝트에서 고려된 방법에 대한 정보와 함께, 이해 당사자(stakeholder) 요청은 여러 이해 당사자(고객, 사용자, 제품 챔피언)가 시스템에서 포함하기를 바라거나 예상하는 내용의 "관심 목록"을 얻기 위해 기존 소스로부터 활발하게 도출되고 수집됩니다.

단계
요구사항 소스 판별
목적 "확장 프로젝트 팀"에서 이해 당사자로서 동작할 개인을 식별합니다.
요구사항에 대한 소스를 판별하고 우선순위를 결정합니다. 

기존 시스템의 경우 이 타스크에 대한 첫 번째 입력 세트는 연기된 개선사항 요청의 세트이며, 이는 정규 변경 요청 관리 프로세스의 파트로서 제품 라이프사이클 내내 수집되었습니다. 이는 데이터를 수집하고 이해 당사자(stakeholder) 요청 세트를 더욱 정제할 유용한 시작점을 제공합니다.

이 초기 정보가 수집된 후 사용자의 이해 당사자를 대표할 수 있는 파트너, 사용자, 고객, 도메인 전문가 및 산업 분석가를 찾으십시오. 지식, 커뮤니케이션 스킬, 가용성 및 "중요성"을 고려하여 정보를 수집하기 위해 함께 작업할 개인을 판별하십시오. 이들 개인이 프로젝트의 이해 당사자("확장 프로젝트 팀")로서 동작합니다. 일반적으로 프로젝트의 지속 기간 동안 사용자와 함께 머물 수 있는 작은 그룹의 인원(2 - 5명)을 갖는 것이 더 좋습니다. 또한 확장 팀에 사람이 많을수록, 그들을 관리하고 시간을 효과적으로 사용하도록 하는 데 더 오랜 시간이 걸릴 것입니다. 이들은 프로젝트에 대해 하루 종일 작업하지 않습니다. 일반적으로 도입/인식(Inception) 및 정제(Elaboration) 단계에서 몇몇 요구사항 수집 워크샵에 참여하고 나중에 검토 세션에 참여합니다.

사용자가 수행하려는 내용을 다른 사람들은 어떻게 수행하고 있는지 배우는 방법을 찾으십시오. 소프트웨어 제품을 개발 중인 경우 이는 경쟁 정보를 수집하는 것을 의미합니다. 사내 정보 시스템의 새 버전을 개발 중인 경우 사람들이 현재 시스템을 사용 중인 방법을 보고 개선할 수 있는 사항을 찾기 위해 현장 방문을 계획해야 합니다.

중요한 소스는 시스템이 사용될 조직의 모든 기존 설명입니다. 이들은 결과 비즈니스 모델링 또는 비즈니스 리엔지니어링으로 작성되는 비즈니스 모델이거나 다른 양식의 모든 비즈니스 정의일 수 있습니다.

정보 수집
목적 대답이 필요한 질문을 공식화합니다.
정보를 수집하고 문서화합니다. 

스토리보딩

정보 수집에 사용할 수 있는 유용한 기법은 스토리보딩으로, 결과물은 스토리보드입니다. 자세한 정보는 가이드라인: 스토리보딩을 참조하십시오.

인터뷰

정보를 수집하는 가장 유용한 방법 중 하나는 핵심 이해 당사자의 선택 그룹과의 인터뷰를 수행하는 것입니다. 일부 질문 샘플 및 사용할 수 있는 기법을 가이드라인: 인터뷰에서 찾을 수 있습니다. 이해 당사자(stakeholder) 요청을 문서화하기 위해 수집할 수 있는 정보에 대한 특정 정보는 중간 산출물: 이해 당사자(stakeholder) 요청에 대해 제공되는 정보를 참조하십시오.

질문지

이는 광범위하게 사용되는 기법입니다. 여러 번의 인터뷰를 수행한 후 동일한 정보가 반복해서 나타나고 있음을 이해할 수 있습니다. 이 유형의 정보는 전형적인 대답을 갖는 질문 세트로 수집되어 선택된 후 더 큰 이해 당사자 그룹으로 보내질 수 있습니다. 이 방법으로 포함된 질문에 제공되는 대답에 대한 정규 통계를 더 잘 수집할 수 있습니다. 그러나 핵심은 이러한 통계로 이해 당사자가 실제로 필요로 하는 내용의 현실적인 결과를 제공하는 방식으로 질문을 공식화할 수 있는 것입니다.

이해 당사자는 인터넷을 통해 대답하고 그 결과를 다시 사용자에게 보낼 수 있습니다. 이를 통해 직접 인터뷰를 수행하는 것보다 훨씬 광범위한 범위의 사람들에게 접근할 수 있지만 결과를 제어하기 어렵습니다. 질문에 대답하는 사람과 직접 커뮤니케이션하여 하는 모든 문제나 오해를 명확히 할 수 없습니다. 질문지는 매우 강력한 도구일 수 있지만 직접 인터뷰를 대신할 수는 없습니다. 또한 관련 질문이 미리 결정되고 의도된 방식으로 읽히도록 질문을 표현할 수 있다고 가정됩니다.

요구사항 워크샵 수행
목적: 프로젝트 팀과 프로젝트의 이해 당사자의 회의
프로젝트 이해 당사자로부터 포괄적인 "관심 목록" 수집
워크샵에 참여한 이해 당사자에 따라 수집한 요구사항의 우선순위 결정 
가이드라인:

결과 평가
목적 서로 다른 요구사항 워크샵의 결과를 비교합니다.
올바른 정보를 수집하도록 합니다. 

특히 둘 이상의 요구사항 워크샵을 수행한 경우 프로젝트 팀이 결과를 차분히 둘러보고 다음을 수행하는 것이 좋은 습관입니다.

  • 각 요청에 우선순위를 제공하십시오.
  • 요청의 소스인 사항 또는 사용자에 대한 정보를 제공하십시오.
  • 요청 사이의 명백한 불일치를 기록하고 가능하면 분류하십시오.

요구사항 워크샵의 결과를 검토 또는 후속 세션에서 선택된 고객 또는 사용자 그룹에게 제시해야 합니다. 이 세션에서 명백하게 설명해야 하는 문제가 있는지를 식별하며, 이를 통해 완료해야 하는 타스크를 식별하고 해당 타스크에 인원을 배정하게 됨을 의미합니다.

자세한 정보