목적
  • 해결해야 할 문제점에 대한 동의 확보
  • 시스템에 대한 스테이크홀더 식별
  • 시스템의 경계 정의
  • 시스템의 기본 기능 기술
역할:  시스템 분석가 
빈도: 필요에 따라, 일반적으로 개념화 및 구현화 단계에서 반복당 한 번 발생할 수 있으며 후속 단계에서 필요에 따라 되돌아올 수 있습니다.
단계
입력물:    결과물:   
툴 멘토르:   

워크플로우 세부사항:   


해결할 문제점에 대한 동의 확보 페이지 맨 위

문제점 정의에 대한 동의를 확보하기 위한 가장 간단한 방법 중 하나는 이를 기록하여 모든 사람이 동의하는지 확인하는 것입니다.

그룹에게 문제점이 무엇인지 물어보십시오.

  • 먼저 문제점을 이해하는 데 시간을 할애하기 전에 황급히 솔루션을 정의하려고 하는 것이 일반적입니다. 먼저 문제점을 기록한 다음 모든 사람이 정의에 동의하는지 확인하십시오.

그런 다음 그룹에게 정말로 문제점이 무엇인지 다시 물어보십시오.

  • 근원 또는 "문제점 뒤에 숨어 있는 문제점"을 파악하십시오. 실제 문제점은 문제점으로 인식된 문제점 뒤에 숨어 있는 경우가 많습니다.

문제점에 대한 첫 번째 설명을 승인하지 마십시오. 무엇이 "실제" 문제점인지 파악하기 위해 계속해서 "왜"라고 질문하십시오.

종종 그룹은 접근하여 실제 근본 문제점이 무엇인지를 공식화하기 어려운 상상적인 솔루션에 너무 초점을 두고 있을 수 있습니다. 이런 경우, 솔루션의 장점을 조사하여 이 장점으로 해결할 수 있는 문제점을 찾아내려고 하는 것이 유리할 수 있습니다. 이 문제점이 조직에서의 "실제" 문제점인지 아닌지를 조사할 수 있습니다. 문제점 뒤에 숨어 있는 문제점을 찾는 데 사용되는 공통 기법은 ../workguid/wg_brnst.htm -- This hyperlink in not present in this generated website브레인스토밍, ../workguid/wg_fish.htm -- This hyperlink in not present in this generated websitefishbone 다이어그램../workguid/wg_paret.htm -- This hyperlink in not present in this generated websitePareto 다이어그램입니다.

스테이크홀더 식별 페이지 맨 위

개발 팀의 도메인 전문 지식에 따라 스테이크홀더를 식별하는 것은 사소한 단계일 수도 있고 그렇지 않을 수도 있습니다. 종종 이는 단순히 의사결정자, 잠재적 사용자 및 기타 관심있는 당사자와 면담을 하여 식별할 수 있습니다. 다음 질문이 도움이 됩니다.

  • 시스템 사용자는 누구입니까?
  • 시스템의 경제적 구매자는 누구입니까?
  • 그 밖에 누가 시스템이 생성하는 결과물의 영향을 받습니까?
  • 시스템이 배달되어 전개되었을 때 누가 시스템을 평가하고 환영합니까?
  • 요구를 해결해야 하는 다른 시스템 내부 또는 외부 사용자가 있습니까?
  • 새 시스템을 누가 유지보수합니까?
  • 그 밖에 다른 사람은 없습니까?
  • 좋습니다. 그 밖에 다른 사람은 없습니까?

시스템의 잠재적(또는 실제) 사용자의 프로파일 개발을 시작하십시오. 이는 개발 중인 시스템의 액터(사람)의 역할에 맵핑됩니다. 핵심 사용자 및 해당 환경에 대한 초기 정보는 비전 문서에 문서화됩니다.

시스템 경계 정의 페이지 맨 위

시스템 경계는 솔루션 및 솔루션을 둘러싼 실제 사회 간에 경계를 정의합니다. 즉, 시스템 경계는 솔루션 시스템이 들어 있는 봉투에 대해 설명합니다. 입력 및 출력 양식으로 되어 있는 정보가 시스템과 시스템 외부에 존재하는 사용자 사이에 전달됩니다. 시스템과의 모든 대화는 시스템과 외부 사회 사이의 인터페이스를 통해 발생합니다.

