소프트웨어 요구사항 명세서(Software Requirements Specification for Royal Straight

Flush)

Ver 1.1

승인자 : 승인 날짜:

2017. 11. 062017. 11. 21

목차

1. SRS 소개(Introduction to SRS) 1.1 목 적(Purpose of SRS) 1.2 범 위(Scope of SRS) 1.3 대 상(Intended audience and reading suggestions of SRS) 1.4 용어 정의(Glossary of term of SRS) 1.5 참고 문헌(References document of SRS) 1.6 문서 형식(Overview of SRS) 1.7 문서 구성 (Overview of SRS)

2. 시스템 개요(Overall Description) 2.1 시스템 개요(The System Overview)2.2 이해관계자 특성(Stakeholder characteristics) 2.3 시스템 기능(The System Features)2.4 일반 제약사항(The general constraints)2.5 가정사항(Assumptions)

3. 비즈니스요구사항

3.1 비즈니스 범위 (Business scope) 3.2 비즈니스 프로세스 정의 (Business processes definitions) 3.3 비즈니스 정보 정의 (Business information definitions) 3.4 비즈니스 규칙 (Business rule)

4. 인터페이스 요구사항(Interface Requirements) 4.1 외부 인터페이스 요구사항 (System Interface Req.) 4.2 사용자 인터페이스 요구사항

4.3 하드웨어 인터페이스 요구사항

4.4 네트워크 인터페이스 요구사항

4.5 소프트웨어 인터페이스 요구사항 (SW interface Req.)

5. 기능 요구사항(Functional Requirements)5.1 시스템 기능 구조(System functional structure) 5.2 상세 기능 요구사항(Detail functional requirement)

6. 데이터 요구사항(Data Requirements) 6.1 도메인 데이터 모델 (Domain data model)

6.2 논리적 데이터베이스 요구사항 (Logical Database Req.)

7. 품질 요구사항(Quality Requirements) 7.1 시스템 품질 모델(System quality goal) 7.2 상세 품질 요구사항(Detail quality requirements)

8. 운영 요구사항(Operational Requirements) 8.1 물리적 운영 요구사항(Physical Operational Requirements) 8.2 설치 요구사항(adaptation requirements) 8.3 사용자 문서와 훈련 요구사항(User Documentation and Training)

9. 제약사항(Constraints)

10. Use Case 명세

11. WBS

1. SRS 소개(Introduction to SRS) 1.1 목 적(Purpose of SRS)

● 본 문서는 ‘Royal Straight Flush’ 어플리케이션 개발을 위한 소프트웨어 요구사항을 명세하고

있다.● 본 문서는 고객, 설계, 개발, QA 담당자를 대상으로 한다.● 본 문서는 ‘Royal Straight Flush’의 BPP 를 바탕으로 고객의 요구사항을 명확하게 도출 하여

향후 개발 과정에서 이를 반영하는데 그 목적이 있다. 따라서 본 문서는 고객의 정확한 요구사항을

수집하고 이를 분석하여 명세한다.● 본 문서는 고객과 개발자간에 다음과 같은 역할을 한다. -본 문서는 고객과 개발자간의 계약서와 동일한 효력을 갖는다. -본 문서는 고객 요구사항을 구체적으로 명시한다. -개발자는 본 문서에 명세된 고객의 요구사항에 따라 목적물을 개발한다. -개발된 목적물은 본 문서에 명세된 모든 요구사항을 만족해야한다. -본 문서는 향후 테스트의 베이스 라인이 된다. -본 문서는 명세된 모든 요구 사항을 바탕으로 설계하고, 테스트 케이스를 작성한다.

1.2 범 위(Scope of SRS) ● ‘Royal Straight Flush’ 어플리케이션은 음성인식을 이용해 받은 <데이터>를 이용해 다양한

카드의 다양한 혜택의 내용을 crawling 해서 사용자에게 <적합한 혜택을 가진 카드>를

추천해준다.

1.3 사 용 대 상(Intended audience and reading suggestions of SRS)

역할 이름 주담당 연락처 연락형식

개발자 강종구 Application 개발 010-7723-1151 전화

개발자 김현배 Application 개발 010-8799-7936 전화

개발자 전민기 데이터베이스 관리 010-9299-5289 전화

PM, 검증 김용수 프로젝트 관리 010-6534-0760 전화

