소프트웨어 요구사항 명세서 (기능명세서)에 대해서 알아보자

안녕하세요 시란입니다. 

이번시간에는 소프트웨어를 설계함에 있어 필요한 문서인 기능명세서에 대해서 알아보려고 합니다. 

프로젝트 처음 시작할 때 아무리 시간이 없다고 해도 필요한 문서가 2가지 있습니다 

문서의 양은 30~50페이지를 넘지 않는다. 

SRS 일명 Software Requirements Specification 과, SAD Software Architecture Document 입니다. 

 

그중 SRS에 대해서 얘기하려고 알아보겠습니다. 

SRS가 중요한것은 스펙을 정함으로써 모든 개발의 모든 분야 일정 예측, 설계 구현, 테스트의 기준이 되고 개발 진행 상황파악, 의사소통이 가능해집니다. 

 

소프트웨어 프로젝트에 있어 요구사항은 무엇을 하는 소프트웨어를 만들지 결정하는 단계입니다. 

요구사항을 작성하는 목적은 프로젝트의 범위확정, 비용 측정, 일정 관리, 문서화 등 다양한 활동을 지원하는데 있다. 

요구사항 분석 단계에서 나오는 최종 산출물은 요구사항 명세서입니다. 명세서에 포함되는 내용은 다양합니다. 시스템의 목표와 독자, 전체 기술 요약 , 프로젝트 제약조건 등이 서론으로 포함되고, 본문에는 자료 흐름도나 프로세스 명세서 ERD등이 포함됩니다. 

하지만 대부분 시간에 쫒기거나 비용에 쫓겨 문서화를 하지 않는 경우가 비일비재합니다. 

대부분은 시스템을 요약적으로 기술한 1-2장의 짧은 문서로 명세서를 대신하는 경우가 많으며 이런 모호함이 프로젝트 종료후 논쟁의 대상이 된다. (하지만 본인은 본인 회사의 시스템 개발이므로 해당되지는 않는다.)

아무튼 기능 명세서는 요구사항 명세에 들어가야 되는 내용 중 하나며, 이 기능 명세서 하나만 제대로 작성되어도 프로젝트를 성공적으로 이끌 수 있다. 

 

그렇다면 기능명세서는 무엇인가?

기능명세란 사용자 관점에서 최종제품이 어떤모습이며 어떻게 동작할 것인지를 기술한 문서를 말한다.

 최종 사용자의 입장에서 기술한 문서기 때문에 내부 구현 또는 설계 이슈는 포함되지 않습니다. 

기능명세는 이렇듯 무엇을 만들 것인지를 분명히 하는 문서라고 보면 됩니다. 

 

개발자 입장에서 기능 명세는 개발과정에서 궁금할 수 있는 모든 질문에 답을 해놓은 문서가 존재한다는 뜻입니다. 

또한 명세는 고객 혹은 최종 사용자의 승인을 받은 문서이므로, 명세만 따라서 만들면 고객이 실제로 원하는 프로그램을 만들수 있다. 분쟁의 소지도 줄어든다.  (본인의 경우 .. 회사가 곧 고객인 셈이므로.. 해당이 없다. )

참고로 기능 명세와 기술 명세는 전혀 다른 내용입니다. 기술 명세는 프로그램 내부 구현에 대한 기술입니다.  기술명세는 설계 및 구현에 직접적인 도움을 주기 위한 것이고 사용자 관점에서 시스템을 기술한 기능 명세와는 다릅니다. 

소규모의 개발조직에서의 프로그래머들은 기술 명세를 생략하는 경우가 많다. 왜냐하면 다들 아는 내용이기 때문이며 소규모 개발조직이기 때문이다.  하지만 기능 명세는 개발자뿐 아니라 다른 비개발자 또한 커뮤니케이션을 하기 위해서 필요한 문서입니다.

 

그렇다면 기술명세에 들어갈 내용은 무엇인가?

 

기술명세는 아래와 같은 요소들이 필요합니다. 특히나 이해가 잘 가능하도록 자세히 기술되어야 합니다. 

 

1) 시나리오: 기술명세는 철저히 사용자 관점에서 시스템을 바라본 것이므로 실제 사용자를 가정하고 시스템을 어떻게 쓸 것인지 시나리오를 작성하는것이 중요합니다. (다만 본인의 경우 회사 내부에서 컨펌이 가능하므로 이부분은 편할듯)

이때 시나리오는 유스 케이스가 될수도있고 유저 시나리오가 될 수 도 있다. 소프트웨어 방법론이나 프로젝트의 성격에 따라 어떤 방식을 선택해도 무관합니다. 아무튼 우너칙은 모든 기능을 한번 이상을 이용할 수 있도록 충분히 많은 시나리오를 작성해서 개발자가 시스템을 설계할 때 전혀 고려된 적 없는 시나리오가 없도록 해야합니다.  기능 명세의 시나리오에 테스트를 어떤 부분을 해야하는지 제공한다면 QC에도 도움이 될 것 입니다. 

 

2) 세부사항: 기능 명세를 작성하면서 세부사항은 정말 중요한 부분입니다. 특히 잘못될 가능성이 있는 경우에 대해서 모든 가능성에 대해서 꼼꼼히 명세를 작성해야 합니다. 또한 세부사항의 경우 UI를 중심으로 기능을 기술하는 것이 가장 효과적입니다.

특히!! 웹 기반인 경우 페이지를 기준으로 소프트웨어가 어떻게 동작하는지 설명하는 방법이 일반적입니다. 

모든 페이지에는 고유의 이름을 붙이고 각 페이지에서 나오는 메뉴와 UI 위젯이 어떤 역할인지 구체적으로 작성해야 합니다. 

 

3) 이슈체크: 명세를 작성하는 이유중 하나는 프로젝트 시작전에 최대한 많은 요구사항을 끌어내고 최종 산출물의 모습을 파악하는데 있지만 일부 문제의 경우 미해결 상태로 남아있게 됩니다. 이런 부분의 경우 기능 명세에서 분명히 기술해서 프로젝트가 진행되면서 해결해 나가야 합니다.

 

이렇게 기술명세서에 대해서 알아보았습니다. 

업무하시는데 참조 및 도움이 되었으면 합니다.

다음번에도 좋은 포스팅으로 찾아뵙겠습니다. 감사합니다.