Wylie College

요구사항 관리 계획

 

버전 2.0

 

 

개정 히스토리

날짜

버전

설명

작성자

1999년 1월 8일

1.0

초기 릴리스

Simon Jones

1999년 2월 10일

2.0 

계획 확장 

 Simon Jones

 
 
 
 
 
 
 
 

 


목차

1.     소개  

1.1      목적  

1.2      범위  

1.3      용어의 정의  

1.4      참조  

2.     요구사항 관리

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

2.2      도구, 환경 및 하부 구조  

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

3.1      요구사항 식별  

3.2      추적성  

3.2.1     제품 요구사항 기준

3.2.2     유스 케이스 요구사항 기준

3.2.3     테스트 케이스 기준

3.3      속성  

3.3.1      유스 케이스 요구사항에 대한 속성

3.3.2     테스트 케이스에 대한 속성

3.4      보고서 및 척도  

3.5      요구사항 변경 관리

3.6      원칙 및 타스크  

4.     이정표  

5.     훈련 및 자원  


요구사항 관리 계획

1.                  소개

1.1               목적

요구사항 속성 가이드라인은 Wylie College의 모든 소프트웨어 프로젝트에 대한 요구사항을 관리하는 데 사용될 속성을 알아보고 이를 설명합니다. 또한 이 문서는 개발 중 프로젝트에 대해 유지보수될 요구사항 추적성에 대해 설명합니다.

각 요구사항에 지정된 속성은 소프트웨어 개발을 관리하고 각 릴리스의 기능에 대한 우선순위를 결정하는 데 사용됩니다.

요구사항 추적성의 목표는 개발 주기 후반부에서 발견되는 결함의 수를 줄이는 것입니다. 모든 제품 요구사항이 소프트웨어 요구사항, 디자인 및 테스트 케이스에 포함되도록 함으로써 제품의 품질을 향상시킵니다.

1.2            범위

이 문서의 속성 및 추적성 가이드라인은 모든 Wylie College 소프트웨어 프로젝트에 대한 제품 요구사항, 소프트웨어 요구사항 및 테스트 요구사항에 적용됩니다.

1.3                용어의 정의

Rational Unified Process 및 Rational RequisitePro 문서에 정의된 용어를 사용합니다.

1.4                참조

다음 참조 사항은 Wylie College 소프트웨어 프로세스 웹 사이트에 있습니다.

1. Wylie College 형상 관리 계획
2. Rational Unified Process
3. Wylie College 개발 사례

2.                  요구사항 관리

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

개별 프로젝트의 소프트웨어 개발 계획을 참조하십시오.

2.2                도구, 환경 및 하구 구조

요구사항 속성 및 추적성을 관리하는 데는 Rational RequisitePro가 사용됩니다. 기타 하부 구조 세부사항은 Wylie College 소프트웨어 프로세스 웹 사이트를 참조하십시오.

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

3.1                요구사항 식별

각 프로젝트는 다음 요구사항 유형을 식별하고 관리합니다.

 

중간 산출물

 

요구사항 유형

설명

비전

제품 요구사항

제품 기능, 제한조건, 품질 범위 및 기타 제품 요구사항

유스 케이스 모델

유스 케이스

Rational Rose에서 설명하는 유스 케이스

테스트 계획

테스트 케이스

시스템이 예상대로 작동하는지 검증하는 방법에 대해 설명하는 사례

 

3.2                추적성

3.2.1     제품 요구사항 기준

비전 문서에 정의된 제품 요구사항은 유스 케이스 명세 및 보충 스펙의 해당 유스 케이스 또는 보충 요구사항을 따릅니다.

각 제품 요구사항은 하나 이상의 유스 케이스 요구사항 및 보충 요구사항을 따릅니다.

각 제품 요구사항은 하나 이상의 유스 케이스 요구사항 및 보충 요구사항을 따릅니다.

3.2.2     유스 케이스 요구사항 기준

유스 케이스 명세 및 보충 스펙에 정의된 유스 케이스 요구사항은 테스트 계획에 지정된 해당 테스트 케이스를 따릅니다.

각 유스 케이스 요구사항은 하나 이상의 시스템 테스트 케이스를 따릅니다.

3.2.3     테스트 케이스 기준

테스트 계획에 지정된 테스트 케이스는 다시 제품 요구사항(비전 참조) 및 특정 테스트 케이스에서 검증하는 유스 케이스 요구사항을 따릅니다.

테스트 케이스는 다시 하나 이상의 제품 및 유스 케이스 요구사항을 따를 수 있습니다. 테스트 케이스에서 파생된 요구사항 또는 디자인을 검증하는 경우 테스트 케이스에는 원래 제품 요구사항 또는 유스 케이스 요구사항에 대한 추적성이 없을 수 있습니다.

3.3                속성

3.3.1      유스 케이스 요구사항에 대한 속성

유스 케이스 요구사항 및 보충 스펙은 이 섹션에 정의된 속성을 사용하여 관리됩니다. 이러한 속성은 개발 노력 관리, 반복 컨텐츠 판별 및 유스 케이스와 해당 특정 Rose 모델과의 연관에 유용합니다.

상태

분석을 통해 유스 케이스 초안을 작성한 후 설정됩니다. 유스 케이스 초안 작성에서 최종 유효성 검증까지 유스 케이스 개발 진행상태를 추적합니다.

제안됨

식별되었으나 아직 검토 및 승인되지 않은 유스 케이스

승인됨

승인되어 앞으로 디자인 및 구현을 수행해야 하는 유스 케이스

유효성이 검증됨

시스템 테스트에서 유효성이 검증된 유스 케이스

