DEVELOPER JOURNAL
평생 일하며 배우고 싶은 개발자입니다
개발, 자격증, 공부 내용을 꾸준히 정리하는 블로그입니다. 오래 다시 볼 수 있는 기록을 차분하게 쌓고 싶습니다.
Archive
지금까지 정리한 글을 한눈에 모아봤습니다.
지난 글에서는 오류신고 관리 시스템의 요구사항 정의서를 작성했다.요구사항 정의서를 통해 회원 기능, 사용자 오류신고 기능, 관리자 오류신고 기능, 공통 요구사항을 정리했다면,이번에는 이 요구사항을 바탕으로 어떤 데이터를 저장해야 하는지 정리해보려고 한다. 이번 글에서는 db-schema.md 파일에 작성한 DB 설계서를 기준으로,오류신고 관리 시스템의 테이블을 어떻게 나누었는지 정리해본다.DB 설계서를 작성한 이유기능을 구현하기 전에 먼저 생각해야 할 것이 있다.바로 어떤 데이터를 저장할 것인가이다. 오류신고 관리 시스템에서는 단순히 오류신고 제목과 내용만 저장하면 되는 것이 아니다.다음과 같은 정보도 함께 필요하다. 필요 정보누가 오류신고를 작성했는가? 오류신고의 현재 처리상태는 무엇인가? 관리자가 답..
지난 글에서는 오류신고 관리 시스템 프로젝트의 README를 정리했다. README가 프로젝트의 전체 방향을 설명하는 문서라면,요구사항 정의서는 실제로 어떤 기능을 만들 것인지 구체화하는 문서라고 볼 수 있다. 개인 프로젝트라고 해서 무조건 요구사항 정의서가 필요한 것은 아니지만,이번 프로젝트는 회원 기능, 사용자 기능, 관리자 기능이 나뉘어 있기 때문에 기준을 먼저 정리해두는 것이 필요하다고 느꼈다. 그래서 구현에 들어가기 전에 requirements.md 파일을 만들고, 요구사항을 먼저 정리해보았다.왜 요구사항 정의서를 작성했을까?처음에는 단순히 “오류신고를 등록하고 관리자가 답변하는 기능” 정도로 생각했다.하지만 막상 기능을 떠올려보니 생각보다 정리해야 할 기준이 많았다. 예를 들면 이런 것들이다...