대학 스포츠 페이징 시스템

요구사항 관리 계획
 
 

버전 1.0


 



 
 

개정 히스토리


날짜
버전
설명
작성자
2000년 7월 2일
1.0
초기 릴리스
Context Integration


목차
 
 

1.소개

1.1목적

1.2범위

1.3정의, 두문자어 및 약어

1.4참조

2.요구사항 관리

2.1조직, 책임 및 인터페이스

2.2도구, 환경 및 하부 구조

3.요구사항 관리 프로그램

3.1요구사항 식별

3.2추적성

FEAT 기준

NEED 기준

UC 기준

SUPP 기준

3.3속성

FEAT 속성

NEED 속성

UC 속성

SUPP 속성

3.4 보고서 및 측정

3.5요구사항 변경 관리

3.6       워크플로우 및 활동

4.이정표

5.훈련 및 자원
 


요구사항 관리 계획

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 요구사항 식별

 
아티팩트(문서 유형)
요구사항 유형
설명
비전(VIS)
이해 당사자 요구(NEED)
중요 이해 당사자 또는 사용자 요구
비전(VIS)
기능(FEAT)
시스템의 해당 릴리스 조건 또는 기능
유스 케이스 모델
유스 케이스(UC)
Rational Rose에서 설명하는 이 릴리스에 대한 유스 케이스와 Rational RequisitePro의 세부사항
보충 스펙(SS)
보충 요구사항(SUPP)
유스 케이스 모델 에서 캡처되지 않는 비기능적 요구사항
표 3.1-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