style: format with markdownlint

Author: pers0n4

README.md

@@ -77,14 +77,23 @@
 
 - SRS 작성자가 다루어야 할 기본 내용
   1. 기능성(Functionality)
+     >
      > - 소프트웨어가 수행하는 작업이 무엇인가?
+     >
   1. 외부 인터페이스(External interfaces)
+     >
      > - 소프트웨어가 사람, 하드웨어, 다른 소프트웨어와 어떻게 상호작용 하는가?
+     >
   1. 성능(Performance)
+     >
      > - 속도, 가용성, 반응 시간, 다양한 소프트웨어 기능의 복구 속도가 어느 정도인가?
+     >
   1. 속성(Attributes)
+     >
      > - 이식성, 정확성, 유지 보수성, 보안성 및 고려사항이 무엇인가?
+     >
   1. 구현에 부과된 설계 제약사항(Design constraints imposed on an implementation)
+     >
      > - 적용해야 하는 표준, 구현하는 언어, 데이터베이스 무결성 정책, 리소스 제약사항, 운영체제가 무엇인가?
 
 ### 2. SRS의 배경(Environment of the SRS)
@@ -100,8 +109,11 @@
 ### 3. 좋은 SRS의 특징(Characteristics of a good SRS)
 
 1. 정확성(Correct)
+   >
    > - SRS에 명시된 모든 요구사항이 소프트웨어가 만족시켜야 하는 내용에 해당한다면 SRS는 correct하다.
+   >
 1. 확실성(Unambiguous)
+   >
    > - SRS에 명시된 모든 요구사항이 단 한 가지 뜻으로 해석된다면 SRS는 unambiguous하다.
    > - 최소한 고유한 용어를 사용하여 제품의 각 특성을 설명해야 한다.
    > - 특정 맥락에서 사용된 용어가 여러 의미를 가질 수 있는 경우, 해당 용어에 관한 구체적인 뜻을 glossary에 포함하는 것이 좋다.
@@ -118,58 +130,84 @@
    >        1. 요구사항을 효과적으로 표현
    >        1. 미묘한 요구사항의 반영
    >   1. 표현 도구(Representation tools)
+   >
 1. 완전성(Complete)
+   >
    > - SRS가 아래 조건들을 만족한다면 SRS는 complete하다.
    > - SRS가 complete하기 위한 조건
    >   1. 기능성, 성능, 설계 제약사항, 속성, 외부 인터페이스와 관련된 모든 요구사항을 인지하고 처리해야 한다.
    >   1. 소프트웨어에서 실현될 수 있는 모든 입력 값의 상황에 대한 반응이 정의되어야 한다.
    >      - 유효한 입력 값과 유효하지 않은 입력 값 모두에 대한 응답을 지정하는 것이 중요함
    >   1. SRS의 모든 그림, 표, 다이어그램에 관한 full label이 참조되어야 하고, 모든 용어와 측정 단위가 정의되어야 한다.
    > - TBD(to be determined)라는 용어를 사용하는 SRS는 완전한 SRS가 아니다.
+   >
    1. TBD가 필요한 상황
+      >
       > - 상황을 해결할 수 있도록 TBD를 발생시키는 조건에 관한 설명
       > - TBD를 없애기 위해 해야 할 일, TBD의 제거에 책임이 있는 사람, 언제 제거되어야 하는지에 관한 설명
+      >
 1. 일관성(Consistent)
+   >
    > - SRS가 어떤 상위의 문서와도 충돌하지 않는다면 SRS는 consistent하다.
    > - SRS에서 발생할 수 있는 충돌의 유형
    >   1. 현실 세계의 객체에 지정된 특성의 충돌
    >   1. 두 행동 사이의 논리적 혹은 시간적 충돌
    >   1. 같은 객체를 설명하는 둘 이상의 요구사항에서 서로 다른 용어의 사용
+   >
 1. 중요도/안정 우선순위(Ranked for importance and/or stability)
+   >
    > - SRS의 각 요구사항은 중요도나 안정성에 따라 등급이 매겨진다.
    > - 요구사항의 등급을 식별할 때의 이점
    >   1. 고객에게 숨겨진 가정 사항을 명확하게 할 수 있다.
    >   1. 개발자가 소프트웨어 정확하게 설계하고 제품의 각 부분에 적절한 수준의 노력을 할 수 있도록 한다.
