지난 글에서는 오류신고 관리 시스템 프로젝트의 README를 정리했다.
README가 프로젝트의 전체 방향을 설명하는 문서라면,
요구사항 정의서는 실제로 어떤 기능을 만들 것인지 구체화하는 문서라고 볼 수 있다.
개인 프로젝트라고 해서 무조건 요구사항 정의서가 필요한 것은 아니지만,
이번 프로젝트는 회원 기능, 사용자 기능, 관리자 기능이 나뉘어 있기 때문에 기준을 먼저 정리해두는 것이 필요하다고 느꼈다.
그래서 구현에 들어가기 전에 requirements.md 파일을 만들고, 요구사항을 먼저 정리해보았다.
왜 요구사항 정의서를 작성했을까?
처음에는 단순히 “오류신고를 등록하고 관리자가 답변하는 기능” 정도로 생각했다.
하지만 막상 기능을 떠올려보니 생각보다 정리해야 할 기준이 많았다.
예를 들면 이런 것들이다.
누가 오류신고를 등록할 수 있는가?
로그인하지 않은 사용자는 어떻게 처리할 것인가?
사용자는 본인이 작성한 오류신고만 볼 수 있는가?
관리자는 모든 오류신고를 볼 수 있는가?
관리자 답변은 언제 등록할 수 있는가?
처리상태는 어떤 값으로 관리할 것인가?
입력값이 비어 있으면 어떻게 처리할 것인가?
이런 기준을 미리 정리해두지 않으면, 구현 도중에 계속 판단이 흔들릴 수 있다고 생각했다.
특히 이번 프로젝트는 단순 게시판이 아니라,
사용자가 오류를 신고하고 관리자가 이를 확인한 뒤 처리상태를 변경하거나 답변을 등록하는 흐름을 가진다.
그래서 기능을 바로 구현하기보다 먼저 요구사항을 정리해보기로 했다.
요구사항을 어떻게 나누었나?
이번 오류신고 관리 시스템의 요구사항은 크게 네 가지로 나누었다.
1. 회원 기능
2. 사용자 오류신고 기능
3. 관리자 오류신고 기능
4. 공통 요구사항
회원 기능에는 회원가입, 로그인, 로그아웃을 정리했다.
사용자 오류신고 기능에는 오류신고 등록, 내 오류신고 목록 조회, 내 오류신고 상세 조회, 관리자 답변 확인을 정리했다.
관리자 오류신고 기능에는 전체 오류신고 목록 조회, 오류신고 상세 조회, 처리상태 변경, 관리자 답변 등록, 관리자 답변 수정을 정리했다.
공통 요구사항에는 권한 체크, 입력값 검증, 페이징을 따로 분리했다.
이렇게 기능을 나눈 이유는 누가 사용하는 기능인지를 기준으로 정리하는 편이 더 명확하다고 생각했기 때문이다.
기능을 단순히 나열하면 나중에 구현할 때 사용자 화면과 관리자 화면의 기준이 흐려질 수 있다.
반면 역할과 목적을 기준으로 나누면, 이후 URL 설계나 권한 설정을 할 때도 기준이 더 분명해진다.
역할별 기능 정리
요구사항을 역할 기준으로 정리하면 아래와 같다.
| 역할 | 주요 기능 |
| 비회원 | 회원가입, 로그인 |
| 일반 사용자 | 오류신고 등록, 내 오류신고 목록 조회, 상세 조회, 답변 확인 |
| 관리자 | 전체 오류신고 조회, 상세 조회, 처리상태 변경, 답변 등록/수정 |
오류신고 관리 시스템에서 가장 중요한 부분은 일반 사용자와 관리자의 권한이 다르다는 점이다.
일반 사용자는 본인이 작성한 오류신고만 조회할 수 있어야 한다.
반면 관리자는 전체 오류신고를 조회하고, 처리상태를 변경하거나 답변을 등록할 수 있어야 한다.
이 기준은 나중에 URL 설계, Spring Security 설정, Service 로직을 구현할 때도 중요한 기준이 될 것 같다.
표와 그림으로 정리해두면, 긴 설명 없이도 구조를 한눈에 볼 수 있다는 장점이 있다.
또한 역할별 기능을 먼저 정리해두면 “이 기능은 누가 사용할 수 있어야 하는가?”라는 질문에 답하기 쉬워진다.
오류신고 처리상태
오류신고는 단순히 등록만 되는 데이터가 아니라, 처리 흐름을 가지는 데이터다.
이번 프로젝트에서는 처리상태를 아래 네 가지로 정리했다.
| 상태 | 의미 |
| 접수 | 사용자가 오류신고를 등록한 초기 상태 |
| 확인중 | 관리자가 오류 내용을 확인 중인 상태 |
| 처리완료 | 관리자가 답변을 등록하고 처리를 완료한 상태 |
| 반려 | 처리 대상이 아니거나 부적절한 신고 |
처리상태를 미리 정리해두면 관리자가 어떤 흐름으로 오류신고를 처리할지 기준이 생긴다.
특히 이번 요구사항에서는 관리자 답변 등록 시 처리상태를 처리완료로 변경하도록 정리했다.
이렇게 해두면 사용자는 본인이 등록한 오류신고가 현재 어떤 상태인지 확인할 수 있고,
관리자는 처리해야 할 신고와 이미 처리한 신고를 구분할 수 있다.
이 흐름을 그림으로 넣으면, 단순히 상태값만 나열하는 것보다 훨씬 이해하기 쉬울 것 같다.
또한 오류신고 관리 시스템이 단순 게시판이 아니라, 상태가 변하는 데이터를 다루는 시스템이라는 점도 더 잘 드러난다.
예외 상황도 함께 정리했다
요구사항을 정리하면서 가장 중요하다고 느낀 부분은 예외 상황이었다.
기능이 정상적으로 동작하는 경우만 생각하면 실제 구현 단계에서 빠지는 부분이 생길 수 있기 때문이다.
예를 들어 이런 경우들이다.
로그인하지 않은 사용자가 오류신고를 등록하려는 경우
일반 사용자가 관리자 기능에 접근하려는 경우
다른 사용자의 오류신고를 조회하려는 경우
제목이나 내용이 비어 있는 경우
정의되지 않은 상태값으로 변경하려는 경우
이런 기준을 먼저 정리해두면, 나중에 Validation, Security, Service 로직에서 무엇을 막아야 하는지 훨씬 명확해진다.
예를 들어 “본인이 작성하지 않은 오류신고는 조회할 수 없다”는 요구사항은 단순히 화면에서 버튼을 숨기는 문제로 끝나지 않는다.
사용자가 URL을 직접 입력해서 다른 사람의 오류신고에 접근할 수도 있기 때문에, Service 로직에서도 작성자 검증이 필요하다.
요구사항 정의서를 작성하며 느낀 점
요구사항 정의서를 작성하면서 단순히 기능 목록을 적는 것과 요구사항을 정리하는 것은 다르다는 생각이 들었다.
기능 목록은 “무엇을 만들 것인가”에 가깝다.
반면 요구사항 정의서는 다음 기준까지 함께 정리한다.
누가 사용할 수 있는가?
어떤 값을 입력받는가?
어떤 조건을 만족해야 하는가?
어떤 예외 상황을 막아야 하는가?
이 기준을 미리 정리해두면 구현 단계에서 고민해야 할 부분이 줄어든다.
특히 이번 프로젝트에서는 역할 분리, 처리상태, 예외 상황을 요구사항 정의서에서 먼저 정리한 것이 도움이 될 것 같다.
정리
이번 글에서는 오류신고 관리 시스템의 요구사항 정의서를 작성한 이유와 전체 구조를 정리했다.
이번 요구사항 정의서에서 가장 중요하게 본 부분은 세 가지였다.
역할에 따라 기능을 나누는 것
오류신고의 처리상태를 정의하는 것
예외 상황을 미리 정리하는 것
개인 프로젝트라고 해도 구현 전에 이런 기준을 먼저 정리해두면 개발 흐름이 훨씬 명확해질 것 같다.
다음 글에서는 이 요구사항을 바탕으로 users, error_reports 테이블을 어떻게 설계했는지 정리해보려고 한다.
'개발 > 프로젝트 기록' 카테고리의 다른 글
| [오류신고 관리 시스템] DB 설계서 작성하기 (0) | 2026.05.27 |
|---|---|
| [오류신고 관리 시스템] Spring Boot 개인 프로젝트 README 작성하기 (0) | 2026.04.30 |
