<프로젝트 이름>

비전

 

버전 <1.0>

 

 

[참고: 이 템플리트는 Rational Unified Process에서 사용됩니다. 대괄호 안에 파란색 이탤릭체로 표시된 텍스트(style=InfoBlue)는 작성자용 안내로 제공되므로 문서를 공개하기 전에 삭제해야 합니다. 해당 스타일로 입력된 단락은 자동으로 일반(style=Body Text)으로 설정됩니다.]

 


개정 히스토리

날짜

버전

설명

작성자

<dd/mmm/yy>

<x.x>

<세부사항>

<이름>

 

 

 

 

 

 

 

 

 

 

 

 

 


목차

1.       소개          

1.1     목적      

1.2     범위      

1.3     정의, 두문자어 및 약어      

1.4     참조      

1.5     개요      

2.       포지셔닝          

2.1     비즈니스 기회      

2.1.1     현재 위치 

2.1.2     변경 이유

2.2     문제점 설명      

2.3     제품 포지션 설명     

3.       이해 당사자(stakeholder) 및 사용자 설명  

3.1     시장 분석     

3.2     이해 당사자(stakeholder) 요약     

3.3     사용자 요약     

3.4     사용자 환경     

3.5     이해 당사자(stakeholder) 프로파일     

3.5.1     <이해 당사자(stakeholder) 이름>           

3.6     사용자 프로파일     

3.6.1     <사용자 이름>           

3.7     중요 이해 당사자(stakeholder) 또는 사용자 요구     

3.8     대안 및 경쟁 제품     

3.8.1     <경쟁사>           

3.8.2     <다른 경쟁사>           

3.9      고려 대상 개발 대안

4.       제품 개요      

4.1     제품 관점     

4.2     기능 요약     

4.3     가정 및 종속성     

4.4     비용 및 가격 책정     

4.5     라이센스 부여 및 설치     

5.       제품 기능         

5.1     기능     

5.1.1       <기능>

5.1.2       <다른 기능>

5.2     운영 시나리오

5.3       지원 제공    

6.       제한조건         

7.       품질 범위

8.       우선순위

9.       기타 제품 요구사항

9.1     적용되는 표준     

9.2     시스템 요구사항     

9.3     성능 요구사항     

9.4     환경 요구사항   

9.5       물리적 요구사항  

10.            문서 요구사항               

10.1     사용자 매뉴얼     

10.2     온라인 도움말     

10.3     설치 안내서, 구성 및 Read Me 파일     

10.4     레이블 및 패키지 처리     

A.                 기능 속성               

   


비전

1.                  소개

[이 문서의 목적은 <<시스템 이름>>의 상위 레벨 요구 및 기능을 수집, 분석 및 정의하는 것입니다. 이 문서는 이해 당사자(stakeholder) 및 대상 사용자에게 필요한 기능 및 해당 기능의 존재 이유에 초점을 맞춥니다. <<시스템 이름>>에서 해당 요구를 이행하는 방법에 대한 자세한 내용은 유스 케이스 및 보충 스펙에 설명됩니다. 참고: 이 비전 템플리트는 특정 고객의 요구사항에 따라, 인지된 시장 요구에 맞게 이론적으로 개발된 수축 포장 제품에서 계약에 따라 개발 중인 온오프(one-off) 시스템에 이르기까지 모든 유형의 개발을 다룹니다. 결과적으로 '제품'과 '시스템'이라는 단어는 특별히 구분하지 않고 '개발할 대상'을 나타내기 위해 사용할 수 있습니다. 특정 응용프로그램의 경우 문서 사용자 조정을 통해 이를 강화할 수 있습니다.]

[비전 문서의 소개에서는 전체 문서에 대한 개요를 제공합니다. 이 비전 문서의 목적, 범위, 정의, 두문자어, 약어, 참조 및 개요가 포함됩니다.]

1.1               목적

[이 비전 문서의 목적을 지정하십시오.]

1.2               범위

[비전 문서의 범위에 대한 간단한 설명. 관련된 프로젝트 및 이 문서의 영향을 받는 기타 내용을 설명합니다.]

1.3               용어의 정의

