기능명세서의 적용

 

오늘 간단한 미팅을 통해서 요구사항명세, 기능명세에 대한 이야기를 나누었는데, 매우 유익한 시간이었다고 생각합니다.

주요한 개발 산출물인 위의 2가지 명세에 대하여 역시나 각자의 생각의 정도나 활용의 목적도 다른 부분이 많았고,

이를 통하여 어느 정도 우리 조직에 맞는 공통된 언어를 사용하는 것은 개발에 큰 힘이 될 것으로 생각합니다.

오늘을 기점으로 저희 팀원 모두가 명세서 작성에 있어서 좀더 관심을 가지고 의미있는 산출물이 나올 수 있었으면 합니다.

금일 미팅을 진행하면서 사실 저도 제가 알고 있는 개념들에 있어서 정확하게 정의하지 않고 혼돈스럽게 이해한 부분들이 있었음을 느꼈습니다.

걍 습관적으로 하다보니 개념적으로 이해하기 보다는 기계적으로 혹은 느낌으로 적용하였던 것들이 있었고,

개념적으로 다시금 정리하고 정확히 정리된 개념들이 몸으로 체득되어 다시 “기계적으로 적용”될 수 있도록 노력해 보겠습니다.

다시 잡아야 할 개념들:

금일 회의가 끝나고 생각해 보니까 제가 지속적으로 언급했던

“Implementation의 구체적 사항을 제외한 나머지 세부 구현 기능을 열거하는 문서”의 정체는

요구사항명세가 아니라 기능명세서 입니다.

제가 잘못 개념잡고 있었던 큰 이유는 “요구사항명세는 기능 명세를 포함한다”라는 사실 때문이었습니다.

엄격한 의미의 요구사항명세서는 상세기능명세서를 한 꼭지로 포함하는 상당히 큰 범주의 보통은 분량도 좀 많은 문서로서

과제의 목적, 관련된 용어 및 개념, 사용자 특성, 제약 사항, 가정 및 의존성, 상세 기능, 유스케이스 분석 등이 포함됩니다.

(샘플문서는 이거를 한번 참조해보심이… 눈에 참 익은 포맷인데, 다시는 쓰고 싶지 않은 괴물과 같은 놈이지요.)

PDPv2.0은 이러한 무거운 요구사항명세서를 지양하기 때문에,

요구사항명세서의 일부인 기능명세서를 충실히 작성하는 것만으로도 과제 진행에 충분하다고 생각됩니다.

(이 시점에서 PDP의 요구사항 템플릿을 보면 요구사항명세서라고 하지 않고, “요구사항목록”이라고 정의하고 있습니다.

고객이 요구한 주요 기능을 열거하는 것이 목적인 듯 합니다.)

어떻게 적용할까 :

1. 요구사항목록(요구사항명세서가 아닙니다) 문서를 통하여 고객이 요구하는 주요 기능들을 열거합니다.
이를 통하여 시스템이 이루고자 하는 방향성을 잡을 수 있을 듯 합니다. 주요 요구 기능이 적은 플랫폼 입장에서는 그닥 쓸모있는 문서가 되지는 않겠습니다….
필수적인 문서일 필요는 없을 것 같습니다. 되도록 이면 과제 계획 단계에서 PM이나 팀장이 작성하는 것으로 하는게 좋을 듯 하네요. ( --> 아래 댓글에 요구 사항 목록에 대한 제 회의감을 피력했습니다.)

2. 기능명세서는 Acceptance Test가 가능한 레벨의 Complete한 set으로 작성합니다. 개발자 뿐만 아니라 고객이나 QA입장에서도 의미 있는 내용이어야 하며, 지속적인 변경이 있을 수 있습니다.
이 부분은 구현을 담당할 개발자가 고객이 요구한 명시적 기능과 시스템에 요구되는 암시적 기능을 포함하여 작성하여야 겠습니다.

3. 스크럼의 product backlog는 2번에서 작성한 기능명세 개념을 기반으로 작성합니다. product backlog는 기능명세서와 동급의 문서이며 이를 작성하는 경우에 기능명세서를 대체할 수 있습니다.

4. 스크럼의 sprint backlog는 product backlog에서 해당 sprint에서 구현할 목록을 추출한 subset이 되는 것을 기본으로 합니다. 추가적으로 세부 구현 사항을 언급하기 위하여 product backlog의 항목을 분해할 수도 있습니다.

[출처] 요구사항명세와 기능명세의 줄타기...|작성자 스탤론