[소프트웨어 스펙의 모든 것] 2장 SRS

 

01 SRS란 무엇인가?

SRS는 specification 혹은 spec(스펙)이라고도 한다.

SRS에는 스펙을 작성할 때 생각하는 방법, 작성하는 프로세스, 기록해야 할 내용, 각 내용의 작성 가이드가 모두 수록된다.

 

02 어떻게 소프트웨어를 빠르게 개발할 것인가?

소프트웨어를 동시에 개발해 프로젝트 기간을 단축하려면 사전 단계인 분석, 설계가 정교하게 되어야 한다.

특히 컴포넌트를 잘 나누고 인터페이스를 견고하게 정의해야 한다.

인터페이스는 간결하게 정의해서 모듈 간의 연동을 쉽게 하고 확고하게 정해서 함부로 바꾸지 않도록 한다.

프로젝트 기간 내내 인터페이스를 잘 유지하기 위해서는 지속적인 통합이 필요하며 이를 위해서는 유닛 테스트, 테스트 자동화가 유용하다.

지속적인 통합을 위해 반드시 필요한 것은 주기적인 빌드다.

시스템 규모가 클수록 병렬 개발은 필요하다.

아키텍트는 복잡한 시스템을 최대한 간결하게 해서 시스템 개발과 유지보수 효율을 높여야 한다.

잘 분석, 설계된 소프트웨어라면 병렬 개발을 진행해 소프트웨어를 빨리 개발할 수 있다.

 

03 스펙 문서의 유형

무엇을 개발해야 하는지 명확하게 정의했다면 이슈 관리시스템의 한 줄 도는 몇 줄의 설명도 훌륭한 스펙이 될 수 있다.

엔지니어링 one-pager는 스펙을 작성하는 정식 절차를 밟기 위해서 작성한다.

수십 페이지의 SRS는 스펙을 작성하는 가장 일반적인 방법으로, 비즈니스 전략, 환경, 기능, 비기능, 성능 등 소프트웨어를 개발하면서 고려해야 할 대부분의 내용을 기술한다.

 

04 요구사항과 스펙의 차이

'요구사항'이란 말은 소프트웨어 업계 안팎에서 일반적 의미, 즉 고객이나 이해관계자가 요구하는 것으로 통용된다.

하지만 소프트웨어 '스펙'은 쓰는 사람에 따라 의미가 조금씩 다르다.

 

05 스펙 문서에 대한 착각

스펙 문서는 작성, 리뷰, 승인의 프로세스를 거치는데 이를 책임지고 작성할 '분석 아키텍트'가 정해지면 적절한 분석 시간이 할당된다.

 

06 스펙인 것과 스펙이 아닌 것

스펙에 포함되는 내용	스펙에 포함되지 않는 내용
프로젝트 비전	프로젝트 일정
비즈니스 전략	프로젝트 조직도
기능 요구사항	프로젝트 참여 인원
사용자 계층	개발자 확보 계획
하위 호환성	개발자 교육 계획
외부 인터페이스/시스템 인터페이스/유저 인터페이스	개발 프로세스
운영 환경/배포 방법	테스트 일정 및 계획
비즈니스 규칙	사용자 매뉴얼
설계 제약사항	국제화/번역 프로세스 및 일정
시스템 특성	빌드 자동화 계획
가정과 종속 관계	하드웨어, 소프트웨어 구매 절차 및 확보 계획
성능	상용 라이브러리 구매 계획

 

07 스펙과 프로젝트 일정의 관계

스펙을 잘 작성하면 프로젝트 종료 일정을 10~20% 오차 내로 정확하게 예측할 수 있다.

• 스펙을 프로젝트 특성에 알맞게 작성한다.
• 작업 내용을 세분화해 WBS를 작성한다.
• 프로젝트를 진행하면서 작업 세부 내용의 일정 예측, 실행, 일정 변경, 피드백을 꾸준히 수집해 경험치를 축적한다.
• 투입 인력에 따라 작업 수행 기간이 다르므로 이를 고려해 일정을 예측한다.
• 개발자 테스트 기간도 일정에 포함한다. 
• 유닛 테스트 작성 시간도 일정에 포함한다.

 

08 스펙과 설계의 구분

잘 분석된 스펙은 상당 부분 설계 영역까지 다루기 마련이다.

스펙을 작성하면서 구현 가능성 검증을 위한 프로토타입을 개발하게 되는데, 이때 개발한 프로토타입의 결과는 상당 부분 설계에 반영된다.

• 스펙과 설계는 명확하게 구분되지 않는다.
• 스펙에는 크고 작은 설계 내용이 포함된다.
• 스펙에 모든 설계 정보가 포함되는 것은 아니다.
• 스펙 작성 후에 별도의 설계 문서를 반드시 만들어야 하는 것은 아니다. 별도로 설계할지 스펙 문서만 가지고 구현할지는 프로젝트 특성에 따라 다르다.
• 설계 정보를 문서로 작성할지 소스코드로 작성할지도 프로젝트에 따라 다르다.
• 프로젝트에서 스펙 문서는 필수지만 설계 문서는 선택이다.