메뉴 구성 작성

시작하기 전

글쓴이는 학원을 다니면서 터득한 문서 작성법이다. 프로젝트 진행하면 모든 단계를 통틀어 설계 단계가 제일 오래 걸린다고 해서 의아했는데 정말 그러했다. 구현 단계에 진입할 때 설계 단계에서 만들어둔 문서들을 참고하며 페이지 및 기능을 만들었다. 취준생의 시점으로 작성한 내용이라 현업 방식과 다소 다를 수 있고, 해당 작업을 진행하지 않을 수도 있다. 

메뉴 구성이란?

메뉴 구성은 '요구사항 정의서'를 완성한 후에 진행하는 작업이다. 전지적 개발자 시점이라 바라보는 시점이 다르다. '요구사항 정의서'는 개발자들이 고객에게 맞는 서비스를 맞춰 기능들을 정리하여 문서화 한 후 소통을 나누는 것이지만, '메뉴 구성'은 개발자들이 구현을 진행하기 위해 기능별로 예비 작업을 해두는 것이다.

 

처음에 정해진 방식대로 작업을 진행하면 더할 나위 좋지만 글쓴이는 유능한 PL이 아니여서 구현하면서 문서 수정을 거쳤다..🥲

실제구성

• 분류
• 화면명, 화면 URL
• 공통코드 사용여부
• 기능, 기능 URL
• 구분
• 담당자
• CRUD, API
• 관련 테이블 개수

필요하다고 생각되는 섹션은 모두 추가해두었다.  정확한 내용은 아래에서 알아보기로 하자.

메뉴 구성 일부

분류

대략적인 대분류라고 생각하면 된다. 이는 '요구사항 정의서'의 요구사항명과 동일하다. '분류'를 통해 주제를 잡은 후 그에 맞는 데이터를 삽입시킨다.

화면명

페이지 기준으로 중분류 개념으로 사용하였다. '분류'에서 주제를 잡았으니 '화면명'에선 주제에 맞는 중분류를 정하면 된다. 위의 이미지을 보자면, 분류(대분류)에 게시판이라면 그에 대한 화면명(중분류)는 페이지 기준으로 전체조회, 상세조회, (게시글)작성, (게시글)수정이 있다.

화면 URL

페이지 기준 사용한 URL이다. Spring 프로젝트에 있는 view 폴더에 생성된 jsp 파일을 URL을 통해 웹 페이지로 만든 것이다.

공통코드 사용여부

카테고리나 이메일 주소 등 공통으로 사용할 수 있는 공통코드를 사용했는지 확인한다. '관련 테이블 개수'에 공통코드 테이블이 하나씩 들어가는 곳을 구분하기 위함이다.

기능

'화면명'에 적혀있는 페이지 기준으로 페이지에 어떠한 기능이 들어갔는지 기재한다.

 

위의 이미지에서 '화면명'이 메인을 예시로 봤을 때, 메인 페이지에는 네이버 API를 활용해 도서와 뉴스를 배치하고, 각 카테고리별로 인기 게시글과 최신 게시글을 배치할 예정이다. 이처럼 메인 페이지에 배치할 부분을 '기능'으로 정의하여 섹션을 나눈 후 내용을 기재한 것이다.

기능 URL

기능에 맞는 URL을 기재한다. 대략 Ajax에 사용한 URL이라고 봐도 무방하다. 위의 이미지에서는 URL 경로가 바로 기능 URL 섹션이다.

 

참고로 글쓴이는 프로젝트를 Spring과 jsp를 사용하여 진행했다.

Spring에서 지원하는 Model 클래스로 쿼리에 맞는 기능을 value로 지정하고, 그에 대한 key를 생성한 후 key 값을 jsp 파일로 넘기면 value에 담긴 정보를 사용할 수 있다. 이러한 방법을 최소화하고 비동기 방식으로 화면을 랜더링해서 진행하고자 했기에 각각 URL을 모두 만들어주었다.

구분

해당 기능이 어떻게 적용되는 것인지 기재한 곳이다.

 

글쓴이는 메뉴와 팝업으로 나누었다. 위의 이미지를 확인해보면 게시글 삭제와 댓글 삭제에만 팝업으로 되어있는걸 확인할 수 있다. 삭제는 팝업창을 띄우고 삭제여부를 물어본 후 진행을 하는 것이기 때문에 팝업으로 표시해둔 것이다. 만약 적용할 부분이 더 추가된다면 서슴없이 추가하면 된다.

 

수정 같은 경우, 팝업창을 띄우며 기능을 실행해도 되지만 이번 프로젝트에서는 팝업창 없이 수정을 한 뒤 완료안내 팝업창만 보여줄 예정이다.

담당자

각 기능에 대한 담당자를 기재해두었다.

 

기능에 좋아요는 기능 URL이 빈칸인 점을 확인할 수 있다. 이는 팀원들과 대화를 나누면서 좋아요 기능은 담당자를 못 정해서이다. 원래 문서 작업할 때 모든걸 정해야 하지만 복습을 하기 위한 프로젝트라 구현 하다가 새로운 기능을 해보고 싶은 팀원이 생기면 해당 기능을 넘겨주기로 했다.

관련 테이블 개수

SQL에 생성한 Table를 뜻하며, 해당 기능에 관련된 테이블의 개수를 적는다.

 

예로, 게시판 → 상세조회 → 관련글 목록에서는 관련 테이블 개수가 2개다. 1개는 게시글에 대한 테이블, 또 다른 1개는 댓글에 대한 테이블이다. 화면에서는 게시글 제목 옆에 댓글 개수를 놔둘 예정이라 관련된 테이블 개수를 2개로 지정해두었다.

CRUD

기능에 대한 작업을 어떻게 진행했는지, 진행한 작업이 각각 몇 개인지 확인한다. CRUD를 아래의 표를 기준으로 기재하였다.

구분		SQL 구문	내용
C	create	INSERT	데이터를 등록한다.
R	read	SELECT	데이터를 읽는다.
U	update	UPDATE	데이터를 수정한다.
D	delete	DELETE	데이터를 삭제한다.

글쓴이는 CRUD 개수를 Spring의 Service단 기준으로 진행했다. 이는 팀원들끼리 정해서 진행한 것이기 때문에 쿼리문 기준이든 비지니스 로직 기준이든 팀 내 룰을 정해서 진행하면 된다.

Service란?
Client의 요청에 대한 비지니스 로직을 수행하는 장소다. 만약, DB를 통해 Client의 요청을 수행해야한다면 DTO나 Mapper을 거쳐 Client에게 응답한다.

Mapper에 기능에 해당되는 쿼리문 1~3개를 하나의 비지니스 로직으로 만들어서 Controller를 통해 페이지로 응답해주었다. 이때 서버에서 정보를 읽어와 페이지에 해야한다면 R이 1개가 된다.

API

사용한 API를 적어두었다.

마치며

이렇게 블로그로 세세하게 적다보니 섹션을 많이 나눈 것 같다. 그래도 섹션을 많이 나누니 문서가 세분화되어 각 기능마다 어떻게 진행하는지에 대한 내용을 빠르게 확인할 수 있었다.

 

문서는 자신이 기재한 내용이면 빠르게 파악되지만 다른 사람이 기재한 내용을 보며 팀원이 무엇을 원하는지 파악하기까지 시간이 다소 걸리는 것이 다반사이다. 이 부분을 보완하고자 내용을 더욱 세분화하였다. 다소 번거로운 작업이지만 구현할 때 참고할 수 있는 유일한 문서이기에 열심히 작성했던 것 같다.

메뉴 구성 기반 문서

요구사항 정의서 작성