[이 섹션에서는 비전 문서의 올바른 해석에 필요한 모든 용어(약어, 머리글자로 이루어진 용어 포함)를 제공합니다. 해당 정보는 프로젝트 용어집의 참조로도 제공될 수 있습니다.]

1.4               참조

[이 섹션에서는 비전 문서 전체에서 참조되는 모든 문서의 전체 목록을 제공합니다. 각 문서는 제목, 보고서 번호(있는 경우), 날짜 및 공개하는 조직으로 식별됩니다. 참조를 가져올 수 있는 소스를 지정하십시오. 이 정보는 부록이나 기타 문서의 참조로도 제공될 수 있습니다.]

1.5               개요

[이 섹션에서는 비전 문서 관련 기타 내용 및 문서를 체계화하는 방법에 대해 설명합니다.]

2.                  포지셔닝

2.1               비즈니스 기회

[프로젝트에서 달성하는 비즈니스 기회를 간략하게 설명합니다.]

2.1.1     현재 위치

[이 서브섹션에서는 기존 시스템 또는 비즈니스 상황의 배경, 목적 및 범위를 설명합니다(해당되는 경우 적용되는 정책, 현재 시스템의 기능, 관련 이해 당사자(stakeholder) 및 지원 문제 포함).]

2.1.2     변경 이유

[이 서브섹션에서는 이미 발생했으며 변경될 새로운 상황 또는 요구를 비즈니스 또는 오퍼레이션 관점에서 설명합니다. 제안되었으나 거부된 변경사항과 해당 근거를 간단하게 식별합니다. 변경 요구에 대한 사례 연구가 수행된 경우 해당 연구를 참조할 수 있습니다.]

2.2               문제점 설명

[프로젝트에서 해결 중인 문제점을 요약하는 설명을 제공합니다. 다음 형식을 사용할 수 있습니다.]

문제점

[문제점을 설명합니다.]

적용

[문제점의 영향을 받은 이해 당사자]

문제점 영향

[문제점의 영향은 무엇입니까?]

성공적인 솔루션

[성공적인 솔루션의 주요 이점 몇 가지 목록을 표시합니다.]

2.3               제품 포지션 설명

[최상위 레벨에서 마켓플레이스에서 제품이 차지하려는 고유 위치를 요약하는 전체적인 설명을 제공합니다. 다음 형식을 사용할 수 있습니다.]

대상 고객

[대상 고객]

대상

[필요사항 또는 기회 설명]

제품 이름

[제품 카테고리]

구매 이유

[반드시 구매해야 하는 이유로 주요 수익성 설명]

경쟁 제품

[주요 경쟁 대체 제품]

우리 제품

[주요 차이점 설명]

[제품 또는 시스템 위치 설명은 관련된 모든 사람에게 시스템의 목적과 프로젝트의 중요성을 알립니다.]

3.                  이해 당사자(stakeholder) 및 사용자 설명

[이해 당사자 및 사용자의 실제 요구를 충족시키는 제품 및 서비스를 효과적으로 제공하려면 모든 이해 당사자를 요구사항 모델링 프로세스의 일부로 포함시켜야 합니다. 시스템 사용자도 식별하고 이해 당사자 커뮤니티에서 해당 사용자를 알맞게 표시하고 있는지 확인해야 합니다. 이 섹션에서는 프로젝트에 관련된 이해 당사자 및 사용자 프로파일 및 제안된 솔루션으로 처리되도록 인지되는 주요 문제점을 제공합니다. 특정 요구사항 또는 요청은 별개로 이해 당사자 요청 아티팩트에서 캡처되기 때문에 자세한 내용를 설명하지는 않습니다. 대신 요구사항이 필요한 이유의 배경 및 정당성이 제공됩니다.]

3.1               시장 분석

[제품 결정에 동기를 부여하는 주요 시장 통계를 요약합니다. 대상 시장 분류를 설명 및 지정합니다. 잠재적 사용자 수, 제품 또는 개선사항에 따라 필요한 요구를 충족시키기 위해 고객이 소비하는 비용을 기준으로 시장 규모 및 성장을 예상합니다. 주요 업계 동향 및 기술을 검토합니다. 다음의 전략적인 질문에 대답합니다.

?          이 시장에서 조직의 명성은 어떠합니까?

?          원하는 기대치는 어느 정도입니까?

?          이 제품 또는 서비스가 목적을 어떻게 지원합니까?]

