2.서비스경험디자인기사 실기 프로젝트 요구사항 파악
프로젝트 요구사항 파악은 서비스디자인의 첫 단계로, 주어진 자료에서 사용자 문제와 과제 목적을 찾아 이후 조사·분석·설계 방향을 정하는 과정이다.
서비스경험디자인기사 실기 프로젝트 요구사항 파악
1. 정의
```프로젝트 요구사항 파악은 서비스경험디자인 프로젝트를 시작할 때 가장 먼저 해야 하는 작업이다.
요구사항은 프로젝트에서 반드시 해결해야 하는 조건, 필요, 문제, 목표를 뜻한다. 쉽게 말하면 “무엇을 해결해야 하는가”, “누구를 위해 해결해야 하는가”, “어떤 결과가 필요한가”를 정리한 것이다.
서비스경험디자인기사 실기에서 프로젝트 요구사항 파악은 주어진 자료를 읽고 서비스의 문제 상황과 사용자 요구를 찾아내는 과정이다.
사용자는 서비스를 실제로 이용하는 사람이다. 고객, 시민, 환자, 학생, 직원, 관리자, 상담원, 운영자 등이 사용자가 될 수 있다.
프로젝트는 특정 목표를 달성하기 위해 정해진 기간 안에 진행하는 일이다. 예를 들어 병원 예약 서비스 개선, 공공 민원 서비스 개선, 키오스크 사용성 개선, 앱 회원가입 과정 개선이 프로젝트가 될 수 있다.
요구사항 파악은 단순히 요청받은 내용을 그대로 적는 일이 아니다. 요청 뒤에 숨어 있는 실제 문제를 찾는 과정이다.
예를 들어 담당자가 “예약 화면을 더 예쁘게 바꿔주세요”라고 요청했다고 가정하자. 이 문장을 그대로 받아들이면 화면 디자인만 수정하게 된다. 하지만 실제 문제는 사용자가 예약 단계를 이해하지 못하는 것일 수 있다.
또는 진료과 이름이 어려워서 선택을 못 하는 것일 수 있다. 또는 예약 가능한 시간이 실제 대기시간과 달라 불만이 생기는 것일 수 있다.
따라서 프로젝트 요구사항 파악은 요청 문장을 분석하고, 사용자 문제와 서비스 목표를 명확하게 정리하는 과정이다.
```2. 필요한 이유
```프로젝트 요구사항 파악이 필요한 이유는 이후 모든 과정의 기준이 되기 때문이다.
서비스경험디자인은 보통 다음 흐름으로 진행된다.
- 프로젝트 요구사항을 파악한다.
- 서비스 환경을 조사한다.
- 사용자를 조사한다.
- 조사 결과를 분석한다.
- 디자인 원칙을 세운다.
- 아이디어를 도출한다.
- 프로토타입을 만든다.
- 서비스 시나리오를 작성한다.
- 서비스 모델을 정리한다.
- 완료보고와 사후관리를 준비한다.
이 중 첫 단계가 요구사항 파악이다. 첫 단계에서 문제를 잘못 잡으면 뒤 단계가 모두 잘못될 수 있다.
예를 들어 사용자의 실제 문제는 “서비스 신청 과정이 어렵다”인데, 프로젝트 목표를 “메인 화면 디자인 개선”으로 잡으면 실제 문제를 해결하지 못한다.
실제 개발에서도 요구사항 파악은 중요하다. 웹사이트, 앱, 관리자 페이지, 예약 시스템, 결제 시스템, 사내 시스템을 만들 때도 요구사항이 먼저 정리되어야 한다.
요구사항을 제대로 파악하지 못하면 다음 문제가 생긴다.
- 필요 없는 기능을 만든다.
- 정작 필요한 기능이 빠진다.
- 사용자 문제를 해결하지 못한다.
- 디자인과 개발 방향이 계속 바뀐다.
- 프로젝트 일정이 늘어난다.
- 비용이 늘어난다.
- 완성 후에도 다시 수정해야 한다.
서비스디자인에서도 마찬가지다. 요구사항을 제대로 파악해야 조사 범위가 정해진다. 어떤 사용자를 만나야 하는지도 정해진다. 어떤 산출물을 만들어야 하는지도 정해진다.
산출물은 프로젝트 결과로 만들어지는 문서나 자료를 뜻한다. 예를 들어 조사 계획서, 인터뷰 질문지, 페르소나, 사용자 여정맵, 서비스 블루프린트, 완료보고서 등이 산출물이다.
```3. 핵심 개념
```3-1. 프로젝트 자료
프로젝트 자료는 프로젝트를 이해하기 위해 제공되는 모든 정보를 뜻한다.
과제 설명서, 요청서, 기존 서비스 화면, 고객 불만, 통계 자료, 인터뷰 기록, 운영 매뉴얼, 정책 자료가 프로젝트 자료가 될 수 있다.
실기 시험에서는 문제 상황이 글로 제시될 수 있다. 그 글 안에서 서비스 대상, 문제 상황, 사용자 불편, 개선 목표를 찾아야 한다.
3-2. 사용자 요구
사용자 요구는 사용자가 서비스에서 필요로 하는 것이다.
사용자가 직접 말한 요구도 있고, 행동을 통해 드러나는 숨은 요구도 있다.
예를 들어 사용자가 “버튼을 크게 해주세요”라고 말했다면 겉으로 보이는 요구는 버튼 크기 확대다. 하지만 실제 요구는 “중요한 기능을 쉽게 찾고 싶다”일 수 있다.
3-3. 발견 이슈
발견 이슈는 자료를 분석하면서 찾아낸 문제나 쟁점이다.
이슈는 단순한 불만과 다르다. 프로젝트에서 해결을 검토해야 할 중요한 문제를 뜻한다.
예를 들어 “사용자가 예약을 중간에 포기한다”는 발견 이슈가 될 수 있다. “상담원이 같은 질문을 반복해서 받는다”도 발견 이슈가 될 수 있다.
3-4. 과제 취지
과제 취지는 이 프로젝트를 왜 하는지에 대한 큰 방향이다.
예를 들어 “고령자의 공공서비스 이용 불편을 줄이기 위해”가 과제 취지가 될 수 있다.
취지는 프로젝트의 배경과 연결된다. 배경은 현재 왜 문제가 발생했는지를 설명하는 정보다.
3-5. 과제 목적
과제 목적은 프로젝트를 통해 달성하려는 구체적인 결과다.
예를 들어 “온라인 민원 신청 완료율을 높인다”, “병원 예약 과정의 중도 이탈을 줄인다”, “키오스크 주문 시간을 단축한다”가 목적이 될 수 있다.
취지는 큰 이유이고, 목적은 달성할 결과다.
3-6. 과제 성격
과제 성격은 프로젝트가 어떤 유형의 문제를 다루는지 파악하는 것이다.
예를 들어 사용자 경험 개선 과제, 공공서비스 개선 과제, 디지털 전환 과제, 접근성 개선 과제, 운영 프로세스 개선 과제로 나눌 수 있다.
과제 성격을 알아야 적절한 조사 방법과 분석 방법을 고를 수 있다.
3-7. 과제 내용
과제 내용은 실제로 무엇을 수행해야 하는지 정리한 것이다.
예를 들어 사용자 조사, 서비스 분석, 문제점 도출, 개선 아이디어 도출, 프로토타입 제작, 운영방안 제시가 과제 내용이 될 수 있다.
3-8. 요구사항 도출
요구사항 도출은 자료와 사용자 요구를 바탕으로 프로젝트에서 해결해야 할 조건을 뽑아내는 과정이다.
도출은 숨겨진 내용을 찾아내어 정리한다는 뜻이다.
요구사항은 이후 디자인 원칙, 기능 아이디어, 서비스 모델을 만드는 기준이 된다.
```4. 주변 기초 개념
```4-1. 문제 정의
문제 정의는 해결해야 할 문제를 명확하게 문장으로 정리하는 것이다.
예를 들어 “사용자가 불편하다”는 문제 정의로 부족하다. 너무 넓고 모호하기 때문이다.
고령 사용자가 키오스크 메뉴 분류를 이해하지 못해 주문 완료까지 시간이 오래 걸린다.
이 문장은 대상, 문제 상황, 원인, 결과가 비교적 명확하다.
4-2. 니즈
니즈는 사용자가 실제로 필요로 하는 것이다.
사용자가 말하는 요청과 실제 니즈는 다를 수 있다. 서비스디자인에서는 사용자의 말만 듣지 않고 행동과 맥락을 함께 봐야 한다.
4-3. 페인포인트
페인포인트는 사용자가 서비스 이용 중 불편을 느끼는 지점이다.
예를 들어 복잡한 인증 절차, 이해하기 어려운 안내문, 긴 대기시간, 찾기 어려운 버튼이 페인포인트가 될 수 있다.
4-4. 이해관계자
이해관계자는 서비스와 관련된 사람이나 조직이다.
사용자는 대표적인 이해관계자다. 하지만 서비스 제공자, 관리자, 상담원, 운영자, 개발자, 정책 담당자도 이해관계자에 포함될 수 있다.
4-5. 범위
범위는 프로젝트에서 어디까지 다룰 것인지를 정하는 기준이다.
범위가 너무 넓으면 프로젝트가 흐려진다. 범위가 너무 좁으면 실제 문제를 해결하지 못할 수 있다.
예를 들어 “병원 서비스 전체 개선”은 너무 넓다. “초진 환자의 모바일 예약 과정 개선”은 더 구체적이다.
4-6. 제약조건
제약조건은 프로젝트에서 반드시 고려해야 하는 제한 사항이다.
예산, 일정, 인력, 법규, 기술 환경, 운영 정책이 제약조건이 될 수 있다.
예를 들어 개인정보를 다루는 서비스라면 개인정보보호법을 고려해야 한다. 법규를 무시한 서비스 설계는 실제로 적용하기 어렵다.
4-7. 기능 요구사항
기능 요구사항은 서비스가 제공해야 하는 기능에 대한 조건이다.
예를 들어 “사용자는 예약 가능한 시간을 조회할 수 있어야 한다”가 기능 요구사항이다.
4-8. 비기능 요구사항
비기능 요구사항은 기능 자체가 아니라 품질, 성능, 보안, 사용성에 대한 조건이다.
예를 들어 “예약 화면은 모바일에서 쉽게 읽혀야 한다”, “개인정보는 암호화되어야 한다”, “페이지는 3초 안에 열려야 한다”가 비기능 요구사항이다.
기능 요구사항은 무엇을 할 수 있어야 하는지에 가깝다. 비기능 요구사항은 얼마나 안전하고 편리하고 빠르게 동작해야 하는지에 가깝다.
```5. 실제 흐름
```프로젝트 요구사항 파악은 다음 순서로 진행할 수 있다.
5-1. 프로젝트 자료를 확인한다
과제 설명, 서비스 현황, 사용자 불만, 기존 화면, 운영 자료를 확인한다.
이 단계에서는 바로 해결책을 생각하지 않는다. 먼저 어떤 상황인지 파악한다.
5-2. 서비스 대상을 찾는다
누가 서비스를 이용하는지 찾는다.
예를 들어 병원 예약 서비스라면 초진 환자, 재진 환자, 보호자, 병원 직원이 대상이 될 수 있다.
5-3. 문제 상황을 정리한다
사용자가 어떤 불편을 겪는지 정리한다.
이때 단순한 불만 문장이 아니라 실제 문제 상황으로 바꿔야 한다.
예를 들어 “앱이 불편하다”는 표현은 모호하다. “사용자가 진료과 선택 단계에서 필요한 정보를 찾지 못해 예약을 중단한다”가 더 명확하다.
5-4. 사용자 요구를 정리한다
사용자가 원하는 것을 정리한다.
사용자가 직접 말한 요구와 행동에서 드러난 요구를 구분하면 좋다.
- 명시적 요구: 사용자가 직접 말한 요구
- 잠재적 요구: 사용자가 직접 말하지 않았지만 행동에서 드러난 요구
5-5. 과제 취지와 목적을 정리한다
왜 이 프로젝트를 하는지 정리한다. 그리고 이 프로젝트를 통해 어떤 결과를 얻어야 하는지 정리한다.
취지는 배경과 방향이다. 목적은 달성할 결과다.
5-6. 과제 성격과 범위를 정한다
이 과제가 사용자 경험 개선인지, 운영 프로세스 개선인지, 디지털 서비스 개선인지 파악한다.
그리고 어디까지 다룰 것인지 정한다.
5-7. 요구사항을 문장으로 도출한다
마지막으로 요구사항을 구체적인 문장으로 정리한다.
좋은 요구사항 문장은 다음 요소를 포함하면 좋다.
- 대상: 누구를 위한 것인가
- 문제: 무엇이 불편한가
- 목표: 무엇을 개선해야 하는가
- 조건: 어떤 제약을 고려해야 하는가
6. 예시
```아래는 프로젝트 요구사항 파악 예시다.
프로젝트 상황:
```
공공기관 온라인 민원 신청 서비스에서 고령 사용자의 신청 중도 이탈이 높다.
프로젝트 자료:
온라인 민원 신청 화면
고객센터 문의 기록
사용자 불만 게시글
신청 단계별 이탈률 데이터
기존 서비스 운영 매뉴얼
서비스 대상:
온라인 민원 서비스를 이용하는 고령 사용자
발견 이슈:
신청 단계가 많고, 행정 용어가 어려워 사용자가 신청을 완료하지 못한다.
사용자 요구:
쉬운 용어로 안내받고 싶다.
현재 신청 단계가 어디인지 알고 싶다.
잘못 입력했을 때 어떻게 수정해야 하는지 알고 싶다.
과제 취지:
고령 사용자가 공공서비스를 더 쉽게 이용할 수 있도록 한다.
과제 목적:
온라인 민원 신청 과정의 이해도와 완료율을 높인다.
요구사항:
신청 단계는 사용자가 현재 위치를 알 수 있도록 표시해야 한다.
어려운 행정 용어는 쉬운 표현과 설명을 함께 제공해야 한다.
입력 오류가 발생하면 수정 방법을 구체적으로 안내해야 한다.7. 코드 또는 설정 설명
```이 주제는 개발 코드보다 요구사항 문장 작성이 중요하다. 따라서 위 예시를 항목별로 설명한다.
7-1. 프로젝트 상황
공공기관 온라인 민원 신청 서비스에서 고령 사용자의 신청 중도 이탈이 높다.프로젝트 상황은 현재 발생한 문제를 설명한다.
여기에는 서비스, 사용자, 문제가 들어가야 한다.
- 서비스: 공공기관 온라인 민원 신청 서비스
- 사용자: 고령 사용자
- 문제: 신청 중도 이탈이 높음
7-2. 프로젝트 자료
온라인 민원 신청 화면
```
고객센터 문의 기록
사용자 불만 게시글
신청 단계별 이탈률 데이터
기존 서비스 운영 매뉴얼프로젝트 자료는 문제를 파악하기 위한 근거다.
화면 자료는 사용자가 어떤 정보를 보는지 확인할 수 있게 해준다. 고객센터 문의 기록은 사용자가 자주 묻는 문제를 보여준다. 이탈률 데이터는 사용자가 어느 단계에서 포기하는지 알려준다. 운영 매뉴얼은 서비스 제공자가 어떤 방식으로 업무를 처리하는지 보여준다.
7-3. 서비스 대상
온라인 민원 서비스를 이용하는 고령 사용자서비스 대상은 문제를 겪는 사용자를 뜻한다.
모든 사용자를 대상으로 잡으면 너무 넓다. 이 예시에서는 고령 사용자를 핵심 대상으로 잡았다.
7-4. 발견 이슈
신청 단계가 많고, 행정 용어가 어려워 사용자가 신청을 완료하지 못한다.발견 이슈는 문제의 원인을 설명한다.
단순히 “불편하다”가 아니라 왜 불편한지를 적어야 한다. 이 예시에서는 신청 단계 수와 어려운 용어가 문제 원인이다.
7-5. 사용자 요구
쉬운 용어로 안내받고 싶다.
```
현재 신청 단계가 어디인지 알고 싶다.
잘못 입력했을 때 어떻게 수정해야 하는지 알고 싶다.사용자 요구는 사용자가 필요로 하는 것이다.
요구는 가능한 한 사용자의 관점으로 작성하는 것이 좋다.
7-6. 과제 취지
고령 사용자가 공공서비스를 더 쉽게 이용할 수 있도록 한다.과제 취지는 프로젝트의 큰 방향이다.
이 예시에서는 디지털 서비스 접근성과 사용 편의성이 핵심 방향이다.
7-7. 과제 목적
온라인 민원 신청 과정의 이해도와 완료율을 높인다.과제 목적은 프로젝트를 통해 얻고 싶은 결과다.
이해도와 완료율은 개선 결과를 판단할 수 있는 기준이 된다.
7-8. 요구사항
신청 단계는 사용자가 현재 위치를 알 수 있도록 표시해야 한다.
```
어려운 행정 용어는 쉬운 표현과 설명을 함께 제공해야 한다.
입력 오류가 발생하면 수정 방법을 구체적으로 안내해야 한다.요구사항은 실제 설계와 개선의 기준이다.
좋은 요구사항은 구체적이어야 한다. “쉽게 만든다”보다 “현재 위치를 표시한다”가 더 구체적이다.
```8. 주의점
```8-1. 요청과 요구사항을 구분해야 한다
요청은 누군가가 해달라고 말한 내용이다. 요구사항은 문제 해결을 위해 반드시 필요한 조건이다.
예를 들어 “버튼을 크게 해주세요”는 요청이다. “사용자가 주요 기능을 쉽게 찾을 수 있어야 한다”는 요구사항이다.
8-2. 해결책부터 쓰면 안 된다
요구사항 파악 단계에서는 바로 해결책을 정하면 안 된다.
먼저 문제와 원인을 파악해야 한다. 해결책은 조사와 분석 이후에 더 정확하게 나올 수 있다.
8-3. 사용자를 너무 넓게 잡으면 안 된다
“모든 사용자”는 너무 넓다.
실제로 문제를 겪는 핵심 사용자를 찾아야 한다.
예를 들어 온라인 민원 서비스에서는 고령 사용자, 처음 이용하는 사용자, 모바일 이용자처럼 세분화할 수 있다.
8-4. 문제를 감정적으로 쓰면 안 된다
“서비스가 별로다”, “사용자가 싫어한다” 같은 표현은 좋지 않다.
실기 답안에서는 구체적인 현상으로 써야 한다.
사용자가 신청 단계에서 필요한 정보를 찾지 못해 중도 이탈한다.8-5. 기능 요구사항과 비기능 요구사항을 구분해야 한다
기능 요구사항은 서비스가 해야 하는 일이다. 비기능 요구사항은 서비스의 품질 조건이다.
| 구분 | 의미 | 예시 |
|---|---|---|
| 기능 요구사항 | 서비스가 제공해야 하는 기능 | 사용자는 예약 가능한 시간을 조회할 수 있어야 한다. |
| 비기능 요구사항 | 성능, 보안, 사용성 같은 품질 조건 | 예약 화면은 모바일에서도 쉽게 읽혀야 한다. |
8-6. 과제 취지와 과제 목적을 헷갈리면 안 된다
과제 취지는 프로젝트의 큰 이유다. 과제 목적은 달성해야 하는 구체적인 결과다.
예를 들어 “고령자의 디지털 서비스 접근성을 높이기 위해”는 취지다. “온라인 신청 완료율을 높인다”는 목적이다.
8-7. 요구사항은 측정 가능하게 쓰는 것이 좋다
“좋은 서비스를 만든다”는 요구사항으로 부족하다.
“신청 단계를 5단계 이하로 줄인다”, “오류 발생 시 수정 방법을 안내한다”처럼 확인 가능한 문장이 좋다.
```9. 요약
```프로젝트 요구사항 파악은 서비스경험디자인 실기의 시작 단계다.
이 단계에서는 프로젝트 자료를 분석하고, 사용자 요구를 찾고, 문제 상황을 정리하고, 과제 취지와 목적을 도출한다.
요구사항은 단순 요청이 아니다. 문제 해결을 위해 반드시 고려해야 하는 조건이다.
좋은 요구사항은 구체적이고, 사용자 문제와 연결되어 있으며, 이후 조사와 설계의 기준이 된다.
실기 답안에서는 감성적인 표현보다 구체적인 절차와 용어를 사용해야 한다.
핵심 흐름은 다음과 같다.
- 프로젝트 자료를 확인한다.
- 서비스 대상을 찾는다.
- 문제 상황을 정리한다.
- 사용자 요구를 파악한다.
- 과제 취지와 목적을 정리한다.
- 과제 성격과 범위를 정한다.
- 요구사항을 문장으로 도출한다.
10. 핵심 용어 정리
```프로젝트 = 정해진 목표를 달성하기 위해 일정 기간 동안 진행하는 일
요구사항 = 프로젝트에서 반드시 해결하거나 만족해야 하는 조건
요구사항 파악 = 자료와 사용자 문제를 분석해 필요한 조건을 정리하는 과정
프로젝트 자료 = 프로젝트를 이해하기 위해 제공되는 문서, 화면, 통계, 불만, 운영 자료
사용자 = 서비스를 실제로 이용하는 사람
사용자 요구 = 사용자가 서비스에서 필요로 하는 것
명시적 요구 = 사용자가 직접 말한 요구
잠재적 요구 = 사용자가 직접 말하지 않았지만 행동과 상황에서 드러나는 요구
발견 이슈 = 자료 분석 과정에서 찾아낸 중요한 문제나 쟁점
과제 취지 = 프로젝트를 진행하는 큰 이유와 방향
과제 목적 = 프로젝트를 통해 달성하려는 구체적인 결과
과제 성격 = 프로젝트가 어떤 유형의 문제를 다루는지에 대한 구분
과제 내용 = 프로젝트에서 실제로 수행해야 하는 작업
요구사항 도출 = 문제와 요구를 바탕으로 필요한 조건을 뽑아내는 과정
문제 정의 = 해결해야 할 문제를 명확한 문장으로 정리하는 것
니즈 = 사용자가 실제로 필요로 하는 것
페인포인트 = 사용자가 서비스 이용 중 불편을 느끼는 지점
이해관계자 = 서비스와 관련된 사람이나 조직
범위 = 프로젝트에서 다룰 영역과 한계
제약조건 = 프로젝트에서 고려해야 하는 제한 사항
기능 요구사항 = 서비스가 제공해야 하는 기능에 대한 조건
비기능 요구사항 = 성능, 보안, 사용성 등 서비스 품질에 대한 조건
산출물 = 프로젝트 결과로 만들어지는 문서나 자료
```AD
제휴 광고
일부 링크는 제휴 링크이며, 구매 또는 가입 시 일정 수수료를 받을 수 있습니다.
AD