📝 docs(docs): add basic srs document (#291)

docs/docs/software-requirement-specification/Intrduction.md

@@ -5,134 +5,68 @@ sidebar_position: 2
 
 # 1	Introduction (개요)
 ## 1.1	Purpose (목표)
-•	Describe the purpose of the particular SRS and specify the intended audience for the SRS.
+•  위치 기반 음악 공유 소셜 서비스, Street Drop의 SRS 문서입니다.
 
 
-•	Identify the product whose software requirements are specified in this document, including the revision or release number.
+• 이 SRS 문서는 **Street Drop 애플리케이션의 요구사항을 정의**합니다.
 
 
-•	핵심을 짧게 잘 적어야 한다.
+•  독자는 Street Drop 개발팀, 디자인팀이며, 외부 독자 또한 포함합니다.
 
 
-•	SRS의 목적이다.
-
-
-•	이 문서는 모바일 HTS를 개발하기 위한 SRS이다. ( 이렇게 하면 안된다 )
-
-
-•	너무 뻔한 이야기를 적으면 안된다.
-
-
-•	CEO가 보아서 가치가 있을 이야기를 적어라.
-
-
-•	이 일은 인도사람에게 외주를 주어서 개발하려는 것이다.  (예)
-
-
-•	이것은 3개월간 프로토타입을 만들기 위한 것이다. (예)
-
-
-•	이 문서의 독자는 외부도 포함한다(예)
-
-
-•	Goals : 제품의 목적은 생략하라
-
-
-•	Audience는 너무 당연한 것 빼고 중요한, 특이한 부분만 적는다.
-•
-•
 ## 1.2	Product Scope (범위)
-Provide a short description of the software being specified. Relate the software to corporate goals or business strategies.
-This should be an executive-level summary. Do not enumerate the whole requirements list here.
-
-•	Identify the software product(s) to be produced by name
-
-
-•	Explain what the software product(s) will, and, if necessary, will not do (더중요)
-
 
-•	Describe the application of the software being specified, including relevant benefits, objectives, and goals  
+• 애플리케이션은 위치 기반 서비스를 활용하여 사용자들이 음악을 공유하고, 다른 사용자들과 상호작용할 수 있는 소셜 서비스를 제공합니다.
 
 
-•	Be consistent with similar statements in higher-level specifications if they exist
+• IOS 디바이스 중 아이폰만 지원할 예정이며, **안드로이드는 지원하지 않습니다.**
 
 
-•	If a separate vision and scope document is available, refer to it rather than duplicating its contents here.
+• 대한민국으로 한정하여 서비스가 제공되며, 추후 해외 서비스를 제공할 수 있습니다.
 
 
-•	비즈니스 전략 : 실제 회사를 가정해도 된다. 아니면 새로운 회사를 가정해도 된다. (중요, 빠져있음)
-
-
-•	임원들을 위한 summary (excutive-level summary)
-
-
-•	이름이 확정되어야 한다.
-
-
-•	우리는 안드로이드를 지원할것이다 보다, 윈모바일이나 블랙베리나..를 지원하지 않는다가 더 중요하다.
-
-
-•	Relevant benefits : 다른 제품과 연관해서 이득. 첫 제품인 경우는 없는 것이고….
-
-
-•	Goals : SRS의 목적
 
+## 1.3	Document Conventions (문서규칙)
+• 특별한 의미가 있거나 강조되어야 할 부분은 **굵게** 표시하였습니다.
 
-•	Higher-level specification 은 없다.
+• 인쇄를 위해 참조이외의 경우에는 링크를 사용하지 않았습니다.
 
 
-•	Separate vision and scope document 는 기획팀 자료..이것은 어디어디를 봐라, 참조하라…
 
+## 1.4	Terms and Abbreviations (정의 및 약어)
 
-•	지원하지 않는 것에 대해서 명시하는 것이 중요하다 ( 이유는 간단히 할 수 있으면 하고 아니면 그냥 하지 마라)
 
+• SRS (Software Requirements Specification): 소프트웨어 요구사항 명세서의 약어로, Street Drop의 요구사항을 문서화한 것입니다.
 
 
-## 1.3	Document Conventions (문서규칙)
-본 문서를 읽는데 필요한 기본 규칙을 기술한다.
+• 위치 기반 서비스 (Location-Based Service): 사용자의 현재 위치 정보를 활용하여 서비스를 제공하는 기술입니다.
 
-Describe any standards or typographical conventions that were followed when writing this SRS, such as fonts or highlighting that have special significance. For example, state whether priorities  for higher-level requirements are assumed to be inherited by detailed requirements, or whether every requirement statement is to have its own priority.
-이 부분은 회사의 sample을 쫒아해도 된다.
-
-## 1.4	Terms and Abbreviations (정의 및 약어)
-본 문서에서 자주 사용되는 용어에 대한 기본 정의 및 약어를 정리한다.
-정의를 해야 한다.
-수 십개 정도…
 
+• 소셜 서비스 (Social Service): 사용자들 간에 소통하고 커뮤니케이션할 수 있는 온라인 플랫폼을 말합니다.
 ## 1.5	Related Documents (관련문서)
-제품기획서, Onepager, SRS, IRS 등 본 프로젝트의 SRS와 관련된 문서를 기술한다.
+• 추후 추가 예정입니다.
 
+## 1.6	Intended Audience and Reading Suggestions (대상 및 읽는 방법)
+이 문서는 Street Drop 애플리케이션을 개발하고 디자인하는 데 관여하는 모든 팀원들과 외부 이해관계자들을 대상으로 합니다.
 
-모든 문서는 소스코드 관리 시스템에서의 파일 위치를 명시한다.
-
+개발팀: 이 문서는 애플리케이션의 요구사항을 정확히 이해하고 구현하는 데 필요한 정보를 제공합니다.
 
-모든 문서는 프로젝트안에 있어야 하고 링크를 걸어 볼 수 있어야 한다.
 
+디자인팀: 디자인 요소와 관련된 특정 요구사항과 사용자 경험에 대한 정보를 참고할 수 있습니다.
 
-문서를 링크 걸어야 한다
 
-## 1.6	Intended Audience and Reading Suggestions (대상 및 읽는 방법)
-본 문서를 리뷰 할 대상(관련 부서/팀 포함)을 명시한다.
+외부 이해관계자: 애플리케이션의 기능과 범위를 이해하고 이에 대한 피드백을 제공하기 위해 이 문서를 참고할 수 있습니다.
 
-Describe the different types of reader that the document is intended for, such as developers, project managers, marketing staff, users, testers, and documentation writers.
 
-Describe what the rest of this SRS contains and how it is organized. Suggest a sequence for reading the document, beginning with the overview sections and proceeding through the sections that are most pertinent to each reader type.
-샘플중에 적당한 것을 사용하면 된다.
-어떻게 어느 정도로 읽어야 하는 지도 명시하면 좋다. 좀 자세히 읽으라든지,
-왜 읽어야 하는지? ( 이런건 시험에 나오기도 한다)
-표로 만드는 것은 좋다. 단, 좀 더 자세히….
+독자들은 전체 문서를 읽는 것을 권장하며, 필요한 경우 관심 있는 부분을 세부적으로 탐색할 수 있습니다.
 
 
 ## 1.7	Project Output (프로젝트 산출물)
-본 프로젝트 결과물의 형태 및 버전 등에 대해 기술한다.
-산출물의 형태가 제품인지 라이브러리인지 툴인지 등을 구분하여 기술하며, 산출물명(가칭) 및 그 대표 버전을 기술한다.
-3장의 배포 방법과 중복이 될 수 있다.
-필연적으로 중복이 될 수는 있는데 (없을 수는 없는데), 그 이유는?   ?
+
 
 ### 1.7.1 	Output Format (산출물 형태)
-안드로이드 : aa.마
-구동할 수 있는 application 이다
+• 최종 산출물은 IOS 애플리케이션과 AWS에 배포된 서버로 구성됩니다.
+
 
 ### 1.7.2 	Output Name and Version (산출물명(가칭) 및 버전)
-Diary_ver1.0.
-파일 이름에 대해 버전을 바꾸어야 하는지 아니면 안드로이드 내부 버전 관리가 되는 지…모름.
+• 프로젝트 산출물의 명칭은 "Street Drop (스트릿 드랍)"이며, 현재 버전은 1.0입니다.

docs/docs/software-requirement-specification/change-management-process.md

@@ -4,11 +4,7 @@ sidebar_position: 9
 ---
 
 # 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?
+변경에 관한 모든 프로세스는 정규 회의시간에 전체회의를 통해서 논의되며, 
+변경에 대한 요청은 Notion에 기록되어야 합니다.
 
-This process can be specified in the one of the ‘Process Diagram’s of the company.
+- API 변경의 경우, IOS 버전에 따라 호환이슈가 존재하므로, 필수적으로 IOS 개발팀 진행사항을 확인하고 변경사항을 적용해야 합니다.

docs/docs/software-requirement-specification/environment.md

@@ -5,56 +5,48 @@ sidebar_position: 4
 
 
 # 3	Environment (환경)
-샘플을 보고 해도 된다.
 ## 3.1	Operating Environment (운영 환경)
-본 프로젝트의 산출물을 설치하고 운영하기 위한 하드웨어 환경 정보와 소프트웨어 환경 정보(OS 및 사전에 설치되어야 할 소프트웨어 등)를 기술한다.
 
 ### 3.1.1 	Hardware Environment (하드웨어 환경)
-안드로이드는 하드웨어 환경이 여러 가지이다.
-CPU는 생략해도 된다.
-버전 정보와 제품 이름 정도…
-### 3.1.2 	Software Environment (소프트웨어 환경)
-안드로이드는 여러 가지이다. 리눅스, 윈도우…DB….
-제품이 사용되어질 환경
-OS 버전, 제품 버전. 등이 많아 진다.
+지원하는 IOS 디바이스 기종은 아래와 같습니다.
 
-#### 3.1.2.1 OS Environment (운영체제 환경)
-본 프로젝트의 산출물이 지원하는 OS를 확인하기 위해 전사적으로 최신 OS 목록을 항상 가지고 있어야 한다.
+Mac, iPhone, iPod touch
 
-지원하는 플랫폼에 따라 내용을 확인하고, 필요에 따라
-(1) 아래 표와 같이 복사하고, 지원여부란을 만들어 체크하거나,
-(2) 지원하는 플랫폼 리스트만 기술하시기 바랍니다.
 
-1) Windows 플랫폼
 
