타스크: 비전 개발
이 타스크는 해결할 문제점, 핵심 이해 당사자(stakeholder), 시스템 의 범위/경계, 시스템의 핵심 기능 및 모든 제한조건을 포함하여 시스템에 대한 전체적인 비전을 개발하는 방법을 설명합니다.
목적

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

  • 해결해야 하는 문제점에 대한 합의를 얻습니다.
  • 시스템의 이해 당사자(stakeholder)를 식별합니다.
  • 시스템의 경계를 정의합니다.
  • 시스템의 기본 기능을 설명합니다.
관계
역할기본: 추가: 지원:
입력필수: 선택사항: 외부:
  • 없음
출력
기본 설명

비전을 개발할 때 다음을 염두에 두십시오.

  • 시스템의 잠재적(또는 실제) 사용자가 개발될 시스템의 인적 액터의 역할에 맵핑됩니다.
  • 대개 액터를 사용하여 시스템의 경계를 정의하고 설명하는 것이 매우 효과적입니다. 타스크: 액터 및 유스 케이스 찾기를 참조하십시오.
  • 이 타스크에서 수집되는 제한조건이 보충 스펙에 정의되는 디자인 제한조건에 대한 초기 입력입니다. 자세한 정보는 타스크: 보충 스펙 개발을 참조하십시오.

단계
해결할 문제점에 대한 합의

문제점의 정의에 대한 합의를 얻는 가장 단순한 방법 중 하나는 해당 정의를 쓰고 모든 사람이 동의하는지 확인하는 것입니다.

그룹에게 질문하십시오. "문제점이 무엇입니까?"

  • 거의 대부분 먼저 문제점을 이해하는 시간을 갖기 보다는 솔루션을 정의하는 데 성급하게 달려듭니다. 문제점을 기록하고 모든 사람에게서 정의에 대한 합의를 얻을 수 있는지 확인하십시오.

그런 다음 그룹에게 다시 질문하십시오. "정말로 문제점이 무엇입니까?"

  • 근본 원인 또는 "문제점 뒤의 문제점"을 찾으십시오. 실제 문제점은 종종 문제점처럼 보이는 내용 뒤에 숨어 있습니다.

문제점에 대한 첫 번째 설명을 채택하지 마십시오. 계속 "왜?"라고 물으십시오. 문제점의 본질을 탐색하십시오.

때로는 그룹이 계획된 솔루션에 너무 집중하여 근본적인 문제점이 실제로는 무엇인지 공식화하기가 어려울 수 있습니다. 이런 경우 솔루션의 이점을 탐색한 후 해당 이점으로 해결되는 문제점을 찾아보는 것이 도움이 될 수 있습니다. 그런 다음 해당 문제점이 조직에서의 "실제" 문제점인지 여부를 탐색할 수 있습니다. 문제점 뒤의 문제점을 찾는 데 사용되는 공통 기법은 브레인스토밍, 물고기 뼈 다이어그램파레토 다이어그램입니다.

이해 당사자(stakeholder) 식별

개발 팀의 도메인 전문 지식에 따라서 이해 당사자(stakeholder)의 식별 단계는 쉬울 수도 있고 쉽지 않을 수도 있습니다. 이는 종종 단순히 의사 결정자, 잠재적 사용자 및 기타 이해 관련자의 인터뷰를 포함합니다. 다음 질문이 도움이 됩니다.

  • 시스템의 사용자는 누구입니까?
  • 시스템에 대한 경제적 구매자는 누구입니까?
  • 시스템이 생성하는 산출물에 의해 영향을 받는 사람은 누구입니까?
  • 시스템이 전달되고 배치될 때 누가 시스템을 평가하고 보호합니까?
  • 시스템의 다른 내부 또는 외부 사용자 중 요구를 고려해야 할 대상이 있습니까?
  • 누가 새 시스템을 유지보수합니까?
  • 다른 사람이 있습니까?
  • 좋습니다. 다른 사람이 있습니까?

시스템의 잠재적(또는 실제) 사용자의 프로파일을 개발하기 시작하십시오. 핵심 사용자 및 해당 환경에 대한 초기 정보가 비전 문서에 문서화되어야 합니다.

시스템 경계 정의

