한빛미디어

스펙이 사람의 역량으로 명명되고 있는 시대, 그래서 더 다양하게 사양되는 단어이기도 합니다.

그리고 프로젝트를 성공으로 이끄는 소프트웨어 스펙 작성법으로 소프트웨어 스펙의 모든 것이 출간되었습니다.

개인적으로는 책 뒷면에 SRS 프로젝트를 망치기 전에 알았다면 좋았을 것들이 소제목이었거나, 앞 페이지에 수식어였다면, 좀 더 명확하게 다가오지 않았을까 생각도 해 봅니다. 하지만 결국은 프로젝트 성공인 것은 마찬가지 입니다.

소프트웨어개발사라는 그리고 개발자라면 항시 고민하게 되는 소프트웨어공학적인 접근과 실제의 괴리감입니다.

프로젝트가 우선이기에 스펙없이 개발을 하다가 돌이키거나, 유지보수에서 전체 소프트웨어를 뜯어고치는 경우는 책에서만이 아니라는 것이다. 그런면에서 이 책은 실제사례를 A사, B사 이렇게 표현하면서 이야기 하고 있습니다. 진단을 위한 실제 사례들을 다루어서 좀 더 현장감이 있다는 겁니다. 

실제로 많은 책들이 실제 다양한 사례들을 현장감있게 정리하는 것조차도 어려운 작업이고, 무엇보다 그래서 어떻게 해야 하는지를 독자에게 맡기는 경우가 많다는 것이다.  문제를 공감하지만 어떻게 약하다는 것이다. 하지만 스펙에 없을 때 등한시 했을 때 사례들과 문제점을 정리하고 스펙을 통해 가져올 수 있는 이점을 정리했고, 더 나아가 스펙을 작성하는 방법은 2부에서 상세히 다루고 있다는 것입니다.

어쩌면 전사적인 활동으로 가능한 일 일수도 있고, 단순히 일회성으로는 유지가 되지 않는 것도 사실입니다. 하지만, 필요에 의하여 하게된다면 보다 체계적으로 진행해야 하는 것이다. 그런면에서 가이드가 되어 줄 책이라고 봅니다. 

소프트웨어 스펙의 모든것

SRS 프로젝트를 망치기 전에 알앗다면 좋았을 것들, 부정적인 문장이지만 그래도 공감도할 수 있는 문장이다.

한빛미디어의 미리보기를 통해서 책의 내용을 참조할 수 있어서, 책의 어떤 내용인지 맛을 볼수 있습니다.

https://preview2.hanbit.co.kr/books/gkws/#p=1

SRS

SRS

SRS, SRS하는데 SRS가 몬가요?

Software Requrements Specification 소프트웨어 스펙, spec, 소프트웨어 요구사항을 분석하고 이를 정리해 작성하는 스펙 문서이다.

그럼 요구사항아인가요. 스펙하고 요구사항은 무엇이 다른가요? 책을 읽어보니 개인적으로 스펙 > 요구사항라고 생각이 듭니다. 

스펙의 구성, 3W

비즈니스 요구사항도 함께 작성이 된다는 것이다.

프로젝트 단계별로

그렇게 모든 것을 이야기 합니다.

프로젝트 성공을 위한 발걸음입니다.

책의 구성은 2부로 구성되어 있습니다. 1부 소프트웨어 스펙이란? 2부 SRS 작성볍

스펙 작성법 중

저자의 경력을 보면 실리콘밸리에서 시작되어, 국내 회사까지 두루 두루 경력이 스펙을 정리합니다. 그래서 단순히 이론에서 끝나지 않는 것 같습니다.

전체적으로 책도 잘 읽혀집니다. 저자가 개발자의 글쓰기에 대하여서도 언급했는데, 명확하게 내용이 들어와서 구성과 내용도 대단히 만목합니다.