-[아래표는 샘플입니다. 반드시, 최신 OS Coverage Sheet를 받아서 사용하시기 바랍니다.]
+### 3.1.2 	Software Environment (소프트웨어 환경)
 
+#### 3.1.2.1 OS Environment (운영체제 환경)
 
-2) Unix/Linux 플랫폼
-   최신 OS Coverage Sheet를 참조하여 작성하시기 바랍니다.
+#### IOS 
 
-3.1.2.2 OS외 software 환경
+| 디바이스         | 최소 요구 사항            |
+|-----------------|--------------------------|
+| Mac             | macOS 11.0 이상, Apple M1 칩 이상 탑재 |
+| iPhone          | iOS 14.0 이상 필요        |
+| iPod touch      | iOS 14.0 이상 필요        |
 
-1) Web Browser
 
-- MS Internet Explorer 버전 (필수 지원)
-- Mozilla Firefox 버전 (필수 지원)
+#### Server
+Window, Linux, Mac OS 등 다양한 운영체제에서 사용 가능하지만, 서비스 배포를 위해 **Linux 환경을 권장**합니다. 
+클라우드 서비스를 이용하여 배포할 경우, AWS, GCP, Azure 등 다양한 클라우드 서비스에서 사용 가능합니다.
+개발 과정에서 클라우드 환경을 고려하여 개발하였습니다.
 
