SRS (Software Requirements Specifications)

CONFIDENTIALITY/SECURITY WARNING

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

 

목 차

 

 


 

 

1 프로젝트 개요

jsTree Service Framework (TSF) .

하나의 스키마 안에서 데이터 집합간의 구조적 관계와
스키마간의 릴레이션을 재사용 가능하게 협업화된 클래스들을 제공하는
서비스 레이어 프레임워크
이다.

1.1 프로젝트의 목표 및 배경

프레임워크는 구현 시 패턴을 제공하는 방식이나, 몇 가지 기능적인 부분을 제외한 서비스 구현 설계는 제시하지 않는다. 따라서 프레임워크를 사용하지만, 실제 구현은 패턴화 되지 않고, 요청 별 처리 프로세스를 만드는 방식을 취하다보니 단편화 현상이 발생하고, 이는 개발 일관성과 유지보수성에 악영향을 미치게 된다.

즉, 프레임워크를 사용하여 얻어지는 이득이나, 수준은 일정 범위를 벗어나게 되면, 그 실효성이 없어지는 현상이 일어난다. 이 현상은 서비스 코드를 작성하는 개발자의 수준과 철학이 코드에 반영되게 되며, 실제 프레임워크가 관여할 수 없는 부분이기 때문이다.

즉, 고객의 요구사항이 변경되거나 스펙이 바뀌게 되면, 프레임워크 레이어상의 변경이 아닌 개발 코드의 변경은 프로세스 요청마다 구현한 코드의 개별 구성 별로 변경이 이루어지다 보니 점차 코드의 품질이 저하되는 현상이 발생하게 된다

이에, TSF는 날로 복잡해지고, 급격하게 변화하는 고객의 요구사항을 빠르게 반영하면서 어플리케이션 품질을 일정하게 유지하기 위하여 일관된 객체 모델을 활용, 개발 생산성과 품질 그리고 수시 유지보수에 대한 적응성등을 동시에 보장하는 어플리케이션의 아키텍처가 필요함에 따라 TSF(jsTree Service Framework)를 연구 및 구현하게 되었다.

본 프로젝트의 목적은 확장된 Tree 모델을 활용하여 어플리케이션을 단일 로직에 대응 할 수 있음을 증명하는데 있다. ( 중앙 집중형 아키텍쳐 )
연구 방법은 기반 프레임워크인 Spring, Struts, iBatis, Hibernate등을 기준으로 확장 Tree Model을 구현하며, Service Layer의 API Code를 제공하는데 집중된다.

최종적으로는 TSF 와 Egovframework를 통합 및 적응 할 수 있는 패키지로 이행한다.
또한, Cloud 시대에 대응하기 위하여 Docker 컨테이너화 및 분산 아키텍쳐를 적용하여
보안성, 확장성, 생산성, 성능 및 품질을 강화하여 배포하는데 최종 목적을 가진다.

 

1.2 프로젝트의 범위

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

 

1.3 문서 규칙

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

 

 

1.4 용어 정의 및 약어

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

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

용어/약어 

의미 

SRS

소프트웨어 요구 사항 명세서(Software Requirement Specification)

SDS

소프트웨어 설계 명세서(Software Design Specification)

IRS

인터페이스 요구 사항 명세서(Interface Requirement Specification)

TDS

테스트 설계서(Test Design Specification)

TCL

테스트 케이스 일람표(Test Case List)

화면설계서 

사용자 인터페이스 설계서 

디자인 스타일 가이드 

사용자 인터페이스에 적용할 디자인 스타일 가이드 

PP

제품 기획자(Product Planner)

PM

프로젝트 관리자(Project Manager)

PE

개발자(Program Engineer)

MK

세일즈 마케터(MarKeting)

QAE

품질보증 담당자(Quality Assurance Engineer)

CC

CC 인증 담당자(Common Criteria evaluation)

TW

기술문서 담당자(Technical Writer)

UX

사용자 경험 & 제품 디자인 (User eXperience)

SA

시스템/네트워크 엔지니어(Security Architect)

ASEC

시큐리티대응센터(313 DEV GRP Security Emergency response Center)

 

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

용어/약어 

의미 

TSF

jsTree Service Framework

 

1.5 관련 문서

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

 

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

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

 

 

 

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)를 포함해야 한다. 어떤 기능이 켜져있거나 동작이 되고 있어야 다른 동작에 영향을 미치는지를 확인할 수 있다.

기능

설명

NODE 구현 SPEC

1. 각 노드는 상위 노드(부모 노드)의 아이디 값을 가진다.