1.4 용어 정의(Glossary of term of SRS) 용어 이름 머리글자 약어 정의

Use Case UC - 사용자 관점에서 소프트웨어 시스템의 사용

시나리오를 기술

1.5 참고 문헌(References document of SRS) 순번 작성자 문서이름 문서종류 문서

형식

버전 발행일

1연세대학교이종석 석사

pagerank 을 이용한

토픽모델구축

논문 PDF Version 3.1.0

2015

2 김동욱

숭실대학교

단어유사도를 이용한

뉴스 토픽 추출

Word docx - 2015.04

3 너의색깔은 SRS 보고서 docx - 2016.08

1.6 문서 형식(Overview of SRS) 1.6.1 요구사항 번호 형식

(1) 요구사항 번호 형식

●종류별 번호 기준 : 요구사항을 기능을 기준으로 하여 번호를 부여한다

(2) 요구사항 번호 부여 기준

● 요구사항의 번호는 기능적 우선순위가 높을 수록 낮은 번호로 부여한다.● 요구사항 변경(추가/ 삭제)시 재번호는 기존의 요구 사항의 번호를 유지하되, 추가되는

요구사항들 끼리의 우선도를 비교하여 높은 우선도를 가지는 요구사항에게 낮은 번호를 부여하도록

한다. 1.6.2 요구사항 명세 형식

(1)개별 요구사항 정의 형식

기능 요구사항 시스템은 카드 혜택에 관심이 있는 사람들이 음성인식을 통해 입력된 카드

혜택에 해당하는 토픽을 뽑아 데이터를 기준으로 crawling 을 하여, 요구에

적합한 카드를 출력하는 기능을 제공 해야 한다.비기능 요구사항 입력된 혜택 외에 비슷한 혜택을 가진 카드를 추천해준다.

(2)개발 요구사항 속성 형식

정보종류 정보 내용

요구사항 ● 요구사항 번호, 요구사항 이름

식별정보 ● 요구사항 내용

● 요구사항 관련자

요구사항

속성 정보

● 요구사항 종류 (비즈니스, 기능, 품질, 제약사항)● 응낙 수준 (필수, 조건, 선택)● 우선 순위, 중요도, 위험도, 투입 노력 (비용, 일정)

요구사항

품질 정보

● 품질 속성(신뢰성, 사용성, 효율성, 이식성, 유지보수성)

요구사항

상태정보

● 요구 사항 처리 상태 (TBD, 제안, 정의, 검토, 검증, 합의, 승인, 거부, 삭제)

요구사항

변경정보

● 요구 사항 변경 가능성 (Global/static requirements)● 변경 내역 정보 ( 요구사항 포함 이유, 날짜 및 참석자)● 변경 처리 상태

요구사항

추적 정보

● 요구사항과 관계된 근거/ 소스와의 추적 정보

● 요구사항과 프로세스 산출물과의 추적 정보

● 다른 요구사항과의 종속성

1.7 문서 구성 (Overview of SRS) 요구사항 형태 시스템 요구사항 상세 요구사항

1. SRS 소개 O O2. 시스템 개요 O O3. 비즈니스 요구사항 O4. 인터페이스 요구사항 외부 인터페이스

요구사항

상세 인터페이스

요구사항

5. 기능 요구사항 시스템 기능 구조 상세 기능 요구사항

6. 데이터 요구사항 음성 데이터 모델

7. 품질 요구사항 시스템 품질 목표 상세 품질 요구사항

8. 운영 요구사항

9. 제약사항 O10. Use Case 명세 O11. WBS

2. 시스템 개요(Overall Description) ●Context diagram

2.1 시스템 개요(The System Overview)(1) 시스템 목적

● 시스템 개발 목적: 시스템은 혜택을 중요시하는 사람들이 합리적인 소비에 대한 관심의

증가와 빅스비, 시리와 같은 음성인식 기능의 사용이 증가하면서, 본인이 원하는 카드 혜택을 가진

여러 카드사의 카드들을 음성 인식 데이터를 통해 검색하여, 추천하는 기능을 제공 해야 한다. ●시스템 개발 동기

- 시스템 개발의 배경 : 음성인식 분야와 데이터 처리에 대한 관심이 증가하고 있는 추세이므로

관련 시스템 자체가 적은 편이며 DB 구축을 위한 계약(카드사와 DB 간의)이 필요하여 번거로움이

