SRS (Software Requirements Specifications)

CONFIDENTIALITY/SECURITY WARNING

이 문서에 포함되어 있는 정보는 313 DEV GRP의 자산이며, 313 DEV GRP의 서면 허락 없이 사용되거나, 재 가공 되거나, 외부로 반출 할 수 없습니다. 이 문서에 대한 열람 및 보관할 수 있는 사람은 분실, 도난, 반출에 대한 책임을 자동 승계하는 것에 대하여 동의하는 자에 한 합니다. 

목 차

• 1 프로젝트 개요
• 1.1 프로젝트의 목표
• 1.2 프로젝트의 범위
• 1.3 문서 규칙
• 1.4 용어 정의 및 약어
• 1.5 관련 문서
• 1.6 대상 독차 및 역할별 체크리스트
• 1.7 프로젝트 결과물
• 1.7.1 결과물 유형
• 1.7.2 결과물 명칭(가칭) 및 버전
• 1.7.3 지적재산권
• 1.7.3.1 예시 : 특허 명칭(가칭) 1
• 2. 전체 설명
• 2.1 제품 조망
• 2.2 시스템 구성
• 2.3 동작 방식
• 2.4 주요 기능
• 2.5 사용자 프로파일
• 2.5.1 예시) 프로파일1: PC사용자
• 2.5.2 예시) 프로파일2 : 소규모 조직 보안 관리자
• 2.5.3 예시) 프로파일3: TrusGuard SSL VPN 원격 사용자
• 2.6 설계와 구현상 제약 조건
• 2.7 가정과 종속 관계
• 2.7.1 예시) APC 4.5 프로젝트
• 2.8 하위 호환성
• 3. 환경
• 3.1 설치 환경
• 3.1.1 하드웨어 환경
• 3.1.2 소프트웨어 환경
• 3.1.2.1 운영체제
• 3.1.2.2 기타 소프트웨어
• 3.1.3 네트워크 환경
• 3.2 제품 설치 및 설정
• 3.3 배포
• 3.3.1 패키지 구성
• 3.3.1.1 예시) 마스터 CD
• 3.3.1.2 예시) 온라인 설치 패키지
• 3.3.3 배포 방법
• 3.3.4 패치 및 업데이트 방법
• 3.4 형상관리
• 3.4.1 산출물 위치
• 3.4.1.1 소스코드
• 3.4.1.2 문서
• 3.4.2 빌드 환경
• 3.5 결함관리
• 4. 인터페이스 요구사항
• 4.1 사용자 인터페이스
• 4.1.1 예시) 일반 사용자용 애플리케이션 인터페이스 요구사항
• 4.1.2 예시) 복구 모드 터미널 인터페이스 요구사항
• 4.1.3 예시) 관리자용 웹 인터페이스 요구사항
• 4.1.4 예시) 관리자용 터미널 인터페이스 요구사항
• 4.2 하드웨어 인터페이스
• 4.3 소프트웨어 인터페이스
• 4.4 통신 인터페이스
• 4.4.1 예시) 관리자용 통신 인터페이스
• 4.4.2 예시) 일반 사용자용 통신 인터페이스
• 5. 비-기능 요구 사항
• 5.1 성능
• 5.1.1 예시) 성능 시험 환경 
• 5.1.2 예시) 성능 시험 성공/실패 기준
• 5.2 보안
• 5.2.1 보안성
• 5.2.2 암호화
• 5.2.3 취약성
• 5.3 소프트웨어 품질 특성
• 5.3.1 기능성
• 5.3.1.1 적합성
• 5.3.1.2 정확성
• 5.3.1.3 상호운용성
• 5.3.1.4 보안성
• 5.3.1.5 컴플라이언스
• 5.3.2 신뢰성(Reliability)
• 5.3.2.1 성숙성
• 5.3.2.2 오류 허용성
• 5.3.2.3 회복성
• 5.3.2.4 컴플라이언스
• 5.3.3 사용성(Usablility)
• 5.3.3.1 이해성
• 5.3.3.2 학습성
• 5.3.3.3 운용성
• 5.3.3.4 친밀성
• 5.3.3.5 컴플라이언스
• 5.3.4 효율성(Efficiency)
• 5.3.4.1 시간반응성
• 5.3.4.2 자원 효율성
• 5.3.4.3 컴플라이언스
• 5.3.5 이식성(Portability)
• 5.3.5.1 적응성
• 5.3.5.2 설치성
• 5.3.5.3 공존성
• 5.3.5.4 대체성
• 5.3.5.5 컴플라이언스
• 5.3.6 유지보수성(Maintainability)
• 5.3.6.1 분석성
• 5.3.6.2 변경성
• 5.3.6.3 안정성
• 5.3.6.4 시험성
• 5.3.6.5 컴플라이언스
• 5.4 국제화 & 현지화(I18N, L12N)
• 5.4.1 인코딩
• 5.4.2 언어 지원 계획
• 5.4.3 로케일
• 5.5. 컴플라이언스
• 5.5.1 인증 획득
• 5.5.1.1 예시) CC인증
• 5.5.2 장애인 차별 금지법 준수
• 5.5.3 전략 물자 관리제도
• 5.6 외부테스트
• 5.7 오픈 소스 라이선스
• 6. 제품 기능
• 6.1 대분류1
• 6.1.1 중분류1
• 6.1.2 중분류2
• 6.1.3 중분류3
• 6.1.1.1 소분류1
• 6.1.1.1.1 세분류 1
• 6.1.1.1.2 세분류2
• 6.1.1.1.3 세분류3
• 6.1.1.1.4 세분류4
• 6.2 대분류 2
• 6.2.1 중분류 1
• 6.2.1.1 소분류 1
• 6.2.1.1.1 세분류1
• 6.3 대분류 3
• 6.3.1 중분류 1
• 6.3.1.1 소분류 1
• 6.3.1.1.1 세분류 1

1 프로젝트 개요

1.1 프로젝트의 목표

프로젝트의 수행 목표를 서술한다.

1.2 프로젝트의 범위

프로젝트 수행(또는 개발) 범위와 프로젝트 결과물의 적용 범위를 서술한다.

1.3 문서 규칙

본 문서의 작성과 읽을 때 필요한 규칙은 다음과 같다.

