요구사항 정의서, 왜 ‘살아있는 문서’여야 할까?

프로젝트를 진행하다 보면 반드시 작성하는 문서가 있습니다.

바로 요구사항 정의서(Requirement Specification) 입니다.

처음 프로젝트를 시작할 때 고객이 원하는 기능과 흐름을 정리하고,

개발사가 그것을 기준으로 설계와 개발을 진행하는 가장 중요한 약속 문서죠.

---

📍 그런데, 문제가 생깁니다

처음엔 고객이 이렇게 말합니다.

“이 기능은 꼭 필요합니다. 이 방식이 우리 회사 업무에 맞습니다.”

그래서 그 내용대로 개발이 진행되고, 시스템이 완성됩니다.

하지만 막상 운영 단계에 들어가면 상황이 달라집니다.

업무 프로세스가 조금 바뀌기도 하고, 사용자들이 실제로 써보면서 새로운 아이디어가 생기기도 합니다.

그러면 이런 얘기가 나오죠.

“그때는 이게 맞았는데, 지금은 다른 방식이 더 편리하네요.”

“여기 조금만 바꿔주면 훨씬 효율적인데요?”

즉, 요구사항 정의서에는 없던 변경 요청이 계속 발생하게 됩니다.

---

📍 고객과 개발사의 시각 차이

• 고객 입장:
• “업무가 바뀌었는데, 시스템도 같이 바뀌어야 하는 거 아닌가?
• 사용자가 편리하게 쓰도록 바꾸는 게 결국 도움이 되잖아?”
• 개발사 입장:
• “처음 약속한 요구사항대로는 다 만들어드렸습니다.
• 변경하려면 일정과 비용이 다시 필요합니다.”

이렇게 되면 서로 입장이 충돌하기 쉽습니다.

고객은 “융통성이 없다”고 느끼고, 개발사는 “끝이 없다”고 느끼죠.

---

📍 해답은 ‘살아있는 문서’

HJSoft는 이 문제를 요구사항 정의서를 고정된 문서가 아니라 ‘살아있는 문서’로 보는 것에서 풀어갑니다.

• 운영 중 발견되는 개선점을 적극적으로 반영할 수 있게 설계
• 변경 요청을 “사소한 수정 vs 신규 기능 추가”로 구분해 투명하게 협의
• 애자일 방식처럼 단계별로 점검하고 반영

즉, 처음 작성한 요구사항 정의서가 끝이 아니라, 시작점이라는 관점입니다.

---

* * 고객 가치 중심의 유연한 대응 **

프로젝트는 결국 문서를 잘 만드는 게 목표가 아닙니다.

고객의 업무가 더 편리하고 효율적으로 돌아가도록 만드는 것이 진짜 목표입니다.

그래서 HJSoft는 이렇게 생각합니다.

• “니가 처음에 요구했잖아, 못 바꿔요” → ❌
• “업무에 도움이 된다면, 합리적으로 조율해서 바꿉시다” → ✅

요구사항은 변할 수밖에 없습니다.

중요한 건 그 변화를 어떻게 관리하느냐이고,

HJSoft는 그 과정에서 고객과 함께 더 나은 길을 찾습니다.