1. 고객이 실제로 필요로 하는 소프트웨어
2. 고객의 마음 속에 원하는 소프트웨어
3. 리서치 후 소프트웨어
4. 디자이너가 설계한 소프트웨어
5. 개발자가 개발한 소프트웨어 < 그러면 최종 개발이 완료된 소프트웨어와 고객이 실제로 필요로 하는 소프트웨어의 차이가 커질 가능성이 높습니다. 실패하거나 잘 하지 못하는 프로젝트가 종종 여기에 있습니다. < P > 그리고 또 한 가지 더 있습니다. 이 과정에서, 뒤로 갈수록, 이러한 편차를 수정하는 데 드는 대가는 감당할 수 없을 때까지 더 커집니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 실패명언) 그렇다면, 당신이 조사한 수요와 고객의 실제 수요, 그리고 고객의 머릿속에서 원하는 세 가지가 일치하고, 이 수요는 개발상 실현될 수 있고 쉽게 실현될 수 있도록, 모든 수요 조사원들이 열심히 하는 것이다. < P > 2. 프로젝트류 수요조사의 특징
1.' 수요사양서' 의 발행은 비교적 촉박하고 품질이 낮다.
(1). 비현실적인 기간 (수요조사가 통과가 됨)
(2). 조사위원들의 잘못된 이해, 추가적인 호소를 이끌어낼까봐 두려워)
(4). 공사 기간 압력으로 각 당사자는 타협하여 서명했다 (폭넓은 지지를 쟁취하지 않았다)
2. 대부분의 수요는' 수요사양설명서' 가 나온 후 나온
(1). 더 많은 기능 호소 < P > 는 이러한 문제의 요점을 파악하고, 실제 운영에서 관련 오류의 요점을 피하고, 고객을 정확하게 안내하고, 수요 조사를 양성한 방향으로 발전시킬 수 있도록 주의를 기울여야 합니다. (윌리엄 셰익스피어, Northern Exposure (미국 TV 드라마), 기능명언) < P > 셋째, 수요 조사의 사전 준비
1. 조사 도구 결정 < P > 수요 조사 과정에서 일부 보조 도구를 선택하고, 선택 요구 사항은 자신 (본 그룹) 에 익숙한 도구이며, 의사 소통 문제를 고려해야 하기 때문에 가장 적합하고 일반적인 요구 사항입니다.
예: 원형, 스케치, WORD, EXCEL, PPT, POWERDESIGNER, 시작 UML 등. < P > 여기서는 프로토타입 방법만 강조하고 있습니다. 프로토타입 방법은 가능한 한 빨리 거친 시스템을 구축하는 것입니다. 이 시스템은 목표 시스템의 일부 또는 전체 기능을 달성합니다. 이러한 시스템을 구축하는 목적은 알고리즘의 실현 가능성, 기술의 실현 가능성, 사용자의 요구 사항 충족 여부 등과 같은 특정 측면의 실현 가능성을 조사하는 것입니다. 예를 들어, 사용자의 요구 사항이 충족되었는지 여부를 조사하기 위해 일부 소프트웨어 도구를 사용하여 프로토타입 시스템을 신속하게 구축할 수 있습니다. 이 시스템은 인터페이스일 뿐 사용자의 의견을 듣고 프로토타입을 개선할 수 있습니다. 앞으로의 목표 시스템은 프로토타입 시스템을 기반으로 개발된다. < P > 프로토타입은 탐색형, 실험형, 진화형의 세 가지 주요 유형이 있습니다. < P > 탐구형: 목표 시스템에 대한 요구 사항을 정확히 파악하고 원하는 특성을 결정하고 다양한 시나리오의 실현 가능성을 모색하기 위한 것입니다. < P > 실험형: 대규모 개발 및 구현을 위한 평가 방안이 적합한지, 사양 설명이 신뢰할 수 있는지 여부. < P > 진화형: 사양 설명을 개선하는 것이 아니라 시스템을 쉽게 만들어서 프로토타입을 개선하는 과정에서 프로토타입을 최종 시스템으로 점진적으로 진화시키는 것입니다.
프로토타입 방법을 사용할 때 폐기 정책, 추가 정책의 두 가지 정책이 있습니다. < P > 폐기 전략: 먼저 기능이 간단하고 품질 요구 사항이 높지 않은 모델 시스템을 구축하고, 이 시스템을 반복적으로 수정하여 더 나은 아이디어를 형성하고, 이에 따라 보다 완전하고 정확하며 일관되며 신뢰할 수 있는 최종 시스템을 설계합니다. 시스템 구조가 완료되면 원래 모델 시스템은 폐기되고 사용되지 않습니다. 탐구형과 실험형은 이런 전략에 속한다.
추가 전략: 먼저 기능이 간단하고 품질 요구 사항이 높지 않은 모델 시스템을 최종 시스템의 핵심으로 구축한 다음, 변경 사항을 지속적으로 확장하여 새로운 요구 사항을 점진적으로 추가하여 최종 시스템으로 발전시킵니다. 진화형은 이런 전략에 속한다.
2. 프로젝트 선행 조건 조사
대상: pre-sales 담당자, 비즈니스 담당자, 프로젝트 관리자 < P > 내용: 입찰, 답안서, 계약 및 기타 사용자와 교류하는 구두 또는 서면 자료 (홍보, 약속 등 포함) < P > 갑의 업계 상황에 대한 이해, 일부 업종 방면의 책을 보고 업무 분야 지식을 배우는 것이 좋다. < P > 고객, 프로젝트의 배경 이해, 사전에 고객이 유사한' 소프트웨어 예비 사고' 와 같은 원본 요구 사항 문서를 제공한 경우 먼저 이 문서를 이해하고, 고객의 목적, 왜 이 소프트웨어를 해야 하는지, 주로 어떤 문제를 해결하고 싶은지, 관련된 업무에 어떤 것이 있는지, 이러한 연구 준비의 기초를 파악합니다.
은 (는) 파악된 예비 사용자 요구 사항에 따라 가능한 어려움이 어디에 있는지 분석하고 이러한 어려움을 나열합니다. 마음속으로 수를 세고, 이전에 수요를 이해하는 과정에서 이해하지 못한 부분을 기록하여 현장에 도착한 후 제때에 고객과 소통할 수 있도록 한다.
3. 요구 사항 조사 사양 설정 < P > 은 (는) 이 프로젝트 서비스를 위해 필요한 파일 관리를 위한 전문 설계 환경 (문서 카탈로그) 을 구축해야 합니다.
(1). 통합 프로젝트에 사용되는 도구
(2). 통합 프로젝트 문서 템플릿
(3). 기타 자원 목록 (자료, 관련 웹 사이트, 문의전화)
4. 고객 조직 구조 명확화 상하 관계는 어떻습니까? 프로젝트 팀을 위한 외부 연락처 주소록을 구축하다.
고객의 조직, 소프트웨어 사용과 관련된 부서, 조사에 참여하는 부서 및 인력, 고객 핵심 인사가 누구인지 등을 이해하고, 고객 상층부의 지원을 최대한 받을 수 있으며, 하향식 수요 조사를 실시하면 조사 작업이 더욱 쉬워집니다. 고객 요구사항 팀 구성원은 가능한 한 많은 고객을 대신하여 서로 다른 사용자 계층을 나타내야 합니다.
5. 프로젝트에 대한 조사 계획 개발
조사 계획 수립 목적: 조사 활동 순서를 분할, 평가, 자원 배정.
계획을 세울 때 분석 시간을 고려합니다. 회사 내부 심사가 통과된 후 제때에 고객에게 제출하여 고객이 조사 계획에 대해 충분히 이해할 수 있도록 할 계획입니다.
리서치 프로그램에는
(1). 무엇을 조사합니까? 어떤 방법으로 조사합니까? 누가 언제 조사합니까?
(2). 프로젝트 팀 직원 분업 (우리 전문가 양성)
(3). 조사에서 모두가 따르는 합의 (예: 서명 필요 여부? 정기 회의 개최 시기 등)
(4). 고객측은 수요의 기능 모듈에 대해 명확한 유일한 협력 담당자
주의사항:
프로젝트 임무서가 발표되면 프로젝트 관리자와 조사관들은 계약의 소프트웨어 범위에 대해 꼼꼼히 검토해야 한다
계획 수립 후 프로젝트 개시 회의, 관련 리더 및 사업부 참여, 쌍방 프로젝트 팀 구성원 파악, 고객 측 파트너 (유일한 담당자), 리더 (유일한 코디네이터) 파악, 프로젝트 팀 인사, 일반 계획, 수요 조사 계획 소개, 여행 및 계획 통보.
4 수요 조사의 결과는 다음과 같습니다.
(1). 사용자가 생성해야 하는 문서와 보고서를 수집합니다. 양식 및 보고서의 구분자
(2). 비즈니스 흐름도를 그리고 각 경로가 완전한지, 예외가 처리되는 방법 (시스템의 동적 특성) 을 주의 깊게 검토하고 확인합니다.
(3). 순서도를 기준으로 각 단계에 필요한 사용 및 운영 데이터를 수집하여 데이터의 유형과 범위 (시스템의 정적 특성) 를 결정합니다.
(4). 운영 단위와 해당 관계를 그리고 운영 단위의 생성 빈도와 데이터 양을 추정합니다.
(5). 비즈니스 프로세스 및 개체 내 수요 변화의 가능성을 평가합니다.
(6). 사용자 권한
(7). 정보 시스템 구축 현황;
(8). 시스템 인터페이스 스타일, 레이아웃, 색상에 대한 사용자 선호도 및 요구 사항 수집
(9). 향후 시스템에서 사용할 하드웨어, 운영 체제, 네트워크 상황을 파악합니다.
(1). 시스템 초기화 데이터를 수집하거나 고객에게 수집 및 정리, 명확한 기간 시간을 요청합니다.
(11).
2. 요구 사항 조사 결과
(1).' 요구 사항 사양'
(2). 시스템 상세 원형
5, 요구 사항 조사 수행 방법
1. 무엇을 해야 하는지 먼저 알아야 한다 < < P > 당신이 이해하지 못하는 업종 (전공) 이라면 전문가가 있는 것이 가장 좋다. 최종 사용자가 전문가가 되는 것이 가장 좋다. 이 전공을 연구하는 것은 전문가가 되는 것이 아니라, 최소한 어느 정도의 전문 지식 (최소한 전문 어휘를 알아야 함) 을 알아야 한다. 그렇지 않으면 무엇을 물어야 할지, 어떻게 물어야 할지, 심지어
해당 전문 자료가 필요하며, 최소한 전문 입문서와 해당 자료가 있어야 하며, 좀 더 심층적인 자료가 필요하다. 물론 전문가의 참여는 별론이다. < P > 업계의 어려움이 크지 않은 경우 분석가의 자체 학습을 통해 단기간에 업계를 이해할 수 있으며 전문가를 사용하지 않을 수도 있습니다. 그렇지 않으면 전문가가 필요합니다.
2. 다양한 수단을 사용하여 요구 사항 발굴 < P > 조사 자료 준비: 조사 자료 (Rose 그림, Ppt, 프로토타입 준비) 일반 고객 그래픽 인터페이스에 관심이 있습니다. 사용자에게 그림을 보여 주는 것이 좋습니다. 유스 케이스 다이어그램, 사용자 인터페이스, 프로세스 협업 다이어그램으로 변환할 수 있습니다. < P > 요구 사항 조사 프로세스에는
1) 과 같은 선별적인 조사 방법이 있습니다. 고객과 대화하고 사용자에게 질문을 합니다.
2). 사용자 워크플로우를 방문하여 사용자 작업을 관찰합니다.
3). 사용자에게 설문지를 보냅니다. < P > 사용자는 일반적으로 논술 질문에 참을성 있게 대답하지 않으므로 객관식 및 참/거짓 문제를 위주로 해야 합니다.
4). 동료, 전문가와 이야기를 나누고 그들의 의견을 경청하다.
5). 기존 소프트웨어 제품을 분석하고 요구 사항을 추출합니다.
6). 업계 표준, 계획에서 요구 사항 추출
7). 인터넷 검색 관련 자료
3. 사용자 입장에서 시스템 기능 고려
1
2). 사용자의 언어는 사용자와 통신합니다.
3). 이전 구현 경험을 요약하고 권장 사항을 작성합니다.
4). 이전 구현 경험을 요약하고 요구 사항을 안내합니다.
* 위 항목도 수요 변경을 최소화하는 수단 중 하나입니다.
4.5W+1H 방법
5w: why, what, who, when, where
1h: how to accomplish (구현) the sh
WHY 법칙: WHY 는 사용자가 시스템을 도입하고, 새로운 정보 시스템을 도입하는 것이 사용자에게 어떤 도움이 되며, 전반적인 업무 성능에서 최종 결과를 달성하는 방법입니다. WHY 의 법칙은 수요가 시작될 때 프로젝트 관리자가 사용자 생산성을 향상시키기 위해 명확해야 한다는 것입니다. 부서 간 협력 메커니즘을 향상시킨다. 고객에 대한 대응 속도를 높이는 시스템 서비스 기업의 경쟁력을 높이는 등. 이러한 WHY 의 도입을 통해 프로젝트 관리자는 사용자가 궁극적으로 제공할 수 있는 시스템을 파악할 수 있으며, 시스템의 위치 및 구축에는 명확한 목표가 있습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 시스템명언)
WHAT 법칙: 각 비즈니스 프로세스의 요구 사항부터 시작하여 두 번째 W 법칙 __-WHAT 법칙을 도입하고 WHAT 는 이 시스템에서 무엇을 해야 합니까? 무엇을 실현하는가? 각 업무 프로세스 문제, 프로세스 제한 문제, 시스템에서 해결해야 할 문제 등을 제기합니다. 이 WHAT 를 기반으로 시스템을 각 기능 모듈로 나누어 모듈 프로세스 요구 사항, 기능 요구 사항, 구조 요구 사항을 점진적으로 파악합니다. WHAT 법칙을 도입하면 시스템의 초기 요구 사항을 알 수 있습니다.
WHO, WHEN, WHERE 법칙: 이 단계는 수요 테셀레이션 단계이며, WHAT 법칙에 따라 시스템의 사용자 요구 사항을 세분화합니다. 누가, 언제, 언제, 어떤 단계에서 이 기능을 조작할 수 있는지 분석하고, 이전 WHAT 법칙과 결합하여 시스템의 프로세스 단계 구분을 정리하고, 문서화해야 합니다.
HOW 법칙: 시스템을 실현하는 방법, 이전 WHY, WHAT, WHO, WHEN, WHERE 를 기반으로 시스템 요구 사항 기본 프레임워크를 구축했습니다. 이러한 사용자 요구 사항을 기반으로 시스템 요구 사항 분석 방법, 요구 사항 사양 분석 방법 및 다음 단계