• DOCS 온라인 문서로 작성하고 읽는다.
• 굵은 텍스트는 강조해야할 문자열에 사용하는 스타일이다.
• 그림, 표에 대해
• 반드시 캡션을 붙여서 사용한다. 캡션은 그림이나 표 위에 기재한다.
• 각 장을 삭제하지 않는다. 기재할 내용이 없으면 N/A를 기재한다.
• 문서의 버전 및 리비전 표기 규칙은 다음과 같다.
• 요구 사항이 확정된 상태를 "기본 형상(baseline)" 이라 한다. 최초 기본 형상 승인 시점의 문서 버전은 "1.0"으로 권장한다.
• 기본 형상이 변경되어 재승인을 거칠 때나, 공식적 배포(예: RTM, 리뷰 등)가 이루어 질 때 마이너 버전을 "1"씩 증가시킨다.
• 기능 요구 사항의 검토 단계를 표현하기 위해 레이블(Label)을 사용한다.
• 레이블은 기능 요구 사항 뒤에 대괄호를 사용하여 표기한다.
• [TBD] 는 아직 결정되지 않은 사항(TBD, To Be Determined)을 표시하는 레이블이다. 기본 형상의 선언 시점에는 [TBD] 기능 요구사항이 없어야 한다.
• [Next]는 프로젝트의 구현 범위에서 제외할 요구 사항을 표시하는 레이블이다. [Next] 요구 사항은 추후 개발 범위에서 다시 검토한다.
• 기능 요구 사항의 우선순위를 표시 할 필요가 있을 때는 아래와 같이 표기한다.
• 숫자가 작을수록 우선순위는 높다.
• 상위 우선순위를 상속한다. 상위와 다를 경우 별도로 표시한다.
• (우1): 높은 우선순위, 핵심 구동 기능 
• (우2): 중간 우선순위, 구현에 큰 위험이 없는 기능. 사용자는 다음 버전까지 기다릴 수 있다.
• (우3): 낮은 우선순위, 위급하지 않은 기능. 사용자는 영원히 기다릴 수도 있다.
• (우4): 불필요한 기능, 개발시간만 소비하는 기능. 제품의 가치와 하등의 관계가 없는 기능 
• 기능 요구 사항은 고유한 식별 ID 부여를 권장 한다.
• 기능 요구 사항의 변경을 표시할 때 준수할 규칙은 다음과 같다.
• 기울임 표시는 나중에 지원할 내용이거나, 지원하지 않을 내용을 명확하게 표시할 때 사용한다.
• 이중 취소선(예: Automotive Intelligence): 기본 형상 확정 이후 단계에서 특정 요구 사항을 제외(spec-out)하면 (스타일로 지정된) 이중 취소선을 사용한다.
• 기능 요구 사항의 추가, 수정, 삭제가 발생하면 문서를 SVN에 커밋할 때 [버전][날짜][작업자][작업항목 및 변경 이유] 형식으로 로그를 남긴다.

1.4 용어 정의 및 약어

본 문서에서 자주 사용하는 용어 및 약어는 다음 표를 참고한다. 용어/약어가 너무 많아 이곳에 기술하는 것이 부적절한 경우 별도의 장으로 나누어 본 문서의 마지막 장에 서술한다.

표 1-1 문서에서 사용하는 관련 용어/약어 

표 1-2 제품/기술/서비스 용어/약어 

1.5 관련 문서

SRS 산출에 사용된 문서와 SVN 경로는 다음과 같다. (다음은 콘텐츠 예시임)

•  제품기획서: http://svn.313 DEV GRP.co.kr/313 DEV GRPDoc/Product/GateSecurity/UTM/1.0/00.기획
•  Onepager:

1.6 대상 독차 및 역할별 체크리스트

본 문서의 독자는 자신의 역할에 따라 다음 체크리스트를 기준으로 문서를 읽는다.

• 제품기획자(제품기획서에서 기술한 요구사항이 SRS에 반영되었는지 확인한다.) 사용자 프로파일이 실제 사용자를 잘 대표하는지 확인한다. PM이 다음 항목을 작성할 수 있도록 기획서를 제공할 책임이 있다. (2장. 제품 조망, 주요 기능, 사용자 프로파일(UX와 협업 요구됨)) 주요 기능에 기술한 내용이 6장에 기술한 제품 기능과 일치하는가? 인증에 다음 사항이 제시되었는지 확인한다.  - 인증 획득 필요성  - 획득이 필요한 인증의 종류(예: CC인증, GS인증, IPv6 Verified, CheckMark, ICSA, ...)  - 정보보호제품 보안 규적 준수 필요성  - 인증을 위한 준비 사항  - 인증 소요 비용

• 프로젝트 관리자(프로젝트 관리자는 프로젝트 진행과 관련하여 다음 사항을 확인한다.) 설계와 구현 상 제약조건을 모두 명시하였는가? 다른 프로젝트나 기술에 대한 가정과 종속 관계를 모두 명시하였는가? 주요 기능이 제품 기능과 일치하는가? 제품 기능 기술이 사용자 관점에서 작성되었는가? 제품 기능 기술이 구체적이고 명확한가? 제품 기능의 세부 기능에 부여된 우선 순위가 타당한가? 기본 형상의 선언 시점에 [TBD]가 있지는 않은가? [Next]가 붙은 제품 기능에 대해 PP 및 협력 부서와 협의가 이루어졌는가? 장애인 접근성이 필요한가? 유지보수 프로젝트인 경우  - 이전 버전에 대한 하위 호환성 범위가 명시되어 있는가?  - 하위 호환을 고려한 마이그레이션 계획이 제시되어 있는가?

• 개발자(개발자는 설계를 고려하여 다음 사항을 확인한다.) 기능과 관련된 외부 인터페이스  - 사용자 입장에서 기능 사용에 필요한 인터페이스 입력 값/유효범위  - 외부 시스템 입장에서 기능 사용에 필요한 인터페이스  - 통신 인터페이스가 사용하는 포트 번호와 프로토콜  - 관련 있는 물리 인터페이스 다른 제품과 통신을 주고 받는 경우  - 대상 제품 이름과 버전  - 통신을 정의한 IRS 항목 식별 ID 기능이 동작하는데 필요한 라이브러리나 외부 모듈/서비스 기능의 동작 설명 오픈 소스 라이선스  - 오픈 소스 이름, 라이런스 종류를 기재했는가?

• 품질보증 담당자 설치 환경 기술이 명확한가?  - 테스트 환경 구성에 필요한 하드웨어 정보가 명확한가?  - 테스트 환경 구성에 필요한 운영체제 정보가 명확한가?  - 테스트 환경 구성에 필요한 기타 소프트웨어 정보가 명확한가? 제품 설치 및 설정 단계가 명확한가? 각 인터페이스의 입력 값/유효범위가 기술되어 있는가?  - 사용자 입장에서 기능 사용에 필요한 인터페이스, 입력 값/유효 범위  - 외부 시스템 입장에서 기능 사용에 필요한 인터페이스  - 통신 인터페이스가 사용하는 포트 번호가 프로토콜  - 관련 있는 물리 인터페이스 제품 기능이 누락한 인터페이스는 없는가? 성능 목표가 계량 가능한 수치로 표시되어 있는가? 결함 관리 계획이 수립되었는가? 유지보수 프로젝트인 경우  - 이전 버전에 대한 하위 호환 범위가 명시되어 있는가?  - 하위 호환을 고려한 마이그레이션 계획이 제시되어 있는가? 관련 문서 중, QA 문서 정보/경로가 정확한가?

