<div id="readability-page-1" class="page"><div id="post-body-4720354133967973404" itemprop="articleBody"><p>
많은 회사에서 소프트웨어 프로젝트를 진행할 때 스펙 문서를 작성한다. 정확하게 말하면 스펙 문서라는 이름의 문서를 작성한다. 하지만 회사에서 작성한 스펙 문서를 살펴보면 진짜 스펙 문서인 경우는 매우 드물다. 이름만 스펙 문서이지 내용은 스펙이라고 부르기에는 뭔가 좀 다른 경우가 많다. 그 사례를 살펴보자.</p><h4>
문서 이름이 문제</h4>
<p>
일단, 스펙 문서라고 하여 여러가지 이름의 문서가 사용되고 있다. “기능명세서”, “요구사항 기술서”, “시방서” 등이 있다. 하지만 이런 문서를 보면 이름만 봐도 스펙 문서라는 생각이 안 든다. 왠지 스펙의 극히 일부분의 내용이 적혀 있을 것으로 생각되고 실제로 내용을 보면 이름에 걸맞게 내용도 반쪽짜리 또는 극히 일부의 내용만이 언급되어 있다. 나름 노력을 해서 스펙 문서라고 적어서 이를 토대로 프로젝트를 진행하지만 주먹구구식 프로젝트보다 약간의 진보가 있을 뿐 큰 차이는 없다. 스펙 문서는 이름도 중요하다. 누가 봐도 스펙 문서라는 것을 알 수 있도록 SRS라고 부르거나 Specification이라는 말이 들어간 이름을 쓰는 것이 좋다.</p><h4>
문서 내용의 문제</h4>
<p>
“기능명세서”, “요구사항 기술서”, “시방서” 등의 이름을 가진 문서들은 대부분 요구사항이나 기능에 집중된 내용이 들어 있다. 그래서 이런 문서는 “스펙”이라고 하기에는 반쪽짜리 문서다. 스펙 문서는 비전, 전략, 기능, 환경, 비기능, 시스템 특성 등 여러가지를 포함해야 한다. 또한 요구사항도 그대로 적는 것이 아니라 잘 분석이 되어서 여러 기능이나 비기능으로 분해가 되어 있어야 한다. 이런 분서에서 빠져 있는 내용은 프로젝트를 진행하면서 수많은 문제와 혼동을 야기할 것이다.</p><h4>
절차의 문제</h4>
<p>
“스펙” 문서라고 하면 일반적으로 인정하는 프로세스가 있다. 작성과 리뷰, 승인 과정을 거친다. 그래서 책임을 지고 작성하는 “분석 아키텍트”가 정해지고 프로젝트에서 적절한 분석 시간을 할당 받는다. 분석 활동으로 공식적으로 인터뷰, 워크샵, 관찰, 토론 등을 진행할 때 이해관계자들의 협조를 받으며 공식 리뷰에 많은 이해관계자들이 자신의 의무를 다하기 위해서 신중하고 꼼꼼하게 리뷰를 하고 승인을 한다. 승인에 대한 압박감도 상당하다. 우리는 “스펙”이라는 용어를 듣는 순간 이러한 프로세스도 거쳤을 것이라고 생각을 한다. 이런 절차 없이 개발팀에서 알아서 작성해서 진행을 하면 안된다.</p><p>

필자는 “스펙”, “소프트웨어 스펙” 또는 “SRS”라는 용어를 사용하길 권장한다. 이런 용어를 사용해서 대화를 한다면 서로 같은 의미로 소통을 하고 있을 가능성이 높다. 특히 외국인 개발자를 채용하거나 글로벌 업체와 협력을 하게 된다면 용어의 사용은 매우 중요하다. “스펙”, “SRS”라는 용어로 소통을 하고 문서를 작성할 때 외국 업체와의 협업이 더 원활할 것이다. 물론 용어만 쓴다고 되는 것은 아니다. “스펙”, “SRS”를 제대로 작성할 수 있어야 한다.</p>