-2) 기타1
+배포를 위한 최소 사양은 다음과 같습니다.
 
-3) 기타2
+| Server               | CPU      | RAM     | Storage |
+|----------------------|---------|---------|---------|
+| API Server           | 1 Core  | 1GB     | 10GB    |
+| Search Server        | 1 Core  | 1GB     | 10GB    |
+| Notification Server  | 1 Core  | 1GB     | 10GB    |
+| Database Server      | 1 Core  | 1GB     | 10GB    |
+| Batch Server         | 1 Core  | 1GB     | 10GB    |
 
 
 ## 3.2	Product Installation and Configuration (제품 설치 및 설정)
-본 프로젝트의 산출물의 설치 과정에서의 요구사항을 기술한다. 또한 제품을 실행하는데 필요한 기본 설정 요소 및 방법에 대한 요구사항을 기술한다.
-
-High Level로 기술하면 된다. (간단하게)
-제품을 어디에 올려서 어디서 다운로드 받아서 사용한다..등..
-
-InstallShield와 같은 상용 설치툴 혹은  자체 개발한 설치툴이 있으면 기술한다.
-
-6장의 Site Adaptation Requirements와 중복되는 부분은 명시하지 않는다.
+App Store를 통해 배포되었습니다. 아래 링크를 통해서 앱스토어에서 제품을 다운로드 받을 수 있습니다.
 
