효과적인 외주 개발을 위한 개발 요구사항 정의서 작성법

모든 애플리케이션은 아이디어로 시작하며, 모바일 앱 개발은 소프트웨어 요구 사항 사양(SRS) 정의하는 일에서부터 시작합니다. 뛰어난 창업 아이템과 아이디어도 물론 중요하지만, 그보다 더 중요한 건 아이디어를 실제 서비스로 구현하는 여정이기도 합니다. 그 여정 속에서 궁극적으로 서비스가 성공할지 실패할지를 판가름나기 때문입니다. 그 여정의 지도와도 같은 개발 요구사항 정의서는, 외주 개발 업체의 역량 이상의 가치를 가집니다.

개발 요구사항 정의서나, 명확한 계획 없이 외주 개발에 접근하면 혼란스러운 구현 프로세스, 비용이 많이 드는 재작업, 일정 지연, 심지어 프로젝트의 실패로 이어질 수밖에 없습니다. 모호하거나 불완전한 요구사항 정의는 외주 개발 비용 상승의 가장 흔하고 큰 이유이기도 하며, 완성 후에도 여러가지 이슈가 발생활 확률을 높입니다. 반면, 정확하고 이해하기 쉬운 개발 요구사항 정의서는 개발 과정에서 맞닥뜨리게 되는 미지의 문제를 피할 수 있도록 도와주며, 이를 통해 프로젝트의 성공으로 이어질 확률을 높여준다는 점을 우린 유념해야 합니다.

앱 개발을 위한 외주 개발 요구사항 정의서의 의미와 목적

개발 요구사항 정의서는, 프로젝트의 기능과 특징, 설계 및 제한사항을 비롯한 전체 목표를 설명하는 기술 문서입니다. 간단히 말해서, SRS는 애플리케이션이 어떻게 작동해야 하는지와 이를 위해 내부/외주 개발 업체가 어떻게 개발을 빌드해야 하는지를 설명합니다. 클라이언트 입장에서는 프로젝트의 기대치와 성과물을 정의하는 데 필요하며, 내부/외주 개발 업체는 작업량을 평가하고, 기술 스택을 정의하며 프로젝트 비용을 추정하는 데 필요합니다.

이 개발 요구사항 정의서에의 주요 목적은 개발의 모든 모호한 측면을 명확히 하고 팀에 다음 사항을 전달하는 것입니다.

• 앱은 어떻게 구축되어야 하는가

• 작동 방식(가능하면 사용 사례가 포함되어야 함)

• 앱의 목적, 기능 및 동작

특히 앱 개발을 외주로 진행해야할 때 개발 요구사항 정의서의 중요성은 더욱 크게 증대됩니다. 전체 프로젝트의 로드맵 역할을 하게 되어야 하는, 개발 요구사항 정의서는 혼란과 오해의 여지가 없어야 하며 명료해야 합니다.

외주 개발 요구사항 정의서에서 포함되어야 할 주요한 정보

개발 요구사항 정의는 내부/외주 개발 업체를 위한 지도이자 청사진으로, 요구 사항에 따라 도구를 빌드하는 데 필요한 모든 정보를 담아야 합니다. 이와 더불어 제품의 목적을 설명하고, 애플리케이션이 무엇을 해야 하고 어떻게 기능해야 하는지를 설명해야 하죠. 개발 요구사항 정의서 작성에는 명확한 정답이 있는 건 아닙니다. 프로젝트의 복잡도와 그에 수반된 개발 방법론에 따라 그 형식은 다를 수 있습니다. 그러나 프로젝트를 성공으로 이끄는 개발 요구사항 정의서에는 다음의 정보들이 명확하게 담겨 있습니다.

• 제품 및 서비스의 목적과 상세
  제품이나 서비스의 의도를 정의하는 명확하고 간결한 정보입니다. 요구 사항을 해결하고 앱 개발이 완료되면 이를 통해 무엇을 달성할 것인지 설명해야 합니다. 또한, 사용자를 비롯하여 제품이 작동할 환경 유형 및 앱 개발 프로세스에 영향을 줄 수 있는 기타 관련 정보를 포함하여 향후 도구에 대한 전반적인 개요를 제공합니다.

• 제품 및 서비스의 기능과 성능
  도구의 성능에 영향을 줄 수 있는 특징, 성능, 제한 또는 제약 사항을 설명합니다. 앱이 구동되는 환경에서의 성능과 관련된 요구 사항, 즉 속도, 효율성, 안정성 및 확장성이 포함되어야 합니다.

