요구 사항 작업을 원활하게 진행할 수 있도록 명확한 프로젝트 목표와 범위 정의.
4.1.2.1 혼란스러운 프로젝트 목표 < P > 는 "기업의 정보화 응용 수준을 전면적으로 높이다" 와 같이 프로젝트 목표에 대해 자주 하는 공허한 목표를 해결하기 어렵다. < P > 혼돈이 불분명한 목표는 내부 뿌리나 외부 소원을 통해 해독할 수 있다. < P > "내부 루트 찾기 < P > 비교적 텅 빈 목표를 볼 때 먼저 기업 내부의 진정한 프로젝트 후원자를 찾아 심도 있게 소통할 수 있습니다. < P > "외부 추적 < P > 프로젝트가 내부적으로 시작된 것이 아니라 일부 외부 조건의 영향을 받는 경우 외부에서 정보를 찾아야 하는 경우가 있습니다.
4.1.2.2 수요 정의의 개념
수요 정의는 질문/기회라는 네 단어입니다.
단계별: GPOA 모델. 수요 정의나 프로젝트 제안 시 목표 Goal- 질문 Problem- 옵션 시나리오 Options- 제안 시나리오 Answer 프로세스를 자주 사용합니다.
' 목표 골: 내부 뿌리 찾기 또는 외부 추적 방법을 통해 전체 프로젝트가 해결해야 할 문제나 기회를 나열한다.
"질문 Problem: 해당 목표에 대한 문제/기회의 원인을 찾아 모두 나열합니다.
"옵션 옵션 옵션 옵션 옵션 옵션: 각 문제/기회에 대해 가능한 한 많은 솔루션을 나열합니다. < P > "권장 시나리오 Answer: 옵션 시나리오 중에서 가장 신뢰할 수 있는 시나리오를 선택합니다. < P > 수요 정의 활동의 경우 RUP 는 5 단계 방법을 제공하지만 실제 프로젝트에서는 조작성이 강하지 않다는 것을 알 수 있습니다. 하지만 좋은 이론적 프레임워크를 제공합니다. 먼저 5 단계 방법을 학습한 다음 착륙에 더 적합한 방법을 소개합니다.
문제를 5 단계로 나눕니다. 첫 번째 단계: 문제 정의에 대한 * * * 지식 달성. 두 번째 단계: 문제의 근본 원인 분석. 3 단계: 관계자와 사용자를 식별합니다. 네 번째 단계: 솔루션의 경계를 정의하십시오. 5 단계: 솔루션에 추가 된 제약 조건을 결정하십시오. < P > 모두가 * * * * 인식을 달성할 수 있도록 통일된 형식으로 문제를 설명하는 것이 효과적인 수단이다.
4.2.1.1 문제 정의 팁 < P > 은 문제를 올바르게 정의했으며, 이는 절반의 성공을 의미하며, 문제 정의 시 변환과 본원 두 가지 기술을 잘 활용해야 합니다.
"전환
요구 사항 정의 단계 알 수 없는 문제를 알려진 문제로 전환
예: 실제 프로젝트 과정에서 고객과 의사 소통할 때 고객의 요구 사항을 단순한 재개발이 아닌 기존 제품으로 변환하는 방법에 주의해야 합니다. < P >' 본원 < P > 문제는 표상으로 가려지는 경우가 많다.' 당신의 불이 켜졌나요?-문제의 진짜 발견' 에는 몇 가지 사례가 수록돼 있다.
어떤 문제에 대한 해결책을 결정할 때 반드시 새로운 문제를 일으킬 수 있는지 생각해야 한다. < P > 하나의 오류를 해결하기 위해 비용이 많이 드는 솔루션을 사용하는 것은 흔한 문제입니다.
오류를 직접 수정하고 다른 시나리오를 사용하여 오류를 보완하지 마십시오.
4.2.1.2 군중 분석에 영향을 미치는 기술
근본 원인 분석에는 물고기 뼈 차트, 파레토 차트 등 두 가지 유틸리티가 있습니다.
4.2.2.1 어골도 < P > 는 근본 원인을 찾아내는 방법이며 주로 정성 분석에 사용됩니다. 어골도는 보통 브레인스토밍, 특히 한 팀이 함께 어골도를 그려야 한다. 단계는 다음과 같습니다.
1 문제 선택. 먼저 특정 질문이나 결과를 선택해야 합니다.
2 브레인스토밍. 브레인스토밍의 목적은 원인을 찾는 것이지, 원인과 해결책을 혼동해서는 안 된다.
3 사유 유형을 결정합니다. 브레인스토밍의 결과 요약에는 일반적으로 사람, 기계, 재료, 법, 고리 등 6 가지를 넘지 않는다.
4 할당 사유. 브레인스토밍의 원인을 해당 원인 유형으로 귀속시켜 어골도에 넣는다.
5 근본 원인 분석.
6 요약.
4.2.2.2 파레토도 < P > 파레토도는 주로 정량 분석을 한다. 주로 가장 중요한 것, 즉 중요한 원인을 식별하는 데 쓰인다. 파레토 분석은 종종 소수의 실수가 대량의 품질 비용, 즉 유명한 28 법칙에 대한 책임을 져야 한다는 현상을 밝혀 준다. 단계는 다음과 같습니다.
1 문제 및 관련 원인을 확인합니다. 이 일은 실제로 어골도에 의해 완성될 수 있다.
2 데이터 수집. 어골도 결과에 대해 무작위로 샘플을 추출하여 각 원인을 분석하는 빈도를 수집합니다.
3 히스토그램을 그립니다. X 축에 원인을 배치하고 y 축에 비율 또는 빈도를 배치합니다.
4 요약. < P > 어골도는 문제 해결을 위한 과녁을 찾았고 파레토도는 고리 수를 표시했다. < P > 이 두 가지 방법 모두 문제의 관점에서 분석하고, 수요자들은 정보 시스템을 통해 해결할 수 있는 원인을 판단하여 시스템 확립을 더욱 과학적으로 만들어야 한다.
문제가 명확해지면 시스템의 목표도 명확해집니다. 다음은 프로젝트 이해 관계자를 명확히하는 것입니다.
4.2.3.1 Stakeholder 분석 (PMP 의 이해 관계자 분석) < P > 프로젝트 이해 관계자, 이해 관계자, 이해 관계자 등 프로젝트 관리 서적에 자주 언급되는 단어는 모두 Stakeholder 에서 유래한 것으로, 원래 칩 보유자였다.
4.2.3.2 사용자 분석
사용자는 실제로 시스템을 직접 사용하는 Stakeholder 의 한 종류입니다.
4.2.4.1 범위 대 경계
범위는 관련된 일이다. 국경은 사람과 시스템의 책임 경계이다.
4.2.4.2 경계 결정
4.2.4.3 국경 협상
사용자는 항상 같은 돈을 쓰고 가능한 많은 기능을 얻기를 원할 것입니다.
이는 전적으로 고객의 원인이 될 수 없습니다. 거래 양측이 정보 비대칭에 있을 때 반드시 발생할 수 있기 때문입니다. < P > 많은 경우 고객이 원하는 기능이 너무 많다고 직접 대답할 수 없습니다. 이러한 투자는 충분하지 않지만 더 강력한 이유를 찾아야 합니다.
4.2.4.3 혁신 경계
4.2.5 로드 솔루션의 제약 결정
는 주로 기술 제약 및 프로젝트 구현 제약 사항을 포함합니다.
4.2.6 RUP 문제 분석 5 단계 요약 < P > 5 단계 접근 방식은 전략, 사고 방식의 초점에서 시작되며 실제 운영에서는 명확한 지침이 제공되지 않습니다. 다음 두 장에서는 수요 분석가가 수요 정의에서 수행해야 할 작업, 구체적으로 무엇을 해야 하는지 중점적으로 분석합니다. < P > 프로젝트 유형에 따라 제품은 POS (프로젝트 개요) 와 Vision (비전) 의 두 가지 범주로 나눌 수 있습니다.
4.3.1.1 POS 클래스 < P > 프로젝트 기반 소프트웨어 개발 작업의 경우 일반적으로 프로젝트 종료 시 프로젝트 보고서를 작성합니다. 가장 일반적인 것은 프로젝트 헌장, 타당성 분석 보고서 등입니다. 주요 내용은 다음과 같습니다.
4.3.1.2 Vision 클래스
비교적 긴 수명 주기, 비교적 널리 사용되는 프로젝트 또는 제품의 경우 POS 기반, 주로 시장 분석, 계획, 가장 일반적인 RUP 권장 Vision 이 추가됩니다
콘텐츠에서 볼 수 있듯이 Vision 은 시장 기회 분석에 더 많은 관심을 기울이고 있으며, 때로는 SWOT 분석과 같은 시장 분석 콘텐츠도 추가하기도 합니다.
4.3.2.1 목표
목표 프로젝트에 있어 그 중요성은 자명합니다. 좋은 목표는 스마트 원칙을 만족시켜야 한다.
' 구체적 (Sprcific)
' 측정 가능한 (Measureable)
' 달성 가능한 (Attainable)
4.3.2.2 범위 < P > 많은 책에서는 컨텍스트 다이어그램을 통해 범위를 설명하는 것이 좋습니다. 여기서는 섹션 4.4 에 자세히 설명되어 있는 "두 개의 그림 1 개요" 방법을 소개합니다.
4.3.2.3 이해 관계자 및 사용자
요구 사항 단계에서는 시스템 가용성 향상을 위한 사용자의 역량 특성을 설명합니다. < P > 요구 정의 시 사용자에게 수집하고 분석해야 할 정보에는 시스템 주제와 관련된 경험, 기술적 경험, 지적 능력, 업무에 대한 태도, 기술에 대한 태도, 교육 수준, 언어 기술, 나이, 성별 등의 정보가 포함됩니다. < P > 사용자 이외의 이해 관계자의 경우 소프트웨어 시스템에 대한 관심 사항과 시스템을 통해 얻을 수 있는 혜택을 이해해야 합니다.
4.3.2.4 관련 사실 및 가정 < P > 수요측은 프로그램 분해 구조 (시스템-하위 시스템-모듈-하위 모듈) 로 표현된 경우가 많습니다. 앞서 이 구조의 폐단을 설명했습니다. 여기서는 두 가지 그림 1 강의 방법, 즉 구성 요소, 컨텍스트 관계 및 수요 개요를 소개합니다. < P > 우리가 새로운 시스템을 마주할 때, 개발될 전체 시스템을 블랙 박스로 볼 수 있다. 우선 서로 다른 주제 도메인으로 나눌 필요가 있는지 판단해야 한다. 필요한 경우 구성 요소 맵을 통해 주제 도메인과 해당 도메인 간의 서비스 인터페이스를 식별합니다.
4.4.2.1 주제 도메인이란 무엇입니까?
주제 도메인 분할은 기존 하위 시스템 분할과 매우 다릅니다. 먼저 전통적인 서브시스템 구분을 살펴본다. < P > 기존 분할 방법은 종종' 업무명사+관리' 방식으로 명명돼 본질적으로 사물을 단서로 삼는다. 시스템의 분해 구조는 반영되지만 각 시스템/모듈 간의 관계는 무시됩니다. < P > 주제 도메인 분할은 일을 단서로 하여 구성 요소 다이어그램을 통해 시스템을 보여줍니다.
주제 도메인 구분에 대한 사고 과정
"조직 구조를 단서로
" 분관 리더십을 돌파로
"일반적인 업무 블록
을 통해 주제 도메인을 최종 결정하기 전에 이러한 주제 도메인을 고려하도록 목표를 결합해야 하며, 주제 도메인이 목표와 무관하면 제거할 수 있다
목표가 범위를 결정합니다.
4.4.2.2 구성 요소 다이어그램 사용
"구성 요소 다이어그램은 서비스 인터페이스의 중요성
" 구성 요소 다이어그램을 사용하여
× 구성 요소
× 서비스 인터페이스
× 구성 요소와 인터페이스 간의 관계를 분석합니다. 주제 도메인을 분할한 후 각 주제 도메인에 대한 컨텍스트 다이어그램을 그려 각 주제 도메인의 범위를 결정합니다.
4.4.3.1 컨텍스트 관계 다이어그램 그리기 포인트
컨텍스트 관계 다이어그램을 그릴 때 다음 단계를 수행해야 합니다.
1 먼저 시스템
2 가 해당 시스템의 모든 고객을 찾는 사각형을 사용하여 각 고객이 시작할 이벤트를 고려합니다
3 마지막으로 각 작업자에게 사전 예방적인 이벤트가 있는지 확인합니다.
컨텍스트 다이어그램을 그릴 때 작업자를 고려하기 전에 고객을 고려하는 것이 중요합니다. < P > 컨텍스트 다이어그램은 사용자가 의사 소통을 할 때 그려지는 팀 모델링의 산물이어야 합니다. < P > 구성 및 컨텍스트 다이어그램이 그려지면 수요 범위도 상자로 정해집니다. 그러나 후속 수요 캡처 분석 및 모델링 활동을 위한 좋은 기반을 제공하기에는 충분하지 않습니다. 즉, 주제 도메인의 내용을 비즈니스 이벤트 목록과 보고서 목록으로 식별할 수 있습니다. < P > 2 장 각기 다른 소프트웨어 프로젝트의 수요 뷰에서 온라인 트랜잭션 처리 시스템의 핵심은 비즈니스 이벤트 (프로세스) 이고 관리 정보 시스템의 핵심은 보고서 (다양한 쿼리, 분석, 통계 포함) 라고 요약했습니다. 일반적인 비즈니스 시스템에는 두 가지 구성 요소가 모두 포함되어 있으므로 요구 사항 정의 단계에서 두 단서를 모두 명확하게 식별해야 합니다. < P > 비즈니스 이벤트 및 보고서는 위의 아래 다이어그램을 기반으로 합니다.
4.4.4.1 업무 이벤트 해결
업무 이벤트는 업무 프로세스의 트리거 지점이며 업무 프로세스는 업무 이벤트에 응답하기 위해 트리거되는 일련의 업무 활동입니다.
비즈니스 프로세스는 일반적으로 서로 다른 부서의 여러 직책에서 공동 작업을 수행하므로 비즈니스 프로세스 정보는 중간 관리자의 손에 달려 있으며 맥락 정보입니다.
업무 활동은 특정 업무 프로세스에 종속되며 한 사람의 활동이므로 업무 활동 또는 업무 단계 정보는 운영자의 손에 달려 있으며 상세 정보입니다.
' 업무 이벤트 유형
' 업무 이벤트 식별 포인트
업무 이벤트는 사전 예방적으로 트리거되어야 하며 일련의 후속 동작이 발생합니다.
비즈니스 이벤트는 시스템에 직접 작용하며 이벤트를 발생시킨 조건과 분리되어야 합니다.
비즈니스 이벤트를 정리할 때는 데이터 백업, 데이터 준비와 같은 기술적 활동을 따로 보관해야 합니다. 시스템 이벤트가 아닌 비즈니스를 빗질하기 때문입니다.
"보고서 목록 정리
" 제 2 장 다양한 시스템의 요구 사항 뷰 "에 따르면 보고서는 일반적으로 다음과 같이 분류됩니다.
실제 프로젝트에서는 중간 사용자 대표와의 인터뷰를 통해 원하는 보고서 유형을 결정해야 합니다. < P > 제목 도메인을 분할하여 제목 도메인 범위를 결정하고 비즈니스 이벤트 및 보고서를 식별한 후 POS 또는 Vision 문서의 "프로젝트 범위" 에 채울 수 있습니다. 먼저 제목 도메인으로 분할한 다음 각 제목 도메인에 대한 요약을 통해 비즈니스 이벤트 및 보고 요구 사항을 별도로 설명할 수 있습니다. < P > 이와 동시에 이러한 범위 정보를 활용하여 SRS (소프트웨어 요구 사항 사양) 의 프레임워크를 구축하여 다음 단계에서 진화하고 채울 수 있습니다. 다음은 Word 와 Rose 의 구성 형태입니다.
4.4.5.1 Word 문서 구성 예
4.4.5.2 Rose 조직 예
최상위 레벨은 구성 요소 다이어그램입니다.
수요 정의 작업은 후속 수요 작업의 토대인 프로젝트 목표와 범위를 명확히 하는 데 중점을 두고 있습니다.
목표 문제를 해결한 후 범위를 정의하는 것입니다. SERU 모델 소개, 주제 도메인, 비즈니스 이벤트, 보고서, 사용 사례의 각도 분석 범위, 구성 요소 차트, 컨텍스트 다이어그램 및 수요 아웃라인을 통해 범위 설명