3.2               이해 당사자 요약

[개발에 관심을 두는 이해 당사자는 많지만 모두 다 사용자는 아닙니다. 일반 사용자가 아닌 이해 당사자 목록 요약을 제공합니다. (사용자는 섹션 3.3에 요약되어 있습니다.) ]

이름

설명

책임

[이해 당사자 유형 이름.]

[이해 당사자를 간단하게 설명합니다.]

[개발 시스템 관점에서 이해 당사자의 주요 책임, 즉 이해 당사자로서의 관심사항을 요약합니다. 예를 들어 이해 당사자는

- 시스템 유지보수를 확인합니다.

- 제품 기능에 대한 시장 수요가 있는지 확인합니다.

- 프로젝트 진행상태를 모니터합니다.

- 자금 지원을 승인합니다.]

3.3               사용자 요약

[식별된 전체 사용자 요약 목록을 제공합니다.]

이름

설명

책임

이해 당사자

[사용자 유형 이름.]

[시스템과 연관해서 표시되는 내용을 간략하게 설명합니다.]

[개발 대상 시스템의 관점에서 사용자의 주요 책임을 나열합니다. 예를 들어 다음과 같습니다.

- 세부사항 캡처

- 보고서 생성

- 작업 조정]

[사용자가 직접 표시되지 않는 경우 사용자의 관심사항 표시를 담당하는 이해 당사자를 식별합니다.]

 

3.4               사용자 환경

[대상 사용자의 작업 환경을 자세히 설명합니다. 몇 가지 제안이 있습니다.

관련 타스크 및 비즈니스 작업자에 대한 아웃라인을 설명하기 위해 비즈니스 모델에서 추출한 내용을 포함시킬 수 있습니다.]

3.5               이해 당사자 프로파일 

[시스템의 각 이해 당사자를 각 이해 당사자용 표에 해당 정보를 입력하여 여기에 설명합니다. 이해 당사자 유형은 사용자, 부서 및 기술 개발자에 따라 분리됩니다. 전체적인 프로파일을 사용하여 이해 당사자의 각 유형에 대한 다음 주제가 처리됩니다.]

3.5.1          <이해 당사자(stakeholder) 이름>

담당자

[프로젝트 이해 당사자(stakeholder)의 대표는 누구입니까?(다른 곳에 문서화한 경우 선택사항)  이름을 명시합니다.]

설명

[이해 당사자 유형에 대한 간략한 설명입니다.]

유형

[이해 당사자의 전문 지식, 기술 배경 및 숙련도(지도자, 비즈니스, 전문가, 일반 사용자 등)의 정도를 규정합니다.]

책임

[개발 시스템 관점에서 이해 당사자의 주요 책임, 즉 이해 당사자로서의 관심사항을 나열합니다.]

성공 기준

[이해 당사자가 성공을 어떻게 정의합니까?

이해 당사자는 어떤 방식으로 보상받습니까?]

관여

[이해 당사자는 어떤 방식으로 프로젝트에 관여합니까? 가능한 경우와 Rational Unified Process 역할, 즉 요구사항 검토자 등을 관련시킵니다.]

인도물

[이해 당사자에게 필요한 추가 인도물이 있습니까? 개발 중인 시스템의 프로젝트 인도물 또는 결과물입니다.]

설명/문제

[성공 및 기타 상관 정보 전체 작성을 방해하는 문제점을 여기에 명시합니다.]

 

3.6               사용자 프로파일 

[시스템의 각 고유 사용자를 각 사용자 유형 표에 해당 정보를 입력하여 여기에 설명합니다. 사용자 유형은 전문 / 비전문에 따라 달라집니다. 예를 들어 전문가인 경우 플랫폼 간 지원 가능한 복잡하고, 융통성있는 도구가 필요한 반면 비전문가에게는 사용하기 편한 쉬운 도구가 필요합니다. 전체 프로파일을 통해 각 사용자 유형에 대한 다음 주제를 다룹니다.]