• 비기능적 요구 사항과 외부 인터페이스
  이는 보안이나 호환성, 그리고 유지 관리성과 같은 요소를 포괄합니다. 또한, 앱이 연결해야 하는 다른 시스템과 어떻게 상호 작용하는지에 대한 정보가 포함되며, 이를 통해 통신 프로토콜과 데이터 형식이 설명됩니다. 또한 화면 레이아웃, 로직 인터페이스, 하드웨어 인터페이스 및 설계에 대한 세부 정보를 간략하게 설명해야 합니다.

• 가정 및 종속성과 품질 속성
  가정 및 종속성은, 개발 요구사항 정의서 작성 중에 만들어진 전제와 프로젝트 계획 및 위험 평가에 중요한 외부 또는 타사 종속성을 나타냅니다. 품질 속성은, 소프트웨어 품질 측면에서 기대하는 사용성, 신뢰성, 접근성에 대한 기준을 정의합니다.

• 보안 프로토콜과 승인 기준
  소프트웨어를 무단 액세스로부터 보호하고 데이터 개인 정보를 보호하기 위한 보안 요구 사항을 설명합니다. 승인 기준은, 소프트웨어가 완성되어 출시될 준비가 되었는지 확인하기 위한 필수 작업 목록을 지정합니다. 여기에는 소프트웨어가 통과해야 하는 모든 테스트와 달성해야 하는 목표가 포함되어야 합니다.

외주 개발에 앞서 개발 요구 사항 문서를 작성하는 방법

창업 아이템의 구상을 마쳤거나, 기존의 제품에 새로운 신규 서비스를 더하고자 했을 때 가장 먼저 해야 하는 일은, 바로 개발 요구사항을 정의하는 작업입니다. 작성하는 것은 어려울 수 있지만 성공적인 앱 서비스를 구축하는 데 필수적이죠. 명확하고 명료한 개발 요구사항 정의서는 개발 작업을 간소화시킬 수도 있을 뿐더러, 이를 통해 외주 개발 비용을 효과적이고 효율적으로 사용할 수 있습니다. 정의서가 더 정교하고 자세할수록 외주 개발팀이 잘못된 방향으로 나아갈 가능성이 줄어들 수밖에 없기 때문입니다. 개발 요구사항 정의서 관련한 다양한 양식이 존재하지만, 정답은 없습니다. 가장 중요한 건, 나의 의도를 얼마나, 그리고 어떻게 구체적으로 담을 수 있느냐에 달려 있기 때문입니다. 때문에 세세한 양식에 얽매이기보다 공유와 설득에 용이한 전체적인 뼈대부터 시작하여 점차 세부적인 정보로 살을 덧대는 방향성만 유념한다면, 자신만의 효과적인 문서를 완성할 수 있습니다.

먼저 서비스의 뼈대와 프로젝트에 대한 일반적인 정보를 정의하는 것부터 시작할 필요가 있습니다. 아래 순서와 흐름대로 각자의 서비스에 수반되는 개발 요청사항을 정의해 보시기 바랍니다.

1단계. 개발 요구사항에 대한 개요 작성

첫 번째 단계는 문서의 프레임워크 역할을 하는 개요와 서비스 관련하여 세부 정보를 담는 틀을 만드는 작업입니다. 이 개요가 뼈대 역할을 함으로써, 이후 상세한 정보들을 붙여가며 전체 문서를 완성해 나가게 됩니다. 개요에는 다음과 같은 중요한 요소가 포함되어야 합니다.

• 소개

  • 목적

  • 사용 목적 및 대상 고객층

  • 제품 범위

  • 정의

• 일반적인 설명

  • 사업 요구 사항

  • 사용자의 요구 사항

  • 제품의 제한 및 제약

  • 가정 및 종속성

• 기능 및 요구 사항

  • 특징

  • 기능적

  • 외부 인터페이스

  • 비기능적

• 지원 정보

2단계. 앱 개발의 목적 정의

앱 개발의 목적을 정의하는 일은, 사실상 서비스의 목표와 이를 통해 이루고자 하는 바를 포괄합니다. 제품에서 무엇을 하길 원하는지, 어떻게 기능하길 원하는지에 대한 명확한 그림을 작성할 수 있습니다. 이를 위해 타겟 고객, 제품과 상호 작용하는 방법, 제품이 제공할 가치에 대한 자세한 설명을 담아야 하죠. 예컨대 다음 질문에 답할 수 있다면 명확한 목적을 작성할 수 있습니다.

• 당신의 제품 및 서비스는 어떤 문제를 해결합니까?

• 타겟 고객은 어떤 사용자입니까?

• 왜 당신의 제품 및 서비스가 중요하고 가치있나요?