• 사용자 경험 & 제품디자인(UX) 사용자 프로파일이 실제 사용자를 대표하는가? 사용자 인터페이스를 설계할 때  - 고려해야 할 설계와 구현상 제약조건이 있는가?  - 제품 기능에 사용자 입장에서 필요한 인터페이스와 입력 값/유효범위가 기술되어 있는가? 관련 문서 중, UX 문서 정보/경로가 정확한가?

• CC인증 담당자 2.1절 "전체 설명"에서 인증 대상 제품의 범위를 확인한다. 3.1절 "설치 환경"에 인증 대상 운영체제 및 하드웨어 장비가 포함되어 있는지 확인한다. 3.3절 "배포" 방식이 안전한 방식을 사용하는지 확인한다. 5.2절 "보안" 요구 사항을 만족하는지 확인한다. 5.7절 "오픈 소스 라이선스"에 기술된 본 프로젝트의 오픈 소스에 알려진 취약성이 있는지 확인한다.

• 기술문서 담당자(TW) 제품 조망이 제품의 개요를 충분히 제공하는가? 시스템 구성이 제품의 설치/배치 기술에 참고할 만한가? 사용자 프로파일이 매뉴얼 독자의 지식 수준을 제공하는가? 설치 환경 기술이 명확한가? - 하드웨어 정보가 명확한가? - 운영체제 정보가 명확한가? - 기타 소프트웨어 정보가 명확한가? 제품 설치 및 설정 단계가 명확한가? 제품 기능에 사용자 입장에서 필요한 인터페이스 입력 값/유효범위가 기술되어 있는가? - 매뉴얼 관련하여: 사용자 입장에서 기능 사용에 필요한 인터페이스, 입력 값/유효범위 - 매뉴얼 관련하여: 외부 시스템 입장에서 기능 사용에 필요한 인터페이스 - 매뉴얼 관련하여: 통신 인터페이스가 사용하는 포트 번호와 프로토콜 - 매뉴얼 관련하여: 관련 있는 물리 인터페이스 제품 기능이 누락한 인터페이스는 없는가? 유지보수 프로젝트인 경우 - 제품 도입 가이드와 관련하여: 이전 버전에 대한 하위 호환 범위가 명시되어 있는가? - 제품 도입 가이드와 관련하여: 하위 호환을 고려한 마이그레이션 계획이 제시되어 있는가? 법적 고지사항과 관련하여 사용하는 오픈 소스 라이선스 정보가 있는가? 산출물 문서 중, TW 문서 정보 및 SVN 경로가 정확한가?

• 기술지원 담당자 시스템 구성이 사용자의 이용 환경에 적합한가? 사용자 프로파일이 실제 사용자를 잘 대표하는가? 유지보수 프로젝트인 경우 - 이전 버전에 대한 하위 호환 범위가 명시되어 있는가? - 하위 호환을 고려한 마이그레이션 계획이 제시되어 있는가? 제품 설치 및 설정 단계가 사용자의 이용 환경에 적합한가? 도움말/매뉴얼 구성이 사용자의 산출물 이용 상황에 적합한가? 비-기능 요구 사항이 타당한가? 제품 기능(세분류 기능 포함)에 부여된 우선 순위가 타당한가? 사용자의 요구 사항 중 제품 기능에서 누락된 것은 없는가?

• 제품 영업 담당자 사용자 프로파일이 실제 사용자를 잘 대표하는가? 인증이 필요한 프로젝트인가? 고객사의 요구 사항이 제품 기능(세분류 기능 포함)에 반영되어 있는가? 제품 기능(세분류 기능 포함)에 부여된 우선 순위가 타당한가?

• 연동 제품 PM 대상 제품이 연동 제품과 통신을 주고 받는 경우 다음 내용을 확인한다. - 대상 제품 이름과 버전 - 통신을 정의한 IRS 항목 식별 ID 유지보수 프로젝트인 경우 - 이전 버전 연동 제품에 대한 하위 호환 범위가 명시되어 있는가? - 하위 호환을 고려한 마이그레이션 계획이 연동 제품에 영향을 미치는가?

1.7 프로젝트 결과물

1.7.1 결과물 유형

프로젝트 결과물의 유형은 다음과 같다.

1.7.2 결과물 명칭(가칭) 및 버전

결과물 명칭(가칭) 및 타겟버전을 서술한다.

1.7.3 지적재산권

본 프로젝트와 관련하여 지적재산권화되어야 할 주요 기술이 있다면 해당 기술에 대해서 간략히 기술한다.

본 프로젝트에서 사용하는 기술 중 타사에서 이미 특허화된 내용이 있다면 특허의 명칭, 출원번호, 출원인의 해당 특허 내용을 간단히 기술한다.

본 프로젝트에서 사용하는 기술 중 본사에서 출원된 특허(또는 디자인)에 기반한 부분은 해당 특허(또는 디자인) 내용을 명칭, 출원번호, 특허(또는 디자인) 내용을 간단히 서술한다.

1.7.3.1 예시 : 특허 명칭(가칭) 1

출원자

예시) 보안정책팀 허훈 책임연구원

기술개요

기술개요에 대하여 설명한다.

2. 전체 설명

2.1 제품 조망

프로젝트 산출물의 전체적인 구성 및 동작, 기능 등에 대해 제품 기획자가 간략하게 서술한다. 본 프로젝트 산출물과 다른 313 DEV GRP 제품(또는 신규 제품)과의 관계 및 연관성, 위치에 대해 정보를 서술한다.

제품조망은 다음과 같은 내용이 필요하다.

제품의 분류 정보. 예를 들어"XXXX는 안티바이러스 제품이다." 라거나, "XXX는 고성능 네트워크 침입 차단 제품으로 전용 어플라이언스에서 동작한다."와 같이 서술한다.

자세하지는 않아도 일반적인 제품 사용 환경 기술이 필요하다. 굳이 여기서 기술하지 않는다면 환경에서 상세한 내용을 제공한다.

2.2 시스템 구성

프로젝트 산출물의 전체 시스템 구성도를 서술한다.

프로젝트 산출물이 단일 시스템에서 운영되는 경우, 운영체제 내에서 산출물의 위치, 운영체제와 다른 애플리케이션 간 관계도를 제시한다.

프로젝트 산출물이 분할 가능한 여러 개의 서브 시스템으로 분리되어 운영되는 경우, 각 서브 시스템 단위로 구성도를 제시한다.

프로젝트 산출물에 안랩이 개발하지 않은 3'rd party의 제품(예, DB 프로그램, 웹서버 등)을 포함하여 전체 시스템 구성을 제시한다.

2.3 동작 방식

시스템 구성도를 기준으로 동작 원리 및 시나리오를 서술한다.

2.4 주요 기능

프로젝트의 산출물의 주요 기능을 사용자 관점에서 간략히 서술한다. 상세한 내용은 6장 제품 기능을 참고하도록 한다. 6장에서 기술되는 기능 명세 중 최상위 수준 기능을 열거하고, 간략히 기능을 서술한다.

아래 6장 내용과 비교해서 각 기능간 의존도(dependency)를 포함해야 한다. 어떤 기능이 켜져있거나 동작이 되고 있어야 다른 동작에 영향을 미치는지를 확인할 수 있다.

