본문 바로가기

운영

오피스체크인 서비스 - 요구 분석 과정

해당 문서는 실제 오피스체크인에서 진행하는 방식에 초점을 두고 주관적으로 작성된 포스팅임을 알려 드립니다. 

목차

1. 개요

2. 요구 분석 과정

3. 기능 정의서 작성을 해야 하는 이유

4. 요구사항을 전달하는 방법

5. 요구 분석 과정의 예시

 

1. 개요

 막연하게 '어떤 기능이 들어갔으면 좋겠다.'라고 생각해서 개발이 이루어지는 것은 아닙니다. 개발자에게 기획안이 전달되는 과정까지 기능의 실현 가능성을 고찰하고 세부 동작과 필요한 데이터, 데이터의 활용 방법 등에 대한 파악이 필요합니다.

 

 이러한 과정의 첫 단계가 '요구 분석 단계'입니다. '요구 분석’이란 새로운 시스템이나 기존 시스템에 기능 추가 및 개선을 위한 요구를 결정하는 작업 단계로, 개발자뿐만 아니라 관리자 외 내부 관계자, 사용자가 함께 의견을 조율하는 단계입니다. 요구 분석 단계가 제대로 진행되지 않으면, 작업의 방향성이 확실하지 못해 좋은 결과가 나오기 어렵습니다. 

 

 아래 Wiki에서 제공하는 요구 분석 과정을 시각화한 그림입니다.

 

 

요구 분석 과정, SE Process 모델

* 출처

https://ko.wikipedia.org/wiki/%EC%9A%94%EA%B5%AC%EC%82%AC%ED%95%AD_%EB%B6%84%EC%84%9D

 

요구사항 분석 - 위키백과, 우리 모두의 백과사전

요구사항 분석(Requirements analysis)은 시스템 공학과 소프트웨어 공학 분야에서 수혜자 또는 사용자와 같은 다양한 이해관계자의 상충할 수도 있는 요구사항을 고려하여 새로운 제품이나 변경된

ko.wikipedia.org

 

2. 요구 분석 과정

  • 요구사항 수집
  • 요구사항 분석
  • 요구사항 작성

 요구 분석 과정은 요구사항을 수집하는 과정을 제외하면 분석과 작성 단계로 구분합니다. 분석 단계에서는 요구사항을 명확하게 정의하고, 시스템의 현황을 확인 후 요구사항 반영을 위한 목표와 할 일을 파악합니다.

 

 그리고 작성 단계에서는 요구사항을 반영하여 완성할 시스템이 어떤 기능이 어떻게 동작하는지 구체화하여 문서화합니다. 문서화는 요구사항 정의서, 기능 명세서, 유저 스토리, 프로토타이핑 등 다양하며 단일 방법이 아니라 여러 방법으로 작성합니다. 또한 하나의 방법을 고수하는 것이 아닌 상황에 맞는 방법을 선택합니다. 이 과정에서 주의사항은 요구사항의 변경되면 개발 과정 전체에 영향을 줄 수 있으므로 정확하고 완전한 문서 작성을 목표로 해야 합니다.

 

3. 기능 정의서 작성을 해야 하는 이유

 기능 정의서란 기능에 대한 정의를 내리고 개발 조건 및 구현 방법 등을 설명하는 문서입니다. 구체화를 시작하는 단계인 만큼, 작성하는 과정에서 기능 개발의 방향성을 잡습니다. 기능 정의서 초안 작성을 통해 구현 가능 여부와 세부 사항 등의 논의가 진행됩니다.

 

 기능 정의서를 작성하는 이유 첫 번째는 가장 명확하게 개발해야 하는 기능을 정의할 수 있으며, 개발자와 원활하게 소통할 수 있기 때문입니다. 기능 정의서를 통해 구현해야 하는 기능이 '무엇'인지 개발자와 소통함으로써 '어떻게' 구현할지 개발자로부터 보완할 수 있습니다. 기능 구현자인 개발자가 기능이 '무엇'인지, '어떻게' 구현해야 하는지 정확히 파악해야 원하는 기능이 제대로 구현될 수 있습니다. 개발자는 개발 과정에서 궁금할 수 있는 질문에 대한 답을 기능 정의서를 통해 전달받습니다.

 

 두 번째는 기능 정의서를 통해 사용자 관점에서 최종 결과물이 어떤 형태이며 어떻게 동작할 것인지 파악할 수 있기 때문입니다. 기능 정의서에는 필요한 기능과 그 세부 항목 등을 사용자 관점에서 정의하므로, 내부적인 구현 방법 등은 포함하지 않습니다. 또한 요구자(고객 또는 사내 관리자)에게 최종적으로 승인을 받기 때문에 해당 문서를 통해 요구자가 원하는 시스템을 완성할 수 있으며 추후 개발이 제대로 수행되었는지 확인할 수 있는 기준으로 활용할 수 있습니다.

 

4. 요구사항을 전달하는 방법

 오피스체크인에서 요구사항이 발생하는 경우는 크게 2가지로 나눌 수 있습니다.

  • 기존 기능에 오류 발생
  • 기능의 확장 및 새로운 기능 추가 

(1) 기존 기능에 오류 발생

 기존 기능에 오류가 발생한 경우에는 사내 프로젝트 관리 툴 '레드마인'에 간단한 양식으로 일감을 남기는 방법을 사용합니다. 또한 관리자용 서비스를 사용하면서 느낀 불편 사항이나 사용성 개선 등의 문제도 요청할 수 있습니다.

 

레드마인 - 오피스 체크인 서비스

 

 

