[08일차] 기획 산출물 - 정책서, 요구사항 정의서, IA, 와이어프레임, 프로토타이핑

 

02. 정책서

 

서비스 정책서

: 서비스에 대한 모든 정책을 총괄하는 문서 

 

서비스 정책 

- 서비스 용어 및 기본 운영 정책을 정의한 프로젝트 산출물 

용어를 통일한다. 

운영 정책: 비지니스를 정의하기 위해서 가장 중요한 문서 

 

- 정책 정의를위해서는 서비스의 비즈니스 구조와 운영 프로세스가 먼저 확정되어야 한다. 

관련 사람들이 어떤 프로세스로 운영할지 충분히 협의해야 한다. 

서비스 방향과 전략이 포함되어 있어야 한다. 

 

- 정책설정은 회사의 서비스 방향과 전략이 반영되어야 한다.

EX

상품 구매하면 어떤 상품은 배송비를 지불해야하고 어떤 상품은 배송비 지불이 필요 없다. 

 

- 정책설정은 화면 UI와 IT 설계의 기본 구조를 결정한다. 

정책을 통해 세분화를 시켜서 개발적으로 명확하게 구분을 해주어야 한다. 

 

가장 시작 단계에서 진행되어야 한다. 

서비스가 단순하면 없어도 되지만 대부분 정책문서가 필요하다. 

 

정책서 작성 순서 - 구성요소 

출처: 강의자료 04-10 

 

- 대형 프로젝트의 경우 업무 프로세스와 필요한 정책에 대해서 모듈 단위로 구분하여 회의르 ㄹ통해 파악 

 

- 정의해야할 용어와 프로세스, 그리고 의사결정이 필요한 선택적 정책 결정 

 

- Process Innovation 과정이 필요 

운영하는 데에 비효율적이라고 판단하면 시스템과 업무 운영을 같이 변경할 수 있기 때문에 

이 과정에서 자연스럽게 PI 가 진행이 된다. 

 

정책서 목차 정의 

강의자료 04-11

 

- 목차 성정을 통해서 정의할 프로세스와 항목 등을 확정 및 작성 범위 설정 

 

상세 작성 

보통 Word 로 작성 되어 있다. 

직관적으로 이해되도록 정의되어 있다. 

 

- 목차의 항목을 기준으로 작성 

 

- 용어정의, 상태값 정의, 의사결정 정책 정의 

 

- 표로 단순화하되 직관적으로 

 

단점 

폭포수 방법론에서 많이 사용되는 산출물 

그래서 문서적인 작업이 많다. 

 

1) UI UX 대한 정의 보다는 구현에 집중이 되어 있다. 

고객에 대한 것 보다는 문서에는 개발에 필요한 내용만 포함되어 있다. 고객 고려가 덜하다. 

 

2) 개발이나 비지니스적 이익만 중요시되기 쉬움 

 

3) Word 로 작성 되기 때문에 업데이트 및 관리가 어려워진다. 

오픈 이후 변경되거나 하면 갱신이 안되어 있는 경우가 많다. 

 

대안 형태 

UserStory + 위키 Wiki 정책서 

모두가 작성하고 수정할 수 있는 위키 서비스를 만들어서 오픈 정책서를 운영하기도 한다. 

그러나 작성 규칙이 일관되지 않고 누락되거나 할 수도 있다. (여러명이 쓰기 때문에)

 

 

03. 요구사항 정의서

 

요구사항 정의서 

개발자와 커뮤니케이션이 이루어지는 최초의 부분이다. 

 > 요구사항 = 개발 요건 

 

• 사전 요구사항 정의서 

현업 요청 사항을 정리하여 중요도를 체크한 문서 

요구사항 들어온거 대로 정리하고 우선 순위로 판단하는 과정을 거친다. 

 

• 요구사항 정의서 

사전 요구사항 바탕으로 서비스 전략을 토대로 기술적으로 필요한 부분을 정리하여 개발에 협업 요청을 하기 위해 만든 문서 

기술적으로 이게 되는지 안되는지 확인해보는 커뮤니케이션 도구이다. 

 

CF) 요구사항 명세서 

: 요구사항이 많을 때 요구사항에 상세 내용 없이 목록화한 문서 

 