이를 바탕으로, 각자의 창업 아이템이 타겟하고 있는 시장에서 어떤 입지와 가치를 창출할 수 있을지 생각해보게 됩니다. 나의 아이템이 다른 제품과 어떻게, 그리고 얼마나 다른지, 그리고 시장에서 어떻게 판도를 바꿀 수 있을지 가늠해볼 수 있습니다.

3단계. 서비스의 주요한 컨셉과 기능 정의

여기서는 창업 아이디어를 명확히 하고 타겟 고객에게 어필할 수 있는 이유를 설명하는 섹션입니다. 서비스 관련 주요한 기능을 설명하고 사용자의 요구에 어떻게 부합하는지 정의합니다. 또한 제품이 시장에 없던 제품인지, 혹은 기존 제품을 대체하는 제품인지, 독립형 앱인지 기존 시스템에 추가된 제품인지 등을 기술합니다. 이를 통해 제품을 특별하게 만들거나, 다른 제품과 차별화되는 점이 명확히 드러나야 합니다.

4단계. 기능적 및 비기능적 요구 사항 설명

종종 창업가, 혹은 클라이언트는 프로젝트 시작 시 의도된 기능에 대해 명확한 아이디어가 없는 경우가 많습니다. 이 경우 요구 사항을 명확히 외주 개발 업체가 이해하기 용이하도록 크게 두 카테고리로 나누어 설명하게 됩니다.

• 기능적 요구사항(Functional Requirements)

기능적 요구사항은 시스템이나 소프트웨어가 수행해야 하는 특정 기능 또는 작업을 정의합니다. 이는 사용자 또는 시스템의 행위와 관련이 있습니다. 기능적 요구사항은, 시스템이 특정 작업이나 기능을 어떻게 수행해야 하는지에 대한 세부적인 설명이나, 사용자가 시스템을 사용하면서 어떤 결과를 기대할 수 있는지를 정의하고, 시스템의 특정 동작이나 기능이 어떤 상황에서 어떻게 동작해야 하는지를 다루는 시나리오와 테스트 케이스를 포함합니다. 예를 들면, 사용자가 상품을 검색할 수 있는 기능이 있어야 한다거나, 장바구니에 상품을 넣은 뒤, 필요에 따라 삭제할 수 있어야 한다는 기능을 서술하는 작업입니다.

• 비기능적 요구사항(Non-functional Requirements)

비기능적 요구사항은 시스템의 품질, 성능, 보안, 유지보수 등과 관련된 요구사항으로, 시스템이나 소프트웨어가 어떻게 내부적으로 동작해야 하는지를 정의합니다. 이는 주로 시스템의 제약사항이나 특성에 관련이 있습니다.  시스템이 얼마나 빠르게 동작해야 하는지, 얼마나 많은 사용자를 지원해야 하는지 등 성능과 관련된 요구사항을 포함하며, 시스템이 데이터를 어떻게 보호할지, 접근 제어 방침 등의 보안 요구사항을 정의하고, 또 변경이나 업데이트를 어렵지 않게 받아들일 수 있도록 하는 요구사항을 포함합니다. 예를 들면, 온라인 쇼핑몰의 비기능적 요구사항의 경우, 웹 페이지 로딩 속도는 3초 이내여야 한다거나, 사용자 인증 정보는 안전한 암호화 알고리즘으로 보호되어야 하는 등의 작업을 정의해야 합니다.

5단계. 보충 세부 정보 추가

추가할 내용이 있거나, 개발자가 작업을 완료하는 데 도움이 될 수 있는 추가적인 아이디어나 제안, 요청자의 의도가 반영된 참조 자료 또는 기타 추가 정보가 있는 경우 추가 섹션을 두어 기재할 필요가 있습니다. 사용하고 싶은 기술에 대한 제안, 디자인에 대한 아이디어 또는 유사한 서비스의 사례를 포함하는 섹션이기도 합니다. 특정 기능에 대한 우선순위를 정의하고 개발팀이 유연성과 창의성을 발휘할 수 있는 영역을 강조할 수도 있습니다. 지나치게 많은 정보도 물론 지양해야겠지만, 최대한 자세한 내용을 기재할수록 소프트웨어가 기대에 더 잘 부합하게 될 수 있다는 점을 명심할 필요가 있습니다.

6단계. 승인 받기

5단계까지 마치게 되면, 이제 프로젝트 관련한 개발팀 및 다양한 이해 관계자가 요구사항 정의서를 주의 깊게 검토하고 의견이나 추가 사항이 있으면 남겨야 하는 작업이 남았습니다. 5단계까지 진행하며 발생한 수정사항을 업데이트 함은 물론, 이 과정에서의 모든 변경 사항을 내/외부적으로 공유합니다. 이 과정 후에 모두의 이해가 합의에 도달하게 될 때, 비로소 앱 개발 혹은 웹 개발을 시작할 준비가 된 셈입니다.

