목적
|
"확장 프로젝트 팀"에서 이해 당사자로서 동작할 개인을 식별합니다.
요구사항에 대한 소스를 판별하고 우선순위를 결정합니다.
|
기존 시스템의 경우 이 타스크에 대한 첫 번째 입력 세트는 연기된 개선사항
요청의 세트이며, 이는 정규 변경 요청
관리 프로세스의 파트로서 제품 라이프사이클 내내 수집되었습니다. 이는 데이터를 수집하고 이해
당사자(stakeholder) 요청 세트를 더욱 정제할 유용한 시작점을 제공합니다.
이 초기 정보가 수집된 후 사용자의 이해 당사자를 대표할 수 있는 파트너, 사용자, 고객, 도메인 전문가 및 산업 분석가를 찾으십시오. 지식, 커뮤니케이션
스킬, 가용성 및 "중요성"을 고려하여 정보를 수집하기 위해 함께 작업할 개인을 판별하십시오. 이들 개인이 프로젝트의 이해 당사자("확장 프로젝트 팀")로서 동작합니다. 일반적으로 프로젝트의 지속 기간 동안
사용자와 함께 머물 수 있는 작은 그룹의 인원(2 - 5명)을 갖는 것이 더 좋습니다. 또한 확장 팀에 사람이 많을수록, 그들을 관리하고 시간을 효과적으로 사용하도록 하는 데 더 오랜 시간이 걸릴 것입니다. 이들은
프로젝트에 대해 하루 종일 작업하지 않습니다. 일반적으로 도입/인식(Inception) 및 정제(Elaboration) 단계에서 몇몇 요구사항 수집 워크샵에 참여하고 나중에 검토 세션에 참여합니다.
사용자가 수행하려는 내용을 다른 사람들은 어떻게 수행하고 있는지 배우는 방법을 찾으십시오. 소프트웨어 제품을 개발 중인 경우 이는 경쟁 정보를 수집하는 것을 의미합니다. 사내 정보 시스템의 새 버전을 개발 중인
경우 사람들이 현재 시스템을 사용 중인 방법을 보고 개선할 수 있는 사항을 찾기 위해 현장 방문을 계획해야 합니다.
중요한 소스는 시스템이 사용될 조직의 모든 기존 설명입니다. 이들은 결과 비즈니스 모델링 또는 비즈니스 리엔지니어링으로 작성되는 비즈니스 모델이거나 다른 양식의 모든 비즈니스 정의일 수 있습니다.
|