2.5 사용자 프로파일

프로젝트 산출물의 사용자 특성을 기술한다. 제품 특성에 따라 다른 유형의 사용자가 있을 수 있다. 예를 들어 어플라이언스 기기는 장비의 모든 기능을 제어할 수 있는 관리자, 정보 조회만 허용된 관리자, 그리고 어플라이언스 기가가

제공하는 서비스를 이용하는 일반 사용자, 그리고 제품의 설치단계부터 관리자에게 사용권을 넘기기 전까지 모든 설치과 설정을 담당하는 네트워크 엔지니어로 유형을 나눌 수 있다.

사용자 프로파일은 사용자의 사용 환경, 사용 빈도, 제품에서 주로 사용하는 기능, 제품과 IT 지식 수준 등을 포함해야 한다.

2.5.1 예시) 프로파일1: PC사용자

V3IS 의 주요 사용자는 Windows 시스템의 관리자 권한을 갖는 사용자들이다.

• 이들은 시스템 전체 제어 권한이 있지만, 안전한 PC의 사용방법은 잘 모른다.
• 스스로 V3 IS 를 설치할 수도 있지만, 안전한 PC의 사용방법은 잘 모른다.,
• 안티바이러스 제품은 필요하지만 불편하다고 생각한다.
• 주로 사용하는 기능들
• 검사 기능 : 전체검사 & 빠른검사 기능
• 실시간검사 : 시스템을 느리고 만든다고 믿고 끄는 경우가 많다.
• 잘 사용하지 않는 기능들PC가 감염된 후에야 제품을 사용하는 경우가 많다.
• 네트워크 보안 기능들
• 파일 완전 삭제
• 업데이트 설정

2.5.2 예시) 프로파일2 : 소규모 조직 보안 관리자

소규모 조직은 구성원의 역할 분담이 명확하지 않아 다른 업무와 병행해서 관리 책임을 지는 관리자가 주요 사용자가 된다. 보안에 대한 전문 지식을 갖추지 못했기 때문에 관리포인트를 줄이고, 문제가 발생한 PC/서버의 장애, 보안 사고를 처리하고 싶어한다.

• DB,서버 등 다른 시스템을 관리하는 경우가 많다.
• 개발 업무와 겸직하는 경우도 많다.
• 투입할 수 있는 예산이 많지 않아 올인원 솔루션을 원한다.
• 보안 전문 지식이 많지 않다.
• 주로 사용하는 기능들
• APC에 의한 원격 설치, 정책 적용 기능
• 주요 시스템 모니터 기능

2.5.3 예시) 프로파일3: TrusGuard SSL VPN 원격 사용자

다른 업체에 파견 근무하거나, 컨설팅 등을 수행하는 사용자들

2.6 설계와 구현상 제약 조건

프로젝트에 따른 개발 과정에서 고려할 기술적인 제약 조건을 서술한다. 하드웨어 상의 제약조건은 하드웨어 환경에서 기술한다. 프로젝트 산출물 설치에 필요한 애플리케이션, 라이브러리 파일은 소프트웨어 환경에 서술한다.

• 반드시 사용해야 할 기술
• 사용하지 말아야 할 기술
• 설계 도구
• 개발 도구
• 개발 언어
• 데이터베이스
• 준수해야할 개발 규칙(프로그래밍 가이드, 오류코드 가이드)

2.7 가정과 종속 관계

본 프로젝트를 수행하기 위해서 필요하거나, 반드시 수행 또는 결정되어야 할 전제조건 또는 선행되어야 할 프로젝트에 대해 기술하여, 그 결과에 따라 본 프로젝트의 어떤 부분에 어떻게 영향을 미칠지를 서술한다. 

또한, 통제 불가능한 외부요소에 의해 영향을 받을 수 있는 경우, 그 요소에 대해 서술한다.

2.7.1 예시) APC 4.5 프로젝트

V3 IS 9.0은 APC를 통해 원격 설치, 제어가 가능하다. 본 프로젝트의 기본 형상이 제공하는 모든 보안 기능은 APC에 의해 제어가 가능하다. APC 개발 프로젝트는 V3 IS 9.0과 병행한다.

• 프로젝트 개발 문서: 

2.8 하위 호환성

신규개발이 아닌 경우, 기존 산출물과의 호환성 방법 및 마이그레이션 방법을 서술한다. 호환성 정보로는 다음과 같은 사항을 제시한다.

• 호환 가능한 이전 버전
• 호환성을 보장할 수 없는 경우다른 프로젝트 산출물과 함께 사용하는 경우, 연동 가능한 버전 정보
• 마이그레이션 방법과 마이그레이션 도구 계획
• 이전 버전에 대한 백포트(backport) 또는 패치 계획

3. 환경

3.1 설치 환경

본 프로젝트의 결과물을 설치하기 위한 하드웨어, 소프트웨어, 네트워크 환경을 기술한다.

제품의 설치삭제와 빌드시스템, 마스터의 구성과 설치파일 목록 등에 대한 보다 자세한 사항을 기술해야 할 필요성이 있는 경우 설치요구명세서를 별도로 작성할 것을 권장한다.

설치요구명세는 샘플과 템플릿을 이용한다.

3.1.1 하드웨어 환경

결과물 설치에 필요한 하드웨어 최소 사양, 권장 사양을 기술한다. 산출물을 여러 시스템에 분리되어 설치해야 하는 경우, 각 설치 대상 시스템 별로 사양을 서술한다.

산출물이 전용 어플라이언스에 설치되는 경우, 해당 기기의 하드웨어 사양을 서술한다. 어플라이언스의 하드웨어 사양은 별도 파일로 제공할 수 있다.

이때 명시가 필요한 항목은 아래와 같다.

3.1.2 소프트웨어 환경

3.1.2.1 운영체제

여기에 명시되는 운영체제는 개발 시에도 중요하지만, 테스팅 단계에서 모두 테스트해야 하므로 명확하게 작성한다. 다음과 같은 요소를 고려해서 작성한다.

• 플랫폼(Windows, Linux, Unix, Android, iOS 등)
• OS 버전 & 에디션(여러 개의 에디션이 존재한다면)
• 서비스 팩 또는 패치 요구 사항

3.1.2.2 기타 소프트웨어

OS 외에 지원 또는 제한되는 소프트웨어를 명시한다. 예를 들면 DBMS나 웹 브라우저 같은 것들이 고려되어야 하는 경우가 많다. 물론 이름과 버전, 서비스팩, 패치 요구 사항을 정확하게 적어야 한다.

3.1.3 네트워크 환경

프로젝트 산출물이 네트워크 연결이 필요한지 명시한다. 어느 시스템(또는 네트워크)과 어떤 통신을 수행하는지는 통신 인터페이스에서 기술한다. 프로젝트 산출물이 네트워크 어플라이언스인 경우, 설치되어 운영하는 네트워크 환경을 명시한다.

3.2 제품 설치 및 설정

