init

2022-04-18 15:18:05 +09:00 · 2022-04-18 15:18:05 +09:00 · 9c20f8adef
commit 9c20f8adef
parent 849bca7cb0
7 changed files with 440 additions and 16 deletions
--- a/.gitignore
+++ b/.gitignore
@ -1,16 +1 @@
-# ---> Rust
+book
 # Generated by Cargo
 # will have compiled files and executables
 debug/
 target/
 # Remove Cargo.lock from gitignore if creating an executable, leave it for libraries
 # More information here https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html
 Cargo.lock
 # These are backup files generated by rustfmt
 **/*.rs.bk
 # MSVC Windows builds of rustc generate these, which store debugging information
 *.pdb
--- a/book.toml
+++ b/book.toml
@ -0,0 +1,6 @@
 [book]
 authors = ["monoid"]
 language = "en"
 multilingual = false
 src = "src"
 title = "Software Requirement Specification"
--- a/src/OverallDescription.md
+++ b/src/OverallDescription.md
@ -0,0 +1,170 @@
 # 2. 전체 시스템 개요(Overall description)
 > - 제품 및 제품 요구사항에 영향을 미치는 일반적인 요인을 설명해야 한다.
 > - 특정 요구사항을 설명하지 않고, 상세 요구사항(Specific requirements)에 관한 배경을 제공한다.
 ### 2.1. 제품 관점(Product perspective)
 > - 제품을 관련된 다른 제품과의 관계를 중심으로 봐야 한다.
 > - 제품이 독립적인 경우 명시되어야 하고, 더 큰 시스템의 구성 요소로 정의된다면 시스템의 요구사항을 소프트웨어의 기능과 관계시켜야 하며 시스템과 소프트웨어 사이의 인터페이스를 식별해야 한다.
 ### 2.1.1. 시스템 인터페이스(System interfaces)
 > - 각 시스템 인터페이스를 나열한다.
 > - 시스템 요구사항을 달성하기 위한 소프트웨어 기능과 시스템에 일치하는 인터페이스에 관해 설명한다.
 본 시스템은 Cross-platform 소프트웨어이다. 다음과 같은 브라우저가 원활히 실행될 수 있는 시스템에서 동작 할 수 있다.
 - Chrome 버전 61 이상
 - Firefox 버전 60 이상
 - Edge 버전 79 이상
 - Safari 버전 11 이상
 - Chrome for Android 버전 100 이상
 - Samsung internet 버전 8.2 이상
 ### 2.1.2. 사용자 인터페이스(User interfaces)
 > 1. 소프트웨어 제품과 사용자 간 인터페이스의 논리적 특성을 지정한다.
 >    - 소프트웨어 요구사항을 충족하는 데 필요한 구성 특성(필요한 화면 형식, 페이지 또는 창 레이아웃, 보고서나 메뉴의 내용, 프로그래밍 가능한 기능 키의 사용 가능)을 포함
 > 1. 시스템을 사용해야 하는 사람에게 최적화된 모든 측면을 설명한다.
 사용자 인터페이스의 디자인은 Material Design이나 Metro Design 같이 플랫한 디자인을 추구한다.
 인터페이스의 구성요소는 다음과 같다. 문서는 글뭉치의 집합입니다. 글뭉치는 문단이나 이미지, 영상, 링크 또는 csv등의 구조적 텍스트입니다. 글뭉치는 안의 내용에 따라 표시됩니다. 사용자는 글뭉치를 이리저리 원하는 장소에 배치 할 수 있습니다. 사용자는 글뭉치를 다른 웹 페이지에서 드래그엔드롭으로 끌어 올 수 있습니다. 사용자는 문서를 보이는 대로 웹 페이지로 출력 할 수 있습니다.
 ### 2.1.3. 하드웨어 인터페이스(Hardware interfaces)
 > - 소프트웨어 제품과 시스템의 하드웨어 컴포넌트 사이에 각 인터페이스의 논리적 특성을 지정해야 한다.
 > - 지원하는 기기의 종류와 지원 방법, 사용하는 프로토콜 등에 관한 내용을 다룬다.
 ### 2.1.4. 소프트웨어 인터페이스(Software interfaces)
 > - 다른 필수 소프트웨어(데이터 관리 시스템, 운영체제, 수학 패키지)의 사용과 다른 시스템과의 인터페이스를 지정한다.
 > - 각 소프트웨어 제품에 대해 제공되어야 하는 정보
 >   1. Name
 >   1. Mnemonic
 >   1. Specification number
 >   1. Version number
 >   1. Source
 > - 각 인터페이스에 대해 제공되어야 하는 정보
 >   1. 소프트웨어와 인터페이스 하는 목적
 >   1. 인터페이스에서 사용되는 메시지의 내용과 형식에 관한 정의
 >      - 문서화된 인터페이스를 자세하게 설명할 필요는 없지만, 인터페이스를 정의하는 문서에 대한 참조가 필요하다.
 ### 2.1.5. 통신 인터페이스(Communications interfaces)
 > - 로컬 네트워크 프로토콜과 같은 통신에 대한 다양한 인터페이스를 지정해야 한다.
 ### 2.1.6. 메모리 제약사항(Memory constraints)
 > - 1차 및 2차 메모리에 적용 가능한 특성과 한계를 명시해야 한다.
 ### 2.1.7. 운영(Operations)
 > - 지정해야 하는 운영 작업의 종류
 >   1. 사용자 그룹의 다양한 운영 모드
 >   1. Interactive한 작업 기간과 unattended한 작업의 기간
 >   1. 데이터 처리 지원 기능
 >   1. 백업 및 복구 동작
 > >
 > > - 사용자 인터페이스 항목의 일부로 지정되기도 한다.
 ### 2.1.8. 사이트 적용 요건(Site adaption requirements)
 > - 특정 사이트, misson, 또는 동작 모드(grid value, safety, etc)에 특화된 어떤 데이터나 초기화 순서에 대한 요구사항을 정의한다.
 > - 소프트웨어를 특정 설치에 알맞도록 수정해야 하는 사이트 또는 mission과 관련된 특징을 지정한다.
 ## 2.2. 제품 기능(Product functions)
 > - 소프트웨어가 수행하는 주요 기능에 대한 요약을 제공한다.
 >   - 필요한 기능의 요약은 상위 수준의 명세서로부터 가져올 수 있다.
 > - 준수해야 하는 사항
 >   1. 고객이나 다른 사람이 봤을 때 기능 목록을 보고 이해할 수 있도록 기능이 구성되어야 한다.
 >   1. 텍스트 또는 그래픽을 통해 기능들 사이의 관계를 보여줄 수 있다.
 >      - 여기에서 표현되는 다이어그램은 설계를 보여주기 위함이 아니라 변수 사이의 논리적 관계를 단순하게 보여주기 위한 것이다.
 본 프로젝트의 결과물은 다음과 같은 기능을 수행한다.
 - Scrap
    - Focus, Unfocus
    - 수정
    - 읽기
    - 삭제
    - 다른 것과 스왑
        - Alt 화살표로 스왑
    - LaTex 편집, 미리보기 띄워주기
    - 링크 타입
        - 미리보기 보여주기
        - 링크 캐시
    - git 히스토리 보여주기
    - LaTex 타입
    - 그림, 비디오
    - 워드, 한글 뷰어
    - 자동 완성
 - Document
    - Scrap 얻어오기
    - 삭제
    - 태그 붙이기
    - 드래그 앤 드롭 업로드
    - 외부 변경 감지 자동 리로드
    - 공유
    - STUN, TURN 서버를 통한 편집
    - navigator
 - File TreeView
    - 파일 삭제
    - 파일 다운로드
    - 파일 업로드
    - Document 오픈
    - 드래그앤드롭 파일 move
 - Search
    - 문서 태그 검색
    - 문서 내용 검색
 - Clipboard
    - 보기
    - 추가
    - 삭제
    - 클립보드 내용 바꾸기.
    - 드래그앤드롭 파일
 - Management
    - login with session
    - Configure
    - 현지화(localization)
    - 테마
 - 내부 플러그인
    - 샘플: 체스 형식 뷰어
 - 브라우저 확장기능: 로그인이 필요한 곳을 위한 캐시된 웹사이트 제공하는
 ## 2.3. 사용자 특성(User characteristics)
 사용자는 기본적인 GUI 조작을 할 줄 알며 인터넷 사용을 원활히 할 수 있고 기본적인 영어를 읽고 쓸 줄 알며, markdown을 작성할 수 있는 사용자로 한정한다. 일반적으로 13세 이상 65세 이하의 사람을 사용자로 가정한다.
 > - 교육 수준, 경험, 기술적 전문 지식을 포함하여 제품의 대상이 되는 사용자의 일반적인 특성을 설명해야 한다.
 > - 세부적인 요구사항을 기술하는 데 사용되어서는 안 되고, 세부 요구사항이 나중에 명시되는 이유로 제공되어야 한다.
 ## 2.4. 제약사항(Constraints)
 > - 개발자의 선택을 제한할 모든 항목에 관한 일반적인 설명을 제공해야 한다.
 > - 포함되는 내용
 >   1. Regulatory plocies
 >   1. Hardware limitations (e.g., signal timing requirements)
 >   1. Interfaces to other applications
 >   1. Parallel operation
 >   1. Audit functions
 >   1. Control functions
 >   1. Higher-order language requirements
 >   1. Signal handshake protocols(e.g., XON-XOFF, ACK-NACK)
 >   1. Reliability requirements
 >   1. Criticality of the application
 >   1. Safety and security considerations
 > 
 - Docker 배포
 - .env 설정
 - 첫 로드후 로딩 0.5s 이내
 - 동시 편집 이용자 5명 이내
 - 1000 RPS 정도 버티기
 - 
 ## 2.5. 가정 및 의존성(Assumptions and dependencies)
 > - SRS에서 명시한 요구사항에 영향을 미치는 요소들을 나열해야 한다.
 > - 이 요소들은 소프트웨어의 설계 제약사항이 아니라 SRS의 요구사항에 영향을 미칠 수 있는 변경 사항들이다.
 ## 2.6. 단계별 요구사항(Apportioning of requirements)
 > - 시스템의 향후 버전으로 지연될 수 있는 요구사항을 식별해야 한다.
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@ -0,0 +1,6 @@
 # Summary
 - [Introduction](./introduction.md)
 - [Overall Description](./OverallDescription.md)
 - [Specific Requirement](./SpecificRequirements.md)
 - [Supporting information](./SupportingInformation.md)
--- a/src/SpecificRequirements.md
+++ b/src/SpecificRequirements.md
@ -0,0 +1,169 @@
 # 3. 상세요구사항(Specific Requirements)
 > - 설계자가 요구사항을 만족하는 시스템을 설계할 수 있도록 모든 요구사항을 상세하게 포함해야 한다.
 > - 테스터가 시스템이 위 요건을 충족하는지 테스트해야 한다.
 > - 모든 요구사항은 사용자, 운영자, 다른 외부 시스템에 의해 외부적으로 인지할 수 있어야 한다.
 > - 이 요구사항에는 시스템에 대한 모든 입력(자극)과 출력(응답) 그리고 입력 또는 출력 지원에 대한 응답으로 실행되는 모든 기능에 관한 설명이 포함되어야 한다.
 > - 상세 요구사항을 작성하기 위한 원칙
 >   1. 상세 요구사항은 "Characteristics of a good SRS"에 설명한 모든 특성을 준수하도록 작성되어야 한다.
 >   1. 상세 요구사항은 관련이 있는 이전 문서들과 상호 참조되어야 한다.
 >   1. 모든 요구사항은 고유하게 식별할 수 있어야 한다.
 >   1. 가독성을 높이기 위해 요구사항을 구성할 때 주의를 기울여야 한다.
 ## 3.1. 외부 인터페이스 요구사항(External interface requirements)
 > - 소프트웨어 시스템의 모든 입력과 출력에 관해 자세히 설명해야 한다.
 > - "Overall description"의 인터페이스 설명을 보완하되, 그곳의 정보가 반복되지 않아야 한다.
 > - 포함되는 외부 인터페이스의 내용 및 형식
 >   1. Name of item
 >   1. Description of purpose
 >   1. Source of input or destination of output
 >   1. Valid range, accuracy, and/or tolerance
 >   1. Units of measure
 >   1. Timing
 >   1. Relationships to other inputs/outputs
 >   1. Screen formats/organization
 >   1. Window formats/organization
 >   1. Data formats
 >   1. Command formats
 >   1. End messages
 ### 3.1.1. 사용자 인터페이스(User interfaces)
 ### 3.1.2. 하드웨어 인터페이스(Hardware interfaces)
 ### 3.1.3. 소프트웨어 인터페이스(Software interfaces)
 ### 3.1.4. 통신 인터페이스(Communications interfaces)
 ## 3.2. 기능 요구사항(Functional requirements)
 > - 기능 요구사항은 소프트웨어가 입력을 처리하고 출력을 생성하는 기본적인 행동을 정의해야 한다.
 > - 포함하는 행동들
 >   1. Validity checks on the inputs
 >   1. Exact sequence of operations
 >   1. Responses to abnormal situations, including
 >      1. Overflow
 >      1. Communication facilities
 >      1. Error handling and recovery
 >   1. Effect of parameters
 >   1. Relationship of outputs to inputs, including
 >      1. Input/output sequences
 >      1. Formulas for input to output conversion
 ## 3.3. 성능 요구사항(Performance requirements)
 > - 소프트웨어 또는 소프트웨어와 사람의 상호작용에 대하여 수치화된 정적/동적 요구사항이 명시되어야 한다.
 > - 수치화된 정적 요구사항의 종류
 >   1. 지원할 터미널 수
 >   1. 지원할 동시 접속 사용자 수
 >   1. 처리할 정보의 양과 유형작업 및 데이터의 양
 ## 3.4. 논리적 데이터베이스 요구사항(Logical database requirements)
 > - 데이터베이스에 저장할 정보에 관한 논리적 요구사항을 지정해야 한다.
 > - 논리적 요구사항의 종류
 >   1. Types of information used by various functuons
 >   1. Frequency of use
 >   1. Accessing capabilities
 >   1. Data entities and their relationships
 >   1. Integrity constraints
 >   1. Data retention requirements
 ## 3.5. 설계 제약사항(Design constraints)
 > - 다른 표준, 하드웨어 한계 등에 의해 부과될 수 있는 설계 제약사항을 명시해야 한다.
 ### 3.5.1. 표준 준수(Standards compliance)
 > - 표준이나 규정에서 파생된 요구사항을 기술한다.
 > - 포함될 수 있는 내용
 >   1. Report format
 >   1. Data naming
 >   1. Accounting procedures
 >   1. Audit tracing
 ## 3.6. 소프트웨어 시스템 속성(Software system attributes)
 > - 요구사항으로 사용될 수 있는 소프트웨어의 여러 가지 속성 중 제품이 객관적으로 입증되는 데 필요한 속성을 명시해야 한다.
 ### 3.6.1. 신뢰성(Reliability)
 > - 배포될 때 소프트웨어 시스템의 필수 신뢰성을 확립하는 데 필요한 요소를 명시해야 한다.
 ### 3.6.2. 가용성(Availability)
 > - 검사, 복구, 재시작과 같이 전체 시스템에 대해 정의된 가용성 수준을 보장하는 데 필요한 요소가 지정되어야 한다.
 ### 3.6.3. 보안성(Security)
 > - 실수 또는 악의적인 접근, 사용, 수정, 파괴, 공개로부터 소프트웨어를 보호하기 위한 요소를 명시해야 한다.
 > - 포함될 수 있는 요구사항
 >   1. Utilize certain cryptographical techinques
 >   1. Keep specific log or history data sets
 >   1. Assign certain functions to diffrent modules
 >   1. Restrict communication between some areas of the program
 >   1. Check data integrity for critical variables
 ### 3.6.4. 유지 보수성(Maintainability)
 > - 소프트웨어 자체를 쉽게 유지 보수할 수 있는 속성을 명시해야 한다.
 > - 모듈화, 인터페이스, 복잡성 등과 관련된 요구사항이 있을 수 있다.
 ### 3.6.5. 이식성(Portability)
 > - 소프트웨어를 다른 호스트 시스템 또는 운영체제로 쉽게 이식할 수 있는 속성을 명시해야 한다.
 > - 포함될 수 있는 속성의 종류
 >   1. Percentage of components with host-dependent code
 >   1. Percentage of code that is dependent
 >   1. Use of a proven portable language
 >   1. Use of a particular compiler or language subset
 >   1. Use of a particular operation system
 ## 3.7. 상세 요구사항의 구성(Organizing the specific requirements)
 > - 시스템의 세부 요구사항은 광범위한 경향이 있으므로 자료를 이해하기에 가장 적합한 방식으로 구성하는 방법을 세심하게 고려해야 한다.
 ### 3.7.1. 시스템 모드(System mode)
 > - 일부 시스템은 운영 모드에 따라 상당히 다르게 작동할 수 있다.
 >   - 예: 제어 시스템은 연습, 일반, 긴급 등의 여러 모드가 있을 수 있다.
 ### 3.7.2. 사용자 부류(User class)
 > - 일부 시스템은 사용자의 부류에 따라 서로 다른 기능을 제공한다.
 >   - 예: 엘리베이터 제어 시스템은 승객, 정비원, 소방관에게 서로 다른 기능을 제공한다.
 ### 3.7.3. 객체(Objects)
 > - 객체는 시스템에서 현실 세계와 대응되는 개체이다.
 > - 객체에는 각 각체의 상태(attributes) 및 객체의 행위(functions)가 포함된다.
 >   - 이러한 행위는 services, methods, processes라고도 한다.
 ### 3.7.4. 특징(Feature)
 > - 특징은 시스템에 의해 외부적으로 요구되는 서비스로서 원하는 결과를 얻기 위해서는 입력이 필요할 수도 있다.
 >   - 예: 전화 시스템에서 특징들은 지역 내 통화, 착신 전환, 화상 통화를 포함한다.
 > - 일반적으로 각 특징은 자극-반응의 순서로 설명된다.
 ### 3.7.5. 자극(Stimulus)
 > - 일부 시스템은 자극의 측면에서 기능들을 설명할 때 가장 잘 구성될 수 있다.
 >   - 예: 항공기 자동 착륙 시스템은 동력 상실, 윈드시어 등을 위해 구성될 수 있다.
 ### 3.7.6. 반응(Response)
 > - 일부 시스템은 반응 생성을 지원하는 기능들을 설명할 때 가장 잘 구성될 수 있다.
 >   - 예: 직원 시스템의 기능은 급여 생성과 관련된 기능들, 직원 목록 생성과 관련된 기능 등으로 구성될 수 있다.
 ### 3.7.7. 기능 계층(Functional hierarchy)
 > - 위 조직 체계 중 유용한 수단이 없다면, 전체 기능은 공통 입력, 공통 출력 또는 공통 내부 데이터 접근에 의해 구성된 기능의 계층으로 구성될 수 있다.
 > - 데이터 흐름 다이어그램과 데이터 사전을 사용하여 기능과 데이터 사이의 관계를 보여줄 수 있다.
 ### 3.7.8. Additional comments
 > - 새로운 SRS를 고려할 때 두 가지 이상의 조직 기법이 적합할 수 있다.
 >   - 이 경우 명세에 따른 시스템의 상세 요구사항에 맞춘 다중 계층의 요구사항을 구성한다.
--- a/src/SupportingInformation.md
+++ b/src/SupportingInformation.md
@ -0,0 +1,16 @@
 # 추가 이력 (Supporting Information)
 ## 4.1. Table of contents and index(목차와 인덱스)
 > - 목차와 인덱스는 매우 중요하므로 일반적인 compositional practices를 따라야 한다.
 ## 4.2. 부록(Appendixes)
 > - 부록은 SRS의 일부로 간주하지 않으며, 항상 필요한 것도 아니다.
 > - 부록이 포함하는 내용
 >   1. Sample input/output formats, descriptions of cost analysis studies, or results of user surveys
 >   1. Supporting or background information that can help the readers of the SRS
 >   1. A description of the problems to be solved by the software
 >   1. Special packaging instructions for the code and the media to mmet security, export, initial loading, or other requirements
 > >
 > > - 부록이 포함된 경우 SRS는 부록이 요구사항의 일부로 간주하는지 명시해야 한다.
--- a/src/introduction.md
+++ b/src/introduction.md
@ -0,0 +1,72 @@
 # 1. 소개(Introduction)
 ## 목적(Purpose)
 본 문서는 전북대학교 컴퓨터공학과의 Floor 팀에서 Scrap Yard라는 어플리케이션을 설계 및 구현하기 위한 소프트웨어 요구사항 명세서(SRS)이다.
 ## 범위(Scope)
 본 프로젝트는 다음과 같은 항목을 범위로 한다.
 - ScrapYard 앱이 가지는 기능
  - 기능: 웹페이지 링크 미리보기
  - 기능: 로그인이 필요한 곳을 위한 캐시된 웹사이트 제공하는 브라우저 확장기능. 
  - 기능: 문서 편집
  - 기능: Latex 수식 편집
  - 기능: 문서 링크 공유(파일 공유)
  - 기능: 드래그 앤 드롭 업로드
  - 기능: 파일이 에디터 외부에서 편집되어도 업데이트
  - 기능: 검색
  - 기능: 문서 태그
  - 기능: 단순 로그인/로그아웃 설정
  - 기능: 관리창
  - 기능: self-hosting을 위한 Docker image 제공
  - 기능: gitbook 과 같은 문법으로 nav를 만들 수 있음.
  - 기능: 다국어 지원: Internationalization (i18n)
  - 기능: 테마(Light, Dark)
  - 기능: 서버에서의 문서 동시 편집.
  - 기능: STUN 서버를 통한 동시 편집.
  - 기능: 자동완성
  - 기능: 문서 히스토리 버퍼
  - 기능: git 사용시 git histroy 보여주고 diff 보여주기
  - 기능: 클립보드
  - 기능: 워드, 한글 뷰어
  - 기능: 여러 파일 형식을 위한 플러그인
 ## 용어 및 약어 정의(Definitions, acronyms and abbreviations)
 |용어 및 약어|정의|
 |---|----|
 |ScrapYard|현재 개발하는 앱의 명칭|
 |DnD|드래그 앤 드롭의 약자|
 ## 참고자료(References)
 1. Knowledge base: https://en.wikipedia.org/wiki/Knowledge_base
 2. Open Meta Graph: https://ogp.me/
 ## 개요(Overview)
 개요는 2장에서는 종합적인 요구사항을 서술하고, 3장에서는 기능 및 UI에 대해서 상세한 요구사항을 설명한다.
 ## 기능적 요구
 ## 비기능적 요구
 - Docker 배포
 - .env 설정
 - 첫 로드후 로딩 0.5s 이내
 - 동시 편집 이용자 5명 이내
 - 1000 RPS 정도 버티기
 ## Detail
 ### Scrap
 #### Focus, Unfocus
 사용자가 Scrap의 영역에 클릭을 했을때, Focus 된다. 다른 Scrap의 포커스는 사라진다. Scrap을 수정, 삭제하기위한 기능은 Focus를 해야 할 수 있다.
 Unfocus 되었을때 Scrap을 저장한다.
 #### 수정
 단순 텍스트를 수정한다.