내부 / 외주 앱 개발에서 탁월한 개발 요구사항 정의서의 특징

정답은 없지만, 좋은 개발 요구사항 정의서에는 다음 항목과 같은 공통된 속성을 발견할 수 있습니다.

• 요구사항 정의서를 읽는 작업자(개발자, 디자이너 등) 중 어느 누가 읽어도 이해하기 쉽습니다.

• 예산과 기간, 현재 환경의 기술적 현실 등이 잘 반영되어 있습니다.

• 무엇을 어떻게 구현되어야 하는지 구조와 흐름이 명확합니다.

• 요구사항에 대해 정량적으로 측정 가능해야 합니다. 소프트웨어 요구 사항이 측정 가능하지 않으면 올바른 방향으로 가고 있는지, 팀이 마일스톤을 완료하고 있는지 알기 어렵습니다.

• 정의서 전체적으로 동일한 용어를 사용하여 혼선을 최소화하고, 하나의 요구사항에 여러가지(복수) 요구사항을 작성하지 않으며, 요구사항 간의 모순이 없습니다.

• 애매한 단어나 주관적 표현을 사용하지 않고 명확하게 기재되어 있습니다. 희망사항과 제안, 필수로 반영해야 하는 요소 간의 위계가 분명합니다. 꼭 필요하고 중요한 요구사항은 따로 표시하는 것이 좋지만, 모든 요구사항에 남발되지는 않아야 합니다.

• 난이도가 있는 기능이거나 프로젝트 기간이 짧아 모든 요구사항을 구현하기 어려울 상황일 경우, 대체 가능한 다른 방법도 함께 기술하여 전달합니다.

외주 개발 업체를 위한 요구사항 정의서를 작성할 때 피해야 할 일반적인 실수

앱 개발 혹은 소프트웨어 개발 요구 사항 사양을 작성할 때 피해야 할 실수들을 소개합니다. 앞서 언급했다시피 요구 사항 문서를 작성하는 정답은 없지만, 요구 사항이 매우 명확하도록 돕기 위해 피해야 할 가장 흔하고 대표적인 실수를 공유합니다.

첫째, 모호한 언어를 사용하는 것을 피해야합니다. 소프트웨어 요구 사항 사양은 오해를 방지하기 위한 것이므로 요구 사항에 혼동이 생기거나 모호하게 느껴지지 않도록 해야 합니다. 모든 기능에 대한 명확한 설명을 제공하고 다중적 의미가 있는 단어는 피하는 것이 좋습니다.

둘째, 정의서를 너무 복잡하게 만들지 말아야 합니다. 이를 위해 문서의 언어를 표준화함은 물론, 전문 용어 사용을 피하고 (필요 시) 특정 용어를 사용하기 전에 그 의미를 문서 내에서 정의하는 것도 좋습니다.

셋째, 정의서를 자세하게 작성하되, 요구 사항을 지나치게 구체적으로 지정하지 말아야 합니다. 필수 요구 사항에 집중하고 지나치게 많은 추가 세부 정보를 제공하지 마십시오. 이 경우 정의서를 읽기가 어렵게 되면서, 명확히 파악이 안됨으로써 가장 중요한 의도가 모호해질 수 있습니다.

효과적인 외주 개발을 위한 처음과 끝, 개발 요구사항 정의서

모든 앱 개발 프로젝트의 성공은 잘 작성된 개발 요구사항 정의서의 가용성에 크게 의존합니다. 이는 개발자와 이해 관계자를 위한 로드맵 역할을 하는 중요한 구성 요소로, 소프트웨어가 무엇을 해야 하는지, 기술적 세부 사항 및 사용자 요구 사항을 모두 포괄하여 설명하기 때문입니다.

포괄적인 개발 요구사항 정의서를 만들기 위해 꽤 많은 시간과 노력이 소요되만, 이러한 창업가/클라이언트의 노력이 전제되었을 때, 모두의 기대를 모두 만족시키는 앱이 개발될 수 있습니다. 개발 요구사항 정의서를 작성하는 과정에서 서비스를 전체적인 관점에서 내려다 보게 되고, 이를 통해 더 나은 대안, 혹은 부족한 점들을 발견할 수도 있습니다. 때문에 단지 내부 개발, 혹은 외주 개발 의뢰를 위한 단순한 문서가 아니라, 서비스에 대한 촘촘하고도 밀도 높은 이해를 돕고 기획의 빈틈을 찾는 수단으로 개발 요구사항 정의서를 더 넓게 정의하고 활용한다면 개발 이후 시간과 비용 모두 절약되는 효과 또한 함께 거둘 수 있을 것입니다.