본 프로젝트의 산출물의 설치나 설정 과정에서 필요한 요구사항을 기술한다. 예를 들어 DBMS나 .NET 프레임워크를 먼저 설치해야 하는 제품이 있을 수 있다. 설치에 필요한 다른 어플리케이션이나 라이브러리 파일을 프로젝트 산출물과 

함께 배포하기로 결정했으면, 마스터 구성에 해당 애플리케이션과 라이브러리 파일 목록을 작성한다.

또한 제품을 실행하는데 필요한 기본 설정 요소 및 방법에 대한 요구사항을 기술한다. 설치나 설정 변경을 위해 별도의 툴이 필요한 경우에는 그 툴에 대한 부분도 명시한다.

어플라이언스 제품은 단일 하드웨어에 여러 소프트웨어를 설치하는 경우가 있을 수 있다. 하드웨어 구성에 따라 설치 방법을 나누어 작성한다.

• 제품 설치에 필요한 사전 준비 조건
• 단일 머신에 설치하는 경우
• 여러 머신에 분산 설치하는 경우

3.3 배포

3.3.1 패키지 구성

3.3.1.1 예시) 마스터 CD

3.3.1.2 예시) 온라인 설치 패키지

온라인 설치 패키지는 마스터 CD 구성 형식과 다를 수 있다. 설치 프로그램만 제공하는 경우가 많기 때문에 매뉴얼과 기타 유틸리티의 제공 방법(예: '안랩 홈페이지에서 로그인 후 제품 구매 내역에서 PDF 매뉴얼을 제공한다.' 또는 '마스터 CD와 동일한

구성물을 압축 파일로 다운로드')을 기술해야 한다.

3.3.3 배포 방법

본 프로젝트의 산출물 마스터를 어떤 방법으로 배포할 것인지를 서술한다. 예를 들어, CD로 배포하거나, 웹페이지에서만 다운로드 받게 할 수 있다. 어플라이언스 기기는 펌웨어를 전용 장비에 설치해 배포하는 방법을 사용한다.

3.3.4 패치 및 업데이트 방법

배포 후 제공할 제품의 패치나 업데이트(엔진이나 시그니처를 사용하는 제품의 경우) 종류와 방법을 명시한다. 스마트 업데이트를 사용해야 하는지 여부와 수동 패치를 위한 설치본 제공 필요 여부 등도 모두 포함된다.

3.4 형상관리

3.4.1 산출물 위치

3.4.1.1 소스코드

소스코드는 다음 경로에 저장한다.

• 예시: http://svn.313 DEV GRP.co.kr/313 DEV GRP/Product/...

3.4.1.2 문서

문서 소스는 다음 경로에 저장한다.

3.4.2 빌드 환경

소스의 빌드를 위한 시스템 환경, 빌드 툴, 컴파일러 등에 대해서 명시한다. 기본적으로 모든 소프트웨어 개발은 별도의 빌드 시스템을 사용하는 것을 원칙으로 하며 로컬 빌드는 개발자 개인의 유닛 테스트 목적인 경우를 제외하고 금지한다.

3.5 결함관리

이슈관리를 위해 사용할 시스템 및 이슈트래킹 프로세스. 사내 기본 이슈관리 시스템인 WORKS를 사용하고 "제품개발 프로세스"를 따르면 프로세스를 별도로 명시할 필요는 없다.

• WORKS 프로젝트 이름 : 

4. 인터페이스 요구사항

4.1 사용자 인터페이스

4.1.1 예시) 일반 사용자용 애플리케이션 인터페이스 요구사항

4.1.2 예시) 복구 모드 터미널 인터페이스 요구사항

4.1.3 예시) 관리자용 웹 인터페이스 요구사항

4.1.4 예시) 관리자용 터미널 인터페이스 요구사항

4.2 하드웨어 인터페이스

필요한 경우 하드웨어 종속적인 요구 사항들을 기술한다. 사용자가 하드웨어(이하 장비)에 접근하기 위해 제공되는 물리적인 인터페이스로서 NIC(Network Interface Card), Serial 포트, LCD, LED 등 인터페이스를 모두 기술한다.

4.3 소프트웨어 인터페이스

4.4 통신 인터페이스

4.4.1 예시) 관리자용 통신 인터페이스

4.4.2 예시) 일반 사용자용 통신 인터페이스

5. 비-기능 요구 사항

5.1 성능

제품이 달성해야 하는 성능 요구 사항 및 성능 목표를 기술한다. 성능 테스트의 Pass/Fail 여부를 판단하는 근거가 되므로, 반드시 정량적으로 측정할 수 있도록 기술한다.

성능 측정 시 사용할 하드웨어 사양을 반드시 기재한다.

성능 측정 시 사용할 소프트웨어 종류와 설정 값을 함께 기술한다.

아래 성능 측정 항목은 프로젝트에 따라 선택 적용하거나 추가할 수 있다.

• 처리량(Throughput)
• 동시 접속 수(Concurrent Session)
• 응답 시간(Response Time)
• 리소스 사용량(Memory/CPU/Disk/Network Usage)
• 검사 시간(Scan Speed)
• 부팅 시간(Boot Time)

5.1.1 예시) 성능 시험 환경 

5.1.2 예시) 성능 시험 성공/실패 기준

아래 성능 시험 실패 기준은 V3를 기준으로 한 가상의 목표이므로, 각 프로젝트의 성격에 맞는 성능 목표를 설정한다.

5.2 보안

제품이 요구하는 보안성 기준치 요구 사항을 기술한다. 다음의 체크리스트를 활용한다.

5.2.1 보안성

최소한의 보안성 요구사항으로 아래 위치의 체크리스트 점검을 본 SRS에 첨부한다.

http://svn.313 DEV GRP.co.kr/313 DEV GRPDoc/Public/Guideline/보안성 가이드

5.2.2 암호화

사용 가능한 암호 알고리즘을 확인한다.

http://svn.313 DEV GRP.co.kr/313 DEV GRPDoc/Public/Guideline/보안성 가이드

5.2.3 취약성

최소한의 제품군 별 취약성으로 다음의 체크리스트가 활용한다.

http://svn.313 DEV GRP.co.kr/313 DEV GRPDoc/Public/Guideline/보안성 가이드

5.3 소프트웨어 품질 특성

ISO/IEC 9126은 소프트웨어에 요구되는 품질 특성에 대해서 정의하고 있는 표준이다. 품질 특성은 주특성과 하위의 부특성들로 이루어져 있다. 이 특성들은 모든 소프트웨어에 공통적으로 요구되는 것이기는 하지만, 개발하고자 하는 소프트웨어의 사업적 가치나 투입할 수 있는 비용의 규모, 개발 기간 등에 의해서 적절한 수용 범위를 정하는게 중요하다.

본 절의 내용들은 기능 이외의 요구사항을 도출하는 과정에서 검토해 볼 질문들을 제시하며 선택적으로 적용하면 된다.

