특히 나는 요구사항 특히 SRS에 대해서 많이 다루려고 합니다.
"소프트웨어개발의모든것"이라는 책에서도 요구사항에 대해서 가장 중요하게 다루고 있지만 지면의 한계와 다양한 독자층의 눈높이를 맞추기 위해서 욕심보다는 많이 설명하지 못하는 측면이 있습니다.
그래서 소프트웨어 개발단계에서 가장 중요한 "요구사항"에 대해서 천천히 여러분들과 의견을 주고 받으면서 심도있게 다뤄볼까 합니다. 제가 세상의 모든 경우의 요구사항 분석 기술 및 경험이 있는 것이 아니니 여러분들과 토론을 하면서 또 많이 배울 것을 기대하고 있습니다.
먼저 제가 책에서 요구사항에 대해서 설명한 내용을 앞부분을 약간 소개할까 합니다.
| 요구사항 분석 |
소프트웨어 프로젝트에 있어서 가장 흔한 실수 중의 하나가 요구사항이 불명확한 상태에서 급하다는 이유로 일단 설계, 구현을 시작하는 일이다. 어떤 경우는 스펙문서가 아예 없는 상태에서 프로젝트를 진행하는 경우도 있다. 또는 간단한 요구사항 목록을 가지고 스펙이라고 착각하는 경우도 많다.
제대로 된 요구사항 개발 없이 프로젝트를 성공적으로 수행하는 것은 거의 불가능하다. 고객의 요구사항을 상세히 기술하였다고 해서 좋은 요구사항은 아니다. 고객도 자신이 원하는 것을 자세히 모르는 경우가 아주 흔하기 때문이다. 고객의 요구사항을 단순히 기술한 정도의 요구사항은 프로젝트 후반에 많이 바뀔 수 있는데, 요구사항 개발 시 간단히 해결할 수 있는 것을 프로젝트 후반이나 유지보수 시까지 와서야 처리함으로써 수십 배의 비용을 추가로 치르는 경우도 있다.
요구사항 개발은 단순히 요구사항을 옮겨 적는 일이 아니다. 요구사항을 수집하고, 분석하고, 정리하고, 리뷰하는 일을 반복하여 완성도를 높여가는 일이다.
책을 보고, 샘플을 보고, 템플릿을 이용해서 독학함으로써 SRS를 잘 쓰는 것은 거의 불가능하다. 책이 도움은 될 수 있으나, SRS를 제대로 쓰려면 제대로 된 회사에 가서 몇 년 동안 일하면서 배워야 한다. 때에 따라서는 전문가에게 컨설팅을 받는 것도 좋은 방법이다. SRS는 기능공처럼 기법에 따라 작성하면 되는 것이 아니라 인간의 판단이 핵심인 문서이기 때문에 작성이 생각처럼 간단하지 않다.
| 요구사항의 중요성 |
요구사항 문서는 프로젝트에서 작성하는 산출물 중에서 가장 중요하다. 요구사항 문서인 SRS는 소프트웨어 프로젝트의 기둥이다.
소프트웨어 시스템 구축에서 가장 어려운 부분은 무엇을 구축할 것인지를 정확하게 판단하는 것이다. 그러나 구현을 시작하기 전에 요구사항을 완벽하게 파악하는 것이 불가능한 경우가 많다. 그렇다고 해서 요구사항 개발에 소홀해서는 안 된다. 시간이 허락하는 한 최대 한도로 많은 정보를 파악하는 것이 좋다.
잘못된 요구사항은 많은 재작업 비용을 필요로 한다. 재작업 비용은 일반적으로 전체 개발 비용의 30~50%에 이르는 것으로 알려져 있다. 요구사항 오류로 인한 재작업 비용은 전체 재작업 비용의 70~85%에 이른다. 잘못된 요구사항, 부족한 요구사항은 일정을 지연시키며 많은 추가 비용을 발생시킨다. (출처, Software Requirements, Karl E. Wiegers, Microsoft Press)
완벽하게 상세한 요구사항이 가장 좋은 요구사항은 아니다. 요구사항은 이해하기 쉽게 간결함을 추구해야 한다. 간결하지만 충분히 설계, 구현할 수 있어야 한다. 그리고 요구사항 문서는 모든 관련자가 충분히 검토해야 한다.
요구사항 오류는 개발 단계가 지나가면 갈수록 그 수정 비용이 기하급수로 증가한다. 유지보수 단계에서 요구사항 오류를 바로 잡으려면 요구분석 단계에서 바로 잡는 것보다 200배의 비용이 더 드는 것으로 알려져 있다. 충분히 검토하여 오류가 없는 요구사항을 만드는 것이 프로젝트를 성공으로 이끄는데 가장 필요한 핵심이다.
| SRS란? |
요구사항 분석 문서의 종류는 수없이 많다. 개발 방법론에 따라서 제시하는 요구사항 문서가 다르고, 그 개수도 다르다. 여기서 소개할 문서는 SRS이다. SRS는 이 책 전체에서 소개하는 많은 문서 중에서 가장 중요하다. 프로젝트를 성공으로 이끄는데 가장 중요한 핵심이기 때문이다. 만약 소프트웨어 프로젝트에서 문서를 딱 하나밖에 만들 시간이 없다고 하면 SRS를 만드는 것이 좋을 것이다.
SRS는 IEEE에서 만든 가이드와 표준 Template이 있다. 회사들마다 사용하는 Template이 약간씩 다르지만 문서이름, 목적, 취지는 전세계적으로 표준이라고 보면 된다. 소프트웨어 개발 회사라면 회사에 맞게 각자 커스트마이즈 된 SRS Template을 가지고 있어야 한다.