+https://apps.apple.com/kr/app/%EC%8A%A4%ED%8A%B8%EB%A6%BF%EB%93%9C%EB%9E%8D-street-drop/id6450315928
 
 ## 3.3	Distribution Environment (배포 환경)
 ### 3.3.1 	Master Configuration (마스터 구성)
@@ -70,7 +62,22 @@ InstallShield와 같은 상용 설치툴 혹은  자체 개발한 설치툴이 
 •	Manual (매뉴얼 폴더)
 
 스크립트도 포함되어야 하고, apk 파일,
-### 3.3.2 	Distribution Method (배포 방법)
+### 3.3.2 	Distribution Method (배포 방법
+#### IOS
+
+| 디바이스         | 최소 요구 사항            |
+|-----------------|--------------------------|
+| Mac             | macOS 11.0 이상, Apple M1 칩 이상 탑재 |
+| iPhone          | iOS 14.0 이상 필요        |
+| iPod touch      | iOS 14.0 이상 필요        |
+
+
+#### Server
+Window, Linux, Mac OS 등 다양한 운영체제에서 사용 가능하지만, 서비스 배포를 위해 **Linux 환경을 권장**합니다.
+클라우드 서비스를 이용하여 배포할 경우, AWS, GCP, Azure 등 다양한 클라우드 서비스에서 사용 가능합니다.
+개발 과정에서 클라우드 환경을 고려하여 개발하였습니다.
+
+배포를 위한 최소 사양은 다음과 같습니다.
 본 프로젝트의 산출물 마스터를 어떤 방법으로 배포할 것인지를 기술한다.
 예를 들어, CD로 전달한다든지, 소프트웨어를 웹에서 다운로드 받게 한다든지 등의 배포 방법이 있다.
 간단하게 적는다
@@ -97,7 +104,24 @@ iTunes AppStore를 통해 배포한다. 배포 전에 iTunes Connect를 통해 A
 형상관리 서버상의 본 프로젝트의 소스 위치 및 문서 위치를 명시한다.
 구글을 사용한다
 #### 3.6.1.1.	 Location of Source Code (소스코드 위치)
+모든 소스코드는 Github를 통해서 관리됩니다.
+
+**IOS**
+
+
+
+**Server**
+- 모노레포 구조로 관리됩니다.
+- 소스 폴더 구조는 다음과 같습니다.
+```
+.
+├── README.md
+├── api
+```
+
 #### 3.6.1.2.	 Location of Documents (문서 위치)
+- 모든 문서는 현재 웹페이지와 내부적으로 사용되는 문서는 모두 Notion을 통해서 관리됩니다.
+
 ### 3.6.2 	Build Environment (빌드 환경)
 빌드머신 등의 빌드 환경을 어떻게 구축/운영할지 Build/Release 팀과 협의하여 기술한다.
 빌드 기계, 빌드 디렉토리, 특수하게 요구되는 빌드방법 등을 기술한다.
@@ -106,10 +130,22 @@ iTunes AppStore를 통해 배포한다. 배포 전에 iTunes Connect를 통해 A
 빌드 서버의 사양, OS, compiler 등을 명시
 
 
+빌드와 배포의 경우 
+
+
+
+
 ## 3.7	Bugtrack System (버그트래킹)