작성

 

엑셀 형태로 많이 정리를 한다. 

 

서비스 구분/ 구현 방안/ 요구사항 

 

화면의 기능적인 부분과 솔루션 내용, UI 작업도 들어갈 수 있다. 

 

- 정책을 세분화하여 기술로 구현하기 위한 모든 범위를 개발 항목 단위로 작성 

완벽하게 처음부터만들어야하는 것은 아니다. 

 

목적 

1) 개발과 사전 커뮤니케이션 하여 기획 포함 및 개발 수용여부를 판단 

2) 요구사항이 누락되지 않고 화면 설계서 까지 관리 할 수 있도록 

번호를 통해서 요구사항을 체크하면서 진행하기 위한 체크 문서라고 볼 수도 있다. 

 

주요 작성 항목 

얼마든지 변경이 가능하다. 보통 많이 사용되는 위조. 

1) 구분: Front / Admin / 기타 

2) 신규여부: 신규/ 기존 수정 

 프로젝트 하다보면 없는 서비스가 아니라 기본 시스템에 만드는 경우일 때, 기존의 화면을 수정하는 경우가 있을 때 

3) 요구사항 번호 : 모듈명 + 숫자 

 ex. Order001 (이와 같은 방법이 많지만 보통)

 체크할 수있는 항목 

4) 요구사항 명 

5) 요구사항 상세 설명, 분석 

 경우에 따라서 세분화해야하는 경우가 많다. 

 복잡도가 높은데 단순하게 설명되어 있으면 분석사항 추가해서 진행할 수 있다. 

 6) 비고: 다른 요구사항과 연결여부 등 

법적인 부분, 관련 요구사항 연결 여부  

ex. 5번이 되어야지 6번이 가느하다. 

7) 개발 수용여부: Y/N/보류 

 개발이 가능한지 여부를 

8) 완료여부: Y/N

 화면설계서나 화면에 직접 확인하면서 

개발과정에서 계속 체크해야한다. 

 

단점 

1) UI UX 정의는 하지만 눈에 보이지 않기 때문에 세세하게 보이지는 않다. 

2) 정책서를 기준으로 내용이 흘러가기 때문에 UI UX 독립적으로 진행되면 서비스적인 이야기를 개발자나 디자이너가 이해하기 조금 어려울 수 있다. 

3) 초기 요구사항 정의서에 없는 항목에 대해서는 프로젝트 도중에 추가 어려움 

 => 폭포수 방법론의 문제점

 

대안 

애자일 Backlog 

요구사항 따로 없이 백로그에 논의하거나 설정 

 

중요한 이유는? 개발자 설득 

왜 개발자를 설득해야하는가?

개발 PL (Project Leader) 의 역할 

- 개발 인적 자원 분배 

- 기존 시스템의 안전성 유지 

 

운영 개발 PL 의 두가지 중요한 질문 

1) 꼭 추가적으로 개발해야하는가 

 

2) 기본 영향도를 최소화할 수 있는가 

기존 프로젝트와 상호 영향을 주게 된다. 

 

04. IA 정의

 

IA (Information Architecture)

 

강의자료 04-23

 

- 서비스의 정보 구조를 설계하는 것을 의미 

대부분화면으로 이루어져 있고 화면 이용하는 대상이 있기 때문에 대상이랑 화면으로 정보를 교류하거나 목표를 맞춰줄 수 있도록 발달 

 

- UX 가 유행하기 전에는 HCI 가 유행을 했다. 

HCI (Human Computer Interact) 

인지과학의 측면에서 유저가 하기 위한 것을 인지하는 과정을 과학적으로 다루고 있는 부분 

 

- 화면간의 상하 관계를 정의하고 고객의 동선을 관리 

 

- 과거 PC 의 경우 페이지 단위로 이루어져있기 때문에 IA 가 사이트의 네비게이션을 결정하였기 때문에 

 

- 그러나 모바일 서비스가 많아지면서 한페이지가 다수의 페이지 역할을 대신할 수있도록 되면서 IA 문서가 개발 페이지 목록으로의 역할이 더 강해지고 있다. 

 

작성 전 작업 

- 동선 설계가 중요하기 때문에 마인드맵이라 트리구조를 이용하여 고객의 Task 별 화면 구조를 정의하는것이 중요하다. 

 