2. 각 노드는 형제 노드의 순서값 ( 좌측부터 0 )을 가진다.

3. 각 노드는 Left, Right 좌표값을 가진다.

4. 각 노드는 Root 노드부터의 Level 값을 가진다.

5. 각 노드는 Depth ( Level ) 값을 가진다.

6. 각 노드는 Leaf Node의 타입은 default이며, folder 타입은 branch 노드, Root node는 drive 타입으로 선언한다.

NODE 기능 SPEC

1. 노드(type : branch)를 추가할 수 있다.

2. 노드(type : leaf)을 추가할 수 있다.

3. 노드를 수정 할 수 있다. ( title, domain data )

4. 노드를 삭제 할 수 있다.

5. 노드를 잘라 낼 수 있다. ( Cut )

6. 노드를 복사 할 수 있다.

7. 노드를 붙일 수 있다. ( cut & paste , copy & paste )

8. 노드를 검색 할 수 있다.

API SPEC

1. getChildNode(T)  return List <T extends ComprehensiveTree>;

2. serchNode(T)  return <T extends ComprehensiveTree> List<String>;

3. addNode(T)  return <T extends ComprehensiveTree>;

4. removeNode(T)  return <T extends ComprehensiveTree>;

5. alterNode(T)  return <T extends ComprehensiveTree>;

6. alterNodeType(T)  return <T extends ComprehensiveTree>;

7. moveNode(T, HttpServletRequest request)  return <T extends ComprehensiveTree>;

8. getPaginatedChildNode return List <T extends ComprehensiveTree>;

9. analyzeNode return String;

 

 

2.5 사용자 프로파일

 

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

 

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

 

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

 

 

 

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

 

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

 

 

 

 

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

 

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

 

 

 

 

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

 

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

 

 

 

2.6 설계와 구현상 제약 조건

 

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

 

jsTree Service Framework 개발 환경

Development Tool : Eclipse & InteliJ

Development Language : OpenJDK Java ( 1.7 higher )

jsTree Service Framework에서 사용한 기술

Part

Detail Skill

View Part

html+css, Bootstrap, RequireJS, Bower, Grunt, AngularJS, jQuery, Qunit, Flex, Json, xml, BlazeDS

Server Part

Apache(modjk), ApiGateway(Zulu), Kafka, Nginx, Tomcat, Resin, Jetty, SiteMash, Tiles, FreeMarker, Velocity

Framework Part

Struts, Spring, iBatis, Hibernate, Spring-integration, Spring-security, Spring-Boot, Spring-DW, Spring-WebFlow, Spring-Data(JPA), Spring-Batch, Spring-WebServices, Spring-Mobile, Spring-MVC

Tool Part

Quartz, Ehcache, MemCache, Redis, Apache-Commons, EgovFramework(Component)

CI Part

Junit, Maven, Hudson, Jenkins, Bamboo, Nexus, Jira, Fisheye, Crucible, Confluence, Sonar

Database Part

MySql, Oracle, MS-sql, postgres, Hadoop, Storm, Spark, Cassandra, MongoDB, GraphDB

Mobile Part

Android, PhoneGap

Search Engine Part

Lucene, Elastic Search, Kibana, Logstash, Beats

Management Part

PMBOK, MicroService, CBD, PLE, Prototype, PMS, ALM

Virtual Image Part

Kubernetes - Zookeeper - Docker

Microservice Part

Scala - Netty - Finagle

 

 

 

2.7 가정과 종속 관계

 

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

 

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

 

 

 

2.7.1 예시) APC 4.5 프로젝트

 

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

 

 

 

 

2.8 하위 호환성

 

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

 

 

 

 

 

 

 

 

 

3. 환경

 

 

 

3.1 설치 환경

 

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

 

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

 

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

 

 

 

3.1.1 하드웨어 환경

 

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

 

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

 

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

 

장비 모델명(가칭)

CPU 사용(CPU종류, Clock, Core수, CPU개수)

Memory 용량

Flash Disk 용량(Flash 사용시)

NIC 구성(Media 종류, 개수)

LCD 사양(LCD 구성 시)

시리얼 포트 여부

Bypass 사양(NIC 종류별 Bypass 지원 여부)

Power 사양(Dual/Single 여부)

 

  

 

3.1.2 소프트웨어 환경

 

 

 

3.1.2.1 운영체제

 

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

 

 

 

 

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 소스코드

 

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

 

 

 

 

3.4.1.2 문서

 

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

 

문서 종류

위치

개발문서

예시) http://svn.313 DEV GRP.co.kr/313 DEV GRPDoc/Product/GateSecurity/UTM/1.0

UX문서