3.6.1          <사용자 이름>

담당자

[프로젝트의 대표 사용자는 누구입니까(다른 곳에 문서화한 경우 선택사항)? 일반적으로 사용자 세트를 나타내는 이해 당사자입니다(예: Stakeholder: Stakeholder1).]

설명

[사용자 유형의 간략한 설명]

유형

[사용자의 전문 지식, 기술 배경 및 숙련도(지도자, 일반 사용자 등)의 정도를 규정합니다.]

책임

[개발 대상 시스템의 관점에서 사용자의 주요 책임을 나열합니다. 즉, 세부사항을 캡처하고 보고서를 생성하며 작업을 조정하는 등의 작업을 수행합니다.]

성공 기준

[사용자가 성공을 어떻게 정의합니까?

사용자에 대한 보상 방법은 무엇입니까?]

관여

[사용자는 어떤 방식으로 프로젝트에 관여합니까? 가능한 경우와 Rational Unified Process 역할, 즉 요구사항 검토자 등을 관련시킵니다.]

인도물

[사용자가 생성하는 인도물이 있습니까? 있는 경우 대상은 누구입니까?]

설명/문제

[성공 및 기타 상관 정보 전체 작성을 방해하는 문제점을 여기에 명시합니다. 사용자 작업을 더 쉽거나 어렵게 만드는 동향이 포함됩니다.

 

3.7               중요 이해 당사자 또는 사용자 요구

[이해 당사자가 인지하는 기존 솔루션의 주요 문제점 목록을 표시합니다. 각 문제점에 대해 다음 문제를 규정합니다.

?          이 문제점의 원인은 무엇입니까?

?          해결 방법은 무엇입니까?

?          이해 당사자 또는 사용자가 원하는 솔루션은 무엇입니까?]

[이해 당사자 또는 사용자가 문제점 해결에서 중요시하는 상관성을 이해하는 것이 중요합니다. 등급 지정 및 누적되는 의결 기법은 반드시 해결해야 하는 문제점과 처리하려는 문제점을 알려줍니다.

다음 표를 작성하십시오. Rational RequisitePro를 사용하여 요구를 캡처하는 경우, 해당 도구에서 추출하거나 보고한 내용입니다.]

요구사항

우선순위

관심사항

현재 솔루션

제안 솔루션

브로드캐스트 메시지

 

 

 

 

 

3.8               대안 및 경쟁 제품

[이해 당사자에게 사용 가능한 대체 방법을 식별합니다. 경쟁 제품 구매, 자체 생산 솔루션 빌드 또는 현상 유지가 포함됩니다. 현재 있거나 앞으로 사용 가능해지는 알려진 경쟁 제품 선택사항 목록을 표시합니다. 이해 당사자 또는 사용자가 인지하는 각 경쟁 제품의 주요 장점 및 단점이 포함됩니다.]

3.8.1          <경쟁사>

3.8.2          <다른 경쟁사>

3.9       고려 대상 개발 대안

[이 서브섹션에서는 고려한 제안 제품의 대안과 연관 사례 연구에 대해 설명합니다.]

4.                  제품 개요

[이 섹션은 제품 기능, 기타 시스템 인터페이스 및 시스템 구성의 상위 레벨 보기를 제공합니다.] 

4.1               제품 관점

[비전 문서의 이 서브섹션은 기타 관련 제품 및 사용자 환경의 관점에서 제품을 설명합니다. 제품이 독립적이며 완전하게 자체포함된 상태인 경우 여기에 명시합니다. 제품이 대규모 시스템의 컴포넌트인 경우, 이 서브섹션은 이 시스템이 시스템 간 관련 인터페이스를 식별하고 상호작용하는 방식과 관련이 있습니다. 대규모 시스템, 상호 연결 및 외부 인터페이스의 주요 컴포넌트를 쉽게 표시하는 방법 중 하나는 블록 다이어그램을 사용하는 것입니다.] 

이해 당사자 및 기타 시스템에 대한 오퍼레이션, 조직 및 개발 영향을 식별합니다.]

4.2               기능 요약

