사용할 중간 산출물 및 각 중간 산출물의 사용법을 결정하십시오. 사용할 중간 산출물의 식별뿐만 아니라 각 중간 산출물을 프로젝트의 필요에 맞게 사용하도록 사용자 조정하는 것도 중요합니다.
아래 표는 권장되는 요구사항 중간 산출물과 선택사항으로 간주되는 형상 및 변경 관리 중간 산출물(예: 특정 경우에만 사용될 수 있음)을 지정합니다. 추가 사용자 조정 고려사항은 중간 산출물 설명 페이지의 사용자
조정 섹션을 참조하십시오.
중간 산출물
|
목적
|
사용자 조정(선택사항, 권장사항)
|
중간 산출물: 유스 케이스 모델 (중간 산출물: 액터, 중간 산출물: 유스 케이스, 중간 산출물: 유스 케이스 패키지)
|
유스 케이스를 사용하여 기능적 요구사항을 정의합니다.
|
대부분의 프로젝트에서 권장됩니다.
유스 케이스는 기능적 요구사항을 캡처하는 경우 권장되는 방법입니다.
|
중간 산출물: 스토리보드
|
실제로 동작 요구사항을 이해하지 못한 프로젝트는 요구사항을 도출하는 방법으로 스토리보딩을 고려해야 합니다.
|
선택사항
기타 요구사항 도출 기법을 사용할 수 있습니다.
|
중간 산출물: 용어집
|
프로젝트에서 모든 사람이 공통 용어를 사용하게 하십시오.
|
대부분의 프로젝트에서 권장됩니다.
|
중간 산출물: 요구사항 속성
|
요구사항 속성의 데이터베이스는 요구사항의 우선순위를 올바르게 지정하고 요구사항을 트랙 및 추적하였는지 보장하는 데 도움이 됩니다.
|
선택사항
그러나 요구사항이 비교적 소수인 프로젝트에서 요구사항 속성의 데이터베이스는 반드시 필수사항은 아닙니다.
|
중간 산출물: 요구사항 관리 계획
|
수집할 정보 및 제품 요구사항의 변경사항을 측정, 보고 및 제어하는 경우 사용할 제어 메커니즘을 설명합니다. 요구사항 관리 복잡도 또는 고객 가시성에서 보증하는 경우 별도의 문서가
필요합니다.
|
선택사항
요구사항이 비교적 소수인 프로젝트는 요구사항 관리 시 소프트웨어 개발 계획에서 직접 문서화할 수 있는 간단한 접근 방식을 사용할 수 있습니다.
기타 프로젝트에서 추가로 엄격한 접근 방식을 선택하여 준수할 수 있지만 정규 설명은 전혀 또는 거의 작성하지 않습니다. 예를 들어 수집할 요구사항 속성 세트는 도구 구성을 통해
내재적으로 문서화될 수 있습니다.
|
중간 산출물: 소프트웨어 요구사항 스펙
|
고객이 제공하는 정규 문서에 있는 모든 요구사항 세트를 수집하는 데 사용됩니다.
|
선택사항
비정규 프로젝트에는 정규 문서가 필요하지 않을 수 있습니다.
|
중간 산출물: 이해 당사자(stakeholder) 요청
|
프로젝트에서 요청한 모든 요청 및 이 요청을 처리하는 방법을 캡처합니다.
|
대부분의 프로젝트에서 권장됩니다.
이해 당사자의 요구를 충족시키는 시스템을 빌드하려면 해당 요청을 확보하고 검토해야 합니다.
많은 프로젝트에서는 이해 당사자(stakeholder) 요청을 변경 요청의 카테고리로만 관리합니다. 기타 프로젝트에서는 이해 당사자(stakeholder) 요청을 비공식적으로만
캡처할 수 있습니다.
|
중간 산출물: 보충 스펙
|
비기능적 요구사항을 캡처하는 데 사용합니다.
|
대부분의 프로젝트에서 권장됩니다.
|
중간 산출물: 비전
|
독자가 개발할 시스템을 이해할 수 있도록 높은 수준의 상위 레벨 요구사항 및 디자인 제한조건을 캡처합니다.
|
대부분의 프로젝트에서 권장됩니다.
|
사용할 보고서 결정은 프로젝트에서 사용 가능한 보고 도구에 따라 다릅니다. 보고서 생성 도구가 있는 경우 모델 지향 또는 데이터베이스 지향 중간 산출물(예: 유스 케이스 및 액터)에서 보고서를 생성하는 것이
좋습니다. RUP 구성의 기존 보고서는 중간 산출물 설명 페이지에서 사용 가능하고 트리 브라우저의 관련 중간 산출물 아래에 그룹화되어 있습니다.
이 섹션에서는 정규 계약, 표준 또는 스펙 문서에서 요구사항 관리 노력에 대한 요구사항을 부가하는 경우에만 적용됩니다. 이 내용을 "입력 요구사항 스펙"이라고 합니다.
요구사항 노력 중, 다음 문서의 요구사항을 캡처합니다. 중간 산출물:
비전, 중간 산출물: 이해 당사자(stakeholder) 요청, 중간
산출물: 유스 케이스 모델, 중간 산출물: 보충 스펙
입력 요구사항 스펙의 유지보수 여부를 결정하십시오. 요구사항이 잘못되었거나 틀렸거나 오류가 있음을 발견한 경우 다시 돌아가 입력 요구사항 스펙을 갱신하시겠습니까? 또한 입력 요구사항 스펙과 중간 산출물: 유스 케이스 간의 추적 또는 참조 유지보수
방법을 결정해야 합니다.
다음 전략 중 하나 또는 해당 조합을 선택하십시오.
-
입력 요구사항 스펙을 갱신하지 마십시오. 유스 케이스 및 보충 스펙에서 시스템의 향후 수행 작업을 지정하십시오.
-
입력 요구사항 스펙을 갱신하지 마십시오. 그러나 다시 유스 케이스에서 해당 스펙으로의 추적성을
유지보수하십시오.
-
관련된 모든 작업 및 비용과 함께 입력 요구사항 스펙을 갱신하십시오.
-
입력 요구사항 스펙을 요구사항을 포함하는 보충 스펙으로 전개하십시오. 기능 입력 요구사항은 단순히 유스 케이스로 이전됩니다.
대부분의 프로젝트에서 잘못되었거나 오류가 있거나 틀린 요구사항이 너무 많아서 원래 입력 요구사항 스펙을 유지보수할 수 없는 상황이 발생합니다. 고객이 자발적으로 유스 케이스 모델링 동안 알려진 새 정보를 사용하여
입력 요구사항 스펙을 갱신하는 작업을 수행하는 프로젝트는 거의 없습니다.
이 주제를 너무 일찍 강조하지 마십시오. 프로젝트 초반에는 여전히 초기 요구사항 스펙을 믿고 있습니다. 그러나 유스 케이스를 사용하여 문제점 영역에서 작업을 하면 대부분의 사람이 초기 요구사항 스펙과는 완전히 다른
생각을 갖게 됩니다.
유스 케이스를 승인하는 방법을 결정하십시오. 고객이 정규로 검토해야 하는 유스 케이스 수를
제한하면 많은 시간을 절감할 수 있습니다. 고객이 정규로 모든 유스 케이스의 서브세트만 검토하는 방법도 허용 가능합니다.
다음 전략 중 하나 이상을 선택하십시오.
-
모든 유스 케이스에서 프로젝트 외부에 있는 대표가 정규 외부 검토를 수행해야 합니다.
-
일부 보조 유스 케이스는 비정규 또는 내부 정규 검토에서 단순화된 방법으로 승인될 수 있습니다.
보조 유스 케이스는 기본 사용자의 타스크가 아닌 시스템에 핵심적인 유스 케이스입니다. 예를 들어 시스템 관리 및 유지보수(예: 시스템에 사용자 추가, 사용자 권한 변경 및 백업 수행)와 관련된 유스 케이스입니다.
이 유스 케이스가 기본적으로 중요한 사용자에게 관심이 없는 경우에도 이 유스 케이스가 없으면 시스템은 작동하지 않습니다.
사용자가 사용하는 전략은 고객과 사용자와의 관계에 따라 다릅니다. 사용자의 고객은 사용자가 정규 승인 프로세스 없이 지원하는 유스 케이스를 올바르게 사용할 수 있다고 믿고 있습니까? 이 경우 시간이 크게 절감되어도
유스 케이스 모델의 올바른 품질을 달성했습니까?
참고: 문제점에 대한 솔루션은 요구사항 노력에서 고객과 관련이 있을 수 있습니다. 고객 대표가 참여함으로써 다른 고객에게 권장사항을 승인하거나 제공할 수 있으며, 고객이 참여함으로써 프로젝트에 신뢰성을
더할 수 있습니다.
검토 레벨에 대한 자세한 정보는 가이드라인: 검토 레벨을
참조하십시오.
|