요구사항 정의서 작성의 기반 -사용자, 현업 인터뷰 -RFP, VOC, 제안서, 설문조사 등의 데이터
요구사항 정의서를 통해 파악할 점? -서비스 기획의 규모 파악 -구현 가능 여부 의사결정 -서비스 기획 일정 수립 -분석 방향 도출 및 개선 방향 정의
요구사항 정의서 작성 시 포함 항목 예시
정책 정의하기
요구사항을 정의해 실제 구현하고자 할 때 해당 서비스의 정책을 정의할 것
정책 협의 -요구사항 협의 완료된 것을 기준으로 한다. -프로젝트 구축 담당자들이 반드시 알아야 하는 내용 -서비스 설계 시 오류를 범할 가능성이 있는 내용 -ASIS에서 크게 변화된 TOBE 항목 및 기능
정책을 명확하게 정의해 놓으면 와이어 프레임 등 기획에 있어서 누수가 없다. 정책 먼저 정의하는 습관 가지기!
정책 정의 예시 *도식화구체적 작성 필요.(탈퇴 후 7일간 재가입 불가 - 어떻게 체크할 것인지 코멘트 작성해야 함)
Information Architecture
ASIS 분석의 문제점들을 정리 (논리적인 구조가 아닌 것 찾기)
개선 방향을 포함한 목적, 방향을 설정
벤치마킹을 통해 타사들의 정보 구조 참고
서비스의 전략과 방향을 반영한 구조
서비스 용어 및 운영 프로세스 구조 정의
ASIS IA 중 중복이나 불필요한 정보 정리
중복 하위 옵션일 경우 IA 구조상에서는 가장 적합한 상위 개념 밑에 넣고, 다른 상위 개념과는 네비게이션처럼 단순 연결로 표기
TOBE의 개선 방향을 포함시킨 IA를 설계
가장 기본적인 IA예시 (위 로그인 화면의 IA)
-번호: ‘사용자가 보는 화면’ 기준으로 번호 정의 (IA의 볼륨 정도를 알 수 있다.) -뎁스: 정보의 깊이, 정보의 구조를 이룬다. 뎁스의 깊이가 깊어지면 사용자의 플로우가 유연하지 않다.
모바일 시대가 되며 깊이보다는 UI 배치 중요도가 높아짐 -1depth: 보통 사용자가 가장 쉽게 먼저 보는 메뉴 -Type: 화면의 유형. 단순 텍스트 화면은 페이지, 링크, html 등으로 표기 / 개발로 기능이 들어간 것은 프로그램 / LP는 레이어 팝업 -외부 API는 회사 정책에 따라 IA에 포함시키기도 하고 제외하기도 한다. -회원가입과 비회원 주문조회는 화면상 로그인 하위 메뉴처럼 보이지만 단순 네비게이션이고, 정보 구조상에서는 로그인과 같은 레벨이기 때문에 1뎁스로 정의한다.
화면ID는 커뮤니케이션의 시작점이기 때문에 정확한 규칙을 갖고 정의할 것! 메뉴가 많은 경우 투 뎁스 사이에 여유를 좀 주고 ID숫자 부여 (대형 서비스의 경우 추후에 화면 추가될 수 있기 때문에)
