[Day 3] 02_소프트웨어 개발 단계와 문서_22.12.19

**소프트웨어 개발 단계
>기획 단계
1. RFP(Request For Proposal) : 제안 요청
2. 프로젝트 계약 완료
3. SRS(Software requirements specification) : 프로젝트 큰 그림 설계
>분석 단계
: 사용자 요구사항 정의서
: 유스 케이스 명세서, 요구사항 추적표
>설계 단계
: 화면 정의서
: 테이블 설계서
: API 명세서
>구현 단계

**사용자 요구사항 정의서
>정의
: 고객의 요청 사항을 기반으로 SRS의 협의 내용을 적용하고 실제 개발에 적용할 수 있는 수준으로 요구사항을 재정의 한 것.
: 표 형태로 시각화
: 기능적 요구사항과 비기능적 요구사항을 나누어 작성
//기능적 요구사항 : 실제 애플리케이션 동작을 수행하는 작업
//비기능적 요구사항 : 애플리케이션의 성능적인 측면의 작업, 예시) A기능을 수행할 시, 이를 1분 내로 처리할 수 있어야 한다.
>항목 예시
-요구사항 ID : 요구사항별로 유일한 ID
-요구사항명 : 요구사항을 요약한 명칭
-구분 : 기능과 부기능으로 구분, 이후 기능과 부기능의 하위로 더 세분화 가능
-요구사항 설명 : 사용자 요구사항 상세 설명
-중요도 : 전체 시스템 구현 측면에서의 중요도
-비고 : 기타 고려 사항

**화면 정의서
>정의
: 사용자에게 제공되는 시스템의 인터페이스의 전체 구조와 목록 등을 상세히 기술한 문서.
: 실제 화면을 미리보기 형식으로 만들어 같이 제공한다.
>항목 예시
-화면 ID
-화면명
-화면 유형
-메뉴 경로
-화면 개요
-화면 미리보기
-기능 번호
-요구사항 ID
-API 활용 여부
-API 주소
-유효성 체크

**테이블 명세서
>정의
: DB의 테이블을 문서화한 것.
: 데이터베이스의 목록과 각각의 데이터베이스의 물리적 상세내용을 기술한 문서
>항목 예시
-데이터 베이스 명
-테이블 명
-요구사항 ID
-테이블 설명
-컬럼명, 컬럼ID, 타입 및 길이, Not Null, PK, FK, IDX, 기본값, 제약 조건 등을 기술하여 실제 테이블의 모습 추가

**API 명세서
>REST API
-URI: 리소스 식별자, URL 상위 개념
-URL: 리소스 좌표, URI 하위 개념
-Resource: REST API 통신 후 기대하는 결과값, 미디어, DB 데이터 등
-Restful한 API: 모든 리소스에 URI를 부여하고 HTTP Method로 리소스를 제어하는 API
>REST의 특징
: 서버-클라이언트 구조 (Server-Client Architecture)
: 무상태성 (Stateless)
: 캐시 가능 (Cacheable)
: 일관된 인터페이스 (Uniform Interface)
: 자체적인 표현 구조 (Self-Descriptiveness)
: 계층 구조 (Layered System)
>항목예시(REST API 규칙)
-규칙
-틀린 예와 옳은 예
>항목예시(HTTP Method)
-URL
-각 URL에서 작동하는 GET, POST, PUT(PATCH), DELETE