이슈관리시스템의 한 줄 또는 몇 줄의 설명
스펙이라고 하면 수십에서 수백페이지의 문서를 먼저 떠올리지만 상황에 따라서는 Jira나 Redmine과 같은 이슈관리시스템의 이슈 하나, 또는 한 줄이 스펙이 될 수도 있다. 보통 작은 유지보수를 위한 변경에서 주로 적용되지만 무엇을 개발해야 하는지 명확하게 정의가 된 것이라면 한 줄 또는 몇 줄의 글이라도 훌륭한 스펙이 될 수 있다.
엔지니어링 One-pager
SRS 등의 제법 큰 템플릿을 가진 문서에 정식으로 스펙을 작성하기에는 프로젝트의 규모가 작거나 이슈가 별로 없을 경우에 작성을 한다. 이슈관리시스템에 간단히 이슈를 정리하고 진행하기도 하지만 굳이 엔지니어링 One-pager라는 문서를 작성하는 이유는 스펙을 작성하는 정식 절차를 밟기 위함이다. One-pager라도 스펙을 일단 작성하면 공식 리뷰를 거쳐서 여러 사람의 의견이나 도움을 공식적으로 받을 수 있다. 그러면 개발하려고 하는 방향이 맞는지 이미 다른 팀에서 비슷한 것을 개발하거나 검토해 놓은 것이 있는지 더 좋은 방법은 없는지 의견을 받을 수 있다. 또한 One-pager의 내용은 공식적으로 다른 사람, 다른 팀에게 공유가 되어서 회사내에서 지식 공유에 도움이 된다.
보통 다음과 같은 경우에 엔지니어링 One-pager를 작성한다.
- 메모리를 50% 절약하는 알고리즘 구현 시도
- 최신 버전의 Visual Studio로 이식하는 프로젝트
- 새로운 그래픽 엔진으로 교체를 하는 일주일짜리 프로젝트
수십페이지의 SRS
가장 일반적으로 스펙을 작성하는 방법이다. 비즈니스 전략, 환경, 기능, 비기능, 성능 등 소프트웨어를 개발하면서 고려해야 할 대부분의 내용이 포함되어 있다. 이 책에서는 SRS에 대한 내용을 자세히 다룰 것이다.
수백, 수천페이지의 거대 방법론의 스펙 문서
거대 방법론에서는 문서를 수십개 이상 작성하기도 한다. 이런 방법론에서는 스펙이 하나의 문서로 정리되는 것이 아니고 여러 개의 문서에 분산되어서 작성된다. 장점으로는 프로젝트에 투입된 역할별로 필요한 문서를 정해서 보면 되는 것이다. 단점으로는 중복이 많이 발생하고 하나의 업무를 하기 위해서 매우 많은 문서를 봐야 한다. 또한 한번 작성하고 나면 수정이 매우 어렵다. 아래와 같은 문서들이 그 예다.
- 요구사항정의서
- 업무기능분해도
- 업무흐름도
- 액터카달로그
- 유스케이스 다이어그램
- 논리 ERD
- 도메인 엔티티 정의서
- 분석패키지 다이어그램
- 코드정의서
- 인터페이스 정의서
- 컴포넌트 명세서
- 화면 정의서
- 메뉴 구조도
기타
- 테스트 코드로 스펙 작성하기
- 소스코드로 스펙 작성하기
- 유저 스토리
댓글 없음:
댓글 쓰기