hoya님 안녕하세요.
CMMI도 결국 소프트웨어를 잘 개발하기 위한 것이 목적이므로 근본 원리는 같습니다.

구차니님 안녕하세요.
요구사항이 변경되면 그에 따른 영향평가가 따라야 하고, 계약이 변경되어야 하는데, 우리나라에서는 스펙따로 계약 따로이기 때문에 요구사항이 2배로 늘어도 계약은 변하지 않는 문제가 있죠.

스펙의 정의와 범위는 막연하지 않습니다. 구체적이지요. ISO나 IEEE에서도 정의가 되어 있습니다. 하지만, 소프트웨어나 프로젝트의 성격에 따라서 중요한 부분이 다르고 적당한 표현방식이 다르기 때문에 Template이 Sample을 보는 것은 도움이 된다기보다는 생각의 폭을 좁히고 사고를 고정시키기 때문에 도움이 안된다고 생각합니다. 또한 NDA에도 어긋나고요. 시간이 되면 저를 한번 방문하셔서 토론할 기회를 가지면 좋을 것 같습니다. 그런 기회는 언제든지 환영입니다.

오히려 설계가 제품마다 상당히 많이 달라서 더 정형화 시키기 어렵죠.

흠.. 그런 의미의 스펙을 말씀하신 거군요.
저는 고객의 요구사항에 따라 만들어지는 제품에 대한 스펙을 말씀하시는 줄 알았습니다. 제가 생각했던 부분은 어찌보면 설계서를 생각했었는데 그 상위 레벨 혹은 단계를 말씀하신 것으로 이해가 됩니다. 그렇다면 말씀하신 대로 문제가 발생이 되겠네요. 좋은 말씀 감사합니다.

곰아리님 안녕하세요. 스펙문서는 소프트웨어 개발방법론마다 다 Template이 있으니 Google에서 찾아보는 것은 그리 어렵지 않습니다. 하지만, 복잡한 개발방법론은 스펙과 연관된 문서가 너무 많고 복잡한 것이 문제입니다. 또한 Template을 보더라도 그 내용을 어떻게 채우는지 아는 것은 더 어렵습니다. 경험도 많이 필요합니다. 그래도 Template를 보고 싶다면, ISO나 IEEE에서 정의한 SRS문서를 보면 참조가 됩니다. Template만 보고 작성된 SRS를 보면 잘못된 내용을 적는 경우가 많더군요.

스펙을 쓰는 사람은 프로젝트마다 다를 수 있습니다. 스펙을 쓰려면, 고객의 요구사항을 잘 분석할 수 있어야 하고, 기술도 잘 알아야 합니다. 선임 개발자가 쓰기도 하고, 소프트웨어 분석가가 따로 있는 경우도 있고, 다양합니다.

일리가 있는 얘기네요. 문제는 스펙을 적는 방법을 잘모르고 경험이 부족한 것이겠지요. 하지만, 개발자들이 자신들이 쓸 소프트웨어를 스스로 만든다면, 그 필요성이 줄어들겠네요. 여태 그렇게 잘 만들어서 써왔고요.

멋진 반전이네요.

sheon님 안녕하세요. 그것도 좋은 방법이네요. ^^ 왠지 개발자들에게는 공통된 인식이 있는듯 하네요.

C-Thinker님 안녕하세요. 팀웍을 중요하게 생각하는 분이 좀 되는 것 같네요.

popopome님 안녕하세요.
스펙은 항상 소프트웨어 개발에 있어서 가장 중요하지만 어렵고, 스펙작성은 개발자들의 역량 중에서 가장 우선시 되곤하나 또한 익히기 어렵다고 알려져 있습니다. Scott의 커멘트를 보니 그사람의 경험과 생각을 미뤄 짐작해볼 수 있습니다. 그래서 절대적인 비교는 되지 않죠. 그러기에는 우리나라 개발환경은 기초가 많이 부족하거든요.

카페모카님 안녕하세요.
그렇게 할 수만 있다면 좋은 생각이죠. 가장 적은 비용으로 가장 좋은 제품이 나올 수도 있겠죠. 그리고 그 코더들도 시간이 흐르면 설계도 할고, 더 비싼일을 할 수 있겠죠.

감사합니다.

강규영님 안녕하세요.
좋은 정보 감사합니다.

안녕하세요. 똘똘마리님

정말 재미있는 의문이네요. 골프나 피아노도 독학은 불가능합니다. 그럼 처음에 골프나 피아노를 친 사람은 누구에게 배웠을까요? 그 분야도 100년 넘게 진화를 해 온겁니다. 한사람이 정립한 것이 아닙니다. 이제 기술은 거의 완성이 되어서 과거나 지금이나 큰 차이가 없습니다. 배우는 방법이나 장비가 계속 발전하고 있을 뿐입니다.

SRS는 60년 소프트웨어 역사에서 소프트웨어 공학이 발전하면서 가장 중요한 것이 스펙이라는 것을 알아내면서 정립된 것이고 거의 완성된지 20년이 지났습니다. 20년동안 기술이 발전하면서 조금씩 바뀌었지만 큰 틀은 변화가 없습니다.
SRS의 틀은 혼자 만든 것이 아니고 20~30년 이상의 최고의 소프트웨어 개발자 수십명이 10년 이상 발전시켜나가면서 완성해 놓은 것입니다. 즉 소프트웨어를 개발할 때 꼭 정의해야 할 것들을 모두 적을 수 있는 틀을 만들어 놓은 겁니다.
폰 노이만이나 앨런 튜닝 같은 천재가 아니고 실제 소프트웨어 프로젝트를 많이 진행 해봤던 실전파 전문가들입니다.
몇가지 SRS Template들이 있지만 큰 틀은 같습니다.

SRS단위는... SRS는 기능명세도 아니고 화면정의서도 아니고 설계소도 아닙니다. 스펙입니다.
그래서 변역을 하지 않고 SRS라고 얘기를 해야 의미가 왜곡되지 않습니다. 외국 개발자들에게 SRS라고 하던가 스펙이라고 해야 의미가 통합니다.
소프트웨어의 스펙은 화면, 인터페이스, 기능, 비기능 등 모든 것을 포함합니다. 그래서 보통 프로젝트에서 하나를 작성합니다. 하지만 프로젝트가 매우 거대하면 쪼개서 작성하기도 합니다만 왠만해서는 그런 정도로 큰 프로젝트를 보기는 힘듭니다.
500MM 넘게 들어가는 프로젝트도 SRS하나면 됩니다.

궁금증이 해결 되셨나요? ^^

거의 3년된 포스팅 글이라 답변이 달릴지 궁금했는데 자세한 답변 감사합니다. SRS를 읽으니 이것이야말로 생존의 돌파구가 아닐까 싶은 생각과 막 배우고 싶은 생각이 듭니다. 지방의 SI를 하고 있어 기회가 없는 것 같아 안타깝네요. 친절하고 꼼꼼한 답변 감사합니다. 포스팅 된 글과 책 열심히 읽어 보겠습니다.