추가 스펙 구조는 유스 케이스 스펙과 같은 작동적 요구사항 결과물에서 손쉽게 파악되지 않는 시스템 요구사항을 파악합니다.
역할:  시스템 분석가 
선택 가능성/발생 시기:  특정 유스 케이스와 연관될 수 없는 시스템 요구사항이 있는 경우 사용됩니다.  
템플리트 및 보고서: 
     
예: 
     
UML 표시:  해당사항 없음.
자세한 정보:   
활동 정보:    활동 결과:   

목적 페이지 맨 위

추가 스펙은 유스 케이스 모델의 유스 케이스에서 손쉽게 파악되지 않는 시스템 요구사항을 파악합니다. 이러한 요구사항에는 다음 사항이 포함됩니다.

  • 법적 및 규정적 요구사항과 어플리케이션 표준
  • 사용성, 신뢰성, 성능 및 지원 가능성 요구사항을 포함하여 작성할 시스템의 품질 속성.
  • 운영 체제 및 환경, 다른 소프트웨어와의 호환성 및 설계 제한조건과 같은 기타 요구사항

시기 페이지 맨 위

추가 스펙은 다음 사항을 포함하여 유스 케이스 모델과 보조를 맞춥니다.

  • 유스 케이스를 따라 시스템 작동 및 범위 정의시 보완사항으로 초기 단계에 최초로 식별되기 시작합니다.
  • 구현화형상 단계 중에 증분 방식으로 확장 및 정제됩니다.

책임 페이지 맨 위

시스템 분석가 역할은 유스 케이스 모델의 중요한 보완인 이 결과물을 기본적으로 책임집니다. 추가 스펙 및 유스 케이스 모델은 함께 시스템의 전체 요구사항을 파악해야 합니다.

이 결과물은 다른 소프트웨어 엔지니어링 작업에 대한 중요한 정보입니다. 다음 역할 및 역할 세트가 추가 스펙을 사용합니다.

  • 분석가는 분석가, 고객 및 개발자 사이의 통신 매체로서 이것을 작성하고 유지보수합니다.추가 스펙
  • 개발자는 클래스에 책임, 조작 및 속성을 정의하고, 구현 환경에 따라 클래스를 조정할 때 이것을 참조합니다.
  • 구현자는 클래스를 구현할 때 이것을 참조합니다.
  • 관리자는 반복을 계획할 때 이것을 참조합니다.
  • 테스터는 시스템 순응의 유효성을 확인할 때 이것을 사용합니다.

사용자 정의 페이지 맨 위

추가 요구사항의 종류는 프로젝트마다 매우 광범위하므로 사용자 정의는 프로젝트에 적절한 섹션을 정의할 때 정의되어야 합니다. 비전에서 관리할 정보(속성)와 요구사항 관리 툴(예: Rational RequisitePro)을 사용하여 관리할 사항을 결정하십시오.

추가 스펙은 소프트웨어 요구사항 스펙 결과물 안에 포함될 수 있습니다.



Rational Unified Process   2003.06.15