시스템 경계는 솔루션과 해당 솔루션을 둘러싸는 현실 세계 사이의 경계를 정의합니다. 달리 말하면 시스템 경계는 솔루션 시스템이 포함되는 겉모양을 설명합니다. 정보는 입력 및 출력 양식으로 시스템에서 시스템 외부에 사는 사용자에게 이리저리 전달됩니다. 시스템과의 모든 상호작용은 시스템과 외부 세계 사이의 인터페이스를 통해 발생합니다.

많은 경우에 시스템의 경계가 명백합니다. 예를 들어 단일 사용자인 Microsoft Windows®에서 실행하는 수축 포장 개인 문의 관리자의 경계는 상대적으로 잘 정의됩니다. 단 한 명의 사용자와 하나의 플랫폼이 있습니다. 사용자와 응용프로그램 사이의 인터페이스는 사용자가 시스템에 정보를 입력하기 위해 액세스하는 사용자 인터페이스 대화 상자와 시스템이 결과 정보를 문서화 또는 전송하는 데 사용하는 기타 산출물 보고서 및 통신 경로로 구성됩니다.

시스템에 부과될 제한조건 식별

고려해야 하는 다양한 제한조건 소스가 있습니다. 다음은 잠재적 소스와 질문할 의문점의 목록입니다.

  • 정치적: 잠재적 솔루션에 영향을 주는 내부 또는 외부 정치적 문제가 있습니까? 부서 사이에 존재합니까?
  • 경제적: 어떤 재무 또는 예산 제한조건을 적용할 수 있습니까? 판매한 상품의 비용 또는 제품 가격 결정 고려사항이 있습니까? 라이센스 부여 문제가 있습니까?
  • 환경적: 환경적 또는 규제 제한조건이 있습니까? 합법적입니까? 제한하는 다른 표준이 있습니까?
  • 기술적: 기술의 선택에 있어서 제한됩니까? 기존 플랫폼이나 기술 내에서 작업하도록 제한됩니까? 임의의 신기술에 대해 금지됩니까?
  • 실현 가능성: 스케줄이 정의됩니까? 기존 자원으로 제한됩니까? 외부 노동력을 사용할 수 있습니까? 자원을 확장할 수 있습니까? 임시입니까? 영구적입니까?
  • 시스템: 솔루션이 기존 시스템에 빌드됩니까? 기존 솔루션과의 호환성을 유지해야 합니까? 어떤 운영 체제 및 환경을 지원해야 합니까?
문제점 설명 공식화

전체 그룹과 함께 이젤 차트에서 작업하여 식별한 각 문제점에 대한 다음 템플리트를 채우십시오.

<문제점 설명>의 문제점이
<문제점의 영향을 받는 이해 당사자(stakeholder)>에게 영향을 줍니다.
이 영향은 <문제점 영향의 개념>입니다.
성공적인 솔루션은 <성공적인 솔루션의 몇 가지 핵심 이점을 나열>합니다.

이 템플리트의 목적은 문제점/질문과 솔루션/대답을 구별하는 데 도움을 주는 것입니다.

예제:

문제점: 고객 서비스 문제의 시기를 놓치고 부적합한 분석
적용: 고객, 고객 지원 대표 및 서비스 기술자.
영향: 고객 불만족, 품질 부족 인식, 직원 불만족 및 수입 손실.
성공적 솔루션:
지원 대표에게 문제점 해결 데이터베이스에 대한 실시간 액세스를 제공하고 지원이 꼭 필요한 위치에만 시기 적절한 방식으로 서비스 기술자를 파견할 수 있게 합니다.

시스템 기능 정의

문제점 설명에 나열된 이점을 기반으로 하여 시스템에서 원하는 기능의 목록을 개발하십시오. 해당 기능을 간략하게 설명하고, 프로젝트에서 일반 상태 및 우선순위를 정의하는 데 도움이 되는 속성을 부여하십시오.

결과 평가

이 단계에서 비전을 확인하여 작업이 제대로 진행 중인지 확인하되, 자세히 검토하지는 마십시오. 비전 문서에 대한 체크리스트(체크리스트: 비전)을 고려하십시오.



특성
다중 발생
이벤트로 구동됨
진행 중임
선택사항
계획됨
반복 가능함
자세한 정보