SRS(Software Requirements Specification)의 중요성
2008/11/19 10:32 by 전규현
All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.
RSS Feed
본 블로그에서 소프트웨어 개발, 소프트웨어 공학에 대한 여러 주제에 대해서 다루겠지만,
RSS Feed
특히 나는 요구사항 특히 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을 가지고 있어야 한다.
'프로젝트 > 요구사항분석' 카테고리의 다른 글
| 개발자들이 바글바글한 외딴섬에 떨어진다면 (20) | 2009/04/22 |
|---|---|
| 요구사항 분석의 출발점 (6) | 2009/02/12 |
| UI Mock-up (2) | 2009/01/21 |
| 샘플만 보여주세요. (0) | 2009/01/20 |
| 그냥 쓸 수 있겠네요. (2) | 2009/01/19 |
| SRS(Software Requirements Specification)의 중요성 (3) | 2008/11/19 |
Trackback Address: http://allofsoftware.net/trackback/21
-
2008/11/19 14:59SRS(Software Requirements Specification)를 작성할 때 유의할 점 Tracked from Younghoe.Info
-
2008/11/19 20:03소프트웨어 개발 방법론 Tracked from 녹차 프린스
-
2008/11/19 22:40요구파악과 사양정의 Tracked from Insight..
-
2008/11/24 11:30SRS는 유용한가.. Tracked from 상실의시대
-
2008/12/09 11:4411 Tracked from 『dK』‘s 나의 지식을 오픈하는 것은 나를 더욱 강하게 만드는 길이다. (아무개..)
좋은 글 읽었습니다. 궁금한 점
1. SRS가 독학으로 거의 불가능하다고 하셨는데 처음 누군가가 SRS를 작성했을 때는 누구에게 배웠을까요? 물론 처음 누군가는 폰 노이만이나 앨런 튜닝같이 천재겠죠? 그래도 완전 불가능한 것이 아니니까 연습하다보면 조금씩은 발전해 나갈 수 있겠죠.
2. SRS의 단위가 궁금합니다. 예를 들면 화면마다 하나씩 만든다라든지 모듈마다 하나씩이라든지 아니면 시스템마다 하나인지?
거의 3년된 포스팅 글이라 답변이 달릴지 궁금했는데 자세한 답변 감사합니다. SRS를 읽으니 이것이야말로 생존의 돌파구가 아닐까 싶은 생각과 막 배우고 싶은 생각이 듭니다. 지방의 SI를 하고 있어 기회가 없는 것 같아 안타깝네요. 친절하고 꼼꼼한 답변 감사합니다. 포스팅 된 글과 책 열심히 읽어 보겠습니다.
안녕하세요. 똘똘마리님
정말 재미있는 의문이네요. 골프나 피아노도 독학은 불가능합니다. 그럼 처음에 골프나 피아노를 친 사람은 누구에게 배웠을까요? 그 분야도 100년 넘게 진화를 해 온겁니다. 한사람이 정립한 것이 아닙니다. 이제 기술은 거의 완성이 되어서 과거나 지금이나 큰 차이가 없습니다. 배우는 방법이나 장비가 계속 발전하고 있을 뿐입니다.
SRS는 60년 소프트웨어 역사에서 소프트웨어 공학이 발전하면서 가장 중요한 것이 스펙이라는 것을 알아내면서 정립된 것이고 거의 완성된지 20년이 지났습니다. 20년동안 기술이 발전하면서 조금씩 바뀌었지만 큰 틀은 변화가 없습니다.
SRS의 틀은 혼자 만든 것이 아니고 20~30년 이상의 최고의 소프트웨어 개발자 수십명이 10년 이상 발전시켜나가면서 완성해 놓은 것입니다. 즉 소프트웨어를 개발할 때 꼭 정의해야 할 것들을 모두 적을 수 있는 틀을 만들어 놓은 겁니다.
폰 노이만이나 앨런 튜닝 같은 천재가 아니고 실제 소프트웨어 프로젝트를 많이 진행 해봤던 실전파 전문가들입니다.
몇가지 SRS Template들이 있지만 큰 틀은 같습니다.
SRS단위는... SRS는 기능명세도 아니고 화면정의서도 아니고 설계서도 아닙니다. 스펙입니다.
그래서 변역을 하지 않고 SRS라고 얘기를 해야 의미가 왜곡되지 않습니다. 외국 개발자들에게 SRS라고 하던가 스펙이라고 해야 의미가 통합니다.
소프트웨어의 스펙은 화면, 인터페이스, 기능, 비기능 등 모든 것을 포함합니다. 그래서 보통 프로젝트에서 하나를 작성합니다. 하지만 프로젝트가 매우 거대하면 쪼개서 작성하기도 합니다만 왠만해서는 그런 정도로 큰 프로젝트를 보기는 힘듭니다.
500MM 넘게 들어가는 프로젝트도 SRS하나면 됩니다.
궁금증이 해결 되셨나요? ^^