Docstoc

SRS_SecretNote_v1.0

Document Sample
SRS_SecretNote_v1.0 Powered By Docstoc
					                              Andy Secret Note v3.0
           Software Requirements Specification


                                   Date : 2010.04.03
            Writer : 안현, 정영훈, 이용규, 최순길, 박범기




ABC Tech Confidential Restricted         1 of 29       2011년 6월 26일 오전 7시 53분
                                        문서정보 / 수정 내역


  파일명:                                    SRS_SecretNote_v1.0.doc
  템플릿 버전:                                 SRS_template_ABC_Tech_v3.0.doc
  원안작성자 :
  수정작업자 :


                                        추가/수정 항
     수정날짜            수정자           버전                                 내    용
                                          목
                                                        * 리뷰 시 관련자 성명(역할)을 직접 명시한다.




ABC Tech Confidential Restricted              2 of 29                 2011년 6월 26일 오전 7시 53분
                                                                               목                      차
1     INTRODUCTION (개요) ..............................................................................................................................................................5

    1.1     PURPOSE (목표)........................................................................................................................................................................5
    1.2     PRODUCT SCOPE (범위) ............................................................................................................................................................5
    1.3     DOCUMENT CONVENTIONS (문서규칙).....................................................................................................................................5
    1.4     TERMS AND ABBREVIATIONS (정의 및 약어) ...........................................................................................................................5
    1.5     RELATED DOCUMENTS (관련문서) ...........................................................................................................................................6
    1.6     INTENDED AUDIENCE AND READING SUGGESTIONS (대상 및 읽는 방법) ................................................................................6
    1.7     PROJECT OUTPUT (프로젝트 산출물) .....................................................................................................................................7
      1.7.1        Output Format (산출물 형태) ........................................................................................................................................7
      1.7.2        Output Name and Version (산출물명(가칭) 및 버전) ..................................................................................................7
      1.7.3        Patent Information (특허 출원 유무 및 내용) ............................................................................................................7

2     OVERALL DESCRIPTION (전체 설명) ....................................................................................................................................8

    2.1     PRODUCT PERSPECTIVE (제품 조망) ........................................................................................................................................8
    2.2     OVERALL SYSTEM CONFIGURATION (전체 시스템 구성) ........................................................................................................8
    2.3     OVERALL OPERATION (전체 동작방식) ...................................................................................................................................9
    2.4     PRODUCT FUNCTIONS (제품 주요 기능)..................................................................................................................................9
    2.5     USER CLASSES AND CHARACTERISTICS (사용자 계층과 특징) .............................................................................................10
    2.6     ASSUMPTIONS AND DEPENDENCIES (가정과 종속 관계) ....................................................................................................... 11
    2.7     APPORTIONING OF REQUIREMENTS (단계별 요구사항) ......................................................................................................... 11
    2.8     BACKWARD COMPATIBILITY (하위 호환성) ............................................................................................................................ 11

3     ENVIRONMENT (환경) .............................................................................................................................................................12

    3.1     OPERATING ENVIRONMENT (운영 환경) .................................................................................................................................12
      3.1.1        Hardware Environment (하드웨어 환경).....................................................................................................................12
      3.1.2        Software Environment (소프트웨어 환경)...................................................................................................................12
    3.2     PRODUCT INSTALLATION AND CONFIGURATION (제품 설치 및 설정) ....................................................................................12
    3.3     DISTRIBUTION ENVIRONMENT (배포 환경) ............................................................................................................................13
      3.3.1        Master Configuration (마스터 구성) ...........................................................................................................................13
      3.3.2        Distribution Method (배포 방법) .................................................................................................................................13
      3.3.3        Patch/Update Method (패치와 업데이트 방법) .........................................................................................................13
    3.4     DEVELOPMENT ENVIRONMENT (개발 환경) ...........................................................................................................................13
      3.4.1        Hardware Environment (하드웨어 환경).....................................................................................................................13
      3.4.2        Software Environment (소프트웨어 환경)...................................................................................................................13
    3.5     TEST ENVIRONMENT (테스트 환경).......................................................................................................................................14
      3.5.1        Hardware Environment (하드웨어 환경).....................................................................................................................14
      3.5.2        Software Environment (소프트웨어 환경)...................................................................................................................14
    3.6     CONFIGURATION MANAGEMENT (형상관리)...........................................................................................................................14
      3.6.1        Location of Outputs (산출물 위치) ..............................................................................................................................14
      3.6.1.1.         Location of Source Code (소스코드 위치)...............................................................................................................14
      3.6.1.2.         Location of Documents (문서 위치) .........................................................................................................................15
      3.6.2        Build Environment (빌드 환경) ....................................................................................................................................15
    3.7     BUGTRACK SYSTEM (버그트래킹) .........................................................................................................................................15
    3.8     OTHER ENVIRONMENT (기타 환경)........................................................................................................................................15

4     EXTERNAL INTERFACE REQUIREMENTS (외부 인터페이스 요구사항)......................................................................17



ABC Tech Confidential Restricted                                                       3 of 29                                              2011년 6월 26일 오전 7시 53분
    4.1       SYSTEM INTERFACES (시스템 인터페이스) ..........................................................................................................................17
    4.2       USER INTERFACE (사용자 인터페이스) ................................................................................................................................18
    4.3       HARDWARE INTERFACE (하드웨어 인터페이스)...................................................................................................................18
    4.4       SOFTWARE INTERFACE (소프트웨어 인터페이스) ................................................................................................................18
    4.5       COMMUNICATION INTERFACE (통신 인터페이스)..................................................................................................................19
    4.6       OTHER INTERFACE (기타 인터페이스) ..................................................................................................................................19

5     PERFORMANCE REQUIREMENTS (성능 요구사항) .........................................................................................................20

    5.1       THROUGHPUT (작업처리량) ..................................................................................................................................................20
    5.2       CONCURRENT SESSION (동시 세션) .......................................................................................................................................20
    5.3       RESPONSE TIME (대응시간) ...................................................................................................................................................20
    5.4       PERFORMANCE DEPENDENCY (성능 종속 관계) ....................................................................................................................21
    5.5       OTHER PERFORMANCE REQUIREMENTS (기타 성능 요구사항) .............................................................................................21