예시) http://svn.313 DEV GRP.co.kr/313 DEV GRPDocUI/Product/04 Network/TrusGuard 

QA문서

예시) http://svn.313 DEV GRP.co.kr/313 DEV GRPDocUI/Product/04 Network/TrusGuard 

TW문서

예시) http://svn.313 DEV GRP.co.kr/313 DEV GRPDocTW/Product/UTM

 

  

 

3.4.2 빌드 환경

 

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

 

 

 

3.5 결함관리

 

이슈관리를 위해 사용할 시스템 및 이슈트래킹 프로세스. 사내 기본 이슈관리 시스템인 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 여부를 판단하는 근거가 되므로, 반드시 정량적으로 측정할 수 있도록 기술한다.

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

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

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

 

5.1.1 예시) 성능 시험 환경 

대상

내용

비고

Hardware

Intel Core2 Duo E6300

DDR3 1G

HDD 1TB 7200RPM

 

OS

Windows 7 Professional SP1

 

Software

V3 IS 9.0

 

Option

실시간검사 On

검사 대상 : 모든 파일

추가 검사 : 유해 가능

ASD : On

 

  

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

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

대상

내용

비고

Idel 상태

CPU : 2% 미만의 CPU 사용량 Pass

(Committed Byte 기준)

수동검사 시

대상 : 소프트웨어 QA팀 엔진테스트 대표 샘플

CPU : 30% 미만

Memory : 150MB 미만

Scan Speed : 대표 샘플 5분 내에 모두 검사 완료

Network : ASD 네트워크 1MB 미만 사용

Disk : 디스크 복사 기간이 미설치보다 5% 미만 저하

Boot Time : 제품 설치 후 부팅시간이 10% 미만 증가

옵션 별 다른 성공/실패 기준 적용 명시한다.

  

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 상호운용성

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

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

 

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)

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

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

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

 

5.4.1 인코딩

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

 

5.4.2 언어 지원 계획

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

 

5.4.3 로케일

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

 

5.5. 컴플라이언스

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

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

 

5.5.1 인증 획득

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

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

 

5.5.1.1 예시) CC인증

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

 

5.5.2 장애인 차별 금지법 준수

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

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

참고)

위 참고자료는 아래 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 사용할 오픈 소스 라이선스

제품/라이브러리 명칭

라이선스 유형

2차 저작물 소스 공개 의무 

참고

BusyBox

GPL v2.0

 O

 품의에 의한 사용 협의 완료

Linux kernel

Free BSD

 X

 

 

 

 

 

 

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

 

 

배경지식

Kubernetes : 쿠버네티스는 디플로이 자동화, 스케일링, 컨테이너화된 애플리케이션의 관리를 위한 오픈 소스 시스템

ZooKeeper : 공개 분산형 구성 서비스, 동기 서비스 및 대용량 분산 시스템을 위한 네이밍 레지스트리를 제공

Apache Kafka : 스칼라로 개발한 오픈 소스 메시지 브로커

Api GateWay : Zulu 리퀘스트 프록시 라우팅 서비스

Redis : Remote Dictionary Server의 약자로서, "키-값" 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈 소스 기반의 비관계형 데이터베이스 관리 시스템

MicroService : 모놀리틱 아키텍처로 구성된 하나의 큰 서비스를 독립적인 역할을 수행하는 작은 단위의 서비스로 분리하여 설계하는 패턴

Netty (Java) : 높은 성능의 프로토콜 서버 및 클라이언트를 신속한 개발을 위한 비동기 이벤트 드리븐 네트워크 어플리케이션 프레임워크

Hadoop : 하둡은 대용량 데이터를 분산 처리할 수 있는 자바 기반의 오픈 소스 프레임워크

E ( Elastic Search ) : 분산형 RESTful 검색 및 분석 엔진

L ( Logstash ) : 서버측 데이터 처리 파이프라인

K ( Kibana ) : 데이터를 시각적으로 탐색하고 실시간으로 분석

Beats : 서버에 에이전트로 설치하여 다양한 유형의 데이터를 Elastic Search 또는 Logstash에 전송하는 오픈 소스 데이터 발송자

NoSQL : 단순 검색 및 추가 작업을 위한 매우 최적화된 키 값 저장 공간으로, 레이턴시와 스루풋과 관련하여 상당한 성능 이익을 내는 것이 목적

GraphDB : 컴퓨팅에서 그래프 데이터베이스는 시맨틱 쿼리를 위해 노드, 엣지, 프로퍼티와 함께 그래프 구조를 사용하여 데이터를 표현하고 저장하는 데이터베이스