[제품에서 제공되는 주요 수익성 및 기능을 요약합니다. 예를 들어 고객 지원 시스템의 비전 문서는 각 기능에 필요한 세부사항을 명시하지 않으면서 문제점 문서, 라우팅 및 상태 보고 처리에 해당 부분을 사용합니다.

기능을 체계화하여 목록을 고객 또는 문서를 처음으로 읽는 모든 사용자가 이해할 수 있도록 합니다. 주요 수익성 및 지원 기능을 나열하는 단순한 표로도 충분합니다. 예를 들면 다음과 같습니다.]

표 4-1 고객 지원 시스템

고객 이점

지원 기능

새로 투입된 지원 인원이 더 빨리 익숙해지게 됩니다.

지식 기반을 통해 해당 인력이 알려진 수정사항 및 해결 방법을 빠르게 식별할 수 있도록 지원합니다.

세부적인 부분을 간과하지 않아 고객 만족도가 향상됩니다.

해결 프로세스를 통해 문제점을 정확히 기술, 분류 및 추적합니다. 노후 관련 문제에 대해서는 자동 알림이 통보됩니다.

관리 팀에서 문제점 영역을 식별하고 인력 워크로드를 파악할 수 있습니다.

성향 및 분포 보고서를 통해 문제점 상태를 높은 수준으로 검토할 수 있습니다.

분배 지원 팀이 협력하여 문제점을 해결할 수 있습니다.

복제 서버를 통해 현재 데이터베이스 정보를 엔터프라이즈에서 공유할 수 있습니다.

고객의 자체 지원으로 지원 비용을 절감하고 응답 시간을 단축시킬 수 있습니다.

지식기반을 인터넷에서 사용할 수 있습니다. 하이퍼텍스트 검색 기능과 그래픽 조회 엔진이 포함됩니다.

4.3               가정 및 종속성

[비전 문서에 명시된 기능에 영향을 주는 각각의 요인 목록을 표시합니다. 가정이 변경되는 경우 비전 문서도 수정해야 하는 가정 목록을 표시합니다. 예를 들어, 비전은 대규모 엔터프라이즈의 컨텍스트에서 구성되고 해당 컨텍스트가 변경되는 경우 비전을 변경해야 합니다. 예를 들어, 경제, 정치, 법률 또는 환경 요인이 포함됩니다. 비전은 또한 장비, 소프트웨어 또는 기타 시스템 컴포넌트의 가용성과 특정 전문 지식 또는 스킬의 가용성에 영향을 받습니다.]

4.4               비용 및 가격 책정

[외부 고객에게 판매되는 제품 및 여러 내부 시스템의 경우, 비용 및 가격 책정 문제는 시스템의 정의 및 구현에 직접적인 영향을 줄 수 있습니다. 이 섹션에서 관련된 모든 비용 및 가격 책정 제한조건을 레코드합니다. 예를 들어, 분배 비용(디스켓 수, CD-ROM 수, CD 마스터링) 또는 기타 판매 상품 비용 제한조건(매뉴얼, 포장)은 응용프로그램 성향에 따라 프로젝트 성공과 직결되거나 관련이 없는 자료가 될 수 있습니다.]

4.5               라이센싱 및 설치

[라이센싱 및 설치 문제는 개발 노력에 직접적인 영향을 줄 수 있습니다. 예를 들어, 액세스 제어, 직렬화, 암호 보안 또는 네트워크 라이센스 부여 지원 대한 요구는 개발 노력에서 고려해야 하는 하는 추가 시스템 요구사항을 작성합니다.

설치 요구사항은 또한 소프트웨어 생성에 영향을 주거나 별도 설치 소프트웨어에 대한 요구를 작성할 수 있습니다. 실제 시스템 또한 특수 설치 요구사항을 부과할 수 있습니다(예: 해당 시스템에 특정 보안 또는 존속성 제한조건이 적용되는 경우).]

5.                  제품 기능