존재한다. - 시스템 개발 목표 : 별도의 부속품 없이 검색 출력이 가능하게 하여 번거로움을 줄이고, 음성

인식을 통해 검색 단어 선택의 어려움을 낮춘다.

(2) 시스템 범위

● 음성 인식 데이터에서 토픽을 찾는 프로그램 개발

● 토픽을 중심으로 crawling 을 하는 서버를 구축하고, 카드 정보와 혜택을 저장할 DB 를 카드사

이용해 처리한다.

(3) 시스템 고려사항

● 카드사의 DB 사용에 있어서 법적 제약이 있는지 검토해야한다.● 12 월 25 일까지 개발이 완성되기 위해서는 개발일정이 여유롭지 않다.● 음성인식, DB 관리, 서버 개발에 대한 경험이 많지 않으므로 위험도가 높다.● 음성 인식 데이터에서 토픽을 찾아내는 정확도 면에서 어려움이 있다.

2.2 이해관계자 특성(Stakeholder characteristics) ●이해 관계자 그룹 식별

●이해 관계자 관점 식별이름 이해 관계자 관점 이해 관계자 관계

Biz 목표 기술제약 품질별 제약사항 영향도 중요도 참여도

도메인전문가

시스템안정성

_ 기능성 상 상 40%

사용자 편리한 사용 관련 기술지식이 낮음

사용성 중 상 80%

PM 프로젝트의 성공

관련 기술지식 높음

완성도 상 상 80%

개발팀 프로젝트완성

관련 기술지식 높음

_ 중 중 60%

투자자 수익성 관련 기술지식 중간

수익성 상 상 40%

2.3 시스템 기능(The System Features)비즈니스 목적 비즈니스 프로세스 시스템 기능 소프트웨어기능

카드 추천 시스템 음성 인식 토픽 추출 기능

구현

음성 데이터 단어 추출

카드 혜택 검색 카드 혜택 매칭 단어를 기준으로 crawling클러스팅된 DB 조회

관련 제품(카드) 추천 관련 제품 DB 관리

카드 정보 DB 등록

카드 혜택 DB 등록

제품군 조회

2.4 일반 제약사항(The general constraints)(1) 시스템 개발 제약 사항

● 현재 어플리케이션 제작 경험이 많지 않으므로, 시스템 개발에 많은 시간이 소요 될 수 있음

● DB 관리 경험이 많지 않으므로, 신속한 개발에는 무리가 있을 수 있음

● 음성 인식을 시행했을 때, 원하는 입력 조건과 다른 결과가 나올 경우를 대비하여 개발해야하는

어려움이 있음.● 카드 DB 를 저장하는 것을 해당 브랜드의 회사가 허용하지 않을 수 있음. (공식화 시)

(2) 소프트웨어 제약 사항

● 해당 사항 없음

(3) 시스템 구현 및 운영 환경에 대한 제약 사항

● 서버 사용 기간은 3 개월으로 제한하여 프로젝트를 개발하고 있으므로 추후 운영을 위해서는

지속적인 관리가 필요함

● 클러스팅된 DB 와 매칭 기능이 실제 사용자의 요구사항과 유사성이 있을지 구현시 확인해야함.

(4) 비즈니스 제약 사항

● 카드 매칭 DB 를 위해 카드 검색 조건을 추출하는 것에 협조가 필요함.

(5) 연회비 제약 사항

● 카드 매칭 DB 를 위해 카드 검색 조건을 추출하는 것에 협조가 필요함.

2.5 가정사항(Assumptions) ● 상업적 용도 외 카드 정보 사용에 문제가 없다는 가정하에 초기 DB 구축.● 맞춤 카드 진단은 추출된 데이터를 이용하여 결과를 도출하는 것이나 완벽한

객관성을 가지고 판단된 것이 아님(주관성이 존재함)을 가정함.● 같은 가중치를 가진 정보가 입력되었을 때, 우선 입력 순위에 가중치를 부여함

3. 비즈니스요구사항

항목 설명

비즈니스 목표음성 인식을 통한 카드 검색 및 추천,

수집된 사용자의 니즈를 분석하여 새로운 페이먼트에 관한 모델 도출

배포 유형 B2C이해관계 카드사 , 사용자, 어플리케이션 광고 수익자

중요한 품질 정확성, 보안성, 신속성

대상 사용자 일반 사용자

