샘플만 보여주세요.

소프트웨어 개발에서 가장 어려운 것이 "요구사항분석"이라고 여러 차례 언급한 바가 있습니다.

요구사항을 분석하여 "스펙"으로 만들어서 적어 놓은 문서를 "SRS"라고 합니다.

그런데 SRS는 샘플이나 Template을 보고 잘 적는 것은 거의 불가능합니다.

개발자들은 원래 샘플 소스코드를 보고 많은 것들을 배워왔기 때문에 스펙도 샘플을 보면 잘 적을 수 있을 것 같은 착각을 하는 경우가 흔합니다. 샘플 소스코드가 도움이 되는 이유는 개발자들인 소스코드에 대해서는 이미 상당한 지식과 경험이 있기 때문입니다.

샘플만 보고 잘하려고 하는 것은 피아노를 잘 치고 싶다고 유명 피아니스트가 친 것을 몇 번 보고 피아노를 잘 치려 하는 것과 비슷합니다. 심지어는 지금 듣고 있는 피아노 연주가 잘 하는 것인지 못하는 것인지 판단하기도 어렵죠.

그래서 인터넷에서 구한 샘플이 별 도움이 안되거나 심지어는 방해가 되는 이유가 그것입니다. 좋은 샘플을 보여주면 일부 도움이 될 수는 있어도 큰 도움은 되지 못합니다. 나쁜 샘플을 만날지 어떻게 알겠습까? 아마 인터넷에서는 좋은 샘플을 구한다는 것은 거의 불가능할 겁니다.

타이거우즈 골프 스윙을 100번 보는 것보다 자신이 실제로 연습을 많이 하고 배우는 것이 더 빨리 배우는 길 일겁니다. 그렇지 않고 배우는 방법은 이미 선배들이 다 겪었던 시행착오를 자신도 그대로 겪는 방법이 있습니다. 자신은 시행착오를 겪지 않고 한번에 제대로 적을 수 있다고 생각하는 것은 자신의 능력에 대해서 대단히 너그럽게 생각하는 심리학적인 오류에 빠지는 것입니다.

비단 스펙을 적는 일뿐만 아니라 스키를 배우던, 발레를 배우던 모든 인생사가 다 비슷하지만 누구에게도 시행착오를 겪지 않는 행운은 찾아오지 않습니다. 책을 보고 공부를 하는 것도 많은 도움이 되지만 주변에서 경험자를 찾아서 도움을 받으세요. 주변에 자신을 도와줄 전문가가 있다면 그것이 행운입니다.

SRS(Software Requirements Specification)의 중요성

본 블로그에서 소프트웨어 개발, 소프트웨어 공학에 대한 여러 주제에 대해서 다루겠지만, 

특히 나는 요구사항 특히 SRS에 대해서 많이 다루려고 합니다.

"소프트웨어개발의모든것"이라는 책에서도 요구사항에 대해서 가장 중요하게 다루고 있지만 지면의 한계와 다양한 독자층의 눈높이를 맞추기 위해서 욕심보다는 많이 설명하지 못하는 측면이 있습니다.

그래서 소프트웨어 개발단계에서 가장 중요한 "요구사항"에 대해서 천천히 여러분들과 의견을 주고 받으면서 심도있게 다뤄볼까 합니다. 제가 세상의 모든 경우의 요구사항 분석 기술 및 경험이 있는 것이 아니니 여러분들과 토론을 하면서 또 많이 배울 것을 기대하고 있습니다.

먼저 제가 책에서 요구사항에 대해서 설명한 내용을 앞부분을 약간 소개할까 합니다.

요구사항 분석

소프트웨어 프로젝트에 있어서 가장 흔한 실수 중의 하나가 요구사항이 불명확한 상태에서 급하다는 이유로 일단 설계, 구현을 시작하는 일이다. 어떤 경우는 스펙문서가 아예 없는 상태에서 프로젝트를 진행하는 경우도 있다. 또는 간단한 요구사항 목록을 가지고 스펙이라고 착각하는 경우도 많다.