[제품 기능을 나열하고 간략하게 설명합니다. 해당 기능은 사용자에게 이점을 제공하는 데 필요한 상위 레벨 시스템 기능입니다. 또한 각 기능과 연관된 성능 특성을 함께 설명합니다. 즉, 기능을 "얼마나 잘" 수행하는가와 특정 수치(예: 시간, 응답 시간, 트랜잭션 비율)를 설명합니다. '기능'이란 시스템 또는 제품이 수행해야 하는 내용을 의미합니다. 각각의 기능은 일반적으로 원하는 결과 획득에 입력을 필요로하는 외부적으로 필요한 서비스입니다. 예를 들어 문제점 트랙 시스템의 기능은 상태동향 보고서 제공을 위한 기능입니다. 유스 케이스 모델에서는 쉐이프를 사용하기 때문에 유스 케이스를 참조하는 설명을 갱신합니다.

비전 문서는 관련된 여러 사람이 검토하기 때문에 세부사항 레벨은 모든 사람이 이해할 수 있을 만큼 일반적이어야 합니다. 그러나 유스 케이스 모델을 작성하는 팀에게는 사용 가능한 충분한 정보를 제공해야 합니다.

복잡도를 효과적으로 관리하려면 모든 새 시스템 또는 기존 시스템 증분의 경우 결과적으로 25 - 99개의 기능을 얻을 수 있는 높은 수준으로 기능을 추상화하는 것이 좋습니다. 해당 기능에서는 제품 정의, 범위 관리 및 프로젝트 관리용 기본 정보를 제공합니다. 각 기능은 유스 케이스 모델을 통해 또는 프로젝트에서 유스 케이스를 생성하지 않는 경우 자연어로 세부 확장됩니다.

해당 섹션 전체에서 각 기능을 사용자, 연산자 또는 기타 외부 시스템이 외부적으로 인지할 수 있게 됩니다. 해당 기능은 기능 설명 및 처리해야 하는 모든 관련 사용성 문제에 대한 설명을 포함해야 합니다. 다음 가이드라인이 적용됩니다.

?          디자인을 사용하지 않습니다. 기능 설명을 일반 레벨로 유지합니다. 구현해야 하는 필요한 기능 및 해당 이유(방법이 아닌)에 초점을 맞춥니다.

Rational RequisitePro 툴킷을 사용하는 경우, 쉽게 참조하고 추적할 수 있는 유형의 요구사항으로 모두 선택해야 합니다.]

5.1               기능

5.1.1     <기능>

5.1.2     <다른 기능>

5.2               운영 시나리오

[시스템과 해당 사용자, 환경 및/또는 기타 시스템 간의 중요하거나 흥미로운 상호작용을 나타내는 몇 가지 제품 또는 시스템 사용법을 설명합니다.]

5.3               지원 제공

[이 서브섹션에서는 지원 제공 방법을 개념적으로 설명합니다(예: 지원 조직, 장비, 유지보수 주기 및 공급 방식).]

6.                  제한조건

[모든 디자인 제한조건, 외부 제한조건 또는 기타 종속성을 기록합니다.]

7.                  품질 범위

[성과, 튼튼함, 결함 허용, 사용성 및 기능 세트에서 캡처되지 않는 비슷한 특성에 대한 품질 범위 정의.]

8.                  우선순위

[다른 시스템 기능의 우선순위를 정의합니다.]

9.                  기타 제품 요구사항

[적용되는 표준, 하드웨어 또는 플랫폼 요구사항, 성능 요구사항과 환경 요구사항을 상위 레벨로 나열합니다.]

9.1               적용 표준

[제품에서 준수해야하는 모든 표준 목록을 표시합니다. 여기에는 법률 및 규제(FDA, UCC) 통신 표준(TCP/IP, ISDN), 플랫폼 준수 표준(Windows, UNIX 및 기타) 및 품질 및 안전 표준(UL, ISO, CMM)이 포함됩니다.]

9.2               시스템 요구사항

[소프트웨어 시스템 개발의 경우, 응용프로그램을 지원하는 데 필요한 시스템 요구사항을 정의합니다. 이 요구사항에는 지원되는 호스트 운영 체제 및 네트워크 플랫폼, 구성, 메모리, 주변장치와 부속 소프트웨어가 포함됩니다.]

9.3               성능 요구사항

