개발 시, 반드시 문서화 작업을 해야 하는 이유 -2부
1부에서는 문서화에 대한 중요성에 대해서 파악해 보았습니다.
이번 2부에서는 어떤 것을 문서화해야 하는지, 혹은 외주 개발사에서 요청해야 하는지에 대해서 상세히 알아보도록 하겠습니다.
기능 요구 사항 정의서 - 브런치 송미경님1. 기능 요구사항 정의서
기능 요구사항 정의서와 기능 명세서에 대해서 무슨 차이점이 있는지 물어보시는 분들이 계십니다.
기능 요구사항의 경우 말 그대로 어떠한 기능에 대해 구현을 요구하는 것에 대해 정의해놓은 문서입니다.
예를 들어 A라는 외주업체에게 외주 개발 요청 시, SNS 로그인 기능 구현 시, 반드시 Naver, Google, kakao 로그인을 기능이 포함되어야 한다고 요구하는 것을 구두로 하는 것이 아닌, 문서화를 통해 기록하는 것입니다.
요구사항을 정의서를 만드는 이유는 ‘개발 완료 후 클라이언트와 개발사 간의 발생하는 문제 사항을 예방’하기 위해서입니다.
요구사항 정의서는 말 그대로, 클라이언트와 개발사 간의 개발 약속, 즉 합의서가 됩니다.
만약 이러한 문서 없이 구두로 이야기가 된 뒤 개발을 진행하고, 문제가 발생한다면, 크게는 법정 싸움으로 시시비비를 가려야 할 상황이 발생될 수 있으므로, 반드시 작성해두는 것이 좋습니다.
요구사항 정의서는 정해진 양식이 있는 것은 아니나, 인터넷에 작성된 양식을 활용하거나, 양측에서 서로 충분히 이해하고 보기 편한 양식을 활용하면 좋습니다.
내용에는, 요청자, 요청사항 명, 요청사항 상세 내용, 참고 예시(있는 경우), 구현 가능 여부 사항이 들어가 있다면 큰 문제 없을 것으로 판단됩니다.
기능 명세서 좌측 - Depth 형태 / 우측 Flow 형태2. 기능 명세서
기능 요구사항 정의서가 어떠한 기능에 대한 구현을 요구한 상황을 기재한 것이라면, 기능 명세서는 실제 개발을 통해 구현된 기능이 적힌 것으로 최종 결과물에 대한 기능들이 설명된 자료로 볼 수 있습니다.
우리는 기능 명세서를 통해서 어떠한 기능이 어떻게 동작되는지 파악할 수 있어야 합니다.
ex) 로그인 기능 -> 아이디/비밀번호 입력을 통해 로그인을 시도할 수 있도록 한다.
[아이디 혹은 비밀번호가 양식과 일치하지 않는 경우 버튼을 비활성화하며, 일치하는 경우에만 활성화할 수 있도록 한다. 비활성화 – 회색 / 활성화 – 파란색]
기능 명세서는 보았을 때, 기능이 어떻게 동작되는지에 대해서 바로 이해가 될 수 있도록 작성되어야 합니다.
기능 명세서의 경우 화면의 Depth 나 flow를 통해서 작성됩니다.
위의 사진들과 같이 페이지에서 페이지 /상세 페이지/ 상세 기능 순으로 정리될 수도 있으며, 화면의 동작(flow)를 통해서 프로세스 과정을 통해서 기능에 대해서 설명이 될 수 있습니다.
기능 명세서의 경우 처음에만 작성한 뒤 관리하지 않는 경우가 있습니다.
하지만, 구글 엑셀 등과 같이 실무자와 공유할 수 있는 Tool을 활용하여 작성함에 따라, 기능 구현에 이슈가 있는 경우 구현 여부 등을 함께 표시하면서, 지속적으로 업데이트한다면 추후 개발 이후에 해당 기능이 정말로 구현되었는지, 확인하는 작업을 줄 일 수 있으므로, 지속적으로 관리를 요청하고 보고받을 수 있도록 하는 것을 추천드립니다.
WBS - 예시 이미지3. WBS[Work Breackdown Structure]
프로젝트의 업무를 관리하기 쉽게 매우 작게 세분화하는 단계로 프로젝트 범위를 가장 작은 단계로 분할하여, 도식화한 문서를 의미합니다.
해당 단계에서는 크게는 주차별 작게는 일일의 작업 내용이 표시되므로, 한눈에 전반적인 프로젝트의 업무 진행 단계를 예상할 수 있습니다.
번거로울 수 있으나, 해당 WBS를 통해서 프로젝트의 진행 상황을 주기적으로 확인하고, 변동 사항이 있는 경우 해당 wbs 수정 요청 및 보고를 요청하시는 것을 추천드립니다.
정보 구조도 - velog.io/@kangtsby 참고4. 정보 구조도
정보 구조도는 간단히 말해 서비스의 목차 역할을 수행합니다.
Web / App 의 어떻게 구성되는지, 어떤 기능의 화면으로 보이는지를 전체적으로 보여주는 도구입니다.
ex) 곰인형을 통한 예시입니다.
곰인형을 다음과 같이 머리/몸으로 나누고 다시 이를 세부 목록으로 나눈 것을 볼 수 있습니다.
이와 같이 서비스의 목차를 Depth 별로 나열 함으로, 전체적인 서비스의 구조도와 세부적인 구조도 모두를 볼 수 있게 하는 것이 정보 구조대입니다.
정보구조도는 서비스를 구조를 한눈에 볼 수 있기 때문에, 디자이너와 개발자 소통에서도 중요하게 사용되기도 하며, 새롭게 개발에 투입되거나 해당 서비스에 대한 프로세스에 대해 설명해 주기 위해 사용되기도 합니다.
해당 정보구조도는 경우에 따라 마인드맵(트리 형태) 혹은 엑셀 형태로 작성되게 됩니다.
두 가지 방식 모두 많이 사용되고 있는 방식이며, 개발사가 가지고 있는 양식과 경험에 따라서 다르게 작성될 수 있습니다.
와이프 레임/스토리보드(화면 설계서) - figma5. 와이어 프레임 / 스토리보드(화면 설계서)
'와이어 프레임'은 서비스의 모습을 간략하게 넣은 문서를 말하며, 여기에 상세 기능 목록 등을 추가해 해당 화면에서 어떠한 기능이 제공되는지, 어떠한 기능으로 동작이 이루어지는지를 합쳐 놓은 문서가 '스토리보드'가 됩니다.
해당 스토리보드를 통해 만들고자 하는 서비스가 대략적으로 어떻게 동작할 것인지, 무슨 기능이 있는지를 시각적으로 파악할 수 있게 됩니다.
퍼니디어 홈페이지 디자인 시안6. 디자인 시안[디자인 결과물 파일]
디자인 시안의 경우 말 그대로, 내 프로젝트에서 디자이너를 통해 만들어지는 디자인 결과물이라 할 수 있습니다.
디자인 산출물의 경우 일반적으로 계약서 작성 시, 전달한다고 되어 있으나
그렇지 않은 경우도 있으니 반드시 확인하여 전달받을 수 있도록 적으실 것을 말씀드립니다.
해당 자료를 받지 않는 경우 추후 타 개발사 혹은 타 디자이너에게 요청하는 경우 해당 디자인 원본 파일 등을 요구하게 되는데, 이때 파일이 없을 경우 새롭게 디자인 작업을 진행해야 하는 경우가 있을 수 있습니다.
소스코드7. 소스코드
소스 코드의 경우 내 프로젝트를 결과물이라 할 수 있습니다.
결과 산출물 전달 시, 자신의 서비스에 대한 소스코드를 전달받지 못하는 경우가 있습니다.
반드시 계약서에 ‘개발 전체에 대한 원본 소스코드’를 전달받는 내용을 작성하여 추후 고도화나, 직접 개발 시 문제가 발생하지 않고 사용할 수 있도록 해야 합니다.
ERD - 예시8. ERD[Entity Relationship Diagram]
ERD란 Entity Relationship Diagram의 약어로, ‘대체관계도’라고도 부르며, 일반적으로 데이터베이스 구조를 한눈에 알아보기 위해서 쓰입니다.
해당 자료는 내 프로젝트에서 저장되는 정보(ex 회원정보, 상품 정보 등)가 어떻게 저장되는지, 다른 정보와 어떤 관계로 이어지고 있는지 등 각 테이블 간의 관계를 보기 위해 쓰입니다.
마치며...
오늘은 외주 개발 진행 시 문서화해야 하는 8가지에 대해서 알아보았습니다.
[기능 요구 정의서, 기능 명세서, WBS, 와이어 프레임/화면 설계서(스토리보드), 정보구조도(IA), 디자인 시안, 소스코드, ERD]
해당 문서의 경우 작성도 중요하지만, 이해할 수 있도록 작성되는 것 또한 중요합니다.
퍼니디어는 이러한 문서 작성 시, 개발자, 디자이너분들뿐만 아니라, 비 개발 혹은 비 디자이너분들이 보았을 때도, 해당 문서를 통해서 자신의 프로젝트에 대한 상황을 이해할 수 있도록 작성하기 위해 지속적으로 트레이닝 작업을 진행하고 있습니다.
저희 퍼니디어에서는 스타트업 전문 개발사로써 끊임없이 합리적인 방법으로 개발하는 방식을 연구하고
발전시켜 파트너 사에게 최고의 결과물을 제공할 수 있도록 오늘도 열심히 성장하고 있습니다.
퍼니디어는 함께 성장하고 발전할 파트너분들을 기다리고 있습니다.
