주제

기타 계획과의 관계 페이지 맨 위

요구사항 관리 계획에는 다른 계획에 의해 보다 크거나 작은 범위까지 다룰 수 있는 정보가 들어 있습니다.

조직, 책임 및 인터페이스 페이지 맨 위

../../papers/apprmuc.htm -- This hyperlink in not present in this generated website백서: 유스 케이스로 요구사항 관리 적용에 설명된 대로 요구사항 관리는 프로젝트 성공 보증에 중요합니다. 가장 일반적으로 인용되는 프로젝트 실패의 원인은 다음과 같습니다.

  • 사용자 정보 부족
  • 요구사항 미비
  • 요구사항 변경

또한 요구사항 오류는 오류의 가장 일반적인 등급이며 수정하는 데 매우 많은 비용이 듭니다.

스테이크홀더와 올바른 관계를 가지면 이러한 문제에 도움이 될 수 있습니다. 스테이크홀더는 요구사항을 정의하고 요구사항의 우선순위를 이해하는 정보의 핵심 소스입니다. 그러나 많은 스테이크홀더는 요청된 기능이 비용 및 스케줄에 미치는 영향에 대한 통찰이 부족하므로 개발 조직이 스테이크홀더의 기대를 다루어야 합니다.

스테이크홀더와의 관계 확립에는 다음 사항의 정의가 포함됩니다.

  • 스테이크홀더의 책임: 컨설팅이 가능한 인력이 현장에 있습니까? 미리 약속된 시간에?
  • 프로젝트 결과물에 대한 스테이크홀더의 가시성: 모든 결과물에 대해서 열린 시각을 가지고 있습니까? 오직 계획된 이정표만 보고 있습니까?

추적성 항목 식별 페이지 맨 위

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

추적성 지정 페이지 맨 위

추적성 링크 식별 외에도 링크 원소의 갯수를 지정해야 합니다. 몇 가지 일반 제한조건은 다음과 같습니다.

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

추적성에 대한 자세한 정보는 백서 ../../papers/traceability.htm -- This hyperlink in not present in this generated website유스 케이스를 사용한 요구사항 관리를 위한 추적성 전략에 설명되어 있습니다.

샘플 속성 페이지 맨 위

다음은 ../activity/ac_devra.htm -- This hyperlink in not present in this generated website활동: 요구사항 관리 계획 개발에서 식별된 요구사항 유형을 사용하여 구성되며 선택하려고 할 수 있는 몇 가지 속성 예입니다.

스테이크홀더 요구사항페이지 맨 위

소스: 요구사항을 제공하는 스테이크홀더. 이것은 또한 "스테이크홀더" 추적성 항목에 대한 추적성으로 구현될 수 있습니다.

비율: 전체 비즈니스 기회에 대한 문제점 비율 또는 프로젝트에서 다루어지는 문제점을 나타냅니다. 백분율(0 - 100%). 모든 비율의 총합은 100%를 넘지 않아야 합니다. 아래는 몇 가지 각 스테이크홀더 요구사항에 대한 비율을 보여주는 ../workguid/wg_paret.htm -- This hyperlink in not present in this generated website파레토 다이어그램 예입니다.

전체 비즈니스 기회에 대해 5개 문제점의 상대적 영향을 보여주는 그래프

기능, 추가 요구사항 및 유스 케이스 페이지 맨 위

상태: "공식 채널"을 통한 요구사항의 검토 및 승인 여부를 나타냅니다(예: 제안, 거부, 승인).

이것은 계약 상의 상태 또는 구속력 있는 의사결정을 내릴 수 있는 작업 그룹에 의해 설정된 상태일 수 있습니다.

장점: 스테이크홀더 시각에서 중요성.

  • 결정적(또는 기본적). 시스템의 기본 타스크, 기본 기능, 개발하는 기능과 관련되어 있습니다. 누락되면 시스템은 기본 임무를 수행할 수 없게 됩니다. 이들은 구조적 설계를 이끌어 내고 가장 자주 사용되는 유스 케이스가 되기 쉽습니다.
  • 중요(또는 보조적). 시스템 기능 지원(예: 통계적 데이터 편집, 보고서 생성, 감독 및 기능 테스트)과 관련되어 있습니다. 누락되어도 시스템은 여전히(잠시 동안) 기본 임무를 수행할 수 있지만 서비스 품질은 저하됩니다. 모델링에서 결정적 유스 케이스보다 덜 중요한 사항이 여기에 추가됩니다.
  • 유용(가지면 좋은 것). 시스템의 기본 임무에는 연관되어 있지 않지만 사용이나 시장 포지셔닝에 도움이되는 "편의" 기능입니다.

노력: 요구사항을 구현하는 데 예상되는 소요일.

예를 들어, 저, 중, 고와 같은 범주일 수 있습니다(예: 저 = < 1일, 중 = 1-20일, 고 = >20일).

노력 정의시 예측에 포함되는 일반 비용(관리 노력, 테스트 노력, 요구사항 노력 등)이 무엇인지 명시적으로 지정해야 합니다.

크기: 테스트 코드와 설명 코드를 제외하고 예상되는 코드의 소스 행(SLOC).