따라서 채택한 내용들을 반드시 본 절에 기록할 필요는 없고, 요구 내용에 따라서 나눠져 있는 본 SRS의 여러 항목 중 적절한 부분에 기술하면 된다.

5.3.1 기능성

소프트웨어가 특정 조건에서 사용될 때, 명시된 요구(본 SRS 또는 기획서 등 요구사항을 정리한 문서에 명시된 요구사항)와 내재된 요구(요구명세 문서에 적혀있지는 않지만, 당연히 소프트웨어 개발 시에 고려되어야 할 요구사항)를 만족하는 기능을 제공하는 소프트웨어 제품의 능력을 말한다.

5.3.1.1 적합성

요구사항이 소프트웨어에 적절하게 기능으로 제공되었는지 여부를 말한다.

문서(SRS, 도움말, 설명서 등)에 기술되어 있는 기능이 모두 구현될 것.

• 요구문서 또는 사용자 문서의 내용과 구현된 소프트웨어가 일치할 것(프로젝트 진행 중 요구사항 변경이 발생할 경우 관련 문서에도 모두 반영되어 있을 것)

소프트웨어에 필요한 필수적인 기능이 충분히 구현될 것

• 소프트웨어가 달성하고자 하는 용도 또는 목적에 비추어 충분한 기능을 제공할 것

5.3.1.2 정확성

올바른 혹은 요구된 결과를 정확하게 제공하는지 여부가 핵심이다.

설계 문서 또는 사용자 문서에 기술된 기능과 구현된 기능 결과의 일치 여부

소프트웨어 동작의 결과값과 문서에 정의된 요구값의 일치 정도

• 허용 오차

경계값이 정의되어 있을 것

• 최소 또는 최대값
• 키의 길이
• 파일 내 레코드의 최대 수
• 탐색 기준의 최대 수
• 최소 샘플 크기

5.3.1.3 상호운용성

하나 이상의 명세된 시스템 또는 타 소프트웨어와 상호작용할 수 있는지가 핵심이다. 완전히 단독으로 동작하며, 동작 환경에 의존성이 전혀 없는 소프트웨어를 제외하고는 연동이나 호환을 위한 규칙이 필요하다.

그것은 인터페이스, 메시지, 프로토콜 등으로 말할 수 있는데, 표준을 따르거나 별도의 규격을 정할 수도 있다.

• 장치 인터페이스
• API(Application Programming Interface)
• 메시지
• 프로토콜
• 기타 다른 소프트웨어나 시스템과 연동할 수 있는 기능
• 상호 운용에 관한 정보 제공

5.3.1.4 보안성

권한이 있는 접근을 허용하고, 권한이 없는 접근으로부터 시스템과 데이터를 보호할 수 있는 것이 핵심이다.

• 데이터의 기밀성
• 데이터(설정값, 감사기록, 교환 데이터 등) 무결성 보장
• 접근제어부인방지 필요성(디지털 서명 등)
• 접근 감시 정보 제공(주로 로그 관련 기능)
• 접근 제어 기능
• 개인정보 보호

5.3.1.5 컴플라이언스

기능과 관련된 표준, 관례 또는 법적인 규제를 충족하는 능력을 말한다.

• 개인정보보호
• 관리솔루션 제품의 경우 감사기록 유지 필요성
• 보안인증(CC)이 필요한 경우 암호화, 접근 제어 등 인증 요구 규격 준수 여부
• 장애인차별법에서 요구하는 기능 준수

5.3.2 신뢰성(Reliability)

명세된 조건에서 사용될 때 결함을 예방하고, 고장 발생시에도 정해진 성능 수준을 유지하며, 고장으로부터 회복하는 능력을 말한다.

5.3.2.1 성숙성

소프트웨어 내의 결함으로 인한 고장을 예방하거나 피해가는 소프트웨어 능력을 말한다.

• 허용되지 않는 입력으로 인한 고장을 막기 위해 입력값이 적절한지 체크하는 기능
• 결함 발생율
• 오조작 방지

5.3.2.2 오류 허용성

명세된 인터페이스를 벗어난 입력 또는 소프트웨어의 결함이 발생했을 때에도 명세된 성능 수준을 유지할 수 있는 능력을 말한다.

• 서비스가 다운되지 않고 계속 사용할 수 있는 시간(MBTF)
• 다운 회피율 : 결함으로 인해 프로그램 또는 시스템 전체의 다운을 발생시키는 정도
• 고장 회피율 : 결함이 발생하더라도 시스템에 심각한 문제를 발생시키지 않는 정도

5.3.2.3 회복성

소프트웨어 제품 사용 중 오류로 인한 영향을 회복하고 정상 사용 가능한 수준으로 회복하는 능력을 말한다.

• 데이터 손실/복구
• 결함에 의해서 영향받은 데이터를 복구 가능 여부
• 오류 발생 시 데이터 복구에 대한 정보가 제공 여부
• 오류 발생으로 데이터 손상시 데이터 복구율
• 소프트웨어 복구
• 한계 복구 시간 내에 성공적으로 복구가 완료되는 정도
• 결함으로 인해 소프트웨어가 중지된 경우 회복될 때까지 소요되는 시간
• 이용 가능율: 정해진 시간 동안 정상 이용 가능했던 시간과 오류로 인해 사용할 수 없었던 시간의 정도

5.3.2.4 컴플라이언스

신뢰성에 관한 규격, 표준, 관례 등을 말하는데, 인증을 필요로 하는 제품의 경우 인증에서 요구하는 규격도 있을 수 있다.

5.3.3 사용성(Usablility)

명세된 조건에서 사용될 경우 사용자에 의해 이해되고, 학습되고, 사용되고, 사용자에게 선호되도록 하는 소프트웨어 능력을 말한다.

5.3.3.1 이해성

소프트웨어가 적합한지 그리고 특정 작업과 사용 조건에서 어떻게 사용될 수 있는지를 사용자가 파악할 수 있도록 하는 능력을 말한다.

• 제품설명서를 통해 기능을 이해할 수 있는 정도
• 도움말을 통해 기능을 이해할 수 있는 정도(데모 또는 튜토리얼 포함)
• 소프트웨어의 메뉴 및 기타 인터페이스를 보고 기능을 이해할 수 있는 정도
• 소프트웨어 UI 상에 출력되는 메시지를 통해 사용을 이해할 수 있는 정도
• 소프트웨어의 입력 및 출력에 사용되는 데이터를 쉽게 이해할 수 있는 정도
• 구현된 소프트웨어 인터페이스들 간의 일관성 정도사용자 문서 내용간 일치 정도
• 인터페이스 일관성: 화면, 아이콘, 디스플레이 배치, 기능키 등
• 내용 일관성
• 용어, 약어, 명령어, 코드 및 다이어그램
• 사용자 문서 내에서 표시되는 위치의 일관성
• 소프트웨어의 사용을 안내하는 기능
• 사용자의 특성을 반영하는 기능

5.3.3.2 학습성

사용자가 소프트웨어 사용 및 응용을 학습할 수 있도록 하는 능력을 말한다.