[이 섹션을 사용하여 성능 요구사항의 세부사항을 표시합니다. 성능 문제에는 다양한 로드 조건이 적용되는 사용자 로드 요인, 대역폭 또는 통신 용량, 처리량, 정확성 및 신뢰성 또는 응답 시간이 포함됩니다.]

9.4               환경 요구사항

[환경 요구사항을 최대한 자세하게 명시해야 합니다. 실제 시스템의 경우, 환경 문제에는 온도, 충격, 습도, 방사능 등이 포함됩니다. 소프트웨어 시스템의 경우, 환경 요인에는 사용 조건, 사용자 환경, 자원 가용성, 유지보수 문제와 오류 처리 및 복구가 포함됩니다.

9.5        물리적 요구사항

[중량 또는 질량 한계나 크기 한계와 같은 물리적 요구사항이 있는 경우, 이 서브섹션에서 설명합니다.]

10.             문서 요구사항

[이 섹션은 성공적인 시스템 배치를 지원하기 위해 개발해야 하는 문서를 설명합니다.]

10.1            사용자 매뉴얼

[사용자 매뉴얼의 목적 및 컨텐츠를 설명합니다. 원하는 길이, 자세한 정도, 색인, 용어집 필요, 학습서 대 참조 매뉴얼 전략 등에 대해 논의합니다. 형식화 및 인쇄 제한조건도 식별해야 합니다.]

10.2            온라인 도움말

[대부분의 시스템은 사용자를 지원하기 위해 온라인 도움말을 제공합니다. 이러한 시스템의 성향은 프로그래밍 측면(하이퍼링크 등)을 조직 및 프리젠테이션과 같은 기술 문서 작성 관점에 결합하므로 일반적이지 않습니다. 온라인 도움말 시스템 개발이 정확한 범위 관리 및 계획 활동의 이점을 활용하는 프로젝트 내 또 다른 프로젝트임은 잘 알려져 있는 사실입니다.]

10.3            설치 안내서, 구성 및 Read Me 파일

[설치 지시사항 및 구성 가이드라인을 포함하는 문서는 전체 솔루션 제공에서 매우 중요합니다. 또는 Read Me 파일은 일반적으로 표준 컴포넌트로 포함됩니다. Read Me 파일에는 이 릴리스의 새로운 기능 섹션과 이전 릴리스의 관련된 호환성 문제에 대한 설명이 포함됩니다. 대부분의 사용자는 알려진 버그 및 임시 해결책을 Read Me 파일에 포함시키길 원합니다.]

10.4            레이블 및 패키지 처리

[최첨단 시스템은 제품 포장에서 시작하여 설치 메뉴, 스플래시 화면, 도움말 시스템, GUI 대화 상자 등을 표시하는 일관된 룩앤필을 제공합니다. 이 섹션은 시스템에 통합될 레이블링 유형과 해당 요구를 정의합니다. 예제에는 저작권 및 특허 주의사항, 회사 로고, 표준화된 아이콘 및 기타 그래픽 요소 등이 포함됩니다.]

A.          기능 속성

[기능은 구현용으로 제안된 제품 항목 평가, 트랙, 우선 순위 지정 및 관리에 사용되는 제공된 속성입니다. 모든 요구사항 유형 및 속성에 대한 개요는 요구사항 관리 계획에 설명해야 하지만 선택한 기능의 속성을 나열하고 간략하게 설명할 수도 있습니다. 이 섹션에서는 제안된 기능 속성 세트가 표시됩니다.]

A.1            상태

[협상 및 프로젝트 관리 팀 검토 후에 설정합니다. 프로젝트 기준선을 정의하는 동안 진행상태를 트랙합니다.]

제안됨

[논의 중이지만 프로젝트 팀, 제품 관리, 사용자 및 고객 커뮤니티의 대표자로 구성되는 작업 그룹과 같은 "공식 채널"에서 아직 검토 및 승인되지 않은 기능을 설명하는 데 사용됩니다.]

승인됨

[유용하고 실현 가능해 보이는 기능으로 공식 채널에서 구현 가능하다고 승인한 기능. ]

통합됨

[시간내의 특정 위치에서 제품 기준선으로 통합된 기능.]

A.2            이점

[마케팅, 제품 관리자 또는 비즈니스 분석가가 설정.] 모든 요구사항이 동일하게 작성되지는 않습니다. 사용자와 관련된 이점으로 요구사항의 등급을 산정함으로써 고객, 분석가 및 개발 팀 구성원과 대화를 시작합니다. 범위 관리 및 개발 우선순위 결정에 사용됩니다.]