6     NON-FUNCTIONAL REQUIREMENTS (기능 이외의 요구사항).......................................................................................22

    6.1       SAFETY REQUIREMENTS (안전성 요구사항) ..........................................................................................................................22
    6.2       SECURITY REQUIREMENTS (보안 요구사항) ..........................................................................................................................22
    6.3       SOFTWARE SYSTEM ATTRIBUTES (소프트웨어 시스템 특성) ...............................................................................................22
      6.3.1          Availability (가용성) .....................................................................................................................................................22
      6.3.2          Maintainability (유지보수성) .......................................................................................................................................23
      6.3.3          Portability (이식성) ......................................................................................................................................................23
      6.3.4          Reliability (신뢰성) .......................................................................................................................................................23
      6.3.5          Remaining Attributes (나머지 특성) ............................................................................................................................23
    6.4       LOGICAL DATABASE REQUIREMENTS (데이터베이스 요구사항) ..........................................................................................23
    6.5       BUSINESS RULES (비즈니스 규칙) ........................................................................................................................................24
    6.6       DESIGN AND IMPLEMENTATION CONSTRAINTS (설계와 구현 제한사항) ...............................................................................24
      6.6.1          Standards Compliance (표준준수) ................................................................................................................................24
      6.6.2          Other Constraints (기타 제한 사항) ...........................................................................................................................24
    6.7       MEMORY CONSTRAINTS (메모리 제한 사항) ........................................................................................................................24
    6.8       OPERATIONS (운영 요구사항) ...............................................................................................................................................25
    6.9       SITE ADAPTATION REQUIREMENTS (사이트 적용 요구사항) ................................................................................................25
    6.10      INTERNATIONALIZATION REQUIREMENTS (다국어 지원 요구사항) .......................................................................................25
    6.11      UNICODE SUPPORT (유니코드 지원) .....................................................................................................................................25
    6.12      64BIT SUPPORT (64비트 지원) ...............................................................................................................................................25
    6.13      CERTIFICATION (제품 인증) ...................................................................................................................................................25
    6.14      FIELD TEST (필드 테스트).....................................................................................................................................................25
    6.15      OTHER REQUIREMENTS (기타 요구 사항) .............................................................................................................................26

7     FUNCTIONAL REQUIREMENTS (기능요구사항) ................................................................................................................27

    7.1       대분류 기능1........................................................................................................................................................................28
      7.1.1          …… ................................................................................................................................................................................28
      7.1.2          7.1.1.1       …… .................................................................................................................................................................28
      7.1.3          …… ................................................................................................................................................................................28
      7.1.4          …… ................................................................................................................................................................................28
    7.2       대분류 기능2........................................................................................................................................................................28
    7.3       대분류 기능3........................................................................................................................................................................28

8     CHANGE MANAGEMENT PROCESS (변경관리 프로세스) ...............................................................................................29

9     DOCUMENT APPROVALS (최종 승인자) ..............................................................................................................................29

10         REFERENCE MATERIALS (참고문헌) ...............................................................................................................................29



ABC Tech Confidential Restricted                                                            4 of 29                                               2011년 6월 26일 오전 7시 53분
11          APPENDIX (부록) ...................................................................................................................................................................29

     11.1      GLOSSARY (용어) ...................................................................................................................................................................29



1           Introduction (개요)

1.1 Purpose (목표)
                이 문서는 안드로이드용 비밀수첩 Application 소프트웨어의 요구사항을 정의하고 소프트웨어와 하드웨어
                 컴포넌트간의 인터페이스를 정의하는 것을 목적으로 한다.
                이 문서의 대상은 비밀수첩 Application을 개발에 직간접적으로 참여하는 개발팀, 마케팅팀, 영업팀, 기획
                 팀, QA팀 이다.



1.2 Product Scope (범위)
                이 제품의 이름은 앤디 비밀 수첩(Andy Secrete Note) 이다. 이하 비밀 수첩(Secrete Note) 라 한다.
                비밀 수첩은 Android 기반 휴대폰에서 개인적으로 사용하는 정보를 기록하고 관리하는 소프트웨어로써,
                 신용카드정보, 통장정보, 인터넷 계정 정보, 가족 정보 등을 관리한다.
                이 제품은 안드로이드 OS를 지원하며, 그 외의 OS는 지원하지 않는다.
                안드로이드 OS version은 2.0과 2.1을 지원하며 그 외 버전은 지원하지 않는다.
                기존의 ver1.0, ver2.0 버전은 Feature Phone에 pre-loading(build-in)된 어플리케이션이며, 이 프로젝트에서
                 개발할 ver3.0은 안드로이드폰에 Downloadable한 형태의 어플리케이션이다.
                스마트폰의 비중이 커지는 시장 상황에 따라 기존 버전(ver1.0, ver2.0)과의 호환성을 가지지 않고 안드로
                 이드폰의 최적화된 어플리케이션으로 전략적 주력상품으로 개발한다.




1.3 Document Conventions (문서규칙)
              글자 font, size 등은 회사에서 규정하는 template을 따르도록 한다.
              본 문서를 해외법인과 공유나 리뷰할 경우에는 해외설계부서에서 규정하는 template를 따르도록 한다.
              각 기능은 고유 ID와 우선순위를 표시한다.
                 -      고유ID는 “코드명-번호”의 형태로 표시한다. 코드명은 기능요구사항 분류 별로 영문 단어로 부여된다.
                        번호는 3자리 수로 구성되며, 분류 별로 001부터 순차적으로 증가한다.
              우선순위는 각 기능은 중요도에 따라 다음과 같은 3가지 개발 Priority로 표시한다.
                 -      높음(P1): 중요한 기능으로 반드시 구현해야 함.
                 -      보통(P2): 일반적인 기능으로 구현해야 함.
                 -      낮음(P3): 부가적인 기능으로 필요 시 배제할 수 있음.




1.4 Terms and Abbreviations (정의 및 약어)
 용어                                                정의
 Android                                           Operating System의 한 종류
 스마트폰                                              Application을 Download받아서 확장 가능한 구조를 가진 폰 장치



ABC Tech Confidential Restricted                                                         5 of 29                                             2011년 6월 26일 오전 7시 53분
 안드로이드 마켓                       안드로이드 기반 디바이스에서 실행 가능한 Application을 유료,무료로 다운받을
                                수 있는 Web 공간
 Pre-loading                    Feature Phone을 양산할 때 이미 어플리케이션을 포함하는 방식
 Downloadable                   Smart Phone을 사용자가 구매한 이후에 외부로부터 어플리케이션을 받아서 사
                                용할 수 있는 방식
 UX                             User Experience




