요구 사항, 요건 정리 작성 방법

스마트폰 앱이나 웹 사이트 개발을 진행하기 위해 어떤 사항을 개발해야 하는지에 대한 내용을 정리하는 것이 필요합니다. 세상에는 다양한 앱/웹이 있습니다. 그러므로 주어지는 제한된 시간과 인력으로 세상의 모든 앱의 기능과 화면을 개발할 수는 없습니다. 이러한 개발 내용을 정리하는 작업을 요건/요구 사항 정리라고 할 수 있습니다.

 

 

요건/요구 사항의 형태

 

요건/요구 사항은 개발되어야 할 기능이나 구성 화면의 내용이 될 수 있습니다. 또한 연동 시스템이나 개발 언어, 프로그램 솔루션 등 다양한 조건을 포함할 수도 있습니다. 특히 기존 사용하고 있는 시스템이나 앱/웹이 있고, 이와 연동이 필요하다면 그 조건이 더 세분화될 수 있을 것입니다.

 

그럼에도 요건/요구 사항의 대부분은 매우 구조적으로 구성되는 특성이 있습니다.

 

기본적으로 요건/요구 사항을 정리하는 과정에서 그 내용이 자연스럽게 구조화되기도 합니다. 또한 서비스 기획 또는 사업 기획의 과정을 통해 구조화될 수도 있습니다.

 

이는 자연스러운 사람의 사고의 결과이므로 기본적으로 요건/요구 사항 정리는 이 형태를 기반으로 작성하면 됩니다.

 

 

요건/요구 사항 정리

 

구조화된 요구 사항은 큰 카테고리에서 세부 카테고리로 분화되는 트리 구조를 가지게 됩니다. 이렇게 구조화되어 있는 요건/요구 사항을 정리해 보면 아래와 비슷한 형태로 정리가 될 것입니다.

 

요구 사항 정리 초기 모습

 

정리되는 요건/요구 사항의 내용은 크게 다음과 같은 분류로 정리될 수  있습니다.

• 앱/웹, 솔루션으로 사용할 기능의 내용과 방법
• 구현될 사용 화면
• 개발 또는 화면 구현 시 지켜야 할 기업 내부 규칙
• 개발 서버
• 운영 DB
• 프로그래밍 방식, 언어
• 프레임워크
• 운영 미디어 (웹 브라우저, OS 등)
• 모바일 대응 방식 (모바일 웹, 반응형 웹, 네이티브/하이브리드/크로스플랫폼 앱 등)  
• 연동 대상 및 규격
• 사용성 제한 조건 (반응 속도 및 트래픽 등)
• 보안

  

이에 외도 요건/요구 사항을 전달하는 기업의 사정에 따라 다양한 내용이 포함될 수 있습니다. 이를 일목요연하게, 알아보기 쉽게 정리하는 것이 가장 먼저 할 요건/요구 사항 정리 작업입니다. 

 

 

요건/요구 사항 상세화

 

이렇게 정리된 요건./요구 사항으로 작업이 완료되는 것은 아닙니다. 이렇게 정리한 이유는 개발해야 할 앱/웹 또는 시스템을 확인하기 위한 것뿐만이 아닙니다. 이 내용을 개발을 할 수 있는지 보완해야 할 부분은 없는지 확인을 하기 위해서입니다.

 

이에 대한 내용은 검토 부분에 정리합니다.

 

이렇게 검토된 내용까지 정리한 것을 가지고 다음의 요건/요구 사항 상세화 작업을 진행합니다.

 

여기서 요건/요구 사항 상세화 먼저 작업해야 하는 것이 있습니다.

• 개발자 협의
• 디자이너 협의
• 앱/웹 또는 시스템 구조 설계
• 기능 프로세스 설계
• 프로그래밍 설계
• DB 설계
• 디자인 아이덴티티 확인

 

위의 작업을 통해 정리된 내용을 검토 항목에 넣어서 요건/요구 사항을 이야기한 고객 또는 팀과 협의 완료해야 합니다.

 

똑같은 앱/웹/시스템이라도 어떻게 개발자를 구성했느냐에 따라, 어떤 개발자가 진행을 하느냐에 따라 개발 방식은 달라질 수 있습니다.

 

또한 고객이 개발 희망하고, 자신의 머리에 그리고 있는 내용과 실제 구현될 앱/웹, 시스템의 모습이 다를 수도 있습니다. 문제는 아무리 요건/요구 사항으로 전달된 개발 내용을 다 완료했어도 희망하고 머릿속에 그린 모습과 다르다 생각 들면 추가 개발 또는 수정 개발을 요구하게 될 수 있다는 것입니다.

 

여기에 추가로 개발이 진해되고 있는 가운데 갑작스럽게 생각이 나거나 확인된 기능 또는 시스템을 추가해 달라고 요구할 수도 있습니다.

 