레드마인 - 일감 작성 화면

 

 작성 시 제목에는 해당 요청이 어떤 서비스에 관한 건지 표시해야 합니다.

  • 관리자 서비스 관련 요청은 머리말 [관리자] 입력
  • 사용자 서비스 관련 요청은 머리말 [사용자] 입력
  • PC/Mobile/App 등 특정 환경 관련 요청은 해당 환경 입력
    • 예시 ) [Mobile] iOS app 빌딩 상세-공유 버튼 미작동, [사용자] 빌딩 문의-회원정보 불러오기 오류

 

  그 외에 일감 작성 화면에서 확인할 사항은 다음과 같습니다.

  • 유형 선택: 버그 관련 [결함] / 관리자 사용성 불편 사항 등 기존 기능 개선[지원]
  • 유형에 맞는 일감 템플릿 선택 후 해당 목록에 맞는 내용 작성
  • 첨부파일이 있는 경우 파일 선택
  • 화면이름 : 해당 링크 또는 발생 메뉴명 등 입력
  • OS: 요청 내용 발생 환경 입력 
    • 관리자 관련 예시 ) mac-safari / windows10-chrome 스테이징 등
    • 사용자 관련 예시 )  PC-Web, window10-explore edge / Mobile-Web, 카카오 인 브라우저 / App - 아이폰 13 mini 등

 

일감 작성 예시 1

 

 위의 예시는 오류 관련 요구사항의 일감이며, 사용성 개선 등의 문제는 목적, 기능 설명 및 검증 방법을 추가로 작성해야 합니다.

  • 목적: 요청하는 요구사항이 필요한 이유 또는 목적
  • 기능 설명: 개선 또는 추가되어야하는 기능 목록 등
  • 기능 검증방법: 제대로 적용되었는지 확인하는 방법

 

일감 작성 예시 2

 

(2) 기능의 확장 및 새로운 기능 추가

 오류 또는 간단한 기능 개선이 아닌 경우에는 요구사항 확인 과정을 거쳐 기능 정의서 작성이 필요합니다. 기능 정의서를 작성할 때는 사용자의 관점에서 작성하는 것이 좋습니다. 애초에 해야 할 일을 사용자 입장을 반영한 형태로 작성하면, 반영된 형태의 할 일이기 때문에 사용자 입장을 계속 생각할 수 있습니다.

 

 또한 기능 정의서에는 '어떤' 기능이 들어가야 하는지 명시해야 합니다. Depth별로 나누어 표현하는 방법이 일반적이나, 간단하게 필요 기능의 목적 및 설명, 표시 내용 등을 작성합니다. 레드마인에 작성하던 항목들을 좀 더 자세히 설명해야 합니다.

 

 아래는 빌딩 리뷰의 일부 기능 명세서입니다.

범주 화면 기능
현재공실 현재공실 상세 내 빌딩 리뷰 1. 빌딩에 대한 사용자 리뷰 표시
2. 비로그인 or 리뷰 미작성 회원은 작성하면 볼 수 있다는 화면 표시
3. 리뷰가 없으면 로그인/리뷰작성 유무 상관없이 리뷰없음 화면 표시
4. 리뷰 작성 1회 이상인 회원에게 현재공실 상세 리뷰 목록 노출

 

 해당 표와 같은 내용을 오피스체크인 서비스 기능 명세서 형식에 맞추어 작성 후 개발팀 및 관련 실무자, 관리자 회의를 거쳐 수정과 보완 작업을 진행할 수 있습니다.

 

 

오피스체크인 서비스 기능 명세서

 

5. 요구 분석 과정의 예시 

 기능 정의서가 실제로 요구 분석 단계에서 어떤 역할을 하는지는 아래의 최근 오피스체크인 App에 출시된 '공유 오피스' 요구 분석 과정을 통해 알 수 있습니다.

(1) 요구 발생

회의 중 ~ "공유오피스 시장의 성장으로 그 중요성이 높아지고 있습니다. 해당 시장의 고객층이 우리 서비스의 잠재 고객인 만큼, 공유 오피스 기능 도입을 고려해보자 합니다." ~

(2) 요구 분석 준비

 본격적인 요구 분석 전 요구사항이 무엇인지 파악하기 위한 정보 수집 및 타 서비스 분석이 진행되었습니다. 

 

공유오피스 요구 분석 준비

(3) 요구 분석 과정

 공유오피스 요구 분석 과정에서 기능 정의서를 작성하되, 프로토타이핑 등의 방법을 통해 피드백을 받아 보완하는 형태로 이루어졌습니다. 

  1. 공유 오피스 기능에 대한 요구사항 정의
  2. 요구 기능의 목적, 설명, 검증 방법 정의
  3. 해당 기능의 IA, 기능 명세서 작성
  4. 프로토타입 제작 후 피드백, 최종 결정

공유오피스 기능 도입을 위한 과정
공유오피스 프로토타입 draft 버전

#끝으로

해당 포스팅에서는 새로운 기능 또는 보수를 위한 개발 첫 번째 단계인 요구 분석 과정에 관해 서술했습니다. 개발자 외의 타 직무의 구성원에게 요구사항 또는 기능 정의서 작성은 낯설고 번거로운 일입니다. 하지만 요구 분석은 개발의 성공 여부를 결정하는 주요 단계인 만큼 피할 수 없는 과정입니다.

 

 

이상으로 글을 마칩니다.

 

'운영' 카테고리의 다른 글

구글 애널리틱스(GA) 기초 - 개요 및 용어  (2) 2021.07.12