1.5 Related Documents (관련문서)
본 비밀 수첩을 개발함에 있어 관련 문서는 다음과 같다. ( 3.4.1.2절의 문서 저장 위치 참조할 것)
         SRS_template_ABC_Tech_v3.0_ref.doc
      




1.6 Intended Audience and Reading Suggestions (대상 및 읽는 방법)
본 문서의 각 장은 아래의 표와 같이 대상이 참조하고 활용하도록 한다.
         H : High              (아주 자세하게 읽을 것)
         M : Middle            (자세하게 읽을 것)
         L : Low               (대충 읽을 것)


                       PM          Senior         개발자        마케팅   테스터     UI 담당자
                                   Engineer
1장 개요                       H
2장 전체설명                     M               M         M        H     M           M
3장 환경                       M               M         M        L     M
4장 외부인터페이                   M               M         H              M           H
스 요구사항
5장 성능요구사항                   M               M         H              H
6장 성능 이외의                   M               M         H              H
요구사항
7장 기능요구사항                   M               M         H              H           M
8장 변경관리프로                   H               M                  M
세스
9장 최종 승인자                   M
10장 참고문헌                    L




ABC Tech Confidential Restricted                   6 of 29          2011년 6월 26일 오전 7시 53분
1.7 Project Output (프로젝트 산출물)

1.7.1    Output Format (산출물 형태)

최종 산출물의 형태는 apk 형식의 파일이다.




1.7.2    Output Name and Version (산출물명(가칭) 및 버전)

본 프로젝트의 최종 산출물은 Andy Secrete Note v3.0 이다.
파일 이름:      Andy_Secrete_Note_v3.0.apk




1.7.3    Patent Information (특허 출원 유무 및 내용)

None
이 제품의 기술적 특성상 이미 존재하는 기술을 응용하는 것으로 특허 출원은 필요하지 않다.
기술적 특화가 아닌 사용자에게 쉽고 직관적인 UX를 제공하는 것을 강조한다.




ABC Tech Confidential Restricted         7 of 29   2011년 6월 26일 오전 7시 53분
2       Overall Description (전체 설명)



2.1 Product Perspective (제품 조망)
비밀 수첩(Secrete Note)은 Android 기반 휴대폰 용 Application으로 개인적으로 사용하는 정보를 기록하고 관리할
수 있다. 비밀 번호를 입력해야 실행할 수 있으며 실행 후에는 신용카드 정보, 통장 정보, 인터넷계정 정보, 가족
정보를 추가하거나 입력된 정보를 확인할 수 있다.




                                         그림 : 제품 조망 Diagram


        사용자 : 비밀 수첩을 사용하는 End User
        Android Market : Android용 Application을 download할 수 있는 online software store
        DBMS : DataBase를 관리하는 시스템. 이 시스템에서는 비밀 수첩에서 사용하는 정보를 저장/관리한다




2.2 Overall System Configuration (전체 시스템 구성)




ABC Tech Confidential Restricted                 8 of 29                     2011년 6월 26일 오전 7시 53분
                                   그림 : 전체 시스템 diagram


        Validation UI – 비밀 번호를 인증하는 UI를 담당한다. 비밀 번호 입력을 위해 가상 키보드를 화면에 띄운다.
         사용자 인증을 위해 Password Validater를 사용한다
        Home UI – 비밀 번호 인증 후 보이는 초기화면을 담당한다. 비밀 노트에서 제공하는 비밀 정보의 종류를
         화면에 표시한다.
        Secret Info UIs – 각 비밀 정보 항목에 특화된 UI를 제공한다. 하나의 화면에서 Add/View/Modify를 모두 처
         리한다.
        Password Verifier – 사용자가 입력한 password가 유효한지 database에 저장된 password 정보를 이용하여
         검증한다. 이 때 password string은 암호화되어 database에 저장돼야 한다.
        Secret Info Manager – 각 비밀 정보 항목에 대해 Add/Modify/Remove를 관리한다
        DBMS – 사용자가 입력한 비밀 정보를 저장/관리한다




2.3 Overall Operation (전체 동작방식)
모든 동작은 비밀 수첩 소프트웨어 초기 실행 시 비밀 번호 확인 후에 실행 가능하며 전체 동작방식은 다음과 같다


        사용자가 비밀번호를 입력해서 비밀수첩을 실행시킨다. 단, 초기 비밀번호는 0000으로 설정되어 있다
        사용자가 초기 화면에서 확인하고 싶은 항목을 (신용카드 정보, 통장 정보, 인터넷계정 정보, 가족 정보 중
         에서) 선택하면 해당 정보 list가 화면에 표시된다
        사용자가 통장 정보를 확인하기 위해서는 초기 화면에서 „통장 정보‟ 메뉴을 선택하면 된다. 통장 정보 list
         화면에서 사용자가 특정 통장 정보 항목을 선택하면 은행명, 통장번호, 용도가 화면에 표시되고 사용자는
         정보를 확인/수정할 수 있다
        사용자가 통장 정보를 추가하려면 통장 정보 list 화면에서 „추가‟ 버튼을 누른다. „은행명, 통장번호, 용도‟를
         입력할 수 있는 화면이 표시되고 내용 입력 후 „저장‟ 버튼을 누르면 해당 내용이 추가된다. 단, 통장 정보
         확인 화면과 추가 화면 그리고 수정 화면은 동일한 UI를 사용한다




