활동:
|
목적
|
역할: 시스템 분석가 |
빈도: 필요에 따라, 일반적으로 개념화 및 구현화 단계에서 반복당 한 번 발생할 수 있으며 후속 단계에서 필요에 따라 되돌아올 수 있습니다. |
단계 |
입력물: | 결과물: |
툴 멘토르: |
워크플로우 세부사항: |
문제점 정의에 대한 동의를 확보하기 위한 가장 간단한 방법 중 하나는 이를 기록하여 모든 사람이 동의하는지 확인하는 것입니다.
그룹에게 문제점이 무엇인지 물어보십시오.
그런 다음 그룹에게 정말로 문제점이 무엇인지 다시 물어보십시오.
문제점에 대한 첫 번째 설명을 승인하지 마십시오. 무엇이 "실제" 문제점인지 파악하기 위해 계속해서 "왜"라고 질문하십시오.
종종 그룹은 접근하여 실제 근본 문제점이 무엇인지를 공식화하기 어려운 상상적인 솔루션에 너무 초점을 두고 있을 수 있습니다.
이런 경우, 솔루션의 장점을 조사하여 이 장점으로 해결할 수 있는 문제점을 찾아내려고 하는 것이 유리할 수 있습니다.
이 문제점이 조직에서의 "실제" 문제점인지 아닌지를 조사할 수 있습니다.
문제점 뒤에 숨어 있는 문제점을 찾는 데 사용되는 공통 기법은 브레인스토밍,
fishbone 다이어그램 및
Pareto
다이어그램입니다.
개발 팀의 도메인 전문 지식에 따라 스테이크홀더를 식별하는 것은 사소한 단계일 수도 있고 그렇지 않을 수도 있습니다. 종종 이는 단순히 의사결정자, 잠재적 사용자 및 기타 관심있는 당사자와 면담을 하여 식별할 수 있습니다. 다음 질문이 도움이 됩니다.
시스템의 잠재적(또는 실제) 사용자의 프로파일 개발을 시작하십시오. 이는 개발 중인 시스템의 액터(사람)의 역할에 맵핑됩니다. 핵심 사용자 및 해당 환경에 대한 초기 정보는 비전 문서에 문서화됩니다.
시스템 경계는 솔루션 및 솔루션을 둘러싼 실제 사회 간에 경계를 정의합니다. 즉, 시스템 경계는 솔루션 시스템이 들어 있는 봉투에 대해 설명합니다. 입력 및 출력 양식으로 되어 있는 정보가 시스템과 시스템 외부에 존재하는 사용자 사이에 전달됩니다. 시스템과의 모든 대화는 시스템과 외부 사회 사이의 인터페이스를 통해 발생합니다.
대부분의 경우 시스템의 경계는 명확합니다. 예를 들어, Microsoft Windows®에서 실행되는 shrink-wrap 개인별 담당자인 단일 사용자 경계는 비교적 잘 정의되어 있습니다. 여기에는 하나의 사용자와 하나의 플랫폼만 있습니다. 사용자와 어플리케이션 사이의 인터페이스는 사용자가 시스템에 정보를 입력하기 위해 액세스하는 사용자 인터페이스 대화 상자와 시스템이 결과 정보를 문서화하거나 전송하기 위해 사용하는 출력 보고서 및 통신 경로로 구성되어 있습니다.
일반적으로 시스템의 경계를 정의하고 기술하기 위해서는 액터를 사용하는 것이 효율적입니다. 활동: 액터 및 유스 케이스 찾기를 참조하십시오.
고려해야 할 제한조건 소스가 많이 있습니다. 이 정보의 대부분은 추가 스펙 결과물에 문서화되어 있을 수 있습니다. 다음은 잠재적 소스 및 질문 내용 목록입니다.
위에서 수집한 정보가 추가 스펙에 정의된 설계 제한조건에 대한 초기 입력이 됩니다.
전체 그룹과 함께 이젤(easel) 다이어그램에 대해 작업하여 식별한 각 문제점에 대해 다음 템플리트를 채우십시오.
<문제점 기술>의 문제점은
<문제점의 영향을 받는 스테이크홀더>에게 영향을 미칩니다.
문제점의 영향은 <문제점이 미치는 영향>입니다.
성공적인 솔루션은 <성공적인 솔루션의 핵심 장점 나열>입니다.
이 템플리트의 목적은 문제점/질문으로부터 솔루션/답변을 구별할 수 있도록 도와주는 것입니다.
문제점: 고객 서비스가 부적절한 시기에 이루어지고 해결 방안이 부적절함
영향을 받는 대상: 고객, 고객 지원 대표 및 서비스 기술 요원.
미치는 영향: 고객 불만족, 품질 저하 인식, 직원 사기 저하 및 수익 감소
성공적인 솔루션: 지원 대표가 문제점 해결 데이터베이스에 실시간 액세스를 제공하고, 적시에 지원이 필요한 장소에 서비스 기술 요원의 디스패치를 용이하게 합니다.
문제점 설명에 나열된 장점을 토대로 시스템에서 원하는 기능 목록을 개발하십시오. 간략히 기술하고 프로젝트의 우선 순위 및 일반 상태를 정의하는 데 도움이 되도록 속성을 부여하십시오.
작업이 올바른 방향으로 진행되고 있는지 확인하려면이 단계에서 비전을 확인해야 합니다. 하지만 자세히 검토하지는 마십시오. 활동: 요구사항 검토의 비전 문서에 대한 체크포인트를 고려하십시오.
Rational Unified Process
|