보안 문제 개인 정보 유출 문제가 발생할 수 있다.

우선순위

1) 음성 인식, crawling 및 클러스팅 된 정보를 가지고 카드

매칭

2) 수집된 사용자 니즈로부터 분석 정보 도출

시간/일정 12 월 22 일까지 프로젝트 완료

예산 10 만원

위험 요소 새로운 개발환경

비즈니스 예상도

4. 인터페이스 요구사항(Interface Requirements) 4.1 외부 인터페이스 요구사항 (System Interface Req.) • 비즈니스 컨텍스트 다이어그램

• Use case 다이어그램

• 외부 인터페이스 요구사항

외부 시스템 이름 어플리케이션

인터페이스 목적 사용자의 니즈를 음성 입력(추천카드확인) 및 정보 확인

데이터 형식 음성파일, 이미지 파일, 텍스트 파일

입력 소스 및 결과물 위치 어플리케이션 화면

4.2 사용자 인터페이스 요구사항(User interface requirements)

< 사용자 인터페이스 방법 >1. 어플리케이션 설치 및 실행

2. 간단한 기본 정보 입력(성별,나이)3. 음성인식이 실행되면 음성 입력 및 입력이 끝나면 종료버튼을 누름

사용자 인터페이스 요구사항

데이터 형식 음성 파일, 이미지 파일, 텍스트 파일

사용 가능 기능 간단한 정보 및 니즈 입력, 추천 카드 확인

사용 불가능 기능 카드 데이터 추가 및 변경

4.3 하드웨어 인터페이스 요구사항

하드웨어 인터페이스 이름 서버 / 핸드폰(마이크가 있는 장치)인터페이스 목적 음성을인식할 수 있는 기계.

4.4 네트워크 인터페이스 요구사항

컴퓨터와 모바일기기 모두 인터넷이 연결되어있는 상태로, 안정적인 연결이 이루어진 상태가

요구된다.네트워크 인터페이스 요구사항

메세지 형식 이미지 파일, 텍스트 파일

프로토콜 TCP/IP사용자 인증 있음

제한 사항 네트워크 연결 없는 경우 서비스 사용 불가

4.5 소프트웨어 인터페이스 요구사항 (SW interface Req.)

서버 구축을 위하여 로컬서버를 이용한다. ORACLE 을 DB 로 사용한다.

5. 기능 요구사항(Functional Requirements)5.1 시스템 기능 구조(System functional structure) • 전체적 시스템의 구조는 아래와 같다.

● 서버 : ubuntu● 어플리케이션: android● 데이터베이스 : ORACLE● 호스팅 : Sogang

비즈니스 개략 상세 목적 입력/결과 우선도

요구사항 요구사항 요구사항

음성인식

을 통한

텍스트

도출

음성인식을

통해

정확한

텍스트

데이터

추출

음성인식사용자의 니즈를

정확히 받는다

음성인식을 통해

텍스트를 받는다상

LDA 를

통한

군집화

사용자에게 받은

데이터를

군집화하여 토픽을

의 가중치에따라

순서를 매긴다.

정렬된 토픽 텍스트 상

DB 를 통해

비교

사용자의 니즈와

함께 DB 에 구축된

값과 비교를 하여

유사도가 가장 높은

값 출력

DB 와 통해 비교된 혜택

내용을 보여준다상

5.2 상세 기능 요구사항(Detail functional requirement)요구사항

번호

R-001 요구사항

이름

음성인식을 통해

사용자의 니즈를

받는다

요구사항

유형

기능

작성자 김용수 작성일 2017-11-06 릴리즈/버전 V1.0이해관계자 시스템 관리자, 개발자, 품질 관리자, 테스터

내용 1.사용자로 부터 needs 를 받아들인다..입력데이터 음성인식 출력데이터 이미지 파일 및 내용

평가방법 1. 음성인식이 정확히 받아지는지 지속적인 확인이 필요하다.

평가기준 구현의 완전성, 정확성, 인터페이스의 정확성

응락수준 필수 처리상태

우선순위 상 중요도 상 위험도 중

품질 속성

변경 가능성 변경내역

관련근거 관련소스

관련요구사항 관련산출물

요구사항

번호

R-002 요구사항

이름

받은 내용을 LDA를 통해 토픽 추출

요구사항

유형

기능

