가이드라인: 요구사항 관리 계획
요구사항 관리 계획에서는 주로 이해 당사자 관계 및 해당 책임, 추적성 항목, 요구사항 변경 관리 및 요구사항 관련 보고서와 척도를 정의합니다. 이 가이드라인은 완전하고 효과적인 요구사항 관리 계획을 개발하는 데 도움이 됩니다.
관계
기본 설명

기타 계획과의 관계

요구사항 관리 계획은 어느 정도 범위 내에서 다른 계획이 다룰 수 있는 정보를 포함합니다.

사용자 조정 안내에 대한 정보는 중간 산출물: 요구사항 관리 계획, 사용자 조정을 참조하십시오.

조직, 책임 및 인터페이스

백서: 유스 케이스로 요구사항 관리 적용에서 설명한 대로, 요구사항 관리는 프로젝트를 성공으로 이끄는 데 중요한 역할을 합니다. 가장 흔한 프로젝트 실패 원인은 다음과 같습니다.

  • 사용자 입력 부족
  • 불완전한 요구사항
  • 변경되는 요구사항

요구사항 오류 역시 가장 일반적인 오류 클래스에 해당될 수 있습니다. 이 오류는 수정 비용이 가장 높습니다.

이해 당사자와 올바른 관계를 맺으면 이 문제점을 해결하는 데 도움이 될 수 있습니다. 이해 당사자는 요구사항을 정의하고 요구사항의 우선순위를 이해하는 데 필요한 입력의 주요 소스입니다. 그러나 많은 이해 당사자가 요청된 기능의 비용 및 스케줄 영향에 대한 통찰력이 결여되어 있습니다. 따라서 개발 조직에서는 이해 당사자의 예상을 관리해야 합니다.

이해 당사자와 관계를 맺으면 다음 사항이 정의됩니다.

  • 이해 당사자 책임: 현장에 상의할 수 있는 직원이 있습니까? 시간이 예정되어 있습니까?
  • 프로젝트 중간 산출물에 대한 이해 당사자의 가시성: 모든 중간 산출물에 대한 가시성이 개방적입니까? 계획된 이정표에서만 가시성이 개방적입니까?

추적성 항목 식별

추적성 항목을 설명하고 이름 지정, 표시 및 번호 지정 방법을 정의하십시오. 개념: 요구사항 유형개념: 추적성을 참조하십시오.

가장 중요한 추적성 항목은 타스크: 요구사항 관리 계획 개발에 나열되어 있습니다.

추적성 지정

핵심적인 중간 산출물의 제한된 세트를 포함하는 일반적인 추적성은 타스크: 요구사항 관리 계획 개발을 참조하십시오.

추적성 링크를 식별할 뿐만 아니라 링크의 카디널리티를 지정해야 합니다. 다음은 몇 가지 공통 제한조건입니다.

  • 승인된 모든 제품 기능은 하나 이상의 보충 요구사항, 하나 이상의 유스 케이스 또는 둘 다와 링크되어야 합니다.
  • 모든 보충 요구사항 및 각 유스 케이스 섹션은 하나 이상의 테스트 케이스에 링크되어야 합니다.

추적성에 대한 자세한 논의는 백서 유스 케이스로 요구사항을 관리하는 추적성 전략에서 제공합니다.

샘플 속성

다음은 타스크: 요구사항 관리 계획 개발에서 식별된 요구사항 유형을 사용하여 구성된, 사용자가 선택할 수도 있는 몇 가지 예제 속성입니다.

이해 당사자 요구

소스: 요구사항을 말한 이해 당사자. "이해 당사자" 추적성 항목에 대한 추적성으로 구현할 수도 있습니다.

기여도: 프로젝트에서 처리하는 문제점 또는 전반적인 비즈니스 기회에 대한 문제점 기여도를 표시합니다. 백분율(0 - 100%). 모든 기여도의 합계는 100%를 초과할 수 없습니다. 다음은 여러 이해 당사자의 모든 요구에 대한 기여도를 표시하는 파레토 다이어그램 예제입니다.

전반적인 비즈니스 기회에 대해 문제점 다섯 개의 상대적인 영향을 표시한 그래프

기능, 보충 요구사항 및 유스 케이스

상태: "공식적인 채널"에서 요구사항을 검토 및 허용하는지 여부를 표시합니다. 예제 값으로 제안, 거부, 허용이 있습니다.

계약 상태 또는 구속력이 있는 결정을 내릴 수 있는 작업 그룹에서 설정한 상태일 수 있습니다.