ABC Tech Confidential Restricted         9 of 29                2011년 6월 26일 오전 7시 53분
2.4 Product Functions (제품 주요 기능)
SecretNote에서 제공하는 제품의 주요 기능은 다음과 같다.
SecretNote를 실행하면, 비밀번호를 묻는 대화창이 실행되며, 비밀번호 입력이 인증되면, 아래와 같은 기능을 수행
할 수 있다.


        신용 카드 정보
               사용자의 신용 카드 결제 정보를 저장하고 보여주는 기능이다.
         1)     신용 카드 정보 메뉴를 선택하게 되면, 현재 저장된 신용 카드 정보 리스트를 보여준다. 해당 리스트
                중 한 아이템을 선택하면, 선택된 카드의 “카드 이름, 카드 번호, 카드의 유효 기간”을 보여준다.
         2)     사용자는 신용 카드 정보 메뉴에서 새로운 신용 카드 정보를 입력할 수 있다. 사용자가 “추가”메뉴를
                선택하면, “카드 이름, 카드 번호, 유효 기간”을 입력할 수 있는 화면으로 이동한다. 정보 입력을 마치
                게 되면 해당 정보는 smartphone기기에 저장이 완료된다.


        통장 정보
               사용자의 통장 계좌 정보를 저장하고 보여주는 기능이다.
         1)     통장 정보 메뉴를 선택하게 되면, 현재 저장된 통장 정보 리스트를 보여준다. 해당 리스트중 한 아이
                템을 선택하면, 선택된 계좌의 “은행 이름, 계좌 번호, 통장 용도”를 보여준다.
         2)     사용자는 통장 정보 메뉴에서 새로운 통장 정보를 입력할 수 있다. 사용자가 “추가”메뉴를 선택하면,
                “은행 이름, 계좌 번호, 통장 용도”를 입력할 수 있는 화면으로 이동한다. 정보 입력을 마치게 되면 해
                당 정보는 smartphone기기에 저장이 완료된다.


        인터넷 정보
               사용자의 인터넷 웹사이트 로긴 정보를 저장하고 보여주는 기능이다.
         1)     인터넷 정보 메뉴를 선택하게 되면, 현재 저장된 인터넷 정보 리스트를 보여준다. 해당 리스트중 한
                아이템을 선택하면, 선택된 인터넷 사이트의 “사이트 이름, 주소, ID, 비밀 번호”를 보여준다.
         2)     사용자는 인터넷 정보 메뉴에서 새로운 인터넷 사이트 정보를 입력할 수 있다. 사용자가 “추가”메뉴를
                선택하면, “사이트 이름, 주소, ID, 비밀 번호”를 입력할 수 있는 화면으로 이동한다. 정보 입력을 마치
                게 되면 해당 정보는 smartphone기기에 저장이 완료된다.


        가족 정보
               사용자의 가족 정보를 저장하고 보여주는 기능이다.
         1)     인터넷 정보 메뉴를 선택하게 되면, 현재 저장된 가족 정보 리스트를 보여준다. 해당 리스트중 한 아
                이템을 선택하면, 선택된 가족의 “가족 관계, 주민등록번호, 생일, 주소, 본적”을 보여준다.
         2)     사용자는 인터넷 정보 메뉴에서 새로운 가족 정보를 입력할 수 있다. 사용자가 “추가”메뉴를 선택하면,
                “가족 관계, 주민등록번호, 생일, 주소, 본적”을 입력할 수 있는 화면으로 이동한다. 정보 입력을 마치
                게 되면 해당 정보는 smartphone기기에 저장이 완료된다.



        정보 초기화
               해당 기기의 ScretNote에 저장된 모든 정보를 삭제하는 기능이다.
           1)   사용자가 “정보 초기화”메뉴를 선택하면 SecretNote내의 모든 정보를 삭제한다.




2.5 User Classes and Characteristics (사용자 계층과 특징)
    SecretNote의 사용자 계층과 특징은 아래와 같다.


        핸드셋 사용자

ABC Tech Confidential Restricted        10 of 29          2011년 6월 26일 오전 7시 53분
         핸드셋 사용자의 SecretNote 이용의 주된 목적은, 개인 정보 필요시 불편함 없이 핸드셋을 통해서 확인을
         하기 위함이다. SecretNote에 저장되는 개인 정보가 유출될 경우에, 신상 정보 유출, 금융 사고 등의 문제
         등이 발생할 수 있으므로, 사용자는 SecretNote의 보안성을 가장 중요시한다.
         SecretNote의 사용 계층은 정보 기기 사용에 익숙하지 않은 사용자가 많기 때문에,프로그램의 설치와 사
         용법이 어려우면 금방 이용를 포기하는 경향이 있다.


         핸드셋 사용자는 한국인 뿐만 아니라, 외국인들도 사용할 수 있으므로, 메뉴의 한국어와 영어 전환이 가능
         해야 한다.


        A/S담당자
         SecretNote A/S담당자는 주로     핸드셋 사용자로부터, 비밀번호 분실이나, SecretNote정보의 분실과 관련해
         서 문의를 받을 확률이 높다. 관련 문의의 A/S를 수행시에도 SecretNote에 저장된 정보는 A/S담당자에 열
         람이 가능하면 안된다.



2.6 Assumptions and Dependencies (가정과 종속 관계)
           TBD…



2.7 Apportioning of Requirements (단계별 요구사항)
        SecretNote의 기능은 본 SRS에 준하며, 추가적으로 구현할 사항은 없다.



2.8 Backward compatibility (하위 호환성)
        SecretNote는 신규 개발 Software로서 고려할 하위 호환성 이슈는 없다.




ABC Tech Confidential Restricted         11 of 29           2011년 6월 26일 오전 7시 53분
3       Environment (환경)

3.1 Operating Environment (운영 환경)
본 프로젝트의 산출물을 설치하고 운영하기 위한 하드웨어 환경 정보와 소프트웨어 환경 정보(OS 및 사전에 설치
되어야 할 소프트웨어 등)를 기술한다.


3.1.1    Hardware Environment (하드웨어 환경)

본 프로젝트의 산출물은 Android Platform버전 1.5, 1.6, 2.0, 2.01, 2.1을 사용한 device들에서 동작 되어야 한다.


다음은 동작되어야 할 단말기를 명시한다.
Google: Nexus One
HTC :Dream, Magic, Hero, T-Mobile G1
Samsung: i7500 Galaxy, Moment, Spica, Behold II, SHW-M100s
LG:GW620, GT540 , OPhone(GW880)


다음 사양은 본 프로젝트의 산출물이 동작하기 위한 최소한의 사양을 명시함(T-Mobile G1의 사양임)
-Processor:528MHz
-Memory: ROM 256MB RAM:192MB
-Display: 320X480
-Connectivity: Bluetooth, Wi-Fi, USB2.0


3.1.2    Software Environment (소프트웨어 환경)