작성자 김용수 작성일 2017-11-06 릴리즈/버전 V1.0이해관계자 시스템 관리자, 개발자, 품질 관리자, 테스터

내용 사용자에게 받은 내용을 LDA알고리즘을 통해 토픽을 추출하여 대표적인

주제를 도출한다.입력데이터 텍스트 형태 출력데이터 분류된 데이터

평가방법

평가기준 기능 구현의 완성성, 타당성, 정확성

응락수준 필수 처리상태

우선순위 상 중요도 상 위험도 중

품질 속성 신뢰성, 효율성, 사용성

변경 가능성 변경내역

관련근거 관련소스

관련요구사항 관련산출물

요구사항

번호

R-003 요구사항

이름

요구사항

유형

기능

작성자 김용수 작성일 2017-11-06 릴리즈/버전 V1.0이해관계자 시스템 관리자, 개발자, 품질 관리자, 테스터

내용 1. 선별된 단어의 가중치를 탐색하며 DB 와 매칭되는 내용을 추출한다.입력데이터 텍스트 출력데이터 텍스트

평가방법 가중치 이외에도 탐색하지 못하는 default 경우를 지속적으로 찾아 문제점을

찾는다

평가기준 기능 구현의 완전성, 정확성

응락수준 필수 처리상태

우선순위 상 중요도 상 위험도

품질 속성 신뢰성

변경 가능성 변경내역

관련근거 관련소스

관련요구사항 관련산출물

요구사항

번호

R-004 요구사항

이름

결과값 확인 요구사항

유형

상

작성자 김용수 작성일 2017-11-06 릴리즈/버전 V1.0

이해관계자 시스템 관리자, 개발자, 품질 관리자, 테스터

내용 1. 추출된 혜택내용이 고객의 니즈에 부합하는지 확인하여, clustering 이

잘됬는지 확인해준다.입력데이터 텍스트 출력데이터 카드 이미지 및 혜택

평가방법 1. 사용자의 니즈에 맞는 결과가 나왔는지 확인한다.

평가기준 구현의 정확성, 완성도

응락수준 필수 처리상태

우선순위 상 중요도 상 위험도 중

품질 속성 신뢰성,변경 가능성 변경내역

관련근거 관련소스

관련요구사항 관련산출물

6. 데이터 요구사항(Data Requirements) 6.1 도메인 데이터 모델 (Domain data model)

6.1.1 객체/엔티티(Object/ Entity)

객체/엔티티 이름 : Card

속성 이름

(Attribute name)

키 (Key)

Benefit Private Key

Age Public Key

Most_Used -

Number -

Amount_Per_Month -

Brand -

Period_of_Use -

6.1.2 속성(Attribute)

속성 이름 : Benefit

데이터 요소 목적 사용자의 카드 혜택을 명시

데이터 분류(정적, 동적 입력/출력) 정적

데이터 형식(문자, 숫자, 문자/숫자) 문자

데이터 허용 값의 범위 또는 이산(Discrete) 값 -

측정 단위 -정확도 100%

데이터 값을 유도하기 위한 계산 또는 알고리즘

-데이터 특성 (정확성, 유효성, 시간 및 용량) 100%의 정확도가 요구됨.데이터 간의 종속성 -

비즈니스 규칙 정보의 신뢰도 및 갱신 신속성이 요구됨.

속성 이름 : Age데이터 요소 목적 사용자의 나이대를 명시

데이터 분류(정적, 동적 입력/출력) 정적

데이터 형식(문자, 숫자, 문자/숫자) 숫자

데이터 허용 값의 범위 또는 이산(Discrete) 값 -

측정 단위 -정확도 100%

데이터 값을 유도하기 위한 계산 또는 알고리즘

-데이터 특성 (정확성, 유효성, 시간 및 용량) 100%의 정확도가 요구됨.데이터 간의 종속성 -

비즈니스 규칙 정보의 신뢰도 및 갱신 신속성이 요구됨.

속성 이름 : Most_Used데이터 요소 목적 사용자가 가장 많이 사용한 카드를 명시

데이터 분류(정적, 동적 입력/출력) 정적

데이터 형식(문자, 숫자, 문자/숫자) 문자

데이터 허용 값의 범위 또는 이산(Discrete) 값 -

측정 단위 -정확도 100%

데이터 값을 유도하기 위한 계산 또는 알고리즘

