<프로젝트 이름>
보충 스펙
버전 <1.0>
[참고: 이 템플리트는 Rational Unified Process에서 사용됩니다. 대괄호 안에 파란색 이탤릭체로 표시된 텍스트(style=InfoBlue)는 작성자용 안내로 제공되므로 문서를 공개하기 전에 삭제해야 합니다. 해당 스타일로 입력된 단락은 자동으로 일반(style=Body Text)으로 설정됩니다.]
개정 히스토리
날짜 |
버전 |
설명 |
작성자 |
<dd/mmm/yy> |
<x.x> |
<세부사항> |
<이름> |
|
|
|
|
|
|
|
|
|
|
|
|
목차
보충 스펙
[보충 스펙의 소개에서는 전체 문서에 대한 개요를 제공합니다. 이 보충 스펙의 목적, 범위, 정의, 두문자어, 약어, 참조 및 개요가 포함됩니다.]
보충 스펙은 유스 케이스 모델의 유스 케이스에서 쉽게 캡처되지 않는 시스템 요구사항을 캡처합니다. 해당 요구사항에는 다음이 포함됩니다.
· 응용프로그램 표준을 포함한 법률 및 규제 요구사항
· 빌드할 시스템의 품질 속성(사용성, 신뢰성, 성능 및 지원 가능성 요구사항 포함)
· 기타 요구사항(예: 운영 체제 및 환경, 호환성 요구사항과 디자인 제한조건)]
[이 보충 스펙의 목적을 지정하십시오.]
[이 보충 스펙의 범위에 대한 간략한 설명(프로젝트 연관 대상 및 이 문서의 영향을 받는 기타 대상)]
[이 서브섹션은 보충 스펙의 올바른 해석에 필요한 모든 용어, 두문자어 및 약어에 대한 정의를 제공합니다. 이 정보는 프로젝트 용어집에 대한 참조로도 제공될 수 있습니다.]
[이 서브섹션은 보충 스펙 전체에서 참조되는 모든 문서의 전체 목록을 제공합니다. 각 문서는 제목, 보고서 번호(해당되는 경우), 날짜 및 출판사로 식별됩니다. 참조할 수 있는 소스를 지정하십시오. 이 정보는 부록이나 기타 문서의 참조로도 제공될 수 있습니다.]
[이 서브섹션에서는 보충 스펙 관련 기타 내용 및 문서를 체계화하는 방법에 대해 설명합니다.]
[이 섹션은 자연어 양식으로 표현되는 시스템의 추가 기능적 요구사항을 설명합니다.]
[요구사항 설명.]
[이 섹션에는 사용성에 적용되는 해당 요구사항 전체가 포함됩니다. 예제는 다음과 같습니다.
· 특정 오퍼레이션에 대한 일반 사용자 및 고급 사용자의 생산성을 향상시키기 위해 필요한 훈련 시간을 지정합니다.
· 일반 타스크에 대한 측정 가능한 타스크 시간을 지정합니다. 또는
· 공통 사용성 표준(예: IBM CUA 표준 또는 Microsoft GUI)을 준수하는 요구사항을 지정합니다.]
요구사항 설명.
[시스템 신뢰성의 요구사항을 여기에 지정해야 합니다. 제안은 다음과 같습니다.
· 가용성 - 사용 가능한 시간의 백분율(xx.xx%), 사용한 시간, 유지보수 액세스, 성능 저하 모드 오퍼레이션 등을 지정합니다.
· 평균 실패 시간 간격(MTBF) - 일반적으로 시간 단위로 지정되지만 일, 월 또는 년 단위로도 지정할 수 있습니다.
· 평균 복구 시간(MTTR) - 실패 후 시스템에서 허용되는 오퍼레이션 정지 시간입니다.
· 정확성 - 시스템 출력에 필요한 정밀도(해상도) 및 정확성(알려진 표준)을 지정합니다.
· 최대 버그 수 또는 결함 비율 - 일반적으로 버그/KLOC(수천 행의 코드) 또는 버그/기능 점수로 표시됩니다.
· 버그 수 또는 결함 비율 - 사소한 버그, 심각한 버그 및 치명적인 버그로 분류됩니다. 요구사항은 치명적인 버그의 의미를 정의해야 합니다(예: 전체 데이터 손실 또는 시스템 기능성의 특정 파트를 사용할 수 없음).]
[요구사항 설명.]
[시스템 성능 특성이 이 섹션에 개요로 제공되어야 합니다. 특정 응답 시간을 포함하십시오. 적용되는 경우 이름별 유스 케이스에 관련된 참조. 일반적으로, 유스 케이스 양식 또는 단순 텍스트로 설명하는지 여부에 관계 없이 모든 필수 기능은 성능 설명(시스템이 성능 또는 기능을 어느 정도 효과적으로 제공하는지 설명)과 연관되어야 합니다. 이러한 성능 설명은 영향을 받는 기능과 근접한 위치(예: 유스 케이스 설명의 "특별 요구사항" 파트)에 보관하는 것이 좋습니다. 여기에는 테스트해야 하지만 특정 기능과 관련이 없는 요구사항에 대한 설명을 보관합니다.
· 트랜잭션에 대한 응답 시간(평균, 최대)
· 처리량(예: 초당 트랜잭션 수)
· 용량(예: 시스템이 처리할 수 있는 고객 또는 트랜잭션 수)
· 성능 저하 모드(시스템 성능이 특정 방식으로 저하된 경우 허용 가능한 오퍼레이션 모드)
· 자원 활용: 메모리, 디스크, 커뮤니케이션 등]
[요구사항 설명.]
[이 섹션에서는 빌드 중인 시스템의 지원 가능성 및 유지보수성 향상에 도움이 되는 모든 요구사항을 표시하고 여기에는 코드 표준, 이름 지정 규칙, 클래스 라이브러리, 유지보수 액세스, 유지보수 유틸리티가 포함됩니다.]
[요구사항 설명.]
[이 섹션에서는 빌드 중인 시스템의 모든 디자인 제한조건을 표시합니다. 디자인 제한조건은 지시되고 이에 따라 진행해야 하는 디자인 결정을 나타냅니다. 예제에는 소프트웨어 언어, 소프트웨어 프로세스 요구사항, 개발 도구의 지정 용도, 아키텍처 및 디자인 제한조건, 구입한 컴포넌트, 클래스 라이브러리 등이 포함됩니다.]
[요구사항 설명.]
[시스템 엔지니어링에서는 잠재적으로 다음과 같은 기타 유형의 요구사항을 다루어야 합니다.]
[예: 중량, 크기, 전원...]
[예: 습기, 오염, 열, 전기, 기계...]
[예: 안전, 보안, 기타 품질 요소(예: 존속성)]
[시스템을 사용하고 지원할 사용자를 지원하기 위해 시스템에 부과되는 요구사항을 설명합니다. 예를 들어, 훈련 기능(훈련을 위해 포함될 장비 및 자료), 유지보수 기능과 인터페이스 설명 및 표준에서 다루지 않는 인간 공학 관련 고려사항이 포함됩니다.]
[물류 고려사항(예: 유지보수, 지원, 교통, 공급, 기존 시스템 수용)으로 인해 시스템에 부과되는 요구사항을 설명합니다.]
[온라인 사용자 문서, 도움말 시스템, 주의사항에 대한 도움말 등에 대한 요구사항이 있는 경우 해당 요구사항을 설명합니다.]
[이 섹션에서는 시스템, 적용되는 라이센싱 또는 사용법 제한 및 관련된 호환성/상호 운영 또는 인터페이스 표준에서 사용되는 구매한 모든 컴포넌트를 설명합니다. ]
[이 섹션은 시스템에서 지원해야 하는 인터페이스를 정의합니다. 시스템을 개발하고 인터페이스 요구사항에 대해 확인할 수 있도록 해당 특성, 프로토콜, 포트 및 논리 주소 등을 포함해야 합니다. 또한 시스템 내부 인터페이스에 부과될 모든 요구사항을 설명해야 합니다. 이러한 요구사항은 예를 들어, 시스템 디자인에서 기존 하드웨어 또는 소프트웨어 컴포넌트를 내부적으로 사용하도록 제한될 때 적용됩니다.]
[시스템에서 구현될 사용자 인터페이스를 설명합니다.]
[이 섹션에서는 시스템에서 지원되는 하드웨어 인터페이스(예: 논리 구조, 실제 주소, 예상 동작 등)를 정의합니다.]
[이 섹션은 시스템에서 지원할 소프트웨어 인터페이스를 지원되는 또한 지원이 필요한 오퍼레이션 및 신호와 프로토콜 및 데이터 특성의 관점에서 설명합니다.]
[근거리 통신망 등과 같은 기타 시스템 또는 장치의 통신 인터페이스를 설명합니다.]
[시스템이 제시할 라이센스 부여 필수 요구사항 또는 기타 사용 제한 요구사항을 정의합니다.]
[이 섹션은 시스템에 적용되는 모든 필수적인 법적 면책사항, 보증사항, 저작권 표시, 특허권 표시, 워드마크(wordmark), 상표 또는 로고에 대한 준수사항을 설명합니다.]
[이 섹션에서는 적용되는 표준 및 설명 중인 시스템에 적용되는 표준에 고유한 특정 섹션을 설명합니다. 예를 들어, 법률, 품질 및 규제 관련 표준과 사용성, 상호운용성, 국제화, 운영 체제 준수 등에 대한 업계 표준이 포함될 수 있습니다.]