이 경우 때로는 며칠 정도 더 노력하면 해결할 수 있는 것들도 있지만, 전체 앱/웹/시스템 설계를 뒤 흔드는 심각한 내용이 있을 수도 있습니다. 

 

이 또한 개발 방식과 코드, 디자인 아이덴티티 등에 따라 같은 사항이라도 다른 무게를 지닐 수 있습니다.

 

그러므로 요건/요구 사항 상세화를 통해 초기 요건/요구 사항에 표현되지 않은 고객 또는 해당 팀의 요구 내용을 끌어내어 협의되어야 합니다. 또한 개발 진행 시 요건/요구 사항에 뒤 따르는 개발 조건이 있는지도 확인하여 상세화 하지 않는다면 개발 도중 어려움을 겪어 될 수도 있습니다.

 

그러므로 요건/요구 사항 상세화는 일종의 고객과의 개발 대상에 대한 최종 협의이면서, 해당 프로젝트팀의 개발 전략을 수립하는 과정이기도 합니다.

 

     

요건/요구 사항 클로우징의 의미

 

요건/요구 사항은 개발될 앱/웹/시스템에 대한 정의이면서 제약입니다. 결국 요건/요구 사항이 모호한 경우 무엇을 개발해야 하는지에 대한 정의가 모호한 것이 되므로 프로젝트가 끝나지 않을 수도 있습니다.

 

그리고 부실한 요건/요구 사항 상세화는 개발이 진행되는 과정에서도 문제를 일으킵니다. 

 

일단 WBS(작업 분할 구조)가 모호해지므로 어떤 개발을 어떤 단계로 진행해야 하는지 애매해집니다. 이로 인해 개발자 인력 관리가 부실해져서 계획보다 더 많은 인건비가 들기도 합니다. 더하여 모호한 작업 단위 내용 구분과 선후 관계로 인해 개발이 지연되기도 하고 에러의 원인이 될 수도 있습니다.

 

개발 과정과 마지막에 이루어지는 테스트와 검수, 감리 있어서도 대상이 모호하므로 이것이 단순 형식에 치우칠 가능성이 큽니다.

 

사용성 테스트는 스토리보드를 활용하여 진행할 수도 있습니다. 그러나 요건/요구 사항에 대한 개발이 완료되었는지는 고객(또는 해당 팀)과 협의를 통해 클로우징 한 문서가 없다면 개발 마지막 시점 논란이 될 수 있습니다.

 

아무리 잘 만든 앱/웹 또는 시스템이라도 요건/요구 사항 내용이 없다면 완료되었다 할 수 없습니다.

 

그러므로 개발 프로젝트 초반 요건/요구 사항 클로우징이 없었다면, 끝나지 않는 개발을 하고 있는 것과 같습니다. 그래서 이런 프로젝트는 대부분 정치적, 영업적 이슈로 종료되고는 합니다.

 

 

요건/요구 사항과 스토리보드

 

스토리보드는 두 가지 시점으로 바라볼 수 있습니다. 하나는 사용자 시점입니다. 그리고 다른 하나는 개발자 시점입니다.

• 사용자 시점 - 이용할 화면을 중심으로 앱/웹/시스템의 이용 스토리를 전개
• 개발자 시점 - 개발되어야 할 앱/웹/시스템의 작동 스토리들 전개

 

이 두 가지 시점은 어느 것이 맞고 틀리다 할 수는 없지만 각각 스토리보드로써 장점과 단점을 가지고 있는 것은 분명합니다. 그럼에도 스토리보드라는 명확한 개발 진행의 가이드가 될 수는 있습니다.

 

문제는 스토리보드가 부실할 때입니다.

 

아무리 좋은 스토리와 구성 방식, 화면 디자인이 포함된 스토리보드라도 개발 요건/요구 사항과 일치하지 않은 일차적으로 해당 프로젝트에 적합하지 않은 스토리보드입니다.

 

이 요건/요구 사항과 스토리보드 내용이 일치하지 않는 상황은 스토리보드를 작성하는 기획자의 문제 때문에 발생한다 생각될 것입니다.

 

그러나 많은 경우 요건/요구 사항이 모호하거나 개발을 위한 필요 내용이 빠져 있기 때문에 나타나기도 합니다. 여기서 요건/요구 사항을 정리하는 개발자가 주로 기획자이므로 기획자의 문제로 귀결됩니다.

 

그러나 때로 요건/요구 사항을 정리하는 기획자와 설계, 스토리보드 작성 기획자가 구분되어 있는 프로젝트도 있습니다. 그리고 계약, WBS와 관리/감독 때문에 PM이 요건/요구 사항의 초안을 잡는 경우도 있습니다.

 

그러므로 요건/요구 사항과 스토리보드의 불일치를 단지 스토리보드 기획자만의 문제라 하기도 어렵습니다.  

  

중요한 사실은 요건/요구 사항 정리가 부실할 경우 스토리보드 작성도 부실해진다는 것입니다.