프로젝트 기획 & 산출물 작성법

프로젝트 기획관리 프로세스

단계 : 착수 - 분석 - 설계 - 개발/시험 - 전환, 최종보고로 마무리

착수	분석	설계	개발/시험	전환
프로젝트 제안	요구사항 정의서	Wireframe (프로토타입)	단위테스트 &	메뉴얼
WBS	기능정의서	정책정의서	통합 테스트 문서	(외부필수/내부선택)
	업무흐름도 (User Story)	IA(정보구조도) & UI Text
		화면설계서
		프로그램 목록 정의서

"볼드체는 필수적인 산출물"

---

WBS (Word Breakdown Structure)🌟

: 업무를 카테고리화 하여 구분하고 각각을 더 세부적인 작업으로 나누어 일정 및 진행사항을 체크하는 기법, 즉 프로젝트의 전체 일정 수립 및 관리 문서임

• 구성
  1. 프로젝트 목표 및 전달 항목 작성
  2. 목표 및 전달 항목 세부화
  3. 작업 패키지와 그에 따른 책임자 배정
  4. 작업 세부화 (팀과 소통 필요)
  
  
• 필요성
  - 프로젝트 전체 일정에 대한 큰 그림 정리
  - 완료일 설정으로 생산성 향상
  - 주 단위 할 일 지정
  
  

요구사항 정의서🌟

: 인터뷰를 통해 고객이 요구하는 것을 파악하고 정리한 문서, 설문조사나 협의를 통해 고객사의 니즈를 파악하고 문제를 정리하는 것이 중요함

• 구성
  1. 요구사항 명
  2. 유형 (기능 | 비기능)
  3. 요구사항 설명
  4. 중요도
  5. 난이도
  6. 안정성
  7. 우선순위 (d,e,f함께 고려해서 선정)
  - 마감 기한이 정해진 외부 프로젝트보다, 내부 프로젝트를 진행할 때 고려할 중요한 요소임
  8. 점검사항 (비고)
  - 외부와 연동이 필요한 부분을 개발자가 체크
  
  

• 필요성
  - 고객이 요구하는 목록이 정리되어야 무엇을 개발할지 알 수 있음
  

[ 유형 ]
기능 : 시스템이 무엇을 하는지, 어떤 데이터를 저장하고, 연산을 하는지에 대한 내용을 포함
비기능 : 시스템 장비 구성, 처리 속도 등의 성능과 안전성, 보완과 같은 기능 외의 요구사항을 포함

✅ 개발자와 난이도 선정하는 과정 필요
✅ 보통 2-3회 인터뷰를 통해 1.5~2주 안에 문서 제작
✅ 메일 시, 기한을 꼭 명시할 것!!!!

기능정의서

: 내부 개발자와 가능성을 검토하여 기한안에 가능한 기능을 위주로 정리

• 구성 :
  - 기능 ID
  - 주 기능, 상세 기능 (depth별 정의)
  - 기능 설명
  - 비고 (추가 고객요청사항 정리)

• 필요성 : 고객의 요구사항을 실제 기능으로 구체화 (요구사항이 너무 많으면 기능이 축소화될 수 있음)
  
  

업무흐름도🌟

: 서비스를 사용하는 사용자의 흐름을 시각적으로 표현
(개발의 Sequence diagram 느낌)

• 필요성
  - 팀원들이 기획자의 의도를 이해하고 사용자가 전반적으로 어떤 흐름을 겪는지 알기 위함
  

draw.oi 툴 활용

와이어프레임

: 디자인 혹은 개발을 시작하기 전 문제를 미리 확인하여 나중에 변경해야 하는 경우를 줄이기 위해 제작, UX 고려한 콘텐츠와 인터페이스 위치 조정을 위함 (디자이너와 협업)

• 구성
  - 타이틀
  - 화면(시각화)
  - 설명

• 필요성
  - 디자이너/FE 개발자에게 화명상 흐름을 보여주기 위함
  - 고객에게 시각적으로 인식시키고 협의하기 위함
  

figma 툴 활용

정책정의서

: 요구 사항을 포함하여 서비스에 대한 모든 정책을 총괄하는 문서

• 예시
  - 권한 정책 : 게시판이나 업무 관련 툴은 담당자, 상태 등 권한 부여 필요
  - Validation & UI정책 : 내용 길이, 첨부파일 갯수, 용량 제한 등

• 필요성
  - 개발자가 세부적인 정책을 놓치지 않게 하기 위함 (권한별, 화면별, 기능별 등 차이에 대해 정리)

• 아직 이 파트는 어려워서 공부해야할 듯..

IA(정보구조도)

: 웹/앱 구축 시 필요한 화면과 메뉴의 정보 구조를 설계 및 정의하는 문서

• 구성
  - Depth | 형태(팝업, 탭, 링크) | 개발 구분 | 그 외(화면 삭제/추가/변경 여부)

• 필요성
  - 화면의 연관성과 접근성을 업무별 필요한 기준으로 분류
  - 서비스가 복잡하고 화면의 수가 많아 정리가 필요할 때
  - 화면 설계에 앞서 작업 우선 순위를 선정해야 할 때

✅ Terminology 제시 필요

UI Text

• 구성
  - 화면 ID | 구분 | 화면 | 설명 | UI Text 문구
  

화면설계서🌟

: 기획한 서비스 화면이 어떤 형태로, 어떤 기능을 제공하는지 상세히 적은 문서, 화면을 어떻게 보여줄지 그려 놓은 와이어프레임과 기능을 구현하기 위해 작성

• 구성
  1. 표지 - 프로젝트 명, 문서 버전, 작성일, 소속, 작성자
  2. 목차
  3. 개요
  4. History : 문서 버전과 히스토리 정리 >
  5. 메뉴 구조도(사이트맵) : 전체 메뉴의 구조를 시각화
  - 메뉴 및 서비스 단위로 작성
  - 작은 프로젝트(3개월)에서 필수 x
  6. 화면목록 : 서비스의 모든 화면을 리스트로 정리
  - 화면 ID와 화면명이 일치하는 것이 중요
  - 화면 ID, depth 단위로 화면에 대한 설명 등 작성
  7. 업무흐름도 : 사용자 입장에서 시작-끝을 시각적으로 표현
  8. 정책 : 기본, 권한 등 정책관련 사항 명시
  9. UI Text : 화면별 필요한 문구 명시
  10. 스토리보드 : 디자이너가 보고 작업할 수 있도록 표현

• 필요성 : 실제 개발/디자인을 위한 산출물

✅History는 디자이너/개발자와의 소통에 중요

[ 화면ID 규칙 ]

• 권한화면 약자숫자 형식
• 숫자는 001~부터
  
  

프로그램 목록 정의서🌟

: 화면별 depth 구분, 틀을 주고 상세 정리는 개발자가 진행

• 필요성
  - 기능 단위로 잘게 쪼개어 실제 개발 일정 산출
  - 개발자 실제 작업 산출물 (큰 규모 프로젝트에서 용이)
  

단위테스트 & 통합테스트 문서🌟

: 기능 단위 테스트와 통합 테스트로 구성

• 기능 단위 T : 개발중 개발자가 하거나 요청 받거나 함

• 통합 단위 T : 고객사를 위한 시연용 > 요청사항 나오면 보완해야함

• 필요성
  - 요구 사항들이 설계 단꼐의 산출물로 정확하게 구현되어 있는지 판단
  - 품질 향상 & 고객 신뢰 상승