이 글의 순서
- 01‘버튼 하나만 추가해주세요’로는 범위를 알기 어렵습니다
- 021. 사용자 — 누가 이 기능을 사용하나요?
- 032. 시작 조건 — 어느 화면과 상태에서 시작하나요?
- 043. 입력과 행동 — 무엇을 입력하고 어떤 순서로 누르나요?
- 054. 완료 결과 — 성공하면 무엇이 함께 바뀌나요?
- 065. 예외 처리 — 실패·취소·중복일 때 어떻게 안내하나요?
- 07다섯 문장을 연결하면 요청이 이렇게 바뀝니다
- 08화면 캡처와 참고 앱은 설명 자료로 사용합니다
- 09기존 범위·오류·변경·추가 개발을 구분합니다
- 10기능 요청서에 함께 남길 운영 정보
- 11보내기 전에 확인할 체크리스트
‘버튼 하나만 추가해주세요’로는 범위를 알기 어렵습니다
화면 캡처에 화살표를 그리고 ‘이 기능을 넣어주세요’라고 보내면 위치는 알 수 있지만 기능 전체는 알기 어렵습니다. 누가 언제 버튼을 누르는지, 무엇을 입력하는지, 완료되면 관리자와 데이터가 어떻게 바뀌는지, 실패했을 때 무엇을 보여줄지가 빠져 있기 때문입니다.
앱개발업체나 어플제작업체에 기능을 요청할 때는 긴 기획서보다 다섯 가지 조건을 같은 순서로 적는 것이 도움이 됩니다. 화면 캡처는 이 문장을 설명하는 보조 자료로 사용하세요.
1. 사용자 — 누가 이 기능을 사용하나요?
기능 이름보다 먼저 사용하는 사람과 권한을 적습니다. 같은 ‘일정 변경’ 기능도 고객, 담당 직원과 관리자가 할 수 있는 일이 다릅니다.
확인할 내용
로그인하지 않은 방문자인지, 가입 고객인지, 판매자·전문가·직원·관리자 중 누구인지 적습니다. 여러 역할이 사용한다면 역할별로 볼 수 있는 정보와 가능한 행동을 나눕니다.
작성 예시
‘예약을 완료한 고객이 자신의 예약 상세 화면에서 사용합니다.’
2. 시작 조건 — 어느 화면과 상태에서 시작하나요?
버튼이 보이는 화면뿐 아니라 버튼을 사용할 수 있는 상태를 적어야 합니다. 결제가 완료된 예약만 변경할 수 있는지, 방문 하루 전까지만 가능한지 같은 조건이 기능 범위를 결정합니다.
확인할 내용
시작 화면, 로그인 상태, 주문·예약·승인 상태, 사용할 수 있는 기간과 필요한 권한을 적습니다.
작성 예시
‘결제 완료 상태이며 방문 하루 전까지인 예약 상세 화면에서 일정 변경 버튼을 누릅니다.’
3. 입력과 행동 — 무엇을 입력하고 어떤 순서로 누르나요?
사용자가 선택하거나 입력해야 할 항목을 순서대로 적습니다. 필수 항목, 선택 항목, 입력 형식과 첨부 파일 조건도 포함합니다.
확인할 내용
선택 항목, 입력값, 업로드 파일, 확인 단계와 최종 실행 버튼을 구분합니다.
작성 예시
‘가능한 시간 중 하나를 선택하고 변경 사유를 입력한 뒤 변경 요청을 누릅니다.’
4. 완료 결과 — 성공하면 무엇이 함께 바뀌나요?
고객 화면만 바뀌는지 확인하지 말고 관리자, 서버 데이터, 알림과 외부 서비스까지 함께 적습니다. 한 화면의 요청이 여러 개발 범위에 연결되는 경우가 많습니다.
고객 화면
변경된 시간, 완료 안내와 다음 행동이 표시됩니다.
관리자와 데이터
관리자 일정표와 예약 기록이 바뀌고, 이전 값과 변경 사유를 보관할지 정합니다.
알림과 외부 연결
고객과 담당자에게 알림을 보낼지, 외부 캘린더·결제·문자 서비스도 갱신해야 하는지 확인합니다.
작성 예시
‘완료되면 고객 예약 시간과 관리자 일정표가 함께 바뀌고 고객과 담당자에게 변경 알림을 보냅니다.’
5. 예외 처리 — 실패·취소·중복일 때 어떻게 안내하나요?
정상 처리만 적으면 검수 단계에서 다시 결정할 일이 생깁니다. 가능한 시간이 없어졌거나 변경 기한이 지났을 때, 같은 요청을 두 번 눌렀을 때처럼 실제로 생길 수 있는 상황을 최소 하나 포함합니다.
작성 예시
‘선택한 시간이 이미 마감됐거나 변경 기한이 지났다면 예약을 바꾸지 않고 이유와 문의 방법을 보여줍니다.’
확인해보세요
- 입력값이 없거나 형식이 맞지 않는 경우
- 권한이 없거나 이용할 수 있는 기간이 지난 경우
- 다른 사용자가 먼저 처리해 상태가 바뀐 경우
- 네트워크·결제·문자 등 외부 서비스가 실패한 경우
- 버튼을 여러 번 누르거나 같은 요청이 중복된 경우
- 사용자가 중간에 취소하거나 이전 화면으로 이동한 경우
다섯 문장을 연결하면 요청이 이렇게 바뀝니다
모호한 요청은 ‘예약 화면에 일정 변경 버튼을 넣어주세요’로 끝납니다. 확인 가능한 요청은 다음과 같습니다.
이 정도면 개발업체가 필요한 화면, 권한, 데이터 변경, 알림과 예외를 질문할 수 있습니다. 모든 기술 방식을 고객이 정할 필요는 없지만 업무 규칙과 기대 결과는 고객이 확인해야 합니다.
예약을 완료한 고객이 예약 상세 화면에서 방문 하루 전까지 일정 변경을 누릅니다. 가능한 시간 중 하나를 선택하고 변경 사유를 입력합니다. 완료되면 고객 예약 시간과 관리자 일정표가 함께 바뀌고 고객과 담당자에게 알림을 보냅니다. 가능한 시간이 없거나 변경 기한이 지났다면 변경하지 않은 이유와 문의 방법을 보여줍니다.
화면 캡처와 참고 앱은 설명 자료로 사용합니다
캡처는 위치와 모양을 설명하기 좋지만 보이지 않는 규칙을 대신할 수 없습니다. 이미지에는 번호나 짧은 메모를 붙이고, 각 번호에 해당하는 다섯 문장을 함께 적으세요.
참고 앱을 보낼 때도 ‘이 앱처럼’이라고만 쓰기보다 참고할 부분을 구체적으로 표시합니다. 다른 서비스의 화면을 그대로 복제한다고 가정하지 말고 우리 서비스의 사용자와 운영 방식에 맞게 해석해야 합니다.
기존 범위·오류·변경·추가 개발을 구분합니다
기능 요청은 모두 추가 개발이 아니며, 모든 요청이 무상 오류 수정인 것도 아닙니다.
구분한 뒤 앱 화면, 관리자, 서버, 디자인, 테스트와 일정에 미치는 영향을 확인해야 비용과 완료일을 결정할 수 있습니다.
기존 계약 범위
계약과 승인된 화면에 포함됐지만 아직 개발되지 않은 항목입니다.
오류 수정
합의한 결과와 다르게 동작하거나 정상적으로 완료할 수 없는 문제입니다.
기존 기능 변경
이미 합의하거나 개발한 동작을 다른 방식으로 바꾸는 요청입니다.
신규 기능
기존 범위에 없던 새로운 사용자 행동, 관리자 업무나 외부 연결입니다.
기능 요청서에 함께 남길 운영 정보
다섯 문장 외에도 요청의 우선순위와 의사결정 정보를 남기면 여러 요청을 정리하기 쉬워집니다.
확인해보세요
- 기능 이름과 요청 날짜
- 요청자와 최종 승인자
- 필요한 이유와 해결하려는 문제
- 필수·중요·나중 중 우선순위
- 필요한 완료일과 그 이유
- 기존 범위·오류·변경·신규 구분
- 개발업체의 영향 검토 결과
- 비용·일정 승인 여부
보내기 전에 확인할 체크리스트
기능 요청의 목적은 개발업체에 일을 빨리 시키는 것이 아니라 고객과 개발업체가 같은 완료 결과를 떠올리게 하는 것입니다. 다섯 문장을 기준으로 요청하면 견적, 일정과 중간 검수도 같은 내용으로 이어갈 수 있습니다.
확인해보세요
- 사용하는 사람과 권한이 적혀 있는가?
- 시작 화면과 사용할 수 있는 상태가 적혀 있는가?
- 입력·선택·업로드와 버튼 순서가 보이는가?
- 완료 뒤 고객·관리자·데이터·알림 변화를 확인했는가?
- 실패·취소·중복 상황을 최소 하나 적었는가?
- 캡처와 참고 앱이 문장을 설명하도록 번호가 연결됐는가?
- 기존 범위인지 변경인지 표시했는가?
- 비용과 일정은 영향 검토 후 승인하도록 남겼는가?