</div></div>

All of Software

많은 회사에서 소프트웨어 프로젝트를 진행할 때 스펙 문서를 작성한다. 정확하게 말하면 스펙 문서라는 이름의 문서를 작성한다. 하지만 회사에서 작성한 스펙 문서를 살펴보면 진짜 스펙 문서인 경우는 매우 드물다. 이름만 스펙 문서이지 내용은 스펙이라고 부르기에는 뭔가 좀 다른 경우가 많다. 그 사례를 살펴보자.
문서 이름이 문제
일단, 스펙 문서라고 하여 여러가지 이름의 문서가 사용되고 있다. “기능명세서”, “요구사항 기술서”, “시방서” 등이 있다. 하지만 이런 문서를 보면 이름만 봐도 스펙 문서라는 생각이 안 든다. 왠지 스펙의 극히 일부분의 내용이 적혀 있을 것으로 생각되고 실제로 내용을 보면 이름에 걸맞게 내용도 반쪽짜리 또는 극히 일부의 내용만이 언급되어 있다. 나름 노력을 해서 스펙 문서라고 적어서 이를 토대로 프로젝트를 진행하지만 주먹구구식 프로젝트보다 약간의 진보가 있을 뿐 큰 차이는 없다. 스펙 문서는 이름도 중요하다. 누가 봐도 스펙 문서라는 것을 알 수 있도록 SRS라고 부르거나 Specification이라는 말이 들어간 이름을 쓰는 것이 좋다.
문서 내용의 문제
“기능명세서”, “요구사항 기술서”, “시방서” 등의 이름을 가진 문서들은 대부분 요구사항이나 기능에 집중된 내용이 들어 있다. 그래서 이런 문서는 “스펙”이라고 하기에는 반쪽짜리 문서다. 스펙 문서는 비전, 전략, 기능, 환경, 비기능, 시스템 특성 등 여러가지를 포함해야 한다. 또한 요구사항도 그대로 적는 것이 아니라 잘 분석이 되어서 여러 기능이나 비기능으로 분해가 되어 있어야 한다. 이런 분서에서 빠져 있는 내용은 프로젝트를 진행하면서 수많은 문제와 혼동을 야기할 것이다.
절차의 문제
“스펙” 문서라고 하면 일반적으로 인정하는 프로세스가 있다. 작성과 리뷰, 승인 과정을 거친다. 그래서 책임을 지고 작성하는 “분석 아키텍트”가 정해지고 프로젝트에서 적절한 분석 시간을 할당 받는다. 분석 활동으로 공식적으로 인터뷰, 워크샵, 관찰, 토론 등을 진행할 때 이해관계자들의 협조를 받으며 공식 리뷰에 많은 이해관계자들이 자신의 의무를 다하기 위해서 신중하고 꼼꼼하게 리뷰를 하고 승인을 한다. 승인에 대한 압박감도 상당하다. 우리는 “스펙”이라는 용어를 듣는 순간 이러한 프로세스도 거쳤을 것이라고 생각을 한다. 이런 절차 없이 개발팀에서 알아서 작성해서 진행을 하면 안된다.
필자는 “스펙”, “소프트웨어 스펙” 또는 “SRS”라는 용어를 사용하길 권장한다. 이런 용어를 사용해서 대화를 한다면 서로 같은 의미로 소통을 하고 있을 가능성이 높다. 특히 외국인 개발자를 채용하거나 글로벌 업체와 협력을 하게 된다면 용어의 사용은 매우 중요하다. “스펙”, “SRS”라는 용어로 소통을 하고 문서를 작성할 때 외국 업체와의 협업이 더 원활할 것이다. 물론 용어만 쓴다고 되는 것은 아니다. “스펙”, “SRS”를 제대로 작성할 수 있어야 한다.
share abctech.software

[Software Spec Series 11] 스펙 문서에 대한 오해

댓글