-데이터 특성 (정확성, 유효성, 시간 및 용량) 100%의 정확도가 요구됨.데이터 간의 종속성 -

비즈니스 규칙 정보의 신뢰도 및 갱신 신속성이 요구됨.

속성 이름 : Number데이터 요소 목적 사용자가 소지한 카드 개수를 명시

데이터 분류(정적, 동적 입력/출력) 정적

데이터 형식(문자, 숫자, 문자/숫자) 숫자

데이터 허용 값의 범위 또는 이산(Discrete) 값 -

측정 단위 -정확도 100%

데이터 값을 유도하기 위한 계산 또는 알고리즘

-데이터 특성 (정확성, 유효성, 시간 및 용량) 100%의 정확도가 요구됨.데이터 간의 종속성 -

비즈니스 규칙 정보의 신뢰도 및 갱신 신속성이 요구됨.

속성 이름 : Amount_Per_Month데이터 요소 목적 사용자의 월 사용액을 명시.

데이터 분류(정적, 동적 입력/출력) 정적

데이터 형식(문자, 숫자, 문자/숫자) 숫자

데이터 허용 값의 범위 또는 이산(Discrete) 값 -

측정 단위 -정확도 100%

데이터 값을 유도하기 위한 계산 또는 알고리즘

-데이터 특성 (정확성, 유효성, 시간 및 용량) 100%의 정확도가 요구됨.데이터 간의 종속성 -

비즈니스 규칙 정보의 신뢰도 및 갱신 신속성이 요구됨.

속성 이름 : Brand데이터 요소 목적 사용자가 사용하고 있는 카드 종류를 명시.

데이터 분류 정적

(정적, 동적 입력/출력)데이터 형식

(문자, 숫자, 문자/숫자) 문자

데이터 허용 값의 범위 또는 이산(Discrete) 값 -

측정 단위 -정확도 100%

데이터 값을 유도하기 위한 계산 또는 알고리즘

-데이터 특성 (정확성, 유효성, 시간 및 용량) 100%의 정확도가 요구됨.데이터 간의 종속성 -

비즈니스 규칙 정보의 신뢰도 및 갱신 신속성이 요구됨.

속성 이름 : Period of Use데이터 요소 목적 사용자가 사용하고 있는 카드 기간을 명시.

데이터 분류(정적, 동적 입력/출력) 정적

데이터 형식(문자, 숫자, 문자/숫자) 문자/숫자

데이터 허용 값의 범위 또는 이산(Discrete) 값 -

측정 단위 -정확도 100%

데이터 값을 유도하기 위한 계산 또는 알고리즘

-데이터 특성 (정확성, 유효성, 시간 및 용량) 100%의 정확도가 요구됨.데이터 간의 종속성 -

비즈니스 규칙 정보의 신뢰도 및 갱신 신속성이 요구됨.

6.2 논리적 데이터베이스 요구사항 (Logical Database Req.) (1) 데이터 제약

- 데이터베이스에 저장되어있는 데이터들은 무결성, 정확성, 신뢰성에

완벽하게 보장되어야 한다. 또한 데이터의 추가, 갱신, 삭제에 대해 일관성을

유지해야 한다.(2) 데이터 보존

- 데이터베이스에 대한 접근 권한을 철저하게 설정하여 외부 사용자의

접근으로부터 데이터를 보호한다. 관리자들만 접근이 가능하다.(3) 유효성 검토 요구사항

- 지속적으로 데이터의 정확도 및 신뢰도를 검증하도록 한다. 현재 나와있는

카드 정보들을 통해 기존의 데이터를 구성하고 데이터의 확장이나 종류를

변경하는 경우 또한 기존의 데이터베이스의 데이터를 이용하도록 한다.

6.3 데이터 제약사항 (Data constraints)

6.3.1 데이터 제약 (Data constraints)

● 파일, 레코드 및 데이터 요소의 최대 크기와 수

파일, 레코드 및 데이터 요소는 초기에는 적은 양의 데이터를 저장할 수 있는 크기로 설정한다. 추후 기본 프로토타입 서비스를 구현한 후 확대해나가도록 한다. 초기 레코드의 개수는 약 10 개로 설정한다.

● 데이터 입력의 소스와 데이터의 수신자

입력의 소스는 음성 파일이며 이를 통해 미리 검색한 혜택 정보를 토대로 데이터베이스를 검색하여 데이터의 수신자인 사용자에게 정보를 전달한다