이점: 이해 당사자 시점의 중요성

  • 핵심(또는 기본). 시스템의 기본 타스크, 기본 기능 및 개발 중인 기능과 관련이 있습니다. 누락된 경우 시스템은 기본 미션을 달성하지 못합니다. 아키텍처 디자인을 유도하고 가장 자주 연습한 유스 케이스일 가능성이 놓습니다.
  • 중요(또는 보조). 시스템 기능(예: 통계 데이터 컴파일, 보고서 생성, 감독 및 기능 테스트) 지원과 관련이 있습니다. 누락된 경우 계속(한동안) 기본 미션은 달성할 수 있지만 서비스 품질이 떨어집니다. 모델링 시 핵심 유스 케이스보다 중요도가 더 떨어집니다.
  • 유용(선택사항). "편안한" 기능으로 시스템의 기본 미션과는 링크되어 있지 않지만 사용 또는 시장 위치 지정에 도움이 됩니다.

노력: 요구사항을 구현하기 위한 예상 노력 일

예를 들어 낮음, 중간, 높음과 같은 카테고리일 수 있습니다. 즉, 낮음 = < 1일, 중간 = 1 - 20일, 높음 = > 20일.

노력을 정의하면서 예상에 포함된 오버헤드(관리 노력, 테스트 노력, 요구사항 노력 등)를 명확히 표시해야 합니다.

크기: 주석이 없는 예상 소스 코드 라인 수(SLOC)(테스트 코드 제외)

예상 비용을 더 잘 계산하기 위해 재사용 및 새 SLOC 사이를 구별하려고 합니다.

위험성: 요구사항의 구현에서 원치 않는 중요한 이벤트(스케줄 일탈, 비용 초과 또는 취소)가 발생할 가능성(%).

예를 들어 낮음, 중간, 높음과 같은 카테고리일 수 있습니다. 즉, 낮음 = <10%, 중간 = 10 - 50%, 높음 = > 50%.

위험성의 또 다른 옵션에서 기술 위험성을 별도로 추적 - 도메인 및/또는 필요한 기술의 경험 부족으로 요구사항을 구현하는 데 심각한 어려움이 발생할 가능성(%). 그러면 기타 속성에 기반하여 가중치를 정한 합계로 전반적인 위험성(크기, 노력, 안정성, 기술 위험성, 아키텍처 영향 및 조직 복잡도 포함)을 계산할 수 있습니다.

조직 복잡도: 요구사항을 개발하는 조직에 대한 제어의 카테고리.

  • 내부: 한 사이트에서 자체 개발
  • 지리적: 지리적으로 분산된 팀
  • 외부: 회사의 외부 조직   
  • 벤더: 외부에서 개발된 소프트웨어의 구매 및 하청

아키텍처 영향: 이 요구사항이 소프트웨어 아키텍처에 주는 영향을 표시합니다.

  • 없음: 기존 아키텍처에 영향을 주지 않습니다.
  • 확장: 기존 아키텍처를 확장해야 합니다.
  • 수정: 요구사항에 맞게 기존 아키텍처를 변경해야 합니다.   

안정성: 이 요구사항이 변경되거나 요구사항을 이해하는 개발 팀이 변경되는 가능성. (> 50% = 높음, 10..50% = 중간, < 10% = 낮음)

목표 릴리스: 요구사항을 충족시키는 제품 릴리스 계획. (Release1, Release1.1, Release2, ...)

위험 레벨/심각성: 일반적으로 필요한 경우 소프트웨어를 수행하는 데 실패한 결과, 건강, 복지 또는 경제적 결과에 주는 영향.

  • 무시: 중대한 상해 또는 장비 손상이 발생하지는 않았습니다.
  • 최소: 상해 또는 주요 시스템 손상없이 제어할 수 있습니다.
  • 심각: 상해 또는 주요 시스템 손상이 발생할 수 있거나 직원의 생존 또는 시스템 복구를 위해 즉각적으로 정정 조치를 취해야 합니다.
  • 치명: 심각한 상해 또는 사망으로 이어지거나 시스템을 완전히 유실할 수 있습니다.

위험은 별도의 요구사항 유형으로도 식별되어 유스 케이스와 링크될 수 있습니다. 위험 가능성, 정정 조치 및/또는 예방 조치를 추적할 수 있습니다.