+   >
    1. 안정도(Degree of stabillity)
+      >
       > - 안정성은 소프트웨어 시스템이 지원하는 단체, 기능, 사람들에 의해 영향을 받는 앞으로 다가올 사건에 대한 경험이나 지식에 근거하여 어떤 요구사항의 예상 변경 횟수로 표현될 수 있다.
+      >
    1. 필요도(Degree of necessity)
+      >
       > - 요구사항의 순위를 지정하는 또 다른 방법으로는 요구사항을 필수, 조건, 선택 사항의 종류로 구분하는 것이다.
+      >
       1. 필수(Essential)
+         >
          > - 제공되지 않는다면 소프트웨어는 수용될 수 없다.
+         >
       1. 조건(Conditional)
+         >
          > - 소프트웨어를 향상할 수 있는 요구사항이지만, 존재하지 않더라도 수용할 수 없는 제품은 아니다.
+         >
       1. 선택(Optional)
+         >
          > - 가치가 있거나, 그렇지 않을 수 있는 기능으로 SRS를 초과하는 기회를 제공한다.
+         >
 1. 검증 가능성(Verifiable)
+   >
    > - SRS에 기술된 모든 요구사항을 검증할 수 있다면 SRS는 verifiable하다.
    > - 일반적으로 모호한 요구사항은 검증할 수 없다.
+   >
 1. 수정 가능성(Modifiable)
+   >
    > - SRS의 구조와 스타일을 유지하면서 요구사항을 쉽고, 완전하고, 일관되게 변경할 수 있다면 SRS는 modifiable하다.
    > - 수정 가능한 SRS가 되기 위한 조건
    >   1. 목차, 인덱스, 명시적 상호 참조가 있는 사용하기 쉬운 구조를 가져야 한다.
    >   1. 중복되지 않아야 한다. (같은 요구사항이 SRS의 다른 곳에 나타나지 않아야 한다.)
-   >   1. 요구사항을 혼합하여 표현하지 말고, 각 요구사항을 별도로 표현해야 한다. > >
-   >      > - 중복 자체는 오류가 아니지만, 오류로 이어질 수 있다.
-   >      > - 중복성이 때로는 SRS를 더 읽기 쉽게 만드는 데 도움이 될 수 있지만, 문서가 업데이트될 때 문제가 발생할 수 있다.
-   >      > - 중복이 필요할 때 SRS는 명시적 상호 참조를 포함하여 이를 수정할 수 있도록 해야 한다.
+   >   1. 요구사항을 혼합하여 표현하지 말고, 각 요구사항을 별도로 표현해야 한다.
+   > >
+   > > - 중복 자체는 오류가 아니지만, 오류로 이어질 수 있다.
+   > > - 중복성이 때로는 SRS를 더 읽기 쉽게 만드는 데 도움이 될 수 있지만, 문서가 업데이트될 때 문제가 발생할 수 있다.
+   > > - 중복이 필요할 때 SRS는 명시적 상호 참조를 포함하여 이를 수정할 수 있도록 해야 한다.
+   >
 1. 추적 가능성(Traceable)
+   >
    > - SRS의 각 요구사항의 출처가 명확하고, 향후 개발 또는 개선 문서에서 참조할 수 있다면 SRSsms traceable하다.
    > - 추적 가능한 SRS의 유형
    >   1. Backwared traceability
    >      - 각 요구사항이 이전 문서의 출처를 명시적으로 참조한다.
-   >   1. Forward traceability - 각 요구사항이 고유한 이름이나 참조 번호를 갖는다. > >
-   >      > - SRS의 forward traceability는 소프트웨어의 운영 및 유지 보수 단계에서 특히 중요하다.
-   >      > - 코드와 설계 문서가 수정됨에 따라 변경될 수 있는 전체 요구사항을 필수로 확인할 수 있어야 한다.
+   >   1. Forward traceability - 각 요구사항이 고유한 이름이나 참조 번호를 갖는다.
+   > >
+   > > - SRS의 forward traceability는 소프트웨어의 운영 및 유지 보수 단계에서 특히 중요하다.
+   > > - 코드와 설계 문서가 수정됨에 따라 변경될 수 있는 전체 요구사항을 필수로 확인할 수 있어야 한다.
 
 ### 4. SRS의 협업(Joint preparation of the SRS)
 