● 데이터의 입출력을 위하여 사용되는 장비

어플리케이션을 이용하여 음성 추출 및 데이터베이스 검색 기능을 구현하도록 한다.

6.3.2 데이터 보존 (Data retention)

● 데이터 생성 이후의 보존 기간

사용자 사생활 침해 보호 차원에서 사용자를 통해 추출한 음성 파일은 주기적으로 삭제하되, DB 구축에 필요한 데이터 정보는 별도로 저장하여 데이터 갱신 시에 추가하여 사용 가능하다.

6.3.3 데이터 구성 (Data format)● 데이터 구성 종류

(1) Private Key- Benefit (혜택)

(2) Public Key- Age (나이)- Most_Used (가장 많이 사용한 카드 브랜드)

- Number (사용하고 있는 카드 숫자)- Amounts_Per_Month (월 사용액)- Brand (사용하고 있는 카드 브랜드)- Period_of_Use (사용하고 있는 카드 기간)

6.3.4 데이터 갱신 (Data update)● 데이터 갱신 시기

카드 정보 갱신이 이뤄져야 하는 경우 (ex : 카드 정보의 증가, 새로운 진단 알고리즘 추가 등), 데이터베이스의 일관성 유지를 위해 갱신한다.

7. 품질 요구사항(Quality Requirements) 7.1 시스템 품질 모델(System quality goal)

품질특성 요구사항 내용 품질 목표 우선순위

기능성 사용자가 요구하는 기능을 수행하는 능력 100% 1효율성 요구되는 기능을 수행할 때 필요한 자원을

소요하는 정도

80% 3

신뢰성 정확하고 일관된 결과를 수행하는 능력 70% 4사용성 사용자가 사용과 이해를 용이하게 할 수 있는

성질

85% 2

유지보수성 변경 발생시 영향을 파악하고 절차에 따라

변경 가능한 정도를 기술

70% 4

이식성 새로운 환경에 쉽게 변경될 수 있는 능력 60% 6

7.2 상세 품질 요구사항(Detail quality requirements) 7.2.1 효율성 요구사항(Performance requirements)(1)시간 효율성

사진을 업로드하고 20초 이내에 결과를 보여주어야 한다.(2)처리 효율성

- 현재 목표를 동시 서버 이용자를 10 명이내로 제한한다.- 현재 목표를 달성 후 동시 서버 이용자를 100 명으로 확장한다.

- 서버 이용자의 수는 업로드한 사용자의 사진의 개수로 파악한다.7.2.2 신뢰성 요구사항(Reliability requirement)(1)복구성 및 성숙성

- 서버상의 문제로 결과가 20초 이내에 안 뜨는 경우 안내 메세지를

띄워주고 다시 사진을 업로드하는 화면으로 간다.

7.2.3 사용성 요구사항(Usability requirement)- 간단하게 음성 인식으로 자신의 요구사항을 확인하는 방법으로

누구나 간단하게 이용할 수 있다. - SNS 연동을 할 수 있게 함으로써 쉽게 결과를 공유할 수 있다. 7.2.4 유지보수성 요구사항(Maintainability requirements)

- 동시접속자로 인해서 서버에서 문제가 발생하는 경우 로그파일을

통해서 접속자 사용자 분석을 할 수 있다. 7.2.5 이식성 요구사항(Portability requirements)

- 웹서버만 있다면 파일을 옮기면 작동시킬 수 있으므로 이식이 쉽다. 7.2.6 보안성 요구사항(Security requirements)

- 사용자가 업로드한 사진 정보(추가적인 신상 정보 포함)가 유출되지

않도록 한다.

8. 운영 요구사항(Operational Requirements) 8.1 물리적 운영 요구사항(Physical Operational Requirements) 해당 시스템을 구현하기 위해서는 웹서버가 있어야 한다.

8.2 설치 요구사항(adaptation requirements) 사용자는 인터넷에 접속할 수만 있으면 누구나 이용할 수 있다.

8.3 사용자 문서와 훈련 요구사항(User Documentation and Training)

사용자가 웹페이지의 간단한 설명에 따라서 순서대로 진행하면 쉽게 이용할

수 있도록 UI 를 구성한다.

9. 제약사항(Constraints) (1) 설계 및 구현 제약: - 어플리케이션 개발을 하기 위해서 Java 를 사용한다.- Crawling 을 하기 위해서 python 를 사용한다.