• 기능에 대한 정보 제공
• 경계값에 대한 정보 제공
• 기능을 학습하는 데 소요되는 시간
• 학습을 통해서 사용할 수 있는 기능의 정도

5.3.3.3 운용성

사용자가 소프트웨어 제품을 운영하고 제어할 수 있도록 하는 능력을 말한다.

• 오류 발생 시 쉽게 복구할 수 있는 방법 제공
• 오류 발생 시 복구가 불가능한 경우 존재 여부
• 오류가 발생하지 않도록 기능 구현 또는 사용자에게 충분히 안내하고 있는지
• 소프트웨어 메시지가 충분히 이해하기 쉬운지(이해성과 관련)
• 기본으로 제시되는 절차 외에 사용자가 운용 절차를 변경할 수 있는지
• 소프트웨어의 동작 진행 상태를 파악할 수 있는지
• 제품 사용시 발생하는 오류의 증상 및 문제 해결에 관한 정보가 제공되는지

5.3.3.4 친밀성

사용자에 의해 선호되는 소프트웨어 제품의 능력을 말한다.

• 사용자가 인터페이스를 선호하는 것으로 조정할 수 있는지 여부
• 사용자가 선호하는 UI로 변경할 수 있는지(스킨 등)

5.3.3.5 컴플라이언스

사용성에 관련된 표준, 관례, 유형 안내 및 규제를 충족하는 능력을 말한다.

• 장애인차별금지법
• 웹 표준 준수 등

5.3.4 효율성(Efficiency)

명시된 조건에서 사용되는 자원의 양에 따라 요구된 성능을 제공하는 능력을 말한다.

5.3.4.1 시간반응성

사용자가 소프트웨어에 어떤 특정한 입력을 제공한 후부터 결과를 얻거나 목적을 달성하기까지 소요된 시간으로 평가한다. 사용자가 인내할 수 있는 한계 시간에 대한 고려도 필요하다.

• 반응시간 : 평균, 최대, 최소
• 처리율 : 평균, 최대, 최소
• 처리시간 : 평균, 최대, 최소

5.3.4.2 자원 효율성

명시된 조건에서 소프트웨어가 그 기능을 수행할 때 적절한 양과 종류의 자원을 사용한다.

• 데이터 전송률 : 최대, 최소, 평균, 사용 자원 대비 데이터의 전송량
• 입출력 자원사용률
• 메모리 사용률
• CPU 사용률
• 최대 부하 조건에서 자원 사용률
• 시스템 자원 능력과 소프트웨어의 처리 능력간의 상관 관계

5.3.4.3 컴플라이언스

효율성과 관련된 표준, 관례, 규격을 충족하는지 여부

5.3.5 이식성(Portability)

한 환경에서 다른 환경으로 전이될 수 있는 소프트웨어 제품의 능력을 말한다.

5.3.5.1 적응성

소프트웨어 내에서 이식의 목적으로 제공되는 것 이외의 활동 혹은 수단을 사용하지 않고 다른 명세된 환경으로 변경할 수 있는 소프트웨어 능력을 말한다.

• 기본적으로 제공되는 환경 이외에 다른 환경으로 변경할 수 있는가?(설정 등)
• 사용자 화면, 트랜잭션의 크기, 보고서 형식 등을 다양한 요구에 맞게 변경할 수 있는가?
• 데이터 구조 적응에 대한 정보가 제공되는가?
• 패치, 업그레이드 등의 경우 데이터의 손실이 발생하지 않는가?(발생할 가능성은?)
• 소프트웨어 재설치 시에도 백업 데이터로부터 복구가 가능한가?
• 지원하는 사양에 대한 정보가 제공되는가?
• 재설치, 패치, 업그레이드, 설정 변경이 용이한가?
• 소요 시간(또는 평균 시간)
• 필요한 작업의 수

5.3.5.2 설치성

명세된 환경에 설치될 수 있는 소프트웨어 제품의 능력을 말한다.

• 명세된 환경에 설치하는데 문제가 없는가?
• 설치에 관한 정보가 제공되는가?
• 제공되는 설명서 또는 사용자 문서만으로 설치가 가능한가?
• 제거하고자 할 때, 설치 전 상태로 완전히 제거 성공할 가능성은?
• 제거 시 재설치시 활용할 수 있도록 사용자 데이터 유지는 가능한가?
• 재설치하면 해당 데이터를 유지하면 실행이 가능한가?

5.3.5.3 공존성

컴퓨터의 자원을 공유하는 다른 독립적인 소프트웨어와 공존할 수 있는 소프트웨어 제품 능력을 말한다.

• 시스템 자원을 공유하는 타 소프트웨어와 충돌하지 않는가?
• 시스템 자원의 지나친 점유로 타 소프트웨어의 동작에 지장이 초래하지 않는가?
• 다른 소프트웨어와 동시에 사용가능한가?(화면 점유, 작업 전환 등)

5.3.5.4 대체성

동일한 환경에서 동일한 목적으로 사용되는 다른 소프트웨어를 대체할 수 있는 능력을 말한다.

• 대체하기 위해 필요한 기능을 모두 갖추고 있는지 여부

5.3.5.5 컴플라이언스

이식성과 관련된 표준, 관례, 규제 등을 충족할 수 있는지 여부

5.3.6 유지보수성(Maintainability)

소프트웨어 제품이 변경되는 능력. 변경에는 환경과 요구사항 및 기능적 명세에 따른 소프트웨어의 수정, 개선, 혹은 개작 등이 포함된다.

5.3.6.1 분석성

소프트웨어의 결함이나 고장의 원인 혹은 변경될 부분들의 식별에 대한 진단을 가능하게 하는 소프트웨어 제품의 능력을 말한다.

• 상태를 모니터링 하기 위해 필요한 데이터를 기록/저장하고 있는가?
• 소프트웨어의 결함이나 고장의 원인 또는 변경된 부분들을 식별할 수 있는가?
• 오류 발생 시 오류를 해결하기 위한 진단 기능이 제공되는가?시스템 또는 소프트웨어의 상태를 모니터링할 수 있는 기능이 제공되는가?
• 진단기능에 대한 정보가 제공되는가?
• 필요한 경우 특정 서비스에 대한 거래 로그를 남길 수 있는가?

5.3.6.2 변경성

명세된 변경이 가능하도록 하는 소프트웨어 제품의 능력을 말한다.

• 설정을 변경할 수 있는가?
• 소프트웨어 변경/변조를 제어할 수 있는가?
• 필요한 경우 환경 설정의 변경을 제어할 수 있는가?
• 기능 키를 재할당할 수 있는가?
• 매개변수나 연산 알고리즘의 변경이 가능한가?

5.3.6.3 안정성

소프트웨어 변경으로 인해 예상치 않는 결과를 최소화하는 소프트웨어 능력을 말한다.

• 변경으로 인해 사용자의 데이터 등의 손상을 발생시키는 경우
• 환경설정의 변경으로 인해 발생할 가능성이 있는 오류에 대한 정보 제공

5.3.6.4 시험성

