RD(요구 문서)의 프로페셔널리즘

소프트웨어 스펙의 모든것

QA 테스트는 SRS(소프트웨어 요구 스펙) 문서의 내용이 개발됐는지 검증하는 것이다. SRS는 PRD(제품 요구 문서)나 MRD(시장 요구 문서) 작성을 위한 제품 회의에서 비롯된다.

핵심이 되는 SRS. 33p. 소프트웨어 스펙의 모든것. 한빛미디어

SRS의 위치. 35p. 소프트웨어 스펙의 모든것. 한빛미디어

여기서 RD는 일반인의 요구사항을 기록한 문서이고 SRS(D)는 RD를 통합적으로 분석한 문서이다.

RD와 SRS(D)의 차이. 52p. 소프트웨어 스펙의 모든것. 한빛미디어

만일 PRD/MRD 가 모호하게 작성된다면 SRS의 불확실성이 커지고, 이는 다시 QA 테스트의 불확실성을 키운다. 각 단계의 불확실성은 비용 증가를 불러온다. 개발 진행 중 기획회의로 회귀하게 되면 추가 피쳐가 생기거나 기존 개발사항을 수정해야 한다. QA 테스트 중 기획회의로 회귀하게 되면 개발 추가/수정뿐만 아니라 관련된 테스트 자체를 처음부터 다시 해야 한다.

비용증가의 문제. 37p. 소프트웨어 스펙의 모든것. 한빛미디어

이런 상황에 배포일이 픽스되어 있다면 대처 방법이 있다. 일단 변경/추가 사항을 확인하고 그에 따른 주변에 미치는 영향을 평가한다. 이 평가를 근거로 해당 사항이 마이너 버전 관련 피쳐라면 기획문서에 빠진 부분을 정리해두되 다음 버전으로 넘기는 것이다. 하지만 메이저 버전 관련 피쳐라면 배포일을 미루고 기획으로 회귀해야 한다. 이를 나중으로 미루면 그 비용이 처음보다 훨씬 커진다. 그러므로 가급적 메이저 버전 기획과 관련된 부분을 놓치는 일은 없어야 모두에게 이롭다.

어떤 요구 문서도 완벽할 수 없다. 사람이 하는 일이기 때문이다. 그렇기에 더더욱 요구 문서 작성과 버전 관리는 중요하다. 문서는 상호 간 오해와 불신을 줄여주고 합리적인 미래를 협의할 수 있는 기반이 되어주는 유일한 매개체다. 각 분야의 프로페셔널에게 요구 문서 작성 능력은 그러므로 필수라고 할 수 있다.

덧,

책 ‘소프트웨어 스펙의 모든 것’의 4장 사례연구 중 ‘4.5 E사의 소프트웨어 개발_있는 것은 소스코드뿐’의 사례를 보면 오늘날 우후죽순 난립하고 있는 소규모 스타트업들이 VC로부터 시리즈 A 혹은 B 레벨의 투자를 받을 시 스케일업을 꽤 하며 공통적으로 겪는 상황을 보여준다. 주먹구구식으로 작은 소프트웨어를 개발하여 시장의 초반 인기를 얻은 후 스케일업 하지 못하고 방황하다 4-5년 사이에 자멸의 길을 걷게 되는데 기인하는 가장 큰 요인 중 하나가 바로 이 요구 문서의 부재임을 알 수 있다.

SRS와 프로젝트 성패. 39p. 소프트웨어 스펙의 모든것. 한빛미디어