-이 제품의 유지보수를 위해 사용할 버그트래킹 시스템과 버그트래킹에서 사용될 제품이름을 명시한다.
-구글에서 한다
-버그트래킹은 언제 시작하는가? SRS를 처음 적고 이것에 오류가 있을 때, 버그트래킹을 사용한다.
-보통 빌드.릴리즈 부서가 담당하는 경우가 많다.
-어느 정도 stable 한 버전이 나와야 의미있는 버그가 나온다. 알파버전?...
+Notion으로 Bug Tracking을 진행합니다. 제 품 버전과 해당 버전에서 발생한 문제, 발생 시간 등을 기록하고, 크리티컬한 문제에 대해서 즉각적으로 대응할 수 있도록, 
+버그 레벨을 분류하고, 버그 레벨에 따라 대응 시간을 정합니다. 추가적으로 버그 담당자를 지정하여, 해당 버그에 대한 해결에 대한 진행사항과 해결 여부를 확인할 수 있도록 합니다.
+
+**버그 레벨**
+- Critical: 1일 이내
+- High: 1주 이내
+- Medium: 2주 이내
+- Low: 1달 이내
+- Very Low: 1달 이상
+
+
+
 ## 3.8	Other Environment (기타 환경)

docs/docs/software-requirement-specification/ovearall-description.md

@@ -3,9 +3,11 @@ title: 2. Overall Description (전체 설명)
 sidebar_position: 3
 ---
 # 2	Overall Description (전체 설명)
+Street Drop은 위치 기반 음악 공유 소셜 서비스로서, 사용자들이 음악을 공유하고 다른 사용자들과 상호작용할 수 있는 플랫폼을 제공합니다. 
 
-본 프로젝트 산출물의 T0-BE 모습에 대한 전체적인 구성 및 동작, 기능 등에 대해 간략하게 기술한다.
-상세한 기능 스펙은 7장에서 기술한다.
+이 서비스는 대한민국 내에서 사용 가능하며, 추후에는 해외 서비스 제공을 확장할 수 있습니다. 
+
+애플리케이션은 iOS 디바이스 중 아이폰만을 지원하며, 안드로이드 기기는 현재 지원하지 않습니다.
 
 ## 2.1	Product Perspective (제품 조망)
 본 프로젝트 산출물과 회사의 기존 제품(또는 신규제품)과의 관계 및 연관성에 대해 기술한다.
@@ -52,21 +54,13 @@ SRS에서 중요한 것은 external interface이다.
 컴포넌트간의 인터페이스 가 명시되어야 하고
 
 ## 2.4	Product Functions (제품 주요 기능)
-본 프로젝트 산출물의 주요 기능을 간략히 기술한다. 상세한 기능은 7장에서 참조한다.
-7장의 주요 제목과 일치해야 한다.
-브로셔에 들어갈 내용을 빠짐없이
-자세한 기술은 생략.
-고객이 보았을 때 이 제품을 왜 사야 하는 지에 대한 것을 기술
+Street Drop은 다음과 같은 기능을 제공합니다.
 
+1) 음악 공유: 사용자들은 자신이 좋아하는 음악을 애플리케이션에 업로드하고, 위치 정보를 기반으로 공유할 수 있습니다.
 
-1)	Provide a summary of  the major functions the product must perform or must let the user perform. Details will be provided in Section 7, so only a high level summary (such as a bullet list) is needed here. Sometimes the function summary that is necessary for this part can be taken directly from the section of the higher-level specification (if one exists) that allocates particular functions to the software product.
-2)	This describes the functionality of the system in the language of the customer .
-3)	What specifically does the system that will be designed have to do?
-4)	Drawings are good, but remember this is a description of what the system needs to do, not how you are going to build it. (That comes in the design document).
+2) 위치 기반 서비스: 애플리케이션은 사용자의 현재 위치 정보를 활용하여 주변의 다른 사용자들이 공유한 음악을 확인하고, 주변 사용자들과 상호작용할 수 있는 서비스를 제공합니다.
 
-For clarity:
-1)	The functions should be organized in a way that makes the list of functions understandable to the customer or to anyone else reading this SRS for the first time.
-2)	Textual or graphic methods can be used to show the different functions and their relationships. A picture of the major groups of related requirements and how they relate, such as a top level data flow diagram or object class diagram, is often effective. Such a diagram is not intended to show a design of a product but simply shows the logical relationships among variables.
+3) 소셜 기능: 사용자들은 음악에 대한 평가와 댓글을 남기며, 다른 사용자들과 소통하고 커뮤니케이션할 수 있습니다.
 
 
 ## 2.5	User Classes and Characteristics (사용자 계층과 특징)