대부분의 경우 시스템의 경계는 명확합니다. 예를 들어, Microsoft Windows®에서 실행되는 shrink-wrap 개인별 담당자인 단일 사용자 경계는 비교적 잘 정의되어 있습니다. 여기에는 하나의 사용자와 하나의 플랫폼만 있습니다. 사용자와 어플리케이션 사이의 인터페이스는 사용자가 시스템에 정보를 입력하기 위해 액세스하는 사용자 인터페이스 대화 상자와 시스템이 결과 정보를 문서화하거나 전송하기 위해 사용하는 출력 보고서 및 통신 경로로 구성되어 있습니다.

일반적으로 시스템의 경계를 정의하고 기술하기 위해서는 액터를 사용하는 것이 효율적입니다. 활동: 액터 및 유스 케이스 찾기를 참조하십시오.

시스템에 적용되는 제한조건 식별 페이지 맨 위

고려해야 할 제한조건 소스가 많이 있습니다. 이 정보의 대부분은 추가 스펙 결과물에 문서화되어 있을 수 있습니다. 다음은 잠재적 소스 및 질문 내용 목록입니다.

  • 정치적: 정치적 솔루션에 영향을 미치는 내부 또는 외부 정치적 이슈가 있습니까? 부처 간의 이슈입니까?
  • 경제적: 어떤 재정적 또는 예산상의 제한조건이 적용됩니까? 제한조건이 판매된 상품의 가격 또는 제품 가격 책정 고려사항입니까? 라이센스 부여 문제점이 있습니까?
  • 환경적: 환경적 또는 관리상의 제한조건이 있습니까? 법적인 제한조건입니까? 지켜야 할 다른 표준이 있습니까?
  • 기술적: 기술 선택시 제한조건이 있습니까? 기존의 플랫폼 또는 기술 내에서만 작업을 해야 합니까? 새 기술을 채택할 수는 없습니까?
  • 유연성: 스케줄이 정해져 있습니까? 기존의 자원을 사용해야 합니까? 외부 인력을 사용할 수 있습니까? 자원을 확장할 수 있습니까? 확장할 수 있다면 일시적입니까? 아니면 영구적입니까?
  • 시스템: 기존의 시스템에 솔루션을 빌드해야 합니까? 기존 솔루션과의 호환성을 유지해야 합니까? 어떤 운영 체제 및 환경이 지원되어야 합니까?

위에서 수집한 정보가 추가 스펙에 정의된 설계 제한조건에 대한 초기 입력이 됩니다.

문제점 설명 공식화 페이지 맨 위

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

<문제점 기술>의 문제점은
<문제점의 영향을 받는 스테이크홀더>에게 영향을 미칩니다.
문제점의 영향은 <문제점이 미치는 영향>입니다.
성공적인 솔루션은 <성공적인 솔루션의 핵심 장점 나열>입니다.

이 템플리트의 목적은 문제점/질문으로부터 솔루션/답변을 구별할 수 있도록 도와주는 것입니다.

예:

문제점: 고객 서비스가 부적절한 시기에 이루어지고 해결 방안이 부적절함
영향을 받는 대상: 고객, 고객 지원 대표 및 서비스 기술 요원.
미치는 영향: 고객 불만족, 품질 저하 인식, 직원 사기 저하 및 수익 감소
성공적인 솔루션:
지원 대표가 문제점 해결 데이터베이스에 실시간 액세스를 제공하고, 적시에 지원이 필요한 장소에 서비스 기술 요원의 디스패치를 용이하게 합니다.

시스템 기능 정의 페이지 맨 위

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

결과 평가 페이지 맨 위

작업이 올바른 방향으로 진행되고 있는지 확인하려면이 단계에서 비전을 확인해야 합니다. 하지만 자세히 검토하지는 마십시오. 활동: 요구사항 검토의 비전 문서에 대한 체크포인트를 고려하십시오.



Rational Unified Process   2003.06.15