Peter님 안녕하세요.
실제로 제가 다른 개발자들이 작성한 여러 SRS를 검토해보면 비기능요구사항이 주로 부실하게 작성되어 있더군요. 하지만 비기능요구사항이 SRS에서 더 중요하다는 것을 잘 인식하지 못합니다. 기능이 하나 잘못적힌 것은 일반적으로 해당 모듈만 수정하면 되지만, 비기능요구사항 하나 누락되거나 잘못 적힌 것은 시스템 전체를 다 뜯어 고쳐야할 정도로 큰 사건일 수 있습니다. 앞으로 블로그에서 이와 관련된 다양한 내용들을 다룰 계획입니다.

구차니님 안녕하세요.
말씀 하신 것처럼 처음부터 스펙을 완벽하게 다 정하고 프로젝트 끝날 때 까지 절대 바꾸지 않을 수는 없습니다. 그래서 어차피 바뀌니 대충 시작하는 것은 더 문제가 크죠.
개발자나 고객이나 모두 스펙에 대한 이식의 변화가 필요하겠죠. 또한 교육, 훈련과 경험 모두가 필요하고 1,2년에 해결될 문제는 아니라고 봅니다.

김경록님 오랫만입니다.
댓글 남겨주셔서 감사합니다. 항상 건강하세요.

Google에서 Software Requirements Specification으로 검색을 하면 여러 Template를 찾을 수 있을 겁니다. 하지민 Template 만 보고 제대로 적는 다는 것은 불가능합니다. 타이거우즈 골프채만 보고 타이거우즈처럼 골프치는 것을 흉내내려는 것과 같습니다.
소프트웨어에서 가장 어렵고도 중요한 것이 바로 무엇을 개발할지(스펙)을 적는 것이지요.

안녕하세요. 임수빈님
소프트웨어 공학은 배울수 없다고들 합니다. 즉 경험을 통해서 익힐 수 밖에 없다는 뜻. 하지만 배우는 것은 나중에 경험을 할 때 큰 도움이 됩니다.
그중에서도 가장 어려운 분야가 요구사항 분석입니다.
이론적인 것 만 가지고 실제 프로젝트에서 제대로 적기는 정말 어렵습니다.
열심히 배우시고 실전에 적용하시기 바랍니다.

구차니님 안녕하세요.
멀티플랫폼 개발을 하고 있다면 중요시 되는 비기능들이 더욱 많죠. 멀티플랫폼은 개발, 빌드, 테스트에 더 많은 시간은 들어가지만 익숙해지면 크게 문제 없지 않나요? 개발자에게는 좋은 경험이죠.

우울한딱따구리님 안녕하세요.
우리나라 고객들은 왠만하면 사인을 잘 안하려고 하지만, 그래도 회의록 작성하고 사인하고 사인하지 않더라도 배포만 하는 것도 나름 효과는 있죠. 계약할 때 SRS와 ATP를 첨부하는 외국과는 아직 거리는 멀죠.

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

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

구차니님 안녕하세요.
필요성을 느끼는 것이 첫걸음이고, 다음은 배워야죠. 대부분 선배들에게 배우지를 못하니 배우는데, 어려움이 있습니다.

A2님 안녕하세요.
협업은 기본인데, 그렇지 않게 생각하는 경우가 너무나 많습니다.

hangum님 안녕하세요.
사실 이런 경우 회사의 책임이 더 크다고 할 수 있죠. 그래도 결국 개발자와 회사 둘다 피해를 입죠.

zeous님 안녕하세요.
반갑습니다.

안녕하세요. Momo님
회사는 어쩔 수 없이 그렇게 되는 것이지요. 하지만 그렇게 반복되면 회사고 개인이고 둘다 미래가 없다는 거....

안녕하세요.
본의 아니게 그렇게 된 경우도 많습니다.

안녕하세요. 장성호님
과거의 가치가 더 높은 개발자들은 자칫하면 그것이 자신의 뒷다리를 잡고 있다는 것을 망각하기 쉽습니다.

안녕하세요. 농부님...
닭이 먼저냐 달걀이 먼저냐? 이슈네요. 개발자들이 일하기 열악한 환경인것은 사실입니다. 조금 더 나은 환경을 만들기 위해서 노력하려고 합니다. 힘내세요.

안녕하세요. 대한민국 개발자님...
물론 외국도 One man company는 혼자서 이런 걸 다하죠. 하지만 우리나라에서는 개발자가 수천명이어도 똑같이 이것들을 해야 한다는 것이 문제죠.
어떻게 협업을 해야 하는지 모르고 훈련도 안되어 있는 겁니다.
협업을 하기 위해서는 문서화, 프로세스, 시스템, 문화가 뒷받침이 되어야 하는데, 여기저기 구멍이 숭숭 뚤려서 제대로 하기 어려운 것이 현실입니다.
대기업들은 이것을 돈을 들여 프로세스와 시스템으로 해결하려고 하기도 하는데 문화가 뒷받침이 안되어서 어렵습니다.
이를 해결하려면 시간도 오래 걸리고 고난의 작업이 될 겁니다.

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

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

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

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

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

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

멋진 반전이네요.

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

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

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

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

감사합니다.