3.1.2.1 OS Environment (운영체제 환경)
1) Android platform버전 1.5, 1,6, 2.0, 2.01, 2.1
2) Linux Kernel 2.6.X


3.1.2.2 OS외 software 환경

NONE



3.2 Product Installation and Configuration (제품 설치 및 설정)

본 프로젝트의 산출물의 제품 설치는 일반적인 Android Application 제품 설치와 동일




ABC Tech Confidential Restricted                 12 of 29    2011년 6월 26일 오전 7시 53분
3.3 Distribution Environment (배포 환경)

3.3.1      Master Configuration (마스터 구성)

본 프로젝트의 산출물은 안드로이드 마켓에 등록 예정이며 필요한 파일은 다음과 같다.


1)Secretnote_v1.0.apk : application file.


2)Screenshots : Max 2page


3)Promotional Graphic



3.3.2      Distribution Method (배포 방법)

본 프로젝트의 산출물은 Android 용 Application 이므로 Android Market 에 등록하여 배포함.
자세한 Android Market 등록 방법은 Android Market 도움말 참조




3.3.3      Patch/Update Method (패치와 업데이트 방법)

본 프로젝트 산출물의 Patch/Update 방법은 Android Market의 Upgrades Rule을 따른다




3.4 Development Environment (개발 환경)

3.4.1      Hardware Environment (하드웨어 환경)


    OS

    - Windows XP(32bit), Windows Vista(32bit/64bit), Windows 7(32bit/64bit)
      Mac OS X 10.4.8 이후(x86판만)
      Linux Ubuntu Dapper Drake




3.4.2      Software Environment (소프트웨어 환경)


    Software 개발 환경

- Java Development kit 설치 :
     Download위치 : from http://developers.sun.com/downloads   Java SE / Java SE(JDK) 6
-   Android SDK 설치 :

ABC Tech Confidential Restricted                  13 of 29                      2011년 6월 26일 오전 7시 53분
     Download위치 : from http://developer.android.com/sdk/ Window item
-   Eclipse 설치 :
     Download위치 : From http://www.eclipse.org/downloads/ Eclipse IDE for JAVA EE Developers / [Korea, Republic of]

-   Eclipse Plug in 설치 :

     Dalvik Debug Monitor Service (ddms) / Android Debug Bridge (adb) / Android Asset Packaging Tool (aapt) /
     Android Interface Description Language (aidl) / sqlite3 / Traceview / Mksdcard / Dx / activityCreator




3.5 Test Environment (테스트 환경)

3.5.1     Hardware Environment (하드웨어 환경)

              -     Target Device : MOTOROI (MOTOROLA)
                      LH KH-5200 : 안드로원 (LG전자)
                      Magic Phone (HTC)




3.5.2     Software Environment (소프트웨어 환경)

-   Android에서 제공하는 다음의 Test Suite를 이용한다.
          -       Runtime Compatibility : CTS (Compatibility Test Suite) / Need to get NDA with Google
                    CTS :   Device Profile ( No need to concern)
                            Software compatibility (Managed API /     Soft API /   Native API /   Web API /
                                API Behavior / API Namespace /       Virtual Machine / User Interface /
                                Application Packaging /    Multimedia Compatibility / Development Tool )
          -       Consistent User Experience : UI/Application Exerciser Monkey
          -       Mobile device emulator : AVD(Android Virtual Device) configurations.
          -       각 Test Suite의 자세한 사용 방법 – TBD
          -




3.6      Configuration Management (형상관리)

3.6.1     Location of Outputs (산출물 위치)


