<프로젝트 이름>

시스템 요구사항 스펙

 

 

 

버전 <1.0>

 

 

[참고: 이 템플리트는 Rational Unified Process에서 사용됩니다. 대괄호 안에 파란색 이탤릭체로 표시된 텍스트(style=InfoBlue)는 작성자용 지침으로 문서를 공개하기 전에 삭제해야 합니다. 해당 스타일로 입력된 단락은 자동으로 일반(style=Body Text)으로 설정됩니다.]


개정 히스토리

날짜

버전

설명

작성자

<dd/mmm/yy>

<x.x>

<세부사항>

<이름>

 

 

 

 

 

 

 

 

 

 

 

 

 


목차

1. 소개         

1.1     목적     

1.2     범위     

1.3 용어의 정의     

1.4     참조     

1.5     개요     

2.       전체 설명    

2.1 유스 케이스 모델 조사 

2.2 가정 및 종속성

3.       특정 요구사항

3.1     시스템 기능

3.1.1 유스 케이스 보고서 

3.1.2 추가 기능성

3.2     비기능적 요구사항

3.2.1 사용성 

3.2.2 신뢰성 

3.2.3 성능 

3.2.4 지원 가능성 

3.2.5 디자인 제한조건 

3.2.6 추가 시스템 엔지니어링 고려사항 

3.2.6.1 물리적 요구사항 

3.2.6.2 환경 요구사항 

3.2.6.3 기타 제품 보증 요구사항 

3.2.6.4 사용자 관련 요구사항 

3.2.6.5 물류 요구사항 

3.2.7 온라인 사용자 문서 및 도움말 시스템 요구사항 

3.2.8 구입한 컴포넌트 

3.2.9 인터페이스 

3.2.9.1 사용자 인터페이스 

3.2.9.2 하드웨어 인터페이스 

3.2.9.3 소프트웨어 인터페이스 

3.2.9.4 통신 인터페이스 

3.2.10 라이센스 부여 요구사항 

3.2.11 법률, 저작권 및 기타 주의사항 

3.2.12 적용되는 표준

4.       지원 정보    


시스템 요구사항 스펙

1.                  소개

[시스템 요구사항 스펙(SysRS) 소개에서는 전체 SysRS의 개요를 제공합니다. SysRS의 목적, 범위, 정의, 두문자어, 약어, 참조 및 개요가 포함됩니다.]

[참고: SysRS는 시스템 또는 시스템 일부의 전체 시스템 요구사항을 캡처합니다. 모든 요구사항을 단일 문서에 캡처하며 결합된 보충 스펙 또는 해당 자료가 삽입됩니다.]

1.1     목적

[이 SysRS의 목적을 지정하십시오. SysRS는 식별된 시스템의 모든 기능 및 동작 기능을 설명합니다. 또한 비기능적 요구사항, 디자인 제한조건 및 시스템 요구사항에 대한 전체 통합 설명을 제공하는 데 필요한 기타 요인에 대해 설명합니다.]

1.2     범위

[SysRS가 적용되는 시스템에 대한 간략한 설명과 이 문서의 영향을 받는 기타 내용]

1.3     용어의 정의

[이 서브섹션은 SysRS의 올바른 해석에 필요한 모든 용어, 두문자어 및 약어에 대한 정의를 제공합니다. 이 정보는 부록 또는 다른 문서에 대한 참조로 제공할 수 있습니다.]

1.4     참조

[이 서브섹션은 SysRS 전체에서 참조되는 모든 문서의 전체 목록을 제공합니다. 각 문서는 제목, 보고서 번호(해당되는 경우), 날짜 및 출판사로 식별합니다. 참조할 수 있는 소스를 지정하십시오. 이 정보는 부록 또는 다른 문서에 대한 참조로 제공할 수 있습니다.]

1.5     개요

[이 서브섹션은 SysRS 관련 기타 내용 및 문서를 체계화하는 방법에 대해 설명합니다.]

2.                  전체 설명

[SysRS의 이 섹션은 시스템 및 해당 요구사항에 영향을 주는 일반 요인을 설명합니다. 이 섹션은 특정 요구사항에 대해 설명하지 않으며 대신 섹션 3에서 세부적으로 정의하는 요구사항을 쉽게 이해할 수 있도록 해당 배경을 제공합니다. 다음과 같은 항목이 포함됩니다.

이 섹션은 해당 문서에서 자료를 복제하지 않고 비전 아티팩트를 참조할 수 있습니다.]

2.1               유스 케이스 모델 조사

 [유스 케이스 모델링을 사용하는 경우 이 섹션에는 유스 케이스 모델의 개요가 포함됩니다. 여기에는 유스 케이스 및 액터 전체의 이름 및 간략한 설명 목록과 적용되는 다이어그램 및 관계가 포함됩니다.  이 지점에서 엔클로저로 사용될 수 있는 유스 케이스 모델 조사 보고서를 참조하십시오.]

