[책] 소프트웨어 스펙의 모든 것

소프트웨어 스펙의 모든 것

 

소프트웨어 스펙의 모든 것은 SRS(Software Requirements Specification)이라고 하는 문서를 아주 심도있게 다룬다. SRS란 무엇인지, 왜 작성해야 하는지, 어떻게 작성하면 되는지 등 여러 예제를 통해 보여준다. 또한 성공한 프로젝트와 실패한 프로젝트에서 소프트웨어 스펙이 어떤 영향을 주었는지는 아주 흥미롭다.

프로젝트의 모든 이해관계자가 참조하는 SRS

아마 기획문서, 설계문서, 아키텍처, 메뉴얼 등 여러가지 이름으로 어쩌면 개발자 주변에 항상 있었을지 모른다. 하지만 SRS는 이것들과 분명히 다르고 별개의 문서로 취급되어야 한다. 책의 서미에 용어에 대한 정리를 보여준다. MDR(Market Requirements Document), MRS(Market Requirements Specification), PRD(Product Requirements Document), SOW(Statement Of Work), SDS(Software Design Specification), IRS(Interface Requirements Specification)과 구분해서 SRS를 공부하면 좋다. 그동안 추상적인 개념으로만 이해하고 있던 SRS를 이 책을 통해 확실히 정리하자. 그리고 현재 프로젝트를 진행하고 있다면 어떻게 적용할 수 있을지, 혹은 이미 적용하고 있다면 책에서 다루는 SRS와 어떻게 다른지 비교해보자. 아주 흥미로운 시간이 될 것이다.

스펙 1:10:100 규칙 그래프

SRS가 제대로 작성되지 않았을 때 프로젝트가 뒤로갈수록 얼마나 처참해질 수 있는지 아주 잘 보여주는 그래프다. 이걸 "스펙 1:10:100 규칙 그래프"라고 부른다. 비유하자면 개발 막바지에 기획이 바껴서 아키텍처를 통째로 수정해야 하는, 즉 근간을 흔드는 요청사항이 뒤늦게 들어왔던 경험은 개발자라면 누구나 한번쯤 있을거다. 책에서 인용한 프레드릭 브룩스의 어록을 살펴보자. 

"소프트웨어 개발에 있어서 가장 어려운 일은 개발 자체가 아니라 무엇을 개발할지 결정하는 일이다."

 

한편, 이 책은 다양한 예제와 함께 SRS를 설명하지만 마냥 모든 부분에서 좋은 책은 아니다. 개인적인 의견이지만 어딘가 모르게 설명에 단호한 어조가 부족한게 유일한 단점이다. 번역서가 아닌 한국에서 태어난 책이라 조금 기대가 컸는지도 모르겠다. 하지만 분명한건 개발팀 이외의 프로젝트 이해관계자와 소통하기 위해 우리는 반드시 소프트웨어 스펙을 준수해야 하며 교감할 수 있어야겠다. 이 책을 통해 SRS 배경지식을 쌓아두는건 어떨까? :) 

 

 

---

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.