-   Secretnote 개발은 Google에서 제공하는 code.google.com의 Project와
TortoiseSVN (version : 1.6.7.18415     / site : http://tortoisesvn.net/downloads에서 download가능 )으로 운영한다.




      Location of Source Code (소스코드 위치)

Secretnote 개발에 대한 Source code의 위치는 다음의 디렉터리 내에 존재한다.
http://code.google.com/p/sep522/source/browse/#svn/trunk/secretnote/src


ABC Tech Confidential Restricted                          14 of 29                        2011년 6월 26일 오전 7시 53분
      Location of Documents (문서 위치)

Secretnote 개발에 대한 SRS의 위치는 다음의 디렉터리 내에 존재한다.
http://code.google.com/p/sep522/source/browse/#svn/trunk/secretnote/doc/srs


3.6.2     Build Environment (빌드 환경)


     개발 OS정의

     - Windows XP(32bit), Windows Vista(32bit/64bit), Windows 7(32bit/64bit)
       Mac OS X 10.4.8 이후(x86판만)
       Linux Ubuntu Dapper Drake
.


     Directory & File 운영

- Build 담당자는 Build Directory rule을 확정한다. (SRS,SRC,DOC의 Directory를 생성)
- Build 담당자는 Configuration file(여러 개발자가 동일한 build를 run할 수 있도록)을 확정 후 공유한다.
- Build 담당자는 Team Project의 Build 시간 및 운영 안을 확정 한다.( 본 Project개발에서는 Daily Build를 대신하
     여 weekly Build (매주 토요일 10시)를 target으로 진행)




     Build Related SW

- 3.4.2절의 Software Environment (소프트웨어 환경)의 SW List와 동일.
-    Detail Information : - TBD




     Build후 Release전 확인 사항 확정

-    EULA(End User License Agreement)추가
-    Public final class인 Manifest에 icon과 label을 지정
-    Debug Application close
-    Log/Backup file의 close
-    private or proprietary data확인 및 삭제
-    Private key 획득
-    Detail Information : -TBD




3.7 Bugtrack System (버그트래킹)
-Secretnote 개발에 활용할 버그트래킹 시스템은 Google에서 제공하는 code.google.com의 issue tracking을 활용한
다.
버그트래킹은 code.goolgle.com의 sep522 Project에 올라가는 매주 토요일 최종 버전의 SRS에 대해 오류 발생 시


ABC Tech Confidential Restricted                  15 of 29                     2011년 6월 26일 오전 7시 53분
사용한다.
각 할당된 Chapter에 대한 이슈는 해당 Chapter담당자가 담당한다.




3.8 Other Environment (기타 환경)
         -    TBD




ABC Tech Confidential Restricted   16 of 29   2011년 6월 26일 오전 7시 53분
4        External Interface Requirements (외부 인터페이스 요구사항)
이 제품과 연결되어 있는 모든 종류의 인터페이스를 기술한다.


[[ If the external interfaces are complicated, the separate IRS can replaces this chapter. ]]


If the product is independent and totally self-contained, it should be so stated here.     If the SRS defines a product that is
a component of a larger system, as frequently occurs, then this subsection relates the requirements of the larger system
to functionality of the software and identifies interfaces between that system and the software.


A block diagram showing the major components of the larger system, interconnections, and external interfaces can be
helpful.   This is not a design or architecture picture.   It is more to provide context, especially if your system will interact
with external actors.   The system you are building should be shown as a black box.          Let the design document present
the internals.


This contains a detailed description of all inputs into and outputs from the software system.


It contains both content and format as follows:


          Name of item
          Description of purpose
          Source of input or destination of output
          Valid range, accuracy and/or tolerance
          Units of measure
          Timing
          Relationships to other inputs/outputs
          Screen formats/organization
          Window formats/organization
          Data formats
          Command formats
          End messages


If the external interfaces are complicated , you may write a separate „Interface Requirement Specification‟ document for
all or any of the following interfaces.




4.1 System Interfaces (시스템 인터페이스)
List each system interface and identify the functionality of the software to accomplish the system requirement and the
interface description to match the system. These are external systems that you have to interact with. For instance, if you
are building a business application that interfaces with the existing employee payroll system, what is the API to that
system that designers will need to use?


[[ Means existing systems that company currently uses. Software systems(e.g. DB) to be installed with this SRS will be
explained in Software Interface section ]]




ABC Tech Confidential Restricted                           17 of 29                           2011년 6월 26일 오전 7시 53분
4.2 User Interface (사용자 인터페이스)
This is a description of how the system will interact with its users.
Describe the logical characteristics of each interface between the software product and the users. This may include
sample screen images, any GUI standards or product family style guides that are to be followed, screen layout
constraints, standard buttons and functions (e.g., help) that will appear on every screen, keyboard shortcuts, error
message display standards, and so on.


Is there a GUI, a command line or some other type of interface?         Are there special interface requirements?   If you are
designing for the general student population for instance, what is the impact of ADA (American with Disabilities Act) on
your interface?


Details of the user interface design should be documented in a separate user interface specification.




4.3 Hardware Interface (하드웨어 인터페이스)
Specify the logical characteristics of each interface between the software product and the hardware components of the
system.   This includes configuration characteristics. This may include the supported device types, the nature of the data
and control interactions between the software and the hardware, and communication protocols to be used.
This is not a description of hardware requirements in the sense that “This program must run on a Mac with 64M of RAM”.
This section is for detailing the actual hardware devices your application will interact with and control.    For instance, if
you are controlling X10 type home devices, what is the interface to those devices?


Designers should be able to look at this and know what hardware they need to worry about in the design.                 Many
business type applications will have no hardware interfaces.       If none, just state “The system has no hardware interface
requirements”
If you just delete sections that are not applicable, then readers do not know if:
         this does not apply or
         you forgot to include the section in the first place.




4.4 Software Interface (소프트웨어 인터페이스)
Describe the connections between this product and other specific software components (name and version), including
databases, operating systems, tools, libraries, and integrated commercial components. Identify the data items or
messages coming into the system and going out and describe the purpose of each.

Describe the services needed and the nature of communications.
Refer to documents that describe detailed application programming interface protocols.
Identify data that will be shared across software components. If the data sharing mechanism must be implemented in a
specific way (for example, use of a global data area in a multitasking operating system), specify this as an
implementation constraint.


[[ This is one of the examples where a senior engineer can write better SRS than a requiremnt specialist ]]



ABC Tech Confidential Restricted                          18 of 29                          2011년 6월 26일 오전 7시 53분
Specify the use of other required software products and interfaces with other application systems.     For each required
software product, include:
   (1) Name
   (2) Mnemonic (약식코드)
   (3) Specification number
   (4) Version number
   (5) Source
For each interface, provide:
   (1) Discussion of the purpose of the interfacing software as related to this software product
   (2) Definition of the interface in terms of message content and format


Here we document the APIs, versions of software that we do not have to write, but that our system has to use.         For
instance if your customer uses SQL Server 7 and you are required to use that, then you need to specify i.e.
„Microsoft SQL Server 7‟.      The system must use SQL Server as its database component.     Communication with the DB
is through ODBC connections.        The system must provide SQL data table definintions to be provided to the company
DBA for setup. A key point to remember is that you do NOT want to specify software here that you think would be good to
use.   This is only for customer-specified systems that you have to interact with.     Choosing SQL Server 7 as a DB
without a customer requirement is a Design choice, not a requirement. This is a subtle but important point to writing good
requirements and not over-constraining the design.




4.5 Communication Interface (통신 인터페이스)
Describe the requirements associated with any communications functions required by this product, including e-mail, web
browser, network server communications protocols, electronic forms, and so on.
Define any pertinent message formatting.
Identify any communication standards that will be used, such as FTP or HTTP.

Specify any communication security or encryption issues, data transfer rates, and synchronization mechanisms.

If you are using a custom protocol to communicate between systems, then document that protocol here so designers
know what to design.   If it is a standard protocol, you can reference an existing document or RFC.




4.6 Other Interface (기타 인터페이스)




ABC Tech Confidential Restricted                        19 of 29                         2011년 6월 26일 오전 7시 53분
5      Performance requirements (성능 요구사항)
프로젝트 목표 제품의 성능 측면의 요구사항을 기술한다. 즉, 성능 목표(가능한 수치화하여)를 도출한다.
아래 항목은 프로젝트 별로 다른 성능 지표를 도출한 경우, 이를 적용하여 수정및 추가 할 수 있다.


[[ Performance requirements is one of the Non-Functional requirements. This section shows requirements that is applied
to all Funtional Requirements. If there are differnet requirements for each function, they have to be specified in Ch7
Functional Requirements section. ]]


If there are performance requirements for the product under various circumstances, state them here and explain their
rationale, to help the developers understand the intent and make suitable design choices.
Specify the timing relationships for real time systems.
Make such requirements as specific as possible. You may need to state performance requirements for individual
functional requirements or features here or “Functional Requirements” section.


Specify both the static and the dynamic numerical requirements placed on the software or on human interaction with the
software, as a whole.
Static numerical requirements may include:
       (a)     The number of terminals to be supported
       (b)     The number of simultaneous users to be supported
       (c) Amount and type of information to be handled
Static numerical requirements are sometimes identified under a separate section entitled capacity.


Dynamic numerical requirements may include, for example, the numbers of transactions and tasks and the
amount of data to be processed within certain time periods for both normal and peak workload conditions.
All of these requirements should be stated in measurable terms.
For example,
         95% of the transactions shall be processed in less than 1 second
rather than,
         An operator shall not have to wait for the transaction to complete.
(Note: Numerical limits applied to one specific function are normally specified as part of the processing subparagraph
description of that function.)




5.1 Throughput (작업처리량)
일정한 시간내에 수행한 작업량을 의미한다.




5.2 Concurrent Session (동시 세션)
동시 처리수를 의미한다.




5.3 Response Time (대응시간)
처리 시간을 의미한다.


ABC Tech Confidential Restricted                          20 of 29                      2011년 6월 26일 오전 7시 53분
5.4 Performance Dependency (성능 종속 관계)
하나 이상의 성능이 서로 종속적일 경우 연관관계를 기술한다.



5.5 Other Performance Requirements (기타 성능 요구사항)
메모리, 디스크 공간 요구사항, DB 최대 row수와 같은 기타 성능 관련 요구사항들을 기술한다.




ABC Tech Confidential Restricted   21 of 29     2011년 6월 26일 오전 7시 53분
6       Non-Functional Requirements (기능 이외의 요구사항)



6.1 Safety requirements (안전성 요구사항)
SecretNote에서 data입력 중에 Phone의 전원을 제거한 경우에 대해서는 입력중인 Data를 보장하지 않는다.




6.2 Security Requirements (보안 요구사항)
SecretNote는 Application의 사용자가 설정한 Password에 따라 사용자를 인식하며, Authentication Process는
Password확인으로 수행된다.
SecretNote는 사용자 Password로 사용 권한이 확인되므로 Confidentiality를 확보 할 수 있다.
SecretNote는 사용자 동작 시 다음의 조건에 Database에 저장을 수행 한다.
              -     신용카드의 예 : 정보 입력 후 Save 동작 수행 시
              -     Application을 정상 종료 시
SecretNote는 사용자 Password입력 후 원하는 날짜와 시간을 기준으로 Database에 저장된 비밀 Data에 대한
복구 동작을 수행 할 수 있으므로 Integration을 확보 할 수 있다.
password string은 암호화되어 database에 저장되어 있고 A/S를 수행 시에도 A/S담당자는 Password자체에 대한 확
인만이 가능하고 SecretNote에 저장된 비밀 Data에 대한 access는 불가능하다.




6.3 Software System Attributes (소프트웨어 시스템 특성)
There are a number of attributes of software that can serve as requirements.           It is important that required attributes are
specified so that their achievement can be objectively verified. Attributes may include availability, correctness, flexibility,
interoperability, maintainability, portability, reliability, reusability, robustness, testability, and usability. The following items
provide a partial list of examples.   These are also known as non-functional requirements or quality attributes.


These are characteristics the system must possess, but that pervade (or cross-cut) the design.
These requirements have to be testable just like the functional requirements.           Its easy to start philosophizing here, but
keep it specific.




6.3.1      Availability (가용성)

SecretNote는 사용자에 의해서 실행이 요구되는 경우에만 동작한다.
사용자에의 의한 실행 요청과 종료 요청에 대해서는 10초 이내로 동작수행 완료하도록 한다.
SecretNote는 사용자 Password입력 후 원하는 날짜와 시간을 기준으로 Database에 저장된 비밀 Data에 대한
복구가 가능하다.
SecretNote의 경우 Restart시에는 항상 Application을 신규 기동(Cold Boot)을 수행한다.



ABC Tech Confidential Restricted                            22 of 29                            2011년 6월 26일 오전 7시 53분
6.3.2    Maintainability (유지보수성)

SecretNote ver 3.0의 경우 Update시의 버전 Rule – TBD
SecretNote의 신규 버전에 대한 버전 Rule - TBD




6.3.3    Portability (이식성)

TBD




6.3.4    Reliability (신뢰성)

비밀 수첩은 한 번 실행되면 사용자가 종료하거나 배터리 부족으로 핸드폰 전원이 나가기 전까지 동작해야 한다.
단, 배터리 부족으로 Android OS가 비밀 수첩 Application을 종료를 시도 하면 현재 화면에 보이는 Activity 내용을
저장한 후 다음에 재실행 시 저장되었던 화면을 표시한다.




6.3.5    Remaining Attributes (나머지 특성)

None (현재 확인된 추가 특성이 없으며, 향후 파악되면 내용 추가)




6.4 Logical Database Requirements (데이터베이스 요구사항)

Android Platform에서 제공하는 SQLite를 사용한다


DB Schema Diagram은 아래와 같다. 단, LoginAccount table에 입력되는 DefaultPassword와 Password 정보는 암호
화해서 입력된다.


LoginAccount
ID*                     DefaultPassword   Password


CreditCard
Name*                   Number*           ValidYear       ValidMonth


BankBook
Name*                   Number*           Purposes


WebAccount
Name*                   Address           ID              Password



ABC Tech Confidential Restricted               23 of 29                2011년 6월 26일 오전 7시 53분
Family
Relation*                 SocialSecurityNum            Birthday            BirthdayType              Address




6.5 Business Rules (비즈니스 규칙)
None (비밀 수첩에서는 해당 사항이 없음)




6.6 Design and Implementation Constraints (설계와 구현 제한사항)



6.6.1       Standards Compliance (표준준수)

코딩 시에 Sun 사의 „Code Conventions for the Java Programming Language‟를 준수한다
(참고 link: http://java.sun.com/docs/codeconv/ )




6.6.2       Other Constraints (기타 제한 사항)

개발용 IDE(Integrated Development Environment)는 Eclipse를 사용하며 Eclipse plug-in 인 “Android Developer Tools”
를 추가로 설치해서 사용한다.


개발 언어는 Java를 사용하나 일반적인 Java SE와는 사용할 수 있는 library가 일부 다르다.


비밀         수첩    Icon   디자인       시   Google의        „Icon   Design     Guidelines,    Android    2.0‟를    따른다   (참고   link:
http://developer.android.com/guide/practices/ui_guidelines/icon_design.html ).


Activity    설계    시     Google의    „Activity   and   Task     Design    Guidelines‟의    Design     Tips를   따른다   (참고   link:
http://developer.android.com/guide/practices/ui_guidelines/activity_task_design.html#design_tips ).




6.7 Memory Constraints (메모리 제한 사항)
           Android Application의 Memory 제한사항은 현재 명시되어 있지 않음.


           현재 상용화된 휴대폰의 Memory Size는 ROM 256MB~2GBMB                                  RAM:128MB~512MB이므로
            Application의 Footprint는 ROM 256MB                RAM 128MB를 넘을 수 없음.


           Android에서는 외장메모리카드에 Application을 다운받을 수 없어 내장 Memory 영역에만 다운 받을 수
            있어 Dalvik VM에서 동작되기 위해서는 Optimized 되어져야 함.


           Application에서 저장되는 Data는 DB로 비휘발성 메모리에 저장됨.



ABC Tech Confidential Restricted                             24 of 29                            2011년 6월 26일 오전 7시 53분
6.8 Operations (운영 요구사항)
        none




6.9 Site Adaptation Requirements (사이트 적용 요구사항)
        N/A



6.10 Internationalization Requirements (다국어 지원 요구사항)
        한국어
        영어
        TDB (그 이외의 언어 지원 여부는 상세 설계단계에서 고려되어져야 함)




6.11 Unicode Support (유니코드 지원)
Unicode 지원.



6.12 64bit Support (64비트 지원)
None
현재 안드로이드 OS가 32bit 이기 때문에 64bit는 지원하지 않는다.




6.13 Certification (제품 인증)
본 프로젝트 산출물이 외부 인증을 받아야 하는지, 받는다면 어떤 인증을 받아야 하는지, 언제 어떤 방법으로 진행
하며, 무엇을 준비해야 하는지, 그 비용은 어떻게 되는지 등을 기술한다. 마케팅과 협의 요망함.


예를 들어, 다음과          같은 리스트가 있다.


        MS Logo 인증
        Good Software 인증
        국제공통평가기준(CC)




6.14 Field Test (필드 테스트)
None
본 제품은 필드 테스트가 필요하지 않다.




ABC Tech Confidential Restricted   25 of 29         2011년 6월 26일 오전 7시 53분
6.15 Other Requirements (기타 요구 사항)
Define any other requirements not covered elsewhere in the SRS. This might include database requirements, legal
requirements, reuse objectives for the project, and so on. Add any new sections that are pertinent to the project.




ABC Tech Confidential Restricted                        26 of 29                          2011년 6월 26일 오전 7시 53분
7     Functional Requirements (기능요구사항)
2장에서 설명되었던 제품 주요 기능을 상세하게 분류하고, 설명한다.
각 기능을 구분 가능하도록 개별번호를 붙인다.
WBS의 각 기능항목은 작업량이 1~2일 정도로 산정 가능하도록 세분하여 작성한다.


Instruction to organizing the functional requirements

    For anything but trivial systems the detailed requirements tend to be extensive. For this reason, it is recommended
    that careful consideration be given to organizing these in a manner optimal for understanding.
    There is no one optimal organization for all systems.


    1. System mode
    Some systems behave quite differently depending on the mode of operation. For example, a control system
    may have different sets of functions depending on its mode: training, normal, or emergency. The choice depends on
    whether interfaces and performance are dependent on mode.


    2. User class
    Some systems provide different sets of functions to different classes of users. For example, an elevator
    control system presents different capabilities to passengers, maintenance workers, and fire fighters.


    3. Objects
    Objects are real-world entities that have a counterpart within the system. For example, in a patient monitoring
    system, objects include patients, sensors, nurses, rooms, physicians, medicines, etc. Associated with
    each object is a set of attributes (of that object) and functions (performed by that object). These functions are
    also called services, methods, or processes. When organizing this section by object, Note that sets of objects may
    share attributes and services. These are grouped together as classes.


    4. Feature
    A feature is an externally desired service by the system that may require a sequence of inputs to effect the
    desired result. For example, in a telephone system, features include local call, call forwarding, and conference
    call. Each feature is generally described in a sequence of stimulus-response pairs.


    5. Stimulus
    Some systems can be best organized by describing their functions in terms of stimuli. For example, the functions
    of an automatic aircraft landing system may be organized into sections for loss of power, wind shear,
    sudden change in roll, vertical velocity excessive, etc.


    6. Response
    Some systems can be best organized by describing all the functions in support of the generation of a
    response. For example, the functions of a personnel system may be organized into sections corresponding to
    all functions associated with generating paychecks, all functions associated with generating a current list of
    employees, etc.


    7. Functional hierarchy
    When none of the above organizational schemes prove helpful, the overall functionality can be organized
    into a hierarchy of functions organized by either common inputs, common outputs, or common internal data
    access. Data Flow diagrams and data dictionaries can be used to show the relationships between and among


ABC Tech Confidential Restricted                         27 of 29                          2011년 6월 26일 오전 7시 53분
    the functions and data.




7.1 대분류 기능1

7.1.1      ……


7.1.2    7.1.1.1     ……


7.1.3    ……


7.1.4    ……




7.2      대분류 기능2


7.3      대분류 기능3

……




ABC Tech Confidential Restricted   28 of 29   2011년 6월 26일 오전 7시 53분
8        Change Management process (변경관리 프로세스)
Identify the change management process to be used to identify, log, evaluate, and update the SRS to reflect changes in
project scope and requirements.
    1)    How are you going to control changes to the requirements?
    2)    Can the customer just call up and ask for something new?
    3)    Does your team have to reach consensus?
    4)    How do changes to requirements get submitted to the team?
    5)    Formally in writing, email or phone call?


This process can be specified in the one of the „Process Diagram‟s of the company.




9        Document Approvals (최종 승인자)

Identify the approvers of the SRS document. Approver name, signature, and date should be used.


Name                                      Signature                   Date




10 Reference Materials (참고문헌)

모든 문서는 소스코드 관리 시스템의 파일 위치로 기재한다.




11 Appendix (부록)

11.1 Glossary (용어)




ABC Tech Confidential Restricted                      29 of 29                        2011년 6월 26일 오전 7시 53분

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:23
posted:6/26/2011
language:Korean
pages:29