대학 스포츠 페이징 시스템 요구사항 관리 계획
버전 1.0 개정 히스토리
목차
요구사항 관리 계획 1. 소개1.1 목적이
문서는 대학 스포츠 페이징 시스템(CSPS) 프로젝트에서
해당 소프트웨어 프로젝트 요구사항을 관리하기 위해 요구사항
문서, 요구사항 유형, 요구사항 속성 및 추적성을 설정하는 데
사용되는 가이드라인에 대해 설명합니다. 또한
Rational RequisitePro
요구사항 관리 도구의 구성 문서로도 사용됩니다.
1.2 범위이 계획은
프로젝트의 모든 단계(Phase)와 관련이 있습니다.
1.3 정의, 두문자어 및 약어용어집을 참조하십시오.
1.4 참조CSPS
소프트웨어 개발 계획
CSPS
개발 사례
CSPS 측정 계획 CSPS 형상 관리 계획 2. 요구사항 관리2.1 조직, 책임 및 인터페이스CSPS 소프트웨어 개발 계획을 참조하십시오.
2.2 도구, 환경 및 하부 구조Rational RequisitePro는 요구사항을 관리하는 데 사용됩니다. 하부
구조 및 환경에 대한 기타 정보는
CSPS 소프트웨어 개발 계획을 참조하십시오.
3. 요구사항 관리 프로그램3.1 요구사항 식별
3.2 추적성![]() 그림 1 - 추적성 다이어그램 FEAT 기준기능은
유스 케이스에 따라 추적합니다.
NEED 기준사용자
요구는 기능(FEAT)에 따라 추적합니다. FEAT에
따라 추적되지 않은 요구는 구현되지 않습니다.
UC 기준유스
케이스는 테스트 케이스에 따라 추적합니다.
SUPP 기준보충
스펙은 테스트 케이스에 따라 추적합니다.
3.3 속성FEAT 속성상태
프로젝트 관리 팀에서 협상 및
검토한 후 설정됩니다. 프로젝트 기준선을 정의하는 동안 진행상태 트랙.
수익성 마케팅, 제품 관리자 또는 비즈니스
분석자가 설정합니다. 모든 요구사항이 동일하게 작성되지는 않습니다.
사용자에 대한 관련 이점에 따라
요구사항의 등급을 산정하면 고객, 분석가 및
개발 팀 구성원과의 대화가 시작됩니다. 범위
관리 및 개발 우선순위 결정에 사용됩니다.
노력 개발 팀에서 설정합니다. 몇몇 기능에서는 다른 기능보다 시간 및 자원이 더 필요하기 때문에 팀 또는 노동력 주(person-week) 수 예상, 필요한 코드 라인 또는 기능점 등이 복잡도를 측정 및 주어진 시간 프레임 동안 수행 가능한 작업과 가능하지 않은 작업의 예상을 설정하는 좋은 방법입니다. 범위 관리 및 개발 우선순위 결정에 사용됩니다. 위험성 프로젝트에서 비용 초과, 스케줄 지연 또는 취소와 같은 원하지 않는 이벤트가 발생할 가능성을 기반으로 개발 팀에서 설정합니다. 대부분의 프로젝트 관리자는 위험성을 보다 세부적으로 분류할 수 있지만 높음, 중간 및 낮음으로 분류하는 것으로도 충분합니다. 위험성은 예상 프로젝트 팀 스케줄의 불확실성(범위)을 측정하여 간접적으로 평가할 수도 있습니다. 안정성 기능이 변경되거나 기능에 대한 팀의 이해가 변경될 수 있는 가능성을 기반으로 분석가 및 개발 팀에서 설정합니다. 개발 우선순위를 설정하고 올바른 다음 조치를 추가로 도출하기 위한 항목을 결정하는 데 사용됩니다. 대상 릴리스 기능이 처음 표시될 대상 제품 버전을 기록합니다. 이 필드는 비전 문서의 기능을 특정 기준선 릴리스에 할당하는 데 사용할 수 있습니다. 이 필드를 상태 필드와 결합하면 팀에서 다양한 릴리스 기능의 개발을 확약하지 않고 제안, 기록 및 논의할 수 있습니다. 상태가 통합됨으로 설정되고 대상 릴리스가 정의된 기능만 구현됩니다. 범위 관리가 발생하면 대상 릴리스 버전 번호가 증가되어 해당 항목은 비전 문서에 남아 있지만 다음 릴리스에 대해 스케줄이 지정됩니다. 담당자 대부분의 프로젝트에서는 세부 도출, 소프트웨어 요구사항 작성 및 구현을 수행하는 "기능 팀"에 기능이 지정됩니다. 이 단순한 풀다운 목록으로 프로젝트 팀의 모든 구성원이 책임을 보다 쉽게 이해할 수 있습니다. 이유 이 텍스트 필드는 요청된 기능의 소스를 추적하는 데 사용됩니다. 요구사항은 특별한 이유로 존재합니다. 이 필드는 설명 또는 설명 참조를 레코드합니다. 예를 들어, 제품 요구사항 스펙의 페이지 및 행 번호, 또는 중요한 고객 인터뷰 비디오의 기록 마커를 참조할 수 있습니다. NEED 속성상태
프로젝트 관리 팀에서 협상 및
검토한 후 설정됩니다. 프로젝트 기준선을 정의하는 동안 진행상태 트랙.
노력 개발 팀에서 설정합니다. 일부 요구는 다른 요구보다 많은 시간과 자원이 필요하므로 팀 또는 사용자 기간(주), 필요한 코드의 행 수 또는 기능 점수를 예측하는 것이 복잡도를 측정하고 해당 시간 프레임에서 달성 가능/불가능한 예상값을 설정하는 가장 좋은 방법입니다. 범위 관리 및 개발 우선순위 결정에 사용됩니다. 위험성 프로젝트에서 비용 초과, 스케줄 지연 또는 취소와 같은 원하지 않는 이벤트가 발생할 가능성을 기반으로 개발 팀에서 설정합니다. 대부분의 프로젝트 관리자는 위험성을 보다 세부적으로 분류할 수 있지만 높음, 중간 및 낮음으로 분류하는 것으로도 충분합니다. 위험성은 예상 프로젝트 팀 스케줄의 불확실성(범위)을 측정하여 간접적으로 평가할 수도 있습니다. 안정성 요구가 변경되거나 요구에 대한 팀의 이해가 변경될 수 있는 가능성을 기반으로 분석가 및 개발 팀에서 설정합니다. 개발 우선순위를 설정하고 올바른 다음 조치를 추가로 도출하기 위한 항목을 결정하는 데 사용됩니다. 대상 릴리스 요구가 처음 충족될 대상 제품 버전을 기록합니다. 이 필드는 비전 문서의 기능을 특정 기준선 릴리스에 할당하는 데 사용할 수 있습니다. 이 필드를 상태 필드와 결합하면 팀에서 다양한 릴리스 기능의 개발을 확약하지 않고 제안, 기록 및 논의할 수 있습니다. 상태가 통합됨으로 설정되고 대상 릴리스가 정의된 요구만 충족됩니다. 범위 관리가 발생하면 대상 릴리스 버전 번호가 증가되어 해당 항목은 비전 문서에 남아 있지만 다음 릴리스에 대해 스케줄이 지정됩니다. 이유 이 텍스트 필드는 요구사항의 소스를 추적하는 데 사용됩니다. 요구사항은 특별한 이유로 존재합니다. 이 필드는 설명 또는 설명 참조를 레코드합니다. 예를 들어, 제품 요구사항 스펙의 페이지 및 행 번호, 또는 중요한 고객 인터뷰 비디오의 기록 마커를 참조할 수 있습니다. UC 속성프로젝트 관리 팀에서 협상 및
검토한 후 설정됩니다. 프로젝트 기준선을 정의하는 동안 진행상태 트랙.
수익성 마케팅, 제품 관리자 또는 비즈니스
분석자가 설정합니다. 모든 요구사항이 동일하게 작성되지는 않습니다.
사용자에 대한 관련 이점에 따라 유스
케이스의 등급을 산정하면 고객, 분석가 및
개발 팀 구성원과의 대화가 시작됩니다. 범위
관리 및 개발 우선순위 결정에 사용됩니다.
노력 개발 팀에서 설정합니다. 일부 유스 케이스의 경우 다른 유스 케이스보다 많은 시간과 자원이 필요하므로 팀 또는 사용자 기간(주), 필요한 코드의 행 수 또는 기능 점수를 예측하는 것이 복잡도를 측정하고 해당 시간 프레임에서 달성 가능/불가능한 예상값을 설정하는 가장 좋은 방법입니다. 범위 관리 및 개발 우선순위 결정에 사용됩니다. 위험성 프로젝트에서 비용 초과, 스케줄 지연 또는 취소와 같은 원하지 않는 이벤트가 발생할 가능성을 기반으로 개발 팀에서 설정합니다. 대부분의 프로젝트 관리자는 위험성을 보다 세부적으로 분류할 수 있지만 높음, 중간 및 낮음으로 분류하는 것으로도 충분합니다. 위험성은 예상 프로젝트 팀 스케줄의 불확실성(범위)을 측정하여 간접적으로 평가할 수도 있습니다. 안정성 유스 케이스가 변경되거나 유스 케이스에 대한 팀의 이해가 변경될 수 있는 가능성을 기반으로 분석가 및 개발 팀에서 설정합니다. 개발 우선순위를 설정하고 올바른 다음 조치를 추가로 도출하기 위한 항목을 결정하는 데 사용됩니다. 대상 릴리스 유스 케이스가 처음 표시될 대상 제품 버전을 기록합니다. 이 필드는 유스 케이스 조사 문서의 유스 케이스를 특정 기준선 릴리스에 할당하는 데 사용할 수 있습니다. 이 필드를 상태 필드와 결합하면 팀에서 다양한 릴리스 유스 케이스의 개발을 확약하지 않고 제안, 기록 및 논의할 수 있습니다. 상태가 통합됨으로 설정되고 대상 릴리스가 정의된 유스 케이스만 구현됩니다. 범위 관리가 발생하면 대상 릴리스 버전 번호가 증가되어 해당 항목은 비전 문서에 남아 있지만 다음 릴리스에 대해 스케줄이 지정됩니다. 담당자 대부분의 프로젝트에서는 세부 도출, 소프트웨어 요구사항 작성 및 구현을 수행하는 팀에 유스 케이스가 지정됩니다. 이 단순한 풀다운 목록으로 프로젝트 팀의 모든 구성원이 책임을 보다 쉽게 이해할 수 있습니다. 이유 이 텍스트 필드는 요청된 유스 케이스의 소스를 추적하는 데 사용됩니다. 요구사항은 특별한 이유로 존재합니다. 이 필드는 설명 또는 설명 참조를 레코드합니다. 예를 들어, 제품 요구사항 스펙의 페이지 및 행 번호, 또는 중요한 고객 인터뷰 비디오의 기록 마커를 참조할 수 있습니다. SUPP 속성상태
프로젝트 관리 팀에서 협상 및
검토한 후 설정됩니다. 프로젝트 기준선을 정의하는 동안 진행상태 트랙.
수익성 마케팅, 제품 관리자 또는 비즈니스
분석자가 설정합니다. 모든 요구사항이 동일하게 작성되지는 않습니다.
사용자에 대한 관련 이점에 따라
요구사항의 등급을 산정하면 고객, 분석가 및
개발 팀 구성원과의 대화가 시작됩니다. 범위
관리 및 개발 우선순위 결정에 사용됩니다.
노력 개발 팀에서 설정합니다. 일부 스펙의 경우 다른 스펙보다 많은 시간과 자원이 필요하므로 팀 또는 사용자 기간(주), 필요한 코드의 행 수 또는 기능 점수를 예측하는 것이 복잡도를 측정하고 해당 시간 프레임에서 달성 가능/불가능한 예상값을 설정하는 가장 좋은 방법입니다. 범위 관리 및 개발 우선순위 결정에 사용됩니다. 위험성 프로젝트에서 비용 초과, 스케줄 지연 또는 취소와 같은 원하지 않는 이벤트가 발생할 가능성을 기반으로 개발 팀에서 설정합니다. 대부분의 프로젝트 관리자는 위험성을 보다 세부적으로 분류할 수 있지만 높음, 중간 및 낮음으로 분류하는 것으로도 충분합니다. 위험성은 예상 프로젝트 팀 스케줄의 불확실성(범위)을 측정하여 간접적으로 평가할 수도 있습니다. 안정성 스펙이 변경되거나 스펙에 대한 팀의 이해가 변경될 수 있는 가능성을 기반으로 분석가 및 개발 팀에서 설정합니다. 개발 우선순위를 설정하고 올바른 다음 조치를 추가로 도출하기 위한 항목을 결정하는 데 사용됩니다. 대상 릴리스 지정된 속성 또는 기능이 처음 표시될 대상 제품 버전을 기록합니다. 이 필드는 특정 기준선 릴리스에 스펙을 할당하는 데 사용할 수 있습니다. 이 필드를 상태 필드와 결합하면 팀에서 다양한 릴리스 스펙의 개발을 확약하지 않고 제안, 기록 및 논의할 수 있습니다. 상태가 통합됨으로 설정되고 대상 릴리스가 정의된 스펙만 구현됩니다. 범위 관리가 발생하면 대상 릴리스 버전 번호가 증가되어 해당 항목은 보충 스펙 문서에 남아 있지만 다음 릴리스에 대해 스케줄이 지정됩니다. 담당자 대부분의 프로젝트에서는 세부 도출, 소프트웨어 요구사항 작성 및 구현을 수행하는 팀에 지정된 속성 또는 기능이 지정됩니다. 이 단순한 풀다운 목록으로 프로젝트 팀의 모든 구성원이 책임을 보다 쉽게 이해할 수 있습니다. 3.4 보고서 및 측정CSPS 측정 계획을 참조하십시오.
3.5 요구사항 변경 관리CSPS
형상 관리 계획을 참조하십시오.
다음 액세스 그룹은 Rational
RequisitePro의 요구사항에 대한 액세스를 제어하기 위해 설정됩니다.
- 도구 관리자 - 모든 도구 파트에 대한 전체 액세스 권한을 갖습니다. 사용자를 추가 및 제거하고 해당 액세스 권한을 변경할 수 있습니다. - 작성자 - 새 요구사항을 작성할 수 있습니다. - 프로젝트 관리자 - 요구사항 상태를 설정합니다. - Tester_QA - 테스트 케이스 요구사항의 상태를 설정합니다. 3.6 워크플로우 및 활동CSPS 개발 사례를 참조하십시오.
4. 이정표CSPS 소프트웨어 개발 계획을 참조하십시오.
5. 훈련 및 자원CSPS 소프트웨어 개발 계획을 참조하십시오.
|
Rational Unified Process
|