우선순위

프로젝트 관리자가 설정합니다. 유스 케이스에 대한 개발 자원 배정 및 유스 케이스 개발 진행상태의 모니터링에 대한 중요성 관점에서 유스 케이스의 우선순위를 결정합니다. 우선순위는 일반적으로 인지된 사용자 이점, 계획된 릴리스, 계획된 반복, 유스 케이스의 복잡도(위험성) 및 유스 케이스 구현 노력을 기반으로 합니다.

높음

유스 케이스의 우선순위가 높아 유스 케이스 구현을 면밀히 모니터하고 자원이 타스크에 적절히 배정됩니다.

중간

유스 케이스의 우선순위가 다른 유스 케이스에 비해 중간 정도입니다.

낮음

유스 케이스의 우선순위가 낮습니다. 이 유스 케이스의 구현은 그다지 중요하지 않으므로 후속 반복 또는 릴리스로 교체되거나 재계획됩니다.

예상 노력

개발 팀에서 설정합니다. 유스 케이스에 따라 다른 유스 케이스보다 많은 시간과 자원을 필요로 하므로 팀 또는 사용자 기간(주), 필요한 코드의 행 수 또는 기능 점수를 예측하는 것이 복잡도를 측정하고 해당 시간 프레임에서 달성 가능/불가능한 예상값을 설정하는 가장 좋은 방법입니다. 범위 관리 및 개발 우선순위 결정에 사용됩니다. 프로젝트 관리자는 이러한 예상 노력을 사용하여 프로젝트 스케줄을 결정하고 타스크 자원 계획을 효과적으로 수행합니다.

력을 인일(person days) 단위로 예측합니다(하루 작업 시간을 7.5시간으로 가정).

기법 위험성

유스 케이스에서 노력 초과, 디자인 결함, 많은 수의 결함, 품질 저하, 성능 저하와 같은 원하지 않은 이벤트가 발생할 가능성을 기반으로 개발 팀에서 설정합니다. 이러한 원하지 않는 이벤트는 일반적으로 정의된 요구사항을 잘못 이해했거나 관련 지식이 충분하지 않거나 자원이 부족하거나 기술이 복잡하거나 신기술, 새 도구 또는 새 장비 사용에 따른 결과입니다.

Wylie College 프로젝트는 각 유스 케이스의 기술 위험성을 높음, 중간 또는 낮음으로 분류합니다.

높음

위험성 발생 가능성과 해당 위험성에 따른 영향이 모두 높습니다.

중간

위험성에 따른 영향이 그다지 심각하지 않거나 위험성 발생 가능성이 낮습니다. 또는 두 가지 경우에 모두 해당합니다.

낮음

위험성에 따른 영향이 가장 적으며 위험성 발생 가능성이 낮습니다.

대상 개발 반복

유스 케이스가 구현될 개발 반복을 기록합니다. 각 릴리스에 대한 개발은 프로젝트 구현/구축(Construction) 단계에서 여러 개발 반복에 걸쳐 수행됩니다.

각 유스 케이스에 배정된 반복 번호는 프로젝트 관리자가 프로젝트 팀의 활동을 계획하는 데 사용합니다.

가능한 값의 양식은 <letter>-<iteration number>입니다. 여기서, letter는 각각 도입/인식(Inception), 정제(Elaboration), 구현/구축(Construction) 및 전이(Transition)를 나타내는 문자 I, E, C 및 T입니다. 예를 들어, 다음과 같습니다.

 E-1

정제 단계, 반복 1에 대해 계획됨

C-1

구현/구축 단계, 반복 1에 대해 계획됨

C-2

구현/구축 단계, 반복 2에 대해 계획됨

C-3

구현/구축 단계, 반복 3에 대해 계획됨

지정 대상

유스 케이스는 추가 분석, 디자인 및 구현을 위해 개인 또는 개발 팀에 배정됩니다. 프로젝트 팀의 모든 구성원이 해당 책임을 보다 잘 이해할 수 있도록 간단한 풀다운 목록이 제공됩니다.

Rational Rose 모델

유스 케이스 요구사항과 연관된 Rose 유스 케이스 모델을 식별합니다.

3.3.2     테스트 케이스에 대한 속성

테스트 상태

테스트 리더가 설정합니다. 각 테스트 케이스의 상태를 추적합니다.

테스트되지 않음

테스트 케이스가 수행되지 않았습니다.

실패

테스트가 수행되었지만 실패했습니다.

조건부 패스

테스트가 완료되었지만 문제점이 있습니다. 테스트 결과 특정 조치 완료를 조건으로 패스 상태를 지정했습니다.

패스

테스트가 완료되었습니다.

빌드 번호

특정 테스트 케이스가 검증될 시스템 빌드를 기록합니다.

테스터

테스트 케이스를 수행하고 검증하기 위해 배정된 개인. 프로젝트 팀의 모든 구성원이 해당 책임을 보다 잘 이해할 수 있도록 간단한 풀다운 목록이 제공됩니다.

테스트 날짜

계획된 테스트 날짜 또는 실제 테스트 날짜

테스트 참조사항

테스트 계획 또는 실행과 연관된 모든 참고사항

3.4                보고서 및 척도

TBD

3.5                요구사항 변경 관리

Wylie College 형상 관리 계획을 참조하십시오.

3.6               원칙 및 타스크

Wylie College 개발 사례를 참조하십시오.

4.                  이정표

각 프로젝트의 소프트웨어 개발 계획에서 설명합니다.

5.                  훈련 및 자원

각 프로젝트의 소프트웨어 개발 계획에서 설명합니다.