해석: 때때로 요구사항이 정규 계약으로 구성된 경우 요구사항의 표현 변경이 어렵고 비용이 많이 들 수 있습니다. 개발 조직이 요구사항을 더 잘 이해하려면 요구사항의 공식적인 표현을 단순히 변경하기보다 해석 텍스트를 첨부해야 할 수도 있습니다.

유스 케이스

위의 항목 이외에도 다음 유스 케이스 속성을 추적하는 데 유용합니다.

세부사항 %: 유스 케이스 정제 정도:

  • 10%: 기본 설명이 제공됩니다.
  • 50%: 기본 플로우가 문서화됩니다.
  • 80%: 완료되었지만 검토하지는 않았습니다. 모든 전제 조건 및 사후 조건이 모두 지정되었습니다.
  • 100%: 검토 및 승인되었습니다.

테스트 케이스

상태: 테스트 개발 중 트랙 진행상태

  • 활동 없음: 이 테스트 케이스를 개발하는 중 작업을 수행하지 않았습니다.
  • 수동: 수동 스크립트를 작성하여 연관된 요구사항을 검증할 수 있는지 유효성을 검증합니다.
  • 자동: 자동 스크립트를 작성하여 연관된 요구사항을 검증할 수 있는지 유효성을 검증합니다.

일반 속성

다음은 일반 적용 가능성을 포함한 일부 기타 요구사항 속성입니다.

  • 계획된 반복
  • 실제 반복
  • 책임자

속성 선택

속성을 사용하여 보통 상태 및 보고 목적으로 추적성 항목과 연관된 정보를 추적합니다. 각 조직에서는 조직에 고유한 특정 추적 정보가 필요할 수 있습니다. 속성을 지정하기 전에 다음을 고려해야 합니다.

  • 이 정보의 제공자는 누구입니까?
  • 이 정보의 사용자는 누구이며 정보가 왜 유용합니까?
  • 이 정보를 추적하는 데 드는 비용이 그만큼의 가치가 있습니까?

범위 관리에 대한 요구사항의 우선순위 지정을 허용하고 요구사항을 반복에 지정하기 위해 추적할 핵심 속성은 위험성, 이점, 노력, 안정성아키텍처 영향입니다. 처음에는 기능에서 추적하고 나중에는 모든 유스 케이스 및 보충 요구사항에서 추적해야 합니다.

파생 정보 고려

요구사항 속성을 직접 사용할 뿐만 아니라 다른 요구사항 유형의 추적성을 통해 이 요구사항 속성에서 정보를 도출할 수 있습니다. 다음은 몇 가지 일반적인 파생 패턴입니다.

  • 하향 파생 - 위의 추적성을 고려할 때 제품 기능에 "목표 릴리스" 속성이 있다고 가정해 보십시오. 이 제품 기능에서 추적한 각 유스 케이스 섹션은 지정된 목표 릴리스 및 이전에 사용 가능해야 한다는 내용을 도출할 수 있습니다.
  • 상향 파생 - 위의 추적성을 고려할 때 유스 케이스 섹션에 "예상 노력" 속성이 있다고 가정해 보십시오. 제품 기능의 비용은 추적하는 유스 케이스 섹션에서 예상 노력을 합하여 예상될 수 있습니다. 여러 제품 기능이 동일한 유스 케이스 섹션에 맵핑될 수 있으므로 주의하여 사용해야 합니다.

따라서 요구사항 속성을 요구사항 유형에 지정하려면 다음을 고려해야 합니다.

  • 이 속성에서 생성하려는 파생 정보/보고서는 무엇입니까?
  • 이 속성을 추적해야 하는 추적성 계층 구조의 레벨은 무엇입니까?

속성의 종속성

일부 속성은 특정 개발 레벨에만 적용 가능합니다. 예를 들어 유스 케이스의 예상 노력 속성은 유스 케이스가 디자인에서 완전히 표시되면 디자인 요소의 예상 노력으로 바뀔 수 있습니다.

보고서 및 척도

다음은 요구사항 관련 보고서 및 척도에 대한 예제입니다. 프로젝트의 필수/희망 보고서 및 척도 세트를 선택하여 요구사항 관리 계획의 필수 속성을 도출할 수 있습니다.

보고서/측정 설명 사용 목적
유스 케이스의 개발 우선순위(위험성, 이점, 노력, 안정성 및 아키텍처 영향별로 정렬한 유스 케이스 목록). 별도로 정렬된 목록이거나 이 속성의 가중치를 조합하여 정렬한 단일 목록일 수 있습니다. 타스크: 유스 케이스 우선순위 지정에서 사용하십시오.
각 상태 카테고리의 기능 백분율 프로젝트 기준선을 정의하는 동안 진행상태 트랙
 - 목표 릴리스별로 분류  - 릴리스를 기초로 진행상태 트랙
 - 노력별로 가중치 설정  - 보다 정확한 진행상태 척도 제공
