소프트웨어 공학의 입구에 서서 문을 열면 가장 먼저 반기는 것이 요구사항이다.
그리고 이렇게 시작한다.
"고객은 자신이 무엇을 원하는지 모른다."
실제 모르는 것이 아니라 머릿속에 있는 것을 표현을 못한다는 말이다.
이것을 구체화하는 작업이 요구사항 정의이다.
에이전시나 SI 프로젝트를 경험하신 분들은 친근하게 느껴질 수 있을 것이다.
하지만 인하우스나 자체 솔루션을 오래부터 가져온 회사 직원은 필요성을 못 느낄 수 있을 것이다.
요구사항의 중요성은 구글에서 검색하면 나무에 그네를 만드는 이미지로 확인할 수 있다.
서론을 시작으로, 요구사항 수집 > 분석 > 정의 > 관리 4단계를 확인한다.
서론, 요구사항 접하기
요구사항 문서에 대해 처음 접하다.
필자가 요구사항을 처음 접한 것은 외국(계) 회사에서 근무했던 직장 선배를 통해서였다.
한 분은 야후 코리아에서 디자이너로 일하셨던 분이고,
다른 한 분은 실리콘밸리에서 안드로이드를 개발했고, 아키텍트를 하고 계신다.
FRD (Functional Requirements Document)
FRD란 용어를 처음 접하고 문서를 보게 되었다.
문서의 구성은 아래와 같다.
표지 : 제목과 제품, 버전, 작성자를 포함한다.
문서승인 : 리뷰자, 의사결정권자의 서명과 날짜를 입력할 수 있다.
문서이력 : 버전, 날짜, 작성자, 내용 흔히 작성하는 이력과 동일하다.
1. 개요 (Overview) : 문서의 목적과 범위 등을 자유롭게 기술한다.
1.1. 용어 정의 : 문서에서 사용되는 용어, "사용자", "관리자" 등 대체 사용하는 용어들을 정의한다.
2. 상위 기능 요구사항 (High Level Functional Requirements) : 기능과 비기능으로 분리하여 개발 컴포넌트나 파트 단위의 큰 기능을 명시한다.
2.1. 기능 요구 사항 : ID, 이름, 컴포넌트(파트), 중요도, 정의
2.2. 비 기능 요구사항 : ID, 이름, 컴포넌트(파트, 품질요소), 중요도, 정의
3. 요구 사항 상세 : 상위 기능 요구사항을 상속받아 세부적인 항목들이 정의된다. ID, 복잡도, 상세 정의(시나리오 or 세부 명세)
FRD 흉내내기 시작
개발자가 만든 문서여서 그런가... 크게 와 닿는 부분은 없었지만 비 개발자 입장에서 흉내를 내기 시작했다.
처음 도입은 소속된 프로젝트에서 HW 장치 일부에 적용했다.
기능 단위로, 상위 요구사항과 상세 요구사항만을 작성하였다.
워드로 작성하니... 있어빌리티는 좋지만, 편집, 작성에 너무 공수가 들어간다.
요구 사항 ID : 파트 앞글자 + 상위 요구사항 ID + 시퀀스
복잡도 : 비 개발자로서 입력을 할 수가 없었다.
상세 정의 : 사용자 입장에서의 시나리오 형태로 작성을 했다.
두 번째 FRD 문서
두 번째 도입은 SNS 서비스 프로젝트에서 도입을 해봤다.
참고로, UI설계서만 보고 개발해오던 개발자들은 요구사항 문서를 극혐 한다.
(그만큼 성숙도가 낮은 개발자들이 많이 있다.)
작성의 번거로움을 해결하고자 스프레드시트로 템플릿을 변경했다.
달리진 포인트가 존재한다.
운영 중인 프로젝트였기 때문에 버전이라는 항목을 추가하여 히스토리 추적을 할 수 있도록 해보았다.
복잡도를 없애고 중요도를 추가하여 개발 우선순위를 정하는 지표로 삼을 수 있도록 해보았다.
시트로 변경하고 효율성이 확실하게 증가됨을 느꼈으나, 프린트해서 보는 사람들 입장에서는 만족스럽지 못했다.
여기까지는 필자의 시행착오이며 서론에 불과하다. 이제부터 요구사항 작성에 대해 실무적으로 다루어보고자 한다.
(이론은 SW공학이나 요구공학 책을 읽으세요~ 상세하고 다양한 관점에서 설명합니다.)
개인적인 요구사항에 대한 바람.
- 요구사항은 사용자 요구사항과 시스템 요구사항으로 구분할 수 있습니다. 사용자 요구사항은 비즈니스 요구사항과 부합하며 실제 사용자 입장의 시나리오를 주축으로 합니다. 시스템 요구사항은 개발 내용과 직접적 연관이 있고 기능들을 기술적으로 설명합니다. 개발자나 아키텍트가 작성하기를 권장합니다.
본론, 요구사항 4단계
1. 요구 사항의 수집
보통 고객의 접점에 있는 인력이 고객의 의견을 듣고 정리해서 전달을 해 준다.
하지만, 우리는 그것을 보고 도대체 무엇을 원하는지 알기가 어렵다. 명확한 게 없기 때문에 무엇을 어떻게 만들어야 할지 정의를 못하기 때문이다.
여러 방법 중, 고객 인터뷰를 통해 요구사항을 수집하고 정리하는 것이 보편적이며 쉽다.
UX 리서치 공부를 하다 보면 인뎁스 인터뷰라는 항목을 접했을 것이다. 바로 이 스킬이 필요하다.
- 중립적 위치에서 편견 없는 태도
- 유도 질문 피하기
- 캐어 묻기
수집된 항목을 가지고 분석을 통해 다음 단계를 진행한다.
2. 요구 사항의 분석
이제부터가 진짜다.
우선 도메인에 대한 이해를 해야 한다.
2.1. 나 자신을 캐스팅한다.
내가 사용자고, 내가 관리자, 내가 운영자가 되는 것이다. (퍼소나 = 나)
그리고 마구마구 아이디어를 내고 적고, 낙서판을 만들어가며 키워드를 추출해낸다.
그리고 그 복잡한 낙서판에서 기능들을 하나씩 추출하기 시작한다.
보통 베이스는 CRUD 를 기반으로 기능들을 추출한다.
(Create, Read, Update, Delete)
이는 데이터 드리븐 모델링과도 부합할 수 있을 것 같다.
사용자의 모든 행위는 데이터를 다루는 것에서 시작하기 때문이다.
2.2. 다음 IA를 작성한다.
우선 Actor 에 대한 모델을 생성하고, Actor 의 행동에 의해 생성되는 모델을 생성한다.
페이스북이라 가정하면,
Actor는 일반 사용자, 법인(개인) 사업자, 운영자, 관리자 의 모델을 만들 수 있다.
Actor에 의해 생생되는 모델은 포스트, 댓글, 채팅, 영상 콘텐츠, 광고, 결제정보, 알림, 추천 정보 등....
이렇게 완성된 모델 껍데기를 나란히 정렬하고 필요한 디지털 데이터(이하"엔티티", Attributes or Entity)를 추가한다.
페이스북의
사용자는 가입일시, 인증일시, 이메일 주소, 이름, 생년월일, 관심설정, 사용 플랫폼, 팔로우, 팔로잉 등 개인과 관련된 정보항목을 추가한다.
포스트는 작성 일시, 공개 여부, 포스트 타입, 제목, 내용, 댓글, 댓글 수, 조회수, 공유수, 조회수, 좋아요 수, 작성자 정보, 포스트 각종 옵션 등... 포스트와 관련된 항목을 추가한다.
댓글은 작성 일시, 작성자, 작성 포스트, 좋아요 수, 대댓글 수 등..
작성된 모델과 엔티티들을 보면 종속관계가 1:1, 1:N, N:N 등 다양하게 얽히게 된다.
CRUD 의 Read 를 통해 종속된 데이터를 불러와서 사용자에게 데이터를 표시할 수 있는 용도로 쓰인다.
샘플
필자는 모든 과정이 결과물을 산출해내기 위한 용도라... 나만 보기 쉽다.
1행은 모델 데이터이고
2행부터 각각 속성, 엔티티들을 작성했다.
모델들은 고유 색상을 가지고 있어 다른 모델의 엔티티로 들어가더라도 보기 쉽도록 해보았다.
DB 모델링을 하던 사람이라면 깔끔하게 정제된 ERD를 만들겠지만.... 난 개발을 하기 싫다.
따라서 Relationship 이 1:1, 1:N, N:N, 0:N....이런 표시가 안돼서 메모로 주요 내용들을 남겼다.
필자는 모든 과정이 결과물을 산출해내기 위한 용도라... 나만 보기 쉽다.
1행은 모델 데이터이고
2행부터 각각 속성, 엔티티들을 작성했다.
모델들은 고유 색상을 가지고 있어 다른 모델의 엔티티로 들어가더라도 보기 쉽도록 해보았다.
DB 모델링을 하던 사람이라면 깔끔하게 정제된 ERD를 만들겠지만.... 난 개발을 하기 싫다.
따라서 Relationship 이 1:1, 1:N, N:N, 0:N....이런 표시가 안돼서 메모로 주요 내용들을 남겼다.
2.3. 다음 IA 기반의 사용자 시나리오를 작성
이제 IA 를 기반으로 Actor 의 CRUD 와 기능을 작성한다.
(Who 누가, What 어떤 데이터를, How 어떻게 이용하는가)
페이스북으로 가정하고
사용자는 포스트를 등록한다. (제목, 내용, 첨부, 공개 범위....)
사용자는 포스트를 조회한다. (포스트 엔티티~~ 많네)
사용자는 포스트를 수정한다. (제목, 내용, 공개 범위, 첨부 추가..)
사용자는 포스트를 삭제한다. (삭제 취소, 삭제 완료, 숨김 처리...)
관리자는 포스트를 조회한다.
관리자는 포스트를 추천한다.
관리자는 포스트를 숨김 처리한다.
모든 데이터에 대한 Actor 들의 행위가 누락 없이 작성되어야 한다.
샘플
IA와 같은 시트에 작성하여 빠르게 수정, 작성을 할 수 있도록 했다.
A열은 요구사항 수집 ID
B열은 (Who) Actor 모델
C열은 (What) 데이터 모델
D열은 (How) CRUD 행위
E열은 CRUD 행의의 상세
UML 툴을 잘 사용하다면 보기 좋게 나오겠지만.... 난 개발이 싫다.
IA와 같은 시트에 작성하여 빠르게 수정, 작성을 할 수 있도록 했다.
A열은 요구사항 수집 ID
B열은 (Who) Actor 모델
C열은 (What) 데이터 모델
D열은 (How) CRUD 행위
E열은 CRUD 행의의 상세
UML 툴을 잘 사용하다면 보기 좋게 나오겠지만.... 난 개발이 싫다.
필자의 요구사항 분석은 여기까지이다.
최종적으로 1개의 스프레드시트에 2개의 산출물이 생성되었다.
여기까지 도달하기 위해 우리는 도메인에 대한 분석, 경쟁사 벤치마킹, UX 리서치, 서비스 전략, 차별화 포인트 등 수많은 고민이 되어야 한다. 이런 고민들이 생략되었으면 앞으로 작성할 요구사항 명세서는 알맹이는 없는 껍데기에 불과할 것이다.
(여기서는 요구사항만 다룰 거니깐....)
3. 요구 사항 명세서의 작성
요구사항 명세서는 흔히 말하는 SRS 로 생각하길 바란다.
(Software Requirements Specification)
SW를 개발한다고 하면, SRS 가 없이는 고객이 원하는 명확한 제품이 나오기 어렵다.
단, SRS 는 인하우스에서 굳이 형식까지 갖출 필요는 없다.
유저 스토리 기반의 요구사항 명세로 작업이 더 수월할 수 있다.
(▼) 유저 스토리 기반의 요구사항
여기서 설명하고자 하는 SRS 는 외주를 맡기거나 수주했을 때
개발을 진행을 위한 상호 프로젝트의 범위에 대한 명시를 명확히 하고 인수 조건(테스트)을 협의하기 위함이기도 하다.
그냥 딱딱하지만, 있으면 매우 유용한 문서, 계륵이라고 해야 하나... 그런 문서이다.
SRS는 IEEE 에서 정의한 템플릿이 존재한다.
참고만 하자. 자괴감이 들 수 도 있다.
4. 요구 사항의 변경 관리
확정되어 개발이 시작된 시점에도 요구 사항의 변경 요청은 빈번한 게 현실이다.
요구 사항을 잘못 작성한 것이 아니라 상황이 변하거나 고객의 변심일 가능성이 높다.
변경 및 추적은 SW 공학에서도 마지막 범위에서 심도 있게 다루는 분야이다.
그러니깐 패스~
한 번 작성되어 확정된 요구사항은 지우면 안 됩니다.
- 사선(삭제)을 긋고 이력을 작성하세요. (근거, 일시)
- 또는 버전을 올려서 버전으로 관리하세요.
추가되는 요구사항은 관련된 요구 사항의 마지막 항목에 추가하세요.
- 요구사항은 비슷한 테마끼리 묶어놓으면 확장성, 기능 중복 등 여러 가지 이점이 있습니다.
- 그리고 이력을 작성하세요. (근거, 일시)
요구사항 관리 시스템이 없다면 요구사항 추적표를 일부러 만들지 마세요.
- 관리 안돼요.
- 요구사항을 엑셀이 아닌 TestLink 와 같은 툴을 이용하면 쉽게 관리할 수 있습니다.
이력을 검색하는 것만으로도 충분이 추적하고 찾아갈 수 있습니다.
변경/추가 시점의 근거와 일시만 남겨 놓으시면 됩니다.
마무리
작성된 요구 사항은 테스트 케이스로 세분화하여(또는 그대로) 사용될 수 있고,
화면 설계서 작성 시, 공통 UI 모듈을 만드는 기반이 됩니다.
보통.... 1000 줄 이상 넘어가는듯 하다.
예시로 사용된 온라인 강의는 3000 줄 정도
이전 테스트 자동화 프로젝트도 1500 줄 정도
댓글