비용 예측을 보다 잘 계산하기 위해 새 SLOC와 다시 사용된 SLOC를 구별하고자 할 수 있습니다.

위험: 요구사항 구현시 스케줄 지연, 비용 초과 또는 취소와 같이 중요한, 원치 않는 이벤트를 만나게 되는 가능성(%).

예를 들어, 저, 중, 고와 같은 범주일 수 있습니다(예: 저 = <10%, 중 = 10-50%, 고 = >50%).

위험에 대한 다른 옵션은 별도로 테크놀러지 위험(해당 영역의 경험 또는 필요한 테크놀러지 부족으로 인해 요구사항 구현의 심각한 어려움이 발생하는 가능성 %)을 추적하는 것입니다. 그런 후 전체 위험을 다른 속성(크기, 노력, 안정성, 테크놀러지 위험, 구조적 영향, 조직 복잡도 포함)에 기초하여 가중치된 합으로 계산할 수 있습니다.

조직 복잡도: 요구사항을 개발하는 조직에 대한 제어의 범주화.

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

구조적 영향: 이 요구사항이 소프트웨어 구조에 미치는 영향을 표시합니다.

  • 없음: 기존 구조에 영향을 미치지 않습니다.
  • 확장: 기존 구조를 확장해야 합니다.
  • 수정: 요구사항을 수용하려면 기본 구조를 변경해야 합니다.  

안정성: 이 요구사항이 변경되거나 개발팀의 요구사항에 대한 이해가 변경될 가능성(>50% = 최고, 10..50% = 중간, <10%=최하).

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

위험 레벨/임계성: 일반적으로 필요에 따라 소프트웨어를 수행하는 데 실패한 결과로 건강, 복지 또는 경제적 결과에 영향을 미치는 기능.

  • 무시 가능: 중요한 상해 또는 설비 손해가 발생하지 않습니다.
  • 주변적: 상해 또는 주요 시스템 손상 없이 제어할 수 있습니다.
  • 결정적: 상해 또는 주요 시스템 손상을 일으킬 수 있고 직원이나 시스템 생존을 위해 즉각적인 수정 조치가 필요합니다.
  • 재난적: 심각한 사상자가 발생하거나 전체 시스템을 유실할 수 있습니다.

위험은 다른 요구사항 유형으로 식별하여 연관된 유스 케이스에 링크시킬 수도 있습니다.또한 위험 가능성, 수정 조치 또는 예방 기준을 추적하고자 할 수 있습니다.

해석: 요구사항이 공식적인 계약을 형성하는 몇 가지 경우 요구사항 문구를 변경하는 것이 어렵거나 비용이 들 수 있습니다.개발 조직이 요구사항에 대해 보다 잘 이해하게 되면 단순히 공식적인 요구사항 문구를 변경하기 보다 해석 텍스트를 첨부해야 할 수 있습니다.

유스 케이스페이지 맨 위

위에 덧붙여 다음과 같은 유스 케이스 속성을 추적하는 것도 유용합니다.

%세부사항: 유스 케이스가 구현된 정도.

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

테스트 케이스페이지 맨 위

상태: 테스트 개발 중에 진행 상황을 추적합니다.

  • 활동 없음: 이 테스트 케이스 개발에서 달성된 작업이 없습니다.
  • 수동: 연관된 요구사항을 확인할 수 있는 수동 스크립트가 작성되어 유효성이 확인되었습니다.
  • 자동: 연관된 요구사항을 확인할 수 있는 자동 스크립트가 작성되어 유효성이 확인되었습니다.

일반 속성페이지 맨 위

일반적으로 적용되는 몇 가지 다른 요구사항 속성은 다음과 같습니다.

  • 계획된 반복
  • 실제 반복
  • 책임 그룹

속성 선택 페이지 맨 위

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

  • 누가 이 정보를 제공합니까?
  • 누가 이 정보를 사용하며 유용한 이유는 무엇입니까?
  • 이 정보의 추적 비용은 가치가 있습니까?

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

도출된 정보 고려

요구사항 속성을 직접 사용하는 것 외에도 다른 요구사항 유형에 대한 추적성을 통해 이러한 요구사항 속성에서 정보를 도출하고자 할 수 있습니다. 몇 가지 도출의 일반적인 패턴은 다음과 같습니다.

  • 하향식 도출 - 위의 추적성이 지정된 경우 제품 기능에 "목표 릴리즈" 속성이 있다고 가정합니다. 이 제품 기능에 의해 추적되는 각 유스 케이스 섹션은 지정된 목표 릴리즈 시점 또는 그 이전에도 사용 가능해야 한다는 것을 도출할 수 있습니다.
  • 상향식 도출 - 위의 추적성이 지정된 경우 유스 케이스 섹션에 "예상 노력" 속성이 있다고 가정합니다. 제품 기능 비용은 추적하는 유스 케이스 섹션의 예상 노력을 합하여 예상할 수 있습니다. 몇 가지 제품 기능이 동일한 유스 케이스 섹션에 맵핑될 수 있으므로 주의해서 사용해야 합니다.

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

  • 이 속성으로부터 생성되는 도출된 정보/보고서는 무엇입니까?
  • 이 속성은 어떤 레벨의 추적성 계층 구조에서 추적해야 합니까?