2.2               가정 및 종속성

[이 섹션은 주요 기술 실현 가능성, 서브시스템 또는 컴포넌트 가용성, 또는 이 SysRS에서 설명하는 시스템의 실현 가능성의 기반이 되는 기타 프로젝트 관련 가정을 설명합니다.]

3.                  특정 요구사항

[SysRS의 이 섹션은 모든 소프트웨어 요구사항을 자세히 설명합니다. 디자이너는 이 내용을 바탕으로 해당 요구사항에 맞게 시스템을 디자인하며 테스터는 시스템이 해당 요구사항을 충족시키는지 테스트합니다.

유스 케이스 모델링을 사용하는 경우, 이 요구사항은 유스 케이스 및 해당 보충 스펙에서 캡처합니다(아티팩트 자체로서 또는 이 문서 "3.2 비기능적 요구사항"의 섹션에 따라).]

3.1               시스템 기능

[이 섹션은 필수 시스템 기능을 유스 케이스로 설명합니다. 이 섹션은 많은 응용프로그램에 있어 SysRS 패키지의 대부분을 구성하므로 이 섹션 구성에 주의를 기울여야 합니다. 이 섹션은 일반적으로 사양, 기능 또는 기능 그룹(비전 아티팩트에서 유추하는 "기능" 특성을 광범위하게 기술)으로 구성되지만 예를 들어, 사용자 또는 역할에 따른 구성과 같이 다른 구성 방법도 사용할 수 있습니다.]

3.1.1           유스 케이스 보고서

[유스 케이스 모델링의 경우, 유스 케이스는 일부 비기능적(성능 관련) 요구사항과 함께 시스템의 대부분의 기능적 요구사항을 정의합니다. 위의 유스 케이스 모델에서 각 유스 케이스에 대해 이 섹션의 유스 케이스 보고서를 참조 또는 포함하십시오. 각 요구사항을 명확히 지정했는지 확인하십시오. 해당되는 경우, 올바른 기능 및 동작 설명 레벨을 달성할 수 있도록 유스 케이스를 기능(필요한 경우 기능에 따라 정제)별로 그룹화하십시오.]

3.1.2           추가 기능성

[이 섹션은 유스 케이스로서 캡처되지 않고 자연어 양식으로 표현되는 시스템의 추가 기능적 요구사항을 설명합니다.]

3.1.2.1     <기능적 요구사항 1>

[요구사항 설명.]

3.2                 비기능적 요구사항

[참고: 보충 스펙 아티팩트가 생성된 경우, 여기에 포함할 수 있습니다. 동일한 주제를 다룹니다.]

3.2.1          사용성