위험성별로 정렬된 기능  - 위험한 기능을 식별합니다. 범위 관리 및 반복에 기능을 지정하는 경우 유용합니다.
 - 각 목표 릴리스에서 요약한 개발 위험성과 함께 목표 릴리스별로 분류됩니다.  - 위험성 기능이 프로젝트에서 계획된 시기(초반 또는 후반)를 평가하는 데 유용합니다.
안정성별로 정렬된 유스 케이스 섹션  - 안정시켜야 하는 유스 케이스 섹션을 결정하는 데 사용됩니다.
 - 아키텍처 영향별로 가중치 설정  - 먼저 안정시켜야 하는 중요한 구조 및/또는 높은 노력의 유스 케이스에서 우선순위를 지정하는 데 유용합니다.
정의되지 않은 속성을 사용하는 요구사항 요구사항을 먼저 제공하는 경우 모든 속성을 즉시 지정하지 못할 수도 있습니다(예: "정의되지 않은" 기본값 사용). 체크리스트: 소프트웨어 요구사항 스펙에서는 이 보고서를 사용하여 이와 같이 정의되지 않은 속성을 확인합니다.
불완전한 추적성 링크를 사용하는 추적성 항목 올바르지 않거나 불완전한 추적성 링크의 보고서는 체크리스트: 소프트웨어 요구사항 스펙에서 사용됩니다.

요구사항 변경 관리 페이지 맨 위

변경이 불가피하므로 변경을 계획해야 합니다. 다음 이유로 변경이 발생합니다.

  • 문제점을 해결하기 위해 필요한 변경. 새 규정, 경제적 억압, 기술 변경 등의 이유로 변경될 수 있습니다.
  • 이해 당사자가 시스템에서 수행할 작업에 대한 생각 또는 이해를 바꾼 경우. 담당 직원 변경, 문제에 대한 깊은 이해 등을 포함하여 다양한 이유로 변경될 수 있습니다.
  • 원래 요구사항을 정의할 때 모든 이해 당사자를 포함하는 데 실패하거나 모든 올바른 질문을 하는 데 실패하는 경우

요구사항 변경을 관리하는 전략은 다음과 같습니다.

  • 요구사항 기준선 작성
  • 변경 제어를 위한 단일 채널 설정
  • 변경 히스토리 유지보수

요구사항 기준선 작성 페이지 맨 위

정제 단계의 마지막에 가면 시스템 분석가가 알려진 모든 요구사항의 기준선을 설정해야 합니다. 보통 요구사항 중간 산출물에 대한 버전 제어가 있는지 확인하고 기준선을 구성하는 중간 산출물 세트 및 해당 버전을 식별하여 수행됩니다.

기준선의 목적은 요구사항을 동결시키지 않는 것입니다. 다소 새 요구사항 및 수정된 요구사항을 식별, 통신, 예상 및 제어할 수 있습니다.

또한 도구 사용 도움말: Rational RequisitePro 프로젝트 도구 기본을 참조하십시오.

변경 제어를 위한 단일 채널 설정

변경에 대한 이해 당사자의 희망이 예산 및 스케줄을 공식적으로 변경한다고 가정할 수 없습니다. 보통 변경을 승인하기 전에 협상 또는 예산 조정 프로세스를 시작해야 합니다. 종종 변경은 서로 밸런스를 맞춰야 합니다.

모든 변경이 단일 경로(변화 제어 위원회(CCB))로 이동하여 시스템에 대한 영향을 판별하고 공식 승인을 받아야 합니다. 변경을 제안하는 메커니즘은 CCB에서 검토변경 요청제출하는 것입니다.

추가 정보는 타스크: 변경 제어 프로세스 설정을 참조하십시오.

변경 히스토리 유지보수

개별 요구사항에 대한 변경의 감사 단서를 유지보수하는 것이 좋습니다. 이 변경 히스토리에서는 요구사항의 모든 이전 변경사항 및 속성 값의 변경, 변경 근거를 볼 수 있습니다. 요구사항의 실제 안정성을 평가하고 변경 제외 프로세스가 작동하지 않는 경우를 식별하는 데 유용할 수 있습니다(예: 적절하게 검토되거나 승인되지 않은 요구사항 변경 정의).