속성 종속성

일부 속성은 특정 레벨의 개발에만 적용할 수 있습니다. 예를 들어, 일단 유스 케이스가 설계에 완전히 표시되면 유스 케이스의 예상 노력 속성은 설계 요소의 노력 예측치로 대체할 수 있습니다.

보고서 및 측정 페이지 맨 위

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

보고서/측정 설명 용도
유스 케이스의 개발 우선순위(위험, 장점, 노력, 안정성 및 구조적 영향별로 정렬된 유스 케이스 목록). 이것은 따로 정렬된 여러 개의 목록이거나 이러한 속성의 가중치별 조합으로 정렬된 단일 목록일 수 있습니다. 활동: 유스 케이스 우선순위 지정에 사용됩니다.
각 상태 카테고리의 기능 퍼센트. 프로젝트 기준선 정의 중에 진행 상황을 추적합니다.
 - 목표 릴리즈별로 분류됩니다.  - 릴리즈에 기초하여 진행 상황을 추적합니다.
 - 노력에 가중치를 줍니다.  - 진행 상황에 대한 보다 정말한 측정을 제공합니다.
위험별로 정렬된 기능  - 위험성 있는 기능을 식별합니다. 범위 관리 및 기능을 반복에 지정할 때 유용합니다.
 - 각 목표 릴리즈를 위해 합해진 개발 위험을 사용하여 목표 릴리즈별로 분류합니다.  - 위험성 있는 기능이 프로젝트 초기 또는 나중에 스케줄되었는지를 평가할 때 유용합니다.
안정성별로 정렬된 유스 케이스 섹션  - 유스 케이스 섹션에 안정화가 필요한지 여부를 결정할 때 유용합니다.
 - 구조적 영향 별로 정렬되거나 가중치를 줍니다.  - 먼저 안정화할 구조적으로 중요하거나 노력이 많이 필요한 유스 케이스에 우선순위를 지정할 때 유용합니다.
정의되지 않은 속성이 있는 요구사항 요구사항을 처음에 제안할 때는 모든 속성을 바로 지정하지 않았을 수 있습니다(예: 기본값 "정의되지 않음" 값 사용). 체크포인트: 소프트웨어 요구사항 스펙은 이 보고서를 사용하여 이러한 정의되지 않은 속성을 확인합니다.
불완전한 추적성 링크가 있는 추적성 항목 올바르지 않거나 불완전한 추적성 링크에 대한 보고서는 체크포인트: 소프트웨어 요구사항 스펙에 사용됩니다.

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

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

  • 해결한 문제점이 변경되었습니다. 이것은 새로운 규제, 경제적 압박, 테크놀러지 변화로 인한 것일 수 있습니다.
  • 스테이크홀더가 시스템에 원하는 수행 능력에 대한 인식이나 마음을 바꾸었습니다. 이것은 담당 인력의 교체, 사안에 대한 심도 깊은 이해 등과 같이 여러 가지가 원인일 수 있습니다.
  • 처음 요구사항을 정의할 때 모든 스테이크홀더를 포함시키지 않았거나 적절한 모든 질문을 행하지 않았습니다.

변경 요구사항 관리 전략에는 다음 사항이 포함됩니다.

  • 요구사항의 기준선을 정합니다.
  • 변경 제어를 위한 단일 채널을 만듭니다.
  • 변경 이력을 관리합니다.

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

구현 단계 종료를 목표로 하여 시스템 분석가는 모든 알려진 요구사항의 기준선을 정해야 합니다. 이것은 보통 요구사항 결과물에 버전 제어가 있는지 확인하거나 기준선을 형성하는 결과물 세트 및 버전을 식별함으로써 수행됩니다.

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

변경 제어를 위한 단일 채널 설정페이지 맨 위

스테이크홀더의 변경 요구는 공식적인 예산 및 스케줄 변경을 전제로 할 수 없습니다. 일반적으로 협상 또는 예산 조정 프로세스는 변경 승인 전에 시작되어야 합니다. 종종 변경사항은 서로 균형이 맞추어져야 합니다.

시스템에 미치는 영향을 판단하고 공식적인 승인을 받아야 하므로 모든 변경은 단일 채널(변경 제어 보드)을 통해야 합니다. 변경 제안 메커니즘은 CCB에서 검토된 변경 요청제출하는 것입니다.

변경 이력 관리페이지 맨 위

각 요구사항에 대한 변경 감사 추적을 관리하는 것이 좋습니다. 이 변경 이력을 사용하여 요구사항에 대한 모든 이전 변경사항 뿐만 아니라 속성 값에 대한 변경 및 변경 이유를 볼 수 있습니다. 이것은 실제 요구사항 안정성을 평가하고 변경 제어 프로세스가 적용되지 않은 경우를 식별(예: 적절하게 검토 및 승인되지 않은 요구사항 변경 식별)할 때 유용할 수 있습니다.



Rational Unified Process   2003.06.15