시작하기 전
무엇이든 계획과 체계에 맞추어 설계를 진행해야 한다. 학원에서 IT를 배우면서 프로젝트 개발을 하기 전에 설계라는 단계가 있고, 설계 단계에서 시간이 많이 소요되는 점을 알게 되었다. 설계 단계는 문서 작업이 대부분이었고, 그중 요구사항 정의서라는 문서를 처음 접했다. 이것이 경험이 되어 학원을 수료하고 나서도 나와 뜻을 함께할 프로젝트 팀원을 구했고, 팀원들과 프로젝트의 첫 번째 단계인 설계 진행하였다. 글쓴이는 취준생으로써 실제 작성하는 방식이 현업과 다를 수 있는 점 양해 바란다.
요구사항 정의서란?
프로젝트를 주먹구식이 아닌 계획과 체계를 맞추어 진행하기 위해 공식 문서들이 필요할 때가 많다. 공식 문서들 중 하나가 요구사항 정의서이다. 요구사항 정의서는 고객에게 맞는 서비스에 맞춰 기능들을 정리하여 문서로 만든 것이다. 만들어진 문서를 통해 고객 소통을 진행한다. 문서를 통해 소통하기 때문에 추후 발생하는 갈등을 예방할 수 있도록 한다.
기본구성
- 구분 ( 웹 / 앱 / 사용자 / 관리자 / 공통 등 )
- 요구사항명, 요구사항 ID
- 세부기능명, 세부기능 ID
- 상세설명
- 비고
위는 기본적으로 필요한 구성들이다. 필요에 따라 구성이 추가되거나 빠질 수 있다.
이번 프로젝트의 경우 앞전에 했었던 프로젝트와 동일하게 학원에서 사용했던 양식에 맞춰 진행했다. 하지만 이번 글을 적으면서 참고한 블로그에는 더욱 자세하게 적혀있어서 너무 괜찮다는 생각이 들었다. 그래서 이번 계기로 요구사항 정의서를 수정해보았다. 실제 요구사항 정의서를 진행했던 구성을 적어보도록 하자.
실제구성
- 요구사항ID, 요구사항명
- 세부기능ID, 세부기능명, 상세설명
- 담당자, 우선순위 / 반영여부
- 사용권한 ( ALL, USER, ADMIN 등 )
- 관련엔터티타입 ( 회원, 게시글, 이미지 등 )
웹으로만 진행할 예정이라 '구분'은 제외했고, '구분'을 제외한 기본구성에서 '담당자'와 '관련엔터티타입', '우선순위/반영여부' 섹션을 추가하였다. 자세한 내용은 아래 이미지로 알아보도록 하자.
'요구사항 정의서'는 고객에게 맞춰 작성해야 하지만 복습차원으로 프로젝트를 진행하는 것이기 때문에 개발자 위주의 요구사항 정의서가 되었다. 그래도 각 열의 뜻에 맞게 작성하였으니 각각의 열에 대해 알아보도록 하자.
요구사항 ID
고객사와 소통할 때나 개발사에 소통을 원활하게 하기 위해 요구사항 ID를 사용한다. 네이밍은 따로 정해진 규칙은 없다.
해당 프로젝트에서는 요구사항을 큰 주제별로 나누어 MEM(회원관리 관련), MAIN(메인페이지 관련), BOR(게시판 관련), REF(댓글 관련)로 구분하였다.
담당자
각 요구사항마다 담당자를 명시해주었다. 담당자를 지정해줌으로써 맡은 일에 책임감을 가지고 완성시키자는 취지에서 섹션을 추가해주었다.
사용권한
요구사항명에 맞춰 사용권한을 적을 때 사용한다. 각 요구사항에 사용권한을 적어보고 싶어서 추가해 주었다. 해당 섹션은 나에게 단계별로 생각할 수 있게 능력을 만들어주었다. 요구사항에 맞춰 기능을 적고, 적으면서 이 기능은 사용권한이 어떻게 되는걸까라는 생각이 저절로 들었다.
예를 들면, 게시판 조회는 비회원, 회원 모두 가능하므로 ALL(전체 사용), 로그인은 USER(회원)만 가능한 것으로 나뉜다. 만약 관리자 페이지 접근이나 공지사항 등록이 있었다면 ADMIN(관리자)로 적을 수 있다.
요구사항명
요구사항을 명시한다. 명사형을 주로 사용하고, 최대한 알아보기 쉽게 작성한다. 보통 요구사항에서 세부기능을 나누지 않고 요구사항 자체만으로도 나열하기도 한다.
세부기능ID
상호 간에 소통을 원활하게 하기 위해 세부기능 ID로 부르는 것으로, 요구사항 ID와 마찬가지로 정해진 규칙은 없다.
이번 프로젝트는 개발자 위주로 하다 보니 기능별로 적는 것이 좋을 듯하여 세부기능 섹션도 같이 작성해 주었다.
세부기능명
요구사항에서 한 단계 더 깊이 들어간 세부 기능명을 명시한다. 기능에 대한 내용이기에 최대한 자세하고 알아보기 쉽게 명사형으로 기능을 적는 것이 중요하다.
상세설명
각 기능에 대한 상세 설명을 서술한다. 비개발자도 이해할 수 있도록 적는 것이 중요하다.
상세설명란을 작성하면서 해당 섹션이 쉽지 않는다는 것을 알게 되었다. 이번 상세설명은 개발자 위주로 적었기 때문에 OAuth2User라던가 Spring Security라는 말이 섞여있다. 저 부분을 제외하고 상세설명을 작성하면 어떤 단어와 문장으로 작성을 해야 할지 또는 어떤 말로 고객들에게 전달해야 할지 의문이다. 이런 부분도 일을 하면서 늘어나는 스킬인 것일까?
관련엔터티타입
관련된 DB 테이블명을 명시해 주었다. 해당 기능을 구현하려면 어떤 DB 테이블을 거쳐야 하는지 적어준 것이다. 원래는 필수 데이터와 선택 데이터로 나누어 적는 것이 맞다. 필수 데이터는 각 기능별로 입력되어야 할 필수 데이터를 적는 것이고, 선택 데이터는 각 기능별 선택적으로 입력할 데이터를 적는 것이다. 필수 데이터와 선택 데이터를 참고하면서 DB를 설계하는 것이 제일 베스트다.
우선순위/반영여부
각 담당자가 어떤 요구사항이 우선인지 적어둔 것이다. 이번 프로젝트 같은 경우 게시판을 먼저 진행하기로 하였다. 게시판 안에서도 기능별로 나뉘어 있기 때문에 그 부분 또한 나누어주었다. 반영여부는 하나씩 기능이 완성될 때마다 문서를 수정할 예정이다.
- 전체 요구사항 정의서
아래는 작성한 전체 요구사항 정의서이다. 다음 개인 프로젝트를 진행할 때도 해당 요구사항 정의서 자료를 참고할 예정이다.
마치며
이번 글을 작성하면서 '요구사항 정의서'에 대해 많이 알아간 것 같다. 학원 다닐 땐 어떤 방식으로 쓰는지, 왜 이걸 적는지 이해하지 못했는데 프로젝트를 하나둘씩 접하다 보니 문서의 중요성을 알아가게 되었고, 만들어진 문서를 통해 나 또한 참고할 내용이 있다는 게 무척 편하기도 했다.