[이 섹션에는 사용성에 영향을 주는 모든 요구사항이 포함됩니다. 예를 들어, 다음과 같습니다.

3.2.1.1     <사용성 요구사항 1>

[요구사항 설명.]

3.2.2          신뢰성

[시스템 신뢰성에 대한 요구사항을 지정합니다. 제안은 다음과 같습니다.

3.2.2.1     <신뢰성 요구사항 1>

[요구사항 설명.]

3.2.3          성능

[이 섹션에는 시스템의 성능 특성을 개략적으로 설명합니다. 특정 응답 시간을 포함하십시오. 해당되는 경우 이름별로 관련 유스 케이스를 참조하십시오. 일반적으로, 유스 케이스 양식 또는 단순 텍스트로 설명하는지 여부에 관계 없이 모든 필수 기능을 성능 설명(시스템이 성능 또는 기능을 어느 정도 효과적으로 제공하는지 설명)과 연관시킵니다. 이러한 성능 설명은 영향을 받는 기능과 근접한 위치(예: 유스 케이스 설명의 "특별 요구사항" 파트)에 보관하는 것이 좋습니다. 여기에는 테스트해야 하지만 특정 기능과 관련이 없는 요구사항에 대한 설명을 보관합니다. 성능 특성은 다음과 같습니다.

3.2.3.1      <성능 요구사항 1>

[요구사항 설명.]

3.2.4          지원 가능성

[이 섹션은 빌드 중인 시스템의 지원 가능성 및 유지보수성 향상과 관련된 모든 요구사항(예: 코딩 표준, 이름 지정 규칙, 클래스 라이브러리, 유지보수 액세스 및 유지보수 유틸리티)을 나타냅니다.]

3.2.4.1    <지원 가능성 요구사항 1>

[요구사항 설명.]

3.2.5          디자인 제한조건

[이 섹션에서는 빌드 중인 시스템의 모든 디자인 제한조건을 표시합니다. 디자인 제한조건은 지시되고 이에 따라 진행해야 하는 디자인 결정을 나타냅니다.  예제에는 소프트웨어 언어, 소프트웨어 프로세스 요구사항, 개발 도구의 지정 용도, 아키텍처 및 디자인 제한조건, 구입한 컴포넌트, 클래스 라이브러리 등이 포함됩니다.]

3.2.5.1     <디자인 제한조건 1>

[요구사항 설명.]

3.2.6     추가 시스템 엔지니어링 고려사항

[시스템 엔지니어링에서는 잠재적으로 다음과 같은 기타 유형의 요구사항을 다루어야 합니다.]

3.2.6.1  실제 요구사항

[예: 중량, 크기, 전원 등]

3.2.6.2  환경 요구사항

[예: 습기, 오염, 열, 전기, 기계 등]

3.2.6.3  기타 제품 보증 요구사항

3.2.6.3.x     <카테고리>

[예: 안전, 보안, 기타 품질 요소(예: 존속성)]

3.2.6.4   사용자 관련 요구사항

[시스템을 사용하고 지원하는 사용자를 지원하기 위해 시스템에 부과되는 요구사항을 설명합니다. 예를 들어, 훈련 기능(훈련을 위해 포함될 장비 및 자료), 유지보수 기능과, 인터페이스 설명 및 표준에서 다루지 않는 인간 공학 관련 고려사항이 포함됩니다.]

3.2.6.5   물류 요구사항

[물류 고려사항(예: 유지보수, 지원, 교통, 공급, 기존 시스템 수용)으로 인해 시스템에 부과되는 요구사항을 설명합니다.]

3.2.7          온라인 사용자 문서 및 도움말 시스템 요구사항

[온라인 사용자 문서, 도움말 시스템, 주의사항에 대한 도움말 등에 대한 요구사항이 있는 경우 해당 요구사항을 설명합니다.]

3.2.8          구입한 컴포넌트

[이 섹션에서는 시스템, 적용되는 라이센싱 또는 사용법 제한 및 관련된 호환성/상호 운영 또는 인터페이스 표준에서 사용되는 구매한 모든 컴포넌트를 설명합니다. ]

3.2.9          인터페이스

[이 섹션은 시스템에서 지원해야 하는 인터페이스를 정의합니다. 시스템을 개발하고 인터페이스 요구사항에 대해 확인할 수 있도록 해당 특성, 프로토콜, 포트 및 논리 주소 등을 포함해야 합니다. 또한 시스템 내부 인터페이스에 부과될 모든 요구사항을 설명해야 합니다. 이러한 요구사항은 예를 들어, 시스템 디자인에서 기존 하드웨어 또는 소프트웨어 컴포넌트를 내부적으로 사용하도록 제한될 때 적용됩니다.]

3.2.9.1     사용자 인터페이스

[시스템에서 구현될 사용자 인터페이스를 설명합니다.]

3.2.9.2      하드웨어 인터페이스

[이 섹션은 시스템에서 지원되는 하드웨어 인터페이스(예: 논리 구조, 실제 주소, 예상 동작 등)를 정의합니다.]

3.2.9.3       소프트웨어 인터페이스

[이 섹션은 시스템에서 지원할 소프트웨어 인터페이스를 지원되는 또한 지원이 필요한 오퍼레이션 및 신호와, 프로토콜 및 데이터 특성의 관점에서 설명합니다.]

3.2.9.4       커뮤니케이션 인터페이스

[근거리 통신망 등과 같은 기타 시스템 또는 장치의 통신 인터페이스를 설명합니다.]

3.2.10        라이센스 부여 요구사항

[시스템이 제시할 라이센스 부여 필수 요구사항 또는 기타 사용 제한 요구사항을 정의합니다.]

3.2.11        법률, 저작권 및 기타 주의사항

[이 섹션은 시스템에 적용되는 모든 필수적인 법적 면책사항, 보증사항, 저작권 표시, 특허권 표시, 워드마크(wordmark), 상표 또는 로고에 대한 준수사항을 설명합니다.]

3.2.12        적용되는 표준

[이 섹션에서는 적용되는 표준 및 설명 중인 시스템에 적용되는 표준에 고유한 특정 섹션을 설명합니다. 예를 들어 법률, 품질 및 규제 표준, 사용성의 업계 표준, 상호운용성, 국제화, 운영 체제 준수 및 기타를 포함할 수 있습니다.]

4.                  지원 정보

[다음과 같은 지원 정보를 통해 SysRS를 보다 쉽게 사용할 수 있습니다.

아키텍처 및 사용자 인터페이스 프로토타입에 대한 정보가 포함됩니다. 부록이 포함되는 경우 SysRS는 해당 부록이 요구사항의 일부로 고려되는지 여부를 명확히 나타내야 합니다.