@@ -195,10 +233,11 @@
 > - 프로토타이핑이 유용한 이유
 >   1. 고객은 SRS를 읽고 반응하는 것보다 프로토타입을 보고 반응할 가능성이 더 높으므로 신속한 피드백을 제공할 수 있다.
 >   1. 프로토타입은 시스템의 예기치 못한 동작을 보여줌에 따라 해답을 제시할 뿐만 아니라 새로운 질문을 제시한다.
->   1. 프로토타입에 기초한 SRS는 개발 중 변동이 크지 않아 개발 시간이 단축된다. > >
->      > - 프로토타입은 소프트웨어 요구사항을 도출하는 방법으로 사용해야 한다.
->      > - 화면이나 보고서 형식의 일부 특성은 프로토타입에서 직접 추출할 수 있다.
->      > - 다른 요구사항은 프로토타입으로 실험을 실행함으로써 추론할 수 있다.
+>   1. 프로토타입에 기초한 SRS는 개발 중 변동이 크지 않아 개발 시간이 단축된다.  
+> >
+> > - 프로토타입은 소프트웨어 요구사항을 도출하는 방법으로 사용해야 한다.
+> > - 화면이나 보고서 형식의 일부 특성은 프로토타입에서 직접 추출할 수 있다.
+> > - 다른 요구사항은 프로토타입으로 실험을 실행함으로써 추론할 수 있다.
 
 ### 7. SRS에 설계 포함하기(Embedding design in the SRS)
 
@@ -212,10 +251,14 @@
 >   1. 모듈 사이의 정보 또는 제어 흐름
 >   1. 데이터 구조
 
-1. 필요한 설계 요구사항(Necessary design requirements) 1. 특정한 기능을 분리된 모듈로 유지한다. 1. 프로그램의 일부 영역 사이에 제한된 통신만 허용한다. 1. 중요한 변수에 대한 데이터 무결성을 검사한다.
-   > > - 유효한 설계 제약 조건의 예로는 물리적 요구사항, 성능 요구사항, 소프트웨어 개발 표준, 소프트웨어 품질 보증 표준이 있다.
-   > > - 요구사항은 오로지 외부 관점에서 명시되어야 한다.
-   > > - 모델을 활용하여 요구사항을 설명할 때는 외부 동작만 나타내며 설계는 지정하지 않는다.
+1. 필요한 설계 요구사항(Necessary design requirements)
+   1. 특정한 기능을 분리된 모듈로 유지한다.
+   1. 프로그램의 일부 영역 사이에 제한된 통신만 허용한다
+   1. 중요한 변수에 대한 데이터 무결성을 검사한다.
+   >
+   > - 유효한 설계 제약 조건의 예로는 물리적 요구사항, 성능 요구사항, 소프트웨어 개발 표준, 소프트웨어 품질 보증 표준이 있다.
+   > - 요구사항은 오로지 외부 관점에서 명시되어야 한다.
+   > - 모델을 활용하여 요구사항을 설명할 때는 외부 동작만 나타내며 설계는 지정하지 않는다.
 
 ### 8. SRS에 프로젝트 요구사항 포함하기(Embedding project requirements in the SRS)
 
@@ -315,8 +358,9 @@
 >   1. 사용자 그룹의 다양한 운영 모드
 >   1. Interactive한 작업 기간과 unattended한 작업의 기간
 >   1. 데이터 처리 지원 기능
->   1. 백업 및 복구 동작 > >
->      > - 사용자 인터페이스 항목의 일부로 지정되기도 한다.
+>   1. 백업 및 복구 동작
+> >
+> > - 사용자 인터페이스 항목의 일부로 지정되기도 한다.
 
 ##### 2.1.8. 사이트 적용 요건(Site adaption requirements)
 
@@ -553,8 +597,9 @@
 >   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는 부록이 요구사항의 일부로 간주하는지 명시해야 한다.
+>   1. Special packaging instructions for the code and the media to mmet security, export, initial loading, or other requirements
+> >
+> > - 부록이 포함된 경우 SRS는 부록이 요구사항의 일부로 간주하는지 명시해야 한다.
 
 ## Annex