변경된 소프트웨어의 결과를 확인할 수 있는 소프트웨어 제품의 능력을 말한다.

• 모든 소프트웨어 요소에 대해 테스트가 가능한가?
• 소프트웨어 자체적으로 정상적인지 여부를 시험할 수 있는 능력이 있는가?
• 테스트 자동화를 위한 고려가 필요한가?

5.3.6.5 컴플라이언스

유지보수성과 관련된 표준, 관례, 규제 등을 충족할 수 있다.

5.4 국제화 & 현지화(I18N, L12N)

제품 메시지와 테크니컬 라이팅 입장에서 국제와(Internationalization, I18N)와 현지화(Localization, L12N)에 대해서 서술한다. 

단일 국가나 지역에서만 사용되는 언어가 아닐 수 있으므로 여러 지역에서 사용되는 언어인 경우 지역을 함께 명시하는 것도 좋은 방법이다.

313 DEV GRP Internationalization Guideline 문서 및 관련 공통모듈(ex: AhnI18N2.dll) 적용 여부 등에 대해 기술한다.

• 313 DEV GRP Internationalization Guideline
• AhnI18N2.dll

5.4.1 인코딩

특별한 이유가 없다면 언어적인 제약을 피하기 위해 유니코드(UTF-8)를 사용한다.

• Message 및 Text 인코딩 : UTF-8
• Log 인코딩 : UTF-8
• DataBase 인코딩 : UTF-8

5.4.2 언어 지원 계획

프로젝트 산출물을 판매 대상 시장에 따라 다국어 작업을 병행하거나, 기준이 될 언어를 지정한다. 여기엔 다음과 같은 내용이 기술되어야 한다.

• 기준 언어(현지화 작업의 기준이 되는 언어): 한국어, 영어, 중국어 등에서 하나만 선택
• 현지화 계획
• 1차 목표(릴리즈 시점에 지원)
• 대상 언어 : 한국어, 영어, 중국어, 일본어...
• 2차 목표(마이너 버전 업그레이드 또는 패치를 통해 지원)
• 대상 언어 : 한국어, 영어, 중국어, 일본어...

5.4.3 로케일

지원하는 로케일을 기술한다.

• 지원 로케일: OS의 언어 로케일을 따름

5.5. 컴플라이언스

본 프로젝트 산출물이 준수해야 하는 법규 준수, 인증(Certification) 획득 필요성 등을 서술한다. 해외에 출시될 제품이라면, 출시 목표 시장에서 준수해야 할 규제항목도 조사해 간략히 서술한다.

어떤 법규를 준수해야 하는지, 획득해야 할 인증은 무엇인지, 받는다면 어떤 인증을 받아야 하는지, 언제 어떤 방법으로 진행하며, 무엇을 준비해야 하는지, 그 비용은 어떻게 되는지 서술한다.(PP/MK 협의 요망)

5.5.1 인증 획득

프로젝트 산출물이 외부 인증을 받아야 하는 경우 인증 준비, 방법, 시기 비용 등을 기술한다.

참고할 외부 인증 사항은 다음과 같다.

• MS Logo 인증
• CC(국제공통평가) 및 보안성 심사
• CheckMark
• VB100
• ICSA
• Good Software
• 중국 공안부 인증

5.5.1.1 예시) CC인증

프로젝트 산출물을 공공기관에 판매하려면 CC 인증 획득이 필요하다.

• 목표 : 국내용 CC 인증, EAL3 이상
• 인증 획득 예상 시점: 2013년 6월 말
• 인증을 위한 준비
• 프로젝트 진행과 동시에 인증을 병행해서 진행한다.
• 베타 버전을 CC 인증 담당자에게 전달한다.
• 베타 버전을 전달 이후 인증에 의한 수정 요청사항은 트렁크에 반영한다. 기본 형상에 영향을 주는 수정 요청사항이 발생하면 소스를 브랜치하여 처리하고, 다음 제품 개발에 머지한다.

5.5.2 장애인 차별 금지법 준수

장애인 차별 금지법 준수 여부를 기술하고, 시장 및 고객 요구 사항에 따라 해당하는 지침과 지침의 반영 범위를 기술한다.

UX팀의 가이드를 참고하여 작성할 수 있다.

참고)

• 미국 연방 정부 및 산하기관 요구 조건
• 미국 재활법 508조 지침 준수
• 국내 표준 지침
• 한국형 웹 콘텐츠 접근성 지침 2.0
• 장애인 웹 콘텐츠 사용성 지침_201012
• D_TTAS KO-1-0213_소프트웨어접근성지침 개정안
• 모바일 애플리케이션 접근성 지침(행안부고시 2011-38호)

위 참고자료는 아래 SVN에서 확인 가능하다.

http://svn.313 DEV GRP.co.kr/313 DEV GRPDocUI/Common/자료/외부자료/접근성 관련 자료/국내외 표준 지침 자료

5.5.3 전략 물자 관리제도

해외 수출용 제품은 전략물자에 해당하는지 확인이 필요하다. 정부에서 운영하는 전략물자관리시스템(http://www.yestrade.go.kr/)에서 확인할 수 있다.

해당 사항이 없다고 판단되는 경우, 본 항목은 N/A 처리한다.

5.6 외부테스트

제품 출시 전에 외부 베타 테스트나 필드 테스트 요구 사항이 있다면 서술한다. 마케터나 제품기획자와 협의할 필요가 있다.

상세 일정 및 레퍼런스 사이트 리스트 등은 개발계획서에 명시한다.

외부에서의 테스트나 특정 고객을 이용한 테스트 계획을 서술한다.

5.7 오픈 소스 라이선스

공개 소프트웨어(Open Source) 사용 여부와 라이선스 종류 및 중복 등에 대해 서술한다. 라이선스 회피 방법 및 소스 공개 범위와 방법에 대해서도 서술한다.

표 5-1 사용할 오픈 소스 라이선스

6. 제품 기능

주요기능에서 설명되었던 제품 주요 기능을 상세하게 분류하고, 설명한다. 상세화 수준은 작업량이 1~2일 정도로 산정 가능하도록 작성한다.

각 기능에는 입력과 출력, 입력 가능한 기본값과 유효범위, 기본상태가 기술되어야 한다.

특정 환경만 지원하는 기능이 있다면 기술한다.(예: 64bit 환경에서 동작하지 않는 기능, Windows 2000이하에서 동작하지 않는 기능, Vista 이상에서만 동작하는 기능 등.)

6.1 대분류1

6.1.1 중분류1

6.1.2 중분류2

6.1.3 중분류3

6.1.1.1 소분류1

6.1.1.1.1 세분류 1

6.1.1.1.2 세분류2

6.1.1.1.3 세분류3

6.1.1.1.4 세분류4

6.2 대분류 2

6.2.1 중분류 1

6.2.1.1 소분류 1

6.2.1.1.1 세분류1

6.3 대분류 3

6.3.1 중분류 1

6.3.1.1 소분류 1

6.3.1.1.1 세분류 1