제대로 된 요구사항 개발 없이 프로젝트를 성공적으로 수행하는 것은 거의 불가능하다. 고객의 요구사항을 상세히 기술하였다고 해서 좋은 요구사항은 아니다. 고객도 자신이 원하는 것을 자세히 모르는 경우가 아주 흔하기 때문이다. 고객의 요구사항을 단순히 기술한 정도의 요구사항은 프로젝트 후반에 많이 바뀔 수 있는데, 요구사항 개발 시 간단히 해결할 수 있는 것을 프로젝트 후반이나 유지보수 시까지 와서야 처리함으로써 수십 배의 비용을 추가로 치르는 경우도 있다.

요구사항 개발은 단순히 요구사항을 옮겨 적는 일이 아니다. 요구사항을 수집하고, 분석하고, 정리하고, 리뷰하는 일을 반복하여 완성도를 높여가는 일이다.

책을 보고, 샘플을 보고, 템플릿을 이용해서 독학함으로써 SRS를 잘 쓰는 것은 거의 불가능하다. 책이 도움은 될 수 있으나, SRS를 제대로 쓰려면 제대로 된 회사에 가서 몇 년 동안 일하면서 배워야 한다. 때에 따라서는 전문가에게 컨설팅을 받는 것도 좋은 방법이다. SRS는 기능공처럼 기법에 따라 작성하면 되는 것이 아니라 인간의 판단이 핵심인 문서이기 때문에 작성이 생각처럼 간단하지 않다.

요구사항의 중요성

요구사항 문서는 프로젝트에서 작성하는 산출물 중에서 가장 중요하다. 요구사항 문서인 SRS는 소프트웨어 프로젝트의 기둥이다.

소프트웨어 시스템 구축에서 가장 어려운 부분은 무엇을 구축할 것인지를 정확하게 판단하는 것이다. 그러나 구현을 시작하기 전에 요구사항을 완벽하게 파악하는 것이 불가능한 경우가 많다. 그렇다고 해서 요구사항 개발에 소홀해서는 안 된다. 시간이 허락하는 한 최대 한도로 많은 정보를 파악하는 것이 좋다. 

잘못된 요구사항은 많은 재작업 비용을 필요로 한다. 재작업 비용은 일반적으로 전체 개발 비용의 30~50%에 이르는 것으로 알려져 있다. 요구사항 오류로 인한 재작업 비용은 전체 재작업 비용의 70~85%에 이른다. 잘못된 요구사항, 부족한 요구사항은 일정을 지연시키며 많은 추가 비용을 발생시킨다. (출처, Software Requirements, Karl E. Wiegers, Microsoft Press)

완벽하게 상세한 요구사항이 가장 좋은 요구사항은 아니다. 요구사항은 이해하기 쉽게 간결함을 추구해야 한다. 간결하지만 충분히 설계, 구현할 수 있어야 한다. 그리고 요구사항 문서는 모든 관련자가 충분히 검토해야 한다.

요구사항 오류는 개발 단계가 지나가면 갈수록 그 수정 비용이 기하급수로 증가한다. 유지보수 단계에서 요구사항 오류를 바로 잡으려면 요구분석 단계에서 바로 잡는 것보다 200배의 비용이 더 드는 것으로 알려져 있다. 충분히 검토하여 오류가 없는 요구사항을 만드는 것이 프로젝트를 성공으로 이끄는데 가장 필요한 핵심이다.

SRS란?

요구사항 분석 문서의 종류는 수없이 많다. 개발 방법론에 따라서 제시하는 요구사항 문서가 다르고, 그 개수도 다르다. 여기서 소개할 문서는 SRS이다. SRS는 이 책 전체에서 소개하는 많은 문서 중에서 가장 중요하다. 프로젝트를 성공으로 이끄는데 가장 중요한 핵심이기 때문이다. 만약 소프트웨어 프로젝트에서 문서를 딱 하나밖에 만들 시간이 없다고 하면 SRS를 만드는 것이 좋을 것이다.

SRS는 IEEE에서 만든 가이드와 표준 Template이 있다. 회사들마다 사용하는 Template이 약간씩 다르지만 문서이름, 목적, 취지는 전세계적으로 표준이라고 보면 된다. 소프트웨어 개발 회사라면 회사에 맞게 각자 커스트마이즈 된 SRS Template을 가지고 있어야 한다.