- 화면 단위 구성으로 진행 

=> 몇개의 화면을 구성할 것인가 

 

문서 작성 

강의자료 04-25

보통 엑셀 형태로 사이트 구조를 정리하게 된다. 

 

주요항목 

1) 화면의 Depth : 트리구조 내 구조 깊이 

2) 페이지명 또는 화면 코드 

cf. 화면코드는 규칙으로 정의

ex. Orger001B

3) 페이지 설명 

4) 담당자 구분 : 디자인/개발/어드민 

5) 개발 완료 여부: Y/N

 

 

문서를 보면 서비스의 복잡도를 볼 수 있다. 

복잡할 수록 리스트와 뎁스가 깊어진다. 

 

05. 와이어프레임과 프로토타이핑 

 

와이어프레임, 목업, 프로토타입이 화면설계서에 들어가게 된다. 

 

와이어프레임 전, 스케치 

(스케치 툴이 아니라)

 

화면을 종이에 그려보면 좋겟다. 

 

사실 프로젝트에서는 산출물로 가치는 없지만 고민의 시기일뿐 

그러나 손으로 그리는 작업이 사고를 높이는 데에 도움을 준다. 

 

디자인에게 넘기기 전에 기본적으로 잡는다고 한다면...

 

처음부터 와이어프레임으로 그리려고 하면 

1) 전체적인 UI 전략보다는 '그리드'의 오와 열에 치중하게 된다. 

 

2) 화면 채우는 것에만 신경쓰이게 된다. 

 

3) 한 버전을 그리고 나면 다른 버전을 그리기 싫어진다. 

다른 UI 를 또 그리고 싶지가 않아진다.... 

 

그래서, 꼭 스케치를 하는 것을 추천한다. 

 

와이어프레임 

- 서비스 UI 설계 작업을 영역의 위치와 컨텐츠 없이 아웃라인만 네모박스로 잡은 형태 

 

- 모바일 서비스로 넘어오면서 UI 형태가 많이 표준화가 되었다. 목업툴을 이용해서 빠르게 그리고 목업 형태에 가깝게 표현하고 있다. 

 

 - AJAX 등장으로 모바일 서비스 특징으로 한 화면에서 많은 기능을 처리할 수 있게 많은 화면이 숨겨져 있다. 

한 화면에서 여러가지 케이스와 시니라오가 생기면서 와아이프레임 형태로 개발자, 디자이너에게 이해가 부족할 수 있다. 

그래서 목업이나 프로토타이핑 형태로 바로 가는 경우도 많아지고 있다. 

 

목업 

- 와이어프레임 보다 좀 더 상세화 되었다. 

정적인 개념이 있고 여기서 움직임이 있으면 프로토타입이라고 보는 것이 좋을 것 같다. 

 

- 디자이너에게 UI를 전달하는 것이 더 용이하다. 모바일 환경에서 중요한 인터렉션을 표시할 수 없는 것이 단점이다. 

 

- 대한적으로 인터렉션 상호관계를 이동 동선 표시로 정의해줄 수 있긴 하다. 

 

페이퍼 목업 테스트 

목업을 잘라서 테스크에 따라 고객이 이용해볼 수 있도록 고객 사용성 테스트 

 

기획 단계에서 신규 서비스의 UI 나 동선 인사이트를 얻을 수 있다. 

 

※ 참고

www.youtube.com/watch?v=yafaGNFu8Eg

 

프로토타이핑과 사용성 테스트 

- 목업 또는 시안에서 간단히인터렉션을 구현하여 모바일폰 또는 디바이스에서 사용해 볼 수 있도록 만든 가짜 앱 

 

- 사용성 테스트와 협업자간 서비스 이해를 위해서 작업 

 

- 기업에 따라서 디자이너가 작업을 진행하는 경우도 있다. 

 

특정 프로그램을 다루어보는 것도 중요하지만 서비스 측면에서 보다 집중하는 것이 더 좋다. 

기획에 신경을 많이 쓰는 것이 좋아요~(강사님 사견)

 

 

 

 

-----

패스트 캠퍼스 

'서비스 기획서 완성 온라인 완주반' 강의 

스터디