개발과 명세1

요구사항 명세는 프로젝트를 진행하는 데 있어서 가장 중요하다고 할 수 있는데요.

그리고 개발자는 요구사항이 적힌 명세를 보고 그에 맞는 개발을 하는 것이 가장 중요합니다.

하지만 이러한 요구사항은 프로젝트 중간에도 변경이 될 수 있는데요. 이때 변경은 일부만 변경하는 세부 구현사항이 변경될 수도 있는 반면에 전체적인 구조가 변경되는 경우도 있기 때문에 주의해야 합니다. 또한 테스트 케이스를 작성(TDD)할때도 요구사항을 반영해야 합니다. 

 

클라이언트의 요구에 따라서 요구사항을 도출을 하는데 그것이 바로 프로젝트의 시작이 됩니다.

 

요구사항 명세서

요구사항 명세서를 작성하는 방식으로는 기본적으로 아래 방식을 이용하는데요.

• Software Requirement Specification(SRS)
  • 구현물의 기능/비기능적인 요구사항을 기술한 문서를 말합니다.
    • 기능적 요구 : 제공해야 하는 기능
    • 비기능적 요구 : 성능/자원 사용량 등에 존재한 여러 측면의 제약
  • 워터폴(waterfall) 모델의 소프트웨어 개발 프로레스에서 필수 산출물로 정의하는 게 기본이지만, 애자일 방법론을 적용하는 경우에는 민첩성으 높이기 위해서 산출을 생략하는 경우도 있습니다.
• Requirement-driven development
  • mission critical system 등 에서는 formal verification 방법과 조합하여 요구사항을 만족을 엄격하게 검증합니다.
  • 웹개발에서는 흔히 적용하는 방법이 아닙니다.

요구사항 명세서 요소

• 기능적 요구사항에 대한 개괄적 설명
• 적용 기술에 대한 지정 - 일반적인 명세서 요소가 x
• 각 요소 기능에 대한 명세(표)
• 데이터베이스 스키마의 약식표현 - 일반적인 명세서 요소가 x
• 백엔드 API 세트의 정의

---

 

1.  기능적 요구사항에 대한 개괄적 설명

구분	내용
요구사항 ID	REQ-01-01
요구사항명	로그인
개요(목적, 내용)	가입된 이메일과 비밀번호를 이용하여 로그인 할 수 있다.
입력	로그인을 하지 않은 상태에서 서비스 방문
출력	로그인 화면이 표시

구분	내용
요구사항 ID	REQ-01-02
요구사항명	회원가입
개요(목적, 내용)	이메일과 비밀번호를 이용해 회원가입 할 수 있다.
입력	로그인 화면에서 회원가입 버튼 클릭
출력	회원가입 화면이 표시

구분	내용
요구사항 ID	REQ-01-03
요구사항명	로그아웃
개요(목적, 내용)	로그아웃, 로그아웃 성공 후에는 로그인 했던 사용자의 정보가 유지되지 않아야 함
입력	화면 상단의 로그아웃 버튼 클릭
출력	로그아웃 후 로그인 화면으로 복

구분	내용
요구사항 ID	REQ-02-01
요구사항명	노트 목록 조회
개요(목적, 내용)	생성일 기준으로 정렬된 노트 목록이 표시된다.
입력	메인페이지 방문
출력	화면 사이드바에 클릭 가능한 노트 목록이 표시

구분	내용
요구사항 ID	REQ-02-02
요구사항명	노트 선택
개요(목적, 내용)	노트 목록에서 노트를 선택할 수 있다.
입력	노트 목록에서 선택할 노트를 클릭
출력	노트 목록에서 선택된 노트가 하이라이트

구분	내용
요구사항 ID	REQ-02-03
요구사항명	노트 조회
개요(목적, 내용)	선택한 노트의 내용을 조회할 수 있다.
입력	사이드바 노트 목록에서 노트를 클릭하여 선택
출력	우측 화면에 노트의 내용이 표시

