요구사항정의서 작성 요령

출처: 요구사항정의서 작성 요령 및 생각 (tistory.com)

모든 프로젝트를 시작하기 전에 개발 요구사항에 대해 정리를 하게 됩니다.

SI에서는 특히 필요한 단계입니다. 요구사항 정의서 없이 개발을 바로 하게 되면, 개발 마지막 단계에서 상당히 고객과 트러블 및 골치 아픈 추가 요구사항이 쭉쭉 나오게 됩니다.

 

요구사항 정의서는 그럼 어떻게 작성해야 하는가?

사실 저도 개발자이지, 기획자가 아니라 요구사항 정의서를 어떻게 작성한다. 이렇게 작성해야 한다 딱 뭐라고 정의하지는 못하겠습니다.

단지, 이리저리 주서서 들은 내용과 실제 경험한 내용에 대해서 주절주절 적어보려고 합니다.

 

1. 요구사항 정의서 작성은 중요하다

일반적으로 기획자가 고객을 만나서 고객이 원하는 그림을 글로 정리하여, 요구사항 정의서를 작성하게 됩니다. 요구사항 정의서가 명확해야 디자인이 나오고, 실제 개발로 이루어지고, 고객이 만족할만한 개발 성과물로 이어지게 됩니다.

만약 요구사항 정의가 잘되지 않고 시작된다면, 중간에 디자인도 틀어지고, 최종 개발 성과물에서도 고객이 만족하지 못하고, 또한 고객이 만족하지 못하니, 추가 요구사항이 나오게 됩니다. 그 말은 곧 개발 데드라인도 같이 길어지게 됩니다.

 

2. 요구사항은 엑셀로 정리를 하자

최근 외주로 기획자를 섭외해서 했는데, 요구사항 정의서 없이 UI/UX기획서가 떡하니 나왔습니다. 요구사항 정의도 안되었는데 기획서가 나와서 놀랐습니다. 물론 제가 생각한 퀄리티도 아니었습니다. 고객의 요구사항도 제대로 정리가 안되었는데 UI/UX기획서가 잘 나올 리 만무합니다. 그래서 제가 다시 일일이 요구사항 엑셀로 정리하고, 그에 대해서 하나하나씩 고객에게 코멘트 의견을 부탁하였습니다. 엑셀로 정리하는 게 제일 편하였습니다.

아래와 같이 엑셀로 정리해서, 고객과 핑퐁 몇 번을 해보면 아주 깔끔해진 요구사항 정리가 된 문서가 나오게 됩니다.

요구사항정의서 샘플

칼럼은 다음과 같습니다.

• 개발 파트 구분 : 개발 담당하는 파트 (웹, API 서버, 앱, 기타 등등)
• 주요 기능 구분 : 큰 메뉴, 카테고리라고 생각하면 되겠습니다.
• 요구사항 ID : ID별로 정의 및 부여하여, UI/UX 기획서, 기능 정의서 등과 같은 다른 문서에서 쉽게 매칭되는 부분을 확인할 수 있습니다.
• 요구사항 설명서 : 요구사항에 대해서 자세히 풀어서 씁니다. 고객들이 먼저 쓰거나, 고객들에게 들은 내용을 나름대로 풀어쓸 수 있습니다. 해당 내용에 대해서 고객과 협의해서 쓸 수도 있습니다.
• 생성 일시 : 처음 작성한 날짜를 적어놓습니다
• 최종 변경 일시 : 요구사항 설명서는 계속 바뀌게 되면서, 최종적으로 바뀐 날짜를 적어놓습니다.
• 수용방안 : 정말 이대로 수용할지, 아니면 수정할지, 아니면 요구사항 자체를 빼버릴지 써놓습니다.

3. 요구사항 정의서는 기획자가 작성한다?

제목 그대로 요구사항 정의서는 기획자가 작성하는 게 맞습니다. 하지만, 기획 구분 없이 하는 게 대부분의 프로젝트입니다. 실제 외주를 주더라도 PM이라는 사람들이 기획을 맡는 사람도 있는데, 지금까지 받아본 기획은 정말 죄다 엉망진창이었습니다. 개인적으로도 기획은 중요합니다. 기획이 잘 나와야 디자인도 한 번에 끝나고, 개발도 개발만 하면 되는데 기획이 엉망진창이면 디자인도, 개발도 나중에 산으로 가는 꼴이 많았습니다. 아직 기획에 중요성을 모르는 사람도 많은 것 같습니다. 아무튼 기획은 기획자가 작성해야 합니다. 저도 개발자인지라 나중에 제가 만든 기획서를 확인해보면, 개발 편의 쪽에 치우치는 경향이 컸습니다. 또한, UI/UX 기획서를 만들 때에도 편의성을 중시하는 부분이 많이 빠져 있었습니다.

물론 개발자도 기획이 가능하나, 그 부분은 기능적으로 가능한지 불가능한지 판단에 대해서 의견을 주는 게 더 맞다고 생각합니다.

 

이상 요구사항 정의서 작성에 대해서 간단한 생각을 정리해보았습니다.