1. 요구 사항은 글 쓰기 이기 때문에
요구 사항을 작성한다는 것은 문서를 작성하는 것. 이것은 프로그래밍이 아닌 작문 능력을 필요
로 하는것. 특히 누구나 쉽게 이해할 수 있는 문서를 작성한다는 것은 많은 연습을 필요로 한다.
특히 개발자가 요구사항을 작성해야 한다면, 많은 어려움을 겪게 될 것.
프로그래밍 능력은 글쓰기와 많이 다른것
2. 고객의 요구사항이 구체적이지 않고, 추측해야 할 수 있기 때문
소프트웨어에 대한 요구 사항은 고객이 알고 있다. 그러므로 이를 작성하기 위해서는 고객을 만나
야 한다. 그런데 바로 소프트웨어를 개발할 수 있을 정도로 구체적으로 요구하는 고객들은 흔하
지 않다. 심지어는 자신이 원하는 것이 무엇인지 조차 잘 모르는 고객들도 있다. 이들로부터 요구 사
항을 도출하기 위해서는 많은 시간과 대화를 필요로 한다.
제일 난감한 고객은 그저 '잘 만들어 주세요'라고만 말하는 고객. 이런 경우에는 요구 사항을 어
쩔 수 없이 '추측'해야만 할 수도 있다. 문제는 개발 도중에 또는 마치고 나서 추측했던 요구사항
이 잘못 되었음이 판명될 가능성이 높다는 것. 고생해서 만들었음에도 불구하고 '잘 만들어 달
라'던 고객은 '이것은 저희가 원하는 게 아닌데요.'라는 대답할 수 있다는 것
3. open source는 있으나 open requirement는 없기 때문
요구 사항이 공개되는 경우는 극히 드물다는것.
이것은 공부를 하기 위한 목적으로 요구 사항 명세서를 구하는 것이 사실상 어려움을 의미
이것도 요구 사항을 배우기가 어려운 커다란 이유 중 하나
4. 요구 사항의 샘플은 도움이 되지 않기 때문
소프트웨어 공학에 종사하는 사람들은 요구 사항 샘플이 요구 사항을 작성하는데 도움이 되지 않는
다고들 말한다. 불완전한, 잘못 된 요구 사항들을 읽는 것이 좋은 요구 사항을 만드는데 오히려 방해
가 될 수 있기 때문
5. 국내 소프트웨어 조직들은 요구 사항이 아직도 낯설다.
아직도 우리 나라에서는 프로젝트를 시작할 때 바로 자리에 앉아서 코딩하는 것을 선호하는 개발자
들이 많다. 그런 경력을 쌓은 개발자들에게 요구 사항은 생소한 개념. 그들이 관리자가 되고 나서 요
구 사항에 대한 필요성을 느끼면 다행. 문제는 현실이 그렇지 않다는 것. 아직도 상당수의 소프트웨
어 개발 업체들은 문서화에 대한 필요성을 인식하지 못 하고 있다. 이러한 회사들이 소프트웨
어를 개발할 때 요구 사항 명세서부터 작성하는 경우는 드뭄.
또한 요구 사항을 어떻게 만들 수 있는지를 설명하는 또는 할 수 있는 사람들이 흔하지 않다는 점