- DB 구축을 하고 MySQL(오라클)을 사용한다.(2) 표준 적합성:내부 규정

- 소프트웨어, 관련 문서 제작 및 수정시 카카오톡 채팅방 방, 구글 docs, Wiki 에

관련 내용을 남긴다.(3) 법적 제약

- 본 SW 와 관련된 법률이 존재하지 않는다.(4) 조직의 문화적 요구사항:- 대중적으로 카드에 대한 관심이 높아지고 있다.- 최근 음성 인식 시스템이 주목받고 있다.

10. Use Case 명세

Use Case UC1이름 사용자 니즈 추출

개요 사용자가 음성 인식을 통해 니즈를 입력한다.액터 사용자, 관리자

사전 조건 사용자는 어플리케이션을 실행한 상태이다.기본 흐름 1. 사용자가 신상 정보를 입력한다.

2. 시스템은 음성 인식 API 를 통해 단어를 추출한다.3. 시스템은 단어의 가중치를 부여한다.4. UC2 로 분기한다.

대안 흐름 .사후 조건 사용자에게 카드 관련 정보를 제공한 상태

Use Case UC2이름 추천 카드 제공

개요 사용자의 니즈의 가중치를 바탕으로 카드를 추천한다.액터 사용자, 관리자

사전 조건 사용자는 신상 정보 입력 및 니즈를 업로드하고 제출을 한 상태이다.

기본 흐름

1. 관리자는 시스템의 제품 DB 를 매일 업데이트 한다.2. 시스템은 사용자의 정보를 바탕으로 DB 에서 검색을 한다.3. 시스템은 추천 제품에 대한 결과를 군집화된 형태로 가공한다.4. 시스템은 결과를 앱에 넘긴다.5. 앱에서 결과를 출력해준다.

대안 흐름 .사후 조건 제품 추천 결과를 앱에 넘긴 상태

11. WBS마지막 수정일 : 2017-11-06

WBS 태스크 작업자 상태 시작일 종료일기간

진척도

1 요구사항 - - 2017-10-29

2017-11-07 9 100

%1.1 위험 분석 강종구 Completed 17-10-29 17-10-30 1 100

%1.2 비즈니스 요구사항 분석 김현배 Completed 17-10-29 17-10-30 1 100

%1.3 사용자 요구사항 분석 공동 Completed 17-10-30 17-11-01 1 100

%1.3.1 기능, 비기능 요구사항 도출 김용수 Completed 17-11-02 17-11-03 1 100

%1.3.2 USE CASE 전민기,

김현배Completed 17-11-03 17-11-04 1 100

%1.4 SRS 문서 작성 공동 Completed 17-11-04 17-11-06 2 100

%1.5 WBS 추가 강종구 Completed 17-11-06 17-11-07 1 100

%2 분석 　 - 0%

2.1 정적 분석 공동 Not Started 0%

　 클래스 , 객체 도출 공동 Not Started 0%2.2 동적 분석 공동 Not Started 0%

Sequence Diagram 작성 공동 Not Started 0%3 설계 　 - 0%

3.1 DB 설계 　 Not Started 0%3.2 아키텍처 설계 　 Not Started 0%3.3 클래스 설계 　 　 0%3.4 UI 설계 　 Not Started 0%3.4 진행 업무 점검 및 이슈 해결 　 Milestone 0%

4 구현 　 - 0%4.1 서버 개발 　 - 　 0%

4.1.1 서버 구축 　 Not Started 0%4.1.2 DB 구축 　 Not Started 0%4.1.3 정보 입력(카드사 이름, 혜택) 　 Not Started 　 0%4.2 앱서비스 개발 　 -

4.2.1 정보입력 　 Not Started4.2.2 음성인식 API 　 Not Started4.2.3 정확한 값을 입력받았는지 확인 　 Not Started 0%4.2.7 중간 전 진행 업무 점검 및 이슈 해결 　 Milestone 0%4.2.8 최종 전 진행 업무 점검 및 이슈 해결 　 Milestone 0%

5 테스트 　 - 0%5.1 통합 테스트 　 - 0%

5.1.1 단위/통합 테스트(서버) 　 Not Started 0%5.1.2 단위/통합 테스트(DB) 　 Not Started 0%5.1.3 단위/통합 테스트(웹) 　 Not Started 0%