구분	내용
요구사항 ID	REQ-02-04
요구사항명	노트 생성
개요(목적, 내용)	새 노트를 생성할 수 있다.
입력	화면 상단의 노트 생성 버튼 클릭
출력	노트 목록의 가장 위에 새 노트가 추가되고, 해당 노트가 선택 및 조

구분	내용
요구사항 ID	REQ-02-05
요구사항명	노트 편집
개요(목적, 내용)	조회 중인 노트를 편집할 수 있다.
입력	조회 중인 노트의 내용을 클릭
출력	커서가 깜빡이며, 편집 가능한 상태

구분	내용
요구사항 ID	REQ-02-06
요구사항명	노트 변경사항 저장
개요(목적, 내용)	노트의 변경사항을 저장할수 있다.
입력	화면 상단의 저장버튼을 클릭
출력	노트의 변경사항이 저장된다.

구분	내용
요구사항 ID	REQ-02-07
요구사항명	노트 삭제
개요(목적, 내용)	조회 중인 노트를 삭제 할 수 있다.
입력	노트를 조회하고 화면상단의 삭제버튼을 누른다.
출력	노트가 삭제된다.

 

2. 적용 기술에 대한 지정

• Frontend
  • React 응용으로 만들어져 UI에 해당하는 부분 서비스
  • BE API 호출은 브라우저의 js 실행에 의해 이루어짐
  • 설정할 것
    • BE의 API URL 설정, js 코드에 포함하여 클라이언트에서 올바른 endpoint를 구성
    • BE URL 👉 https://주소/api
• Backend
  • Express 응요로 만들어져 데이터베이스를 이용한 데이터 모델 서비스
  • JWT를 이용한 사용자 인증을 통해 데이터 접근을 보호
  • CORS 정책을 통해 악의적인 접근 방지
  • 설정할 것
    • DB(host, database, user, pw), 직접 데이터베이스에 접근할 수 있게 해야 한다.
    • DB 👉 주소/port
    • FE, CORS 정책에 의해 특정 소스로부터 접근을 허용할 수 있도록 해야 한다.
    • FE URL 👉 https://주소
• Database
  • "~~"라는 이름의 데이터베이스에 n개의 테이블 포함

서비스 모델 아키텍처

서비스를 하기전에 테스트를 위해 다른 환경에 비슷한 환경을 구성을 하는데요, 이 때 차이점은

1. 웹서버를 사이에 두지 않는다. ( 이는 FE,BE 접근 URL 설정에 차이가 있습니다.)

2. 인터넷을 통하여 접근이 불가능하다.

3. 데이터베이스 인스턴스도 동일한 클러스터 내에 배치

4. SSL 인증이 없다 == jwt 쿠키 처리 방시에 차이가 있습니다.

 

⭐ 개발 및 배포 환경 셋업 전략

Production 👉 AWS EC instance에 minikube를 이용한 k8s 클러스터 운용

Staging 👉 Production 환경과 완전히 동일한 셋업(같은 region, 같은 type의 인스턴스) 이용

Development(개발 단계에서의 검증) 👉 로컬 컴퓨터에 docker desktop이 제공하는 single-node cluster 이용

Development(개발 단계)

 

이렇게 개발 및 배포 환경 셋업 전략에 대해서 정리를 해 보았는데요. 이때 development에서 코드 변경이 이루어질때마다 로컬 테스트 환경에 배포하는것은 시간이 소요되어 작업의 효율성이 떨어지고, 코드가 어느 정도의 구조를 갖추기 전까지는 구성을 확정짓기 어려워서 환경설정이나 디버깅에 드는 수고 때문에 조금 부담스럽기 때문에 단위 테스트를 활용하거나, 간단한 사용자 테스트를 활용하는것이 좋습니다.

Dev	Dev docker	Test (Local k8s)	Stage (AWS)	Prod (AWS)
코드개발 단위테스트 FE/BE 개별 테스트 수동 사용자 테스트	BE부터 dockerize docker compose 빌드된 코드 이용 컨테이너 테스트	kubectl + yaml 클러스터 운용 테스트	Acceptance Test 테스트 종료 후 파괴	Smoke Test 서비스 제
	클러스터에 올리기 전	클러스터에 올라간 후