핵심

[필수 기능. 구현이 실패하면 고객의 요구에 시스템이 부응하지 못한 것입니다. 릴리스 내에 핵심 기능이 구현되어야 하며, 그렇지 않으면 스케줄이 지연됩니다.]

중요

[대부분의 시스템 사용에 있어 효과 및 효율성에 중요한 기능. 기능은 다른 방식으로는 제공하기 힘듭니다. 중요 기능 포함이 결여된 경우 고객 또는 사용자 만족 또는 심지어 수입에도 치명적이지만 중요 기능이 결여된 상태라도 릴리스가 지연되지는 않습니다.]

유용함

[일반적이지 않은 사용법을 지원하는 기능은 결과적으로 자주 사용되지 않거나 효율적인 해결 방법을 얻을 수 있습니다. 해당 항목이 릴리스에 포함되지 않은 경우 많은 수입 또는 고객 만족 영향을 기대하기 힘듭니다.]

 

A.3            노력

[개발 팀이 설정합니다. 일부 기능에서는 다른 기능보다 많은 시간 및 자원을 필요로 하므로 팀 또는 사용자 기간(주) 예상이나 노력과 관련이 있는 일부 크기 측정(예: 소프트웨어의 기능 점수 또는 필요한 코드 행 수)을 통해 복잡도를 정확하게 평가하고 해당 시간 계획 안에서 수행 가능한 작업과 불가능한 않은 작업의 예상을 설정할 수 있습니다. 범위 관리 및 개발 우선순위 결정에 사용됨.]

A.4            위험성

[개발 팀이 설정하며 개연성을 기준으로 프로젝트는 비용 초과, 스케줄 지연 또는 취소와 같은 원하지 않는 이벤트를 경험하게 됩니다. 대부분의 프로젝트 관리자는 위험성을 높음, 중간, 낮음으로만 분류하지만 보다 세부적인 등급 분류도 가능합니다. 위험성은 프로젝트 팀의 예상 스케줄에 대한 불확실성(범위)을 측정하여 간접적으로 평가할 수도 있습니다.]

A.5            안정성

[분석가 및 개발 팀에서 기능의 변경 가능성 또는 기능에 대한 팀의 이해가 변경될 가능성을 기반으로 설정합니다. 개발 우선순위 설정 및 다음 조치로 추가 도출이 적당한 항목을 결정하는 데 사용됩니다.]

A.6            대상 릴리스

[기능이 처음 표시되는 계획된 제품 버전을 레코드합니다. 다음 필드는 비전 문서의 기능을 특정 기본 제품 릴리스에 할당하는데 사용됩니다. 상태 필드와 결합되어 릴리스의 다양한 기능을 개발 확약하지 않고 제안, 레코드 및 논의할 수 있습니다. 상태가 통합됨으로 설정되고 대상 릴리스가 정의된 기능만 구현됩니다. 범위 관리가 발생하면 대상 릴리스 버전 번호가 증가되어 항목은 비전 문서에 남아있지만 이후 릴리스용으로 스케줄이 정해집니다.]

A.7            지정 대상

[많은 프로젝트에 있어 기능은 요구사항에 대한 향후 도출, 캡처 및 정제와 구현을 담당하는 "기능 팀"에 지정됩니다. 단순한 풀다운 목록으로 프로젝트 팀의 모든 구성원이 책임을 더 쉽게 이해할 수 있게 도와줍니다.]

A.8            이유

[해당 텍스트 필드는 요청된 기능 소스 트랙에 사용됩니다. 요구사항은 특별한 이유로 존재합니다. 이 필드는 설명 또는 설명 참조를 레코드합니다. 예를 들어 참조는 제품 요구사항 스펙의 페이지 또는 행 번호 또는 중요한 고객 검토 비디오의 기록 마커가 될 수 있습니다. ]