프로젝트 개발에 무작정 돌입했지만 요구사항을 한번 싹 정리해놓고 개발하는 게 좋겠다는 생각이 들었다. 기능을 하나 개발하고 보니 추가적으로 필요한 매개변수가 생각나는 문제점이 존재해 이런 생각에 이르렀다. 그리고 다음에는 무엇을 개발해야 할 지 생각하는 게 조금 오래 걸리는 감이 있어서 요구사항 정리의 필요성을 느꼈다.
스프링 5와 vue.js2로 시작하는 모던 웹 애플리케이션 개발 책을 보고 있는데 요구사항 분석부터 데이터 모델링, 코드 설계, api 설계, 개발, 배포까지 전 과정을 정리해 놓은 좋은 리소스이다. 백엔드 개발을 공부할 때 많이 보게 됐던 디자인 패턴과 용어들을 잘 정리해준 책이다.
이 포스트에서는 사용자 스토리로 요구사항을 작성하는 부분을 내 프로젝트에 적용해보았다.
사용자 스토리란 어떤 권한을 가진 사용자가 애플리케이션 내에서 어떤 행동을 할 수 있어야 하는 지를 지칭한다. 사용자가 애플리케이션을 사용하면서 취하게 되는 동작들이라고 보면 된다.
이때 UI에 관련된 내용은 스토리에 포함시키지 않는 게 좋다. "나는 검색을 하기 위해 검색창을 누르고 글자를 입력하는데 자동완성된 추천 검색어들이 나타나고 나는 여기에서 하나를 누르면 해당 단어로 검색이 가능하다"처럼 긴 서술은 피해야 한다. 최대한 간결해야 한다.
책에서 추천해준 사용자 스토리의 형식이다.
어떤 유형의 사용자로서 나는 어떤 가치를 얻기 위해 어떤 것을 할 수 있다.
예시: 방문자로서, 나는 서비스에 가입하기 위해 카카오 로그인, 로컬 로그인을 사용할 수 있다.
제약 조건이 필요하다면 스토리에 같이 적어준다.
가령, 회원가입 시 비밀번호에 제약 조건이 필요할 수 있다. 몇 글자 이상, 특수문자 포함 같은 제약 조건 말이다.
그룹화 한다.
작업 대상이 같은 사용자 스토리끼리 묶어주면 파악하기 편하다.
프로젝트의 요구사항을 정리해봤다.
사용자 역할
- 방문자: 로그인하지 않은 익명의 사용자
- 등록된 사용자: 로그인을 한 사용자
- 프로젝트 생성자: 해당 프로젝트를 만든 사용자
- 프로젝트 멤버: 해당 프로젝트에 참여하고 있는 사용자
- 파트 리더: 해당 파트에서 리더 역할을 하고 있는 사용자
- 파트 멤버: 해당 파트에 참여하고 있는 사용자
- 질문 생성자: 해당 질문을 한 사용자
사용자
- 가입하기: 방문자로서, 나는 서비스를 원활하게 이용하기 위해 이메일, 비밀번호, 이름, 개발 포지션을 입력하고 계정을 만들 수 있다. 가입하기 과정 직후에 추가 정보 입력을 위해 회원 정보 수정을 요청한다. 제약 조건은 다음과 같다.
- 이메일 주소는 시스템에 이미 존재해서는 안 된다.
- 이름은 시스템에 이미 존재해서는 안 된다.
- 비밀번호는 최소 8자 이상이어야 한다.
- 비밀번호는 알파벳 대소문자와 특수문자만 사용 가능하다.
- 비밀번호는 특수문자를 최소 1개 이상 포함해야 한다.
- 비밀번호는 알파벳을 최소 1개 이상 포함해야 한다.
- 회원 정보 수정하기: 등록된 사용자로서, 나는 내 계정의 이름, 기술 스택, 소개글, 프로필 사진, 깃허브 주소, 링크, 리더 가능 여부를 변경할 수 있다.
프로젝트
- 프로젝트 생성하기: 등록된 사용자로서, 나는 팀원을 구할 수 있도록 마크다운을 사용해 프로젝트를 생성할 수 있다.
- 프로젝트 상태 수정하기: 프로젝트 생성자로서, 나는 프로젝트 팀원 모집이 종료되었음을, 다시 팀원 모집함을, 프로젝트 개발이 완료되었음을 알리기 위해 내가 생성한 프로젝트의 상태를 변경할 수 있다.
- 프로젝트 설명 수정하기: 프로젝트 생성자로서, 나는 프로젝트가 변경되었음을 알리기 위해 내가 생성한 프로젝트의 설명을 수정할 수 있다.
- 프로젝트 제목 수정하기: 프로젝트 생성자로서, 나는 프로젝트가 변경되었음을 알리기 위해 내가 생성한 프로젝트의 설명을 수정할 수 있다.
- 프로젝트 검색하기: 방문자로서, 나는 원하는 프로젝트만을 보기 위해 다음 조건을 바탕으로 프로젝트를 검색할 수 있다.
- 지원하고자 하는 파트 포지션
- 지원하고자 하는 파트의 리더 공석 여부
- 프로젝트에서 사용하는 기술 스택
- 프로젝트 추천받기: 등록된 사용자로서, 나는 내 기술 스택과 리더 가능 여부를 바탕으로 프로젝트를 추천받는다.
- 유저 추천받기: 등록된 사용자로서, 나는 파트원을 찾는 데에 도움이 되는 유저 추천을 받는다.
- 리더가 불가능한 나는 같은 파트 포지션의 리더가 가능하고 내 기술 스택과 유사한 유저를 추천 받기를 원한다.
- 리더가 가능한 나는 내 기술 스택과 유사한 같은 파트 포지션 유저를 추천 받기를 원한다.
- 파트 리더인 나는 프로젝트에서 쓰는 스택과 유사한 스택을 사용할 수 있는 같은 파트 포지션 유저를 추천 받기를 원한다.
- 프로젝트 생성자로서 나는 내가 만든 프로젝트에서 파트원이 없는 파트의 리더 역할을 할 수 있는 유저를 추천 받기를 원한다.
결과물
- 프로젝트 결과물 생성하기: 프로젝트 생성자로서, 나는 프로젝트 개발이 완료된 뒤 서비스에 기록을 남기기 위해 프로젝트의 결과물에 대한 문서를 생성할 수 있다.
- 프로젝트 결과물 수정하기: 프로젝트 생성자로서, 나는 내가 생성한 프로젝트 결과물 문서를 수정할 수 있다.
파트
- 파트에 기술스택 추가하기: 파트 리더로서, 나는 파트에 사용하는 기술 스택을 추가할 수 있다.
- 파트 멤버 추가하기: 파트 리더로서, 나는 요청한 등록된 사용자를 내 파트에 멤버로 추가할 수 있다.
질문
- 질문 생성하기: 등록된 사용자로서, 나는 어떤 프로젝트 또는 어떤 질문에 대한 궁금증을 해결하기 위해 질문을 생성할 수 있다.
- 질문 수정하기: 질문 생성자로서, 나는 내가 한 질문의 내용을 수정할 수 있다.
사용자 테마는 조금 더 구체화가 필요하다 생각한다.
'프로젝트 > 크루트' 카테고리의 다른 글
.nuxt 하위 파일을 변경하지 마세요 (0) | 2022.02.11 |
---|---|
처음 테스트 코드를 작성하며 겪었던 문제들 (0) | 2022.02.10 |
AService에서는 ARepository만 사용하고 BService 사용은 지양하자 (0) | 2022.01.30 |
단일 테이블 전략에 의해 자동으로 생성된 칼럼인 dtype을 get하고 싶으면 (0) | 2022.01.28 |
Entity 설계하기 (0) | 2022.01.21 |