Proven by Intelligence

MDS인텔리전스는 PTC사의 Codebemaer 사업을 담당하고 있으며 Codebeamer의 국내 초기 구축

부터 함께한 파트너로서, 국내 최대 ALM 구축 레퍼런스를 가지고 있습니다. 

​이번 포스팅에서는 PTC 공식 사이트에서 요구사항과 관련한 좋은 콘텐츠가 있어 공유 드리고자 합니다.

모든 연구의 시작점인 프로젝트의 필수사항! ‘요구사항 관리’의 8가지 Tip

​

요구사항을 잘 작성하는 것은 성공적인 프로젝트와 실패한 노력 사이의 성패를 가르는 요소가 될 수 있습니

다. 요구 사항을 잘못 작성하게 되면 그로 인해 개발 비용, 지연 뿐만 아니라 기타 예상하지 못하는 상황들이

발생할 수 있습니다. 그 이유는 종종 프로젝트가 이미 시작된 후 프로젝트의 범위가 제어되지 않는 방식으로 

변경되어 그 범위가 커져버릴 수 있기 때문입니다. 

프로젝트의 범위가 처음부터 명확한 요구 사항 작성에 의해 잘 정의되어 문서화 되어있지 않은 경우, 모두가 

아시는 것과 같이 현업 실무자들이 가장 영향을 많이 받게 됩니다. 

​

이러한 과부하가 걸리지 않도록 요구사항에 대해 명확하게 정의 내려야 하는 것이 프로젝트 성공의 시작이

라 할 수 있겠습니다.

​

요구사항 관리의 중요성

성공을 위한 제품 또는 프로젝트 설정의 핵심은 요구 사항을 최대한 효과적으로 작성하고 관리하는 것입니

다. 효율적인 요구 사항 엔지니어링에는 브레인스토밍, 문서화, 분석 및 간소화된 방식으로 요구 사항의 우

선 순위를 지정하는 작업이 포함됩니다. 

또한 프로젝트에 관련된 모든 사람이 변경 사항을 추적할 수 있도록 모든 팀 구성원과 이해 관계자 간의 커뮤

니케이션을 지원하기 위해 요구 사항을 추적할 수 있어야 합니다. 

이러한 단계를 주의 깊게 따르면 프로젝트 목표가 달성될 가능성이 높아집니다.

요구사항 작성 시 흔히 발생하는 실수

요구 사항 관리 프로세스를 시작할 때 첫 번째 단계는 요구 사항 백로그를 만드는 것 즉, 요구 사항을 기록하

는 것입니다. 

이는 사용자 요구 사항을 개발자에게 전달하거나 번역하는 주요 방법으로 이 요구 사항 모음은 모든 팀 구성

원, 개발자 및 이해관계자 간의 커뮤니케이션을 지원하고 조직이 엄청난 비용을 절약하는 데 도움이 됩니다. 

​■ 실수 예시 

  I.  부정확하거나 일관되지 않은 용어 사용 

  II. 문법 실수 

  III. 너무 모호하거나 애매한 정의 

  IV. 너무 구체적이고 장황한 묘사 

  V.  잘못된 가정 생성 

  VI. 필요한 것 대신 구현하는 방법을 설명

이렇듯 요구 사항을 작성하는 것은 기술적으로 어렵지는 않지만 작성 과정 중 위와 같은 실수가 빈번하게 일

어나기 때문에 신중하게 접근해야 합니다.

​

요구사항에는 무엇이 포함되어야 할까요?

요구 사항 엔지니어는 세부 사항에 주의하여 가능한 최선의 방법으로 요구 사항을 구조화하고 이를 표현, 제

시해야 합니다. 이상적으로 모든 요구사항 설명(사용자 관점)은 다음을 충족해야 합니다. 

1. 사용자 역할 포함 

2. 사용자가 요구 사항을 통해 어떤 이점을 얻을 수 있는지 설명 

3. 요구 사항이 달성하는 데 도움이 되는 원하는 상태를 간략하게 설명 

4. 해당되는 경우 요구사항 테스트를 허용하는 측정항목 포함 

일반적으로 다음과 같은 요구사항 예시와 같아야 한다는 것입니다. 

예시)  '사물'은 '원하는 결과'를 달성하기 위해 '무언가'를 제공/수행해야 합니다.

​

요구사항 관리를 위한 8가지 TIP!

효과적으로 요구사항을 작성하기 위해서는 다음의 사항을 확인하여야 합니다.

1)  Necessary (필요성)

   I.  우리는 무엇을 할 것인가? 

   II. 우리는 왜 그런 일을 하는 걸까?  

   III.누가 혜택을 받는가?  

​

위의 질문에 대한 답을 쉽게 찾을 수 없다면 ? 

사용자의 요구 사항을 완전히 이해하지 못했을 가능성이 높습니다. 결과적으로 실제로 필요하지 않은 요구

사항을 포함하게 되어 과도하게 크게 설정될 수 있기 때문에 필요한 내용에 대해서 명확한 정의를 내릴 필요

가 있습니다. 

​

2)  Clear (명확하게) 

요구사항이 실제로 필요하다는 것을 확인한 후 다음 단계로, 가능한 명확하고, 직접적이며, 모호하지 않게 하

는 것에 포커스를 맞춰 진행합니다.

​

예를 들어 간단한 문장은 ‘그것을 읽는 모든 사람이 같은 방식으로 그 의미를 이해할 수 있는 정도’로 명확

해야 합니다. 이를 달성하기 위해서 요구사항을 표현할 때 피해야 할 필수 조건은 다음과 같습니다.

​

  I.  수동태 사용

  II.  전문 용어, 전문 용어, 약어, 두문자어 또는 널리 이해되지 않는 용어 (어떤 이유로든 피할 수 없는 경우, 

      용어집에 포함시켜주세요.) 

   III.  다양한 의미로 해석될 수 있는 부사 (모호한 단어) 

   IV.  '해서는 안 되는' 일을 설명하는 부정적인 문구 (대신 무엇을 해야 하는지 설명해주세요.) 

   V.  그 외 테스트하고 검증하기 어려운 모호한 표현 

​

3)  Concise & Consistent (간결하고 일관적이게)

가능한 최고의 가독성을 위해 짧게! 요점만! 생각해 요구사항을 작성하세요. 

이 간단한 포인트 만으로도 이해관계자와 개발자가 프로젝트 요구 사항을 훨씬 쉽게 구성, 이해, 분석

할 수 있습니다. 요구사항은 가능한 한 간결해야 하며 필요한 정보를 완전히 전달할 수 있어야 합니다.

요구사항을 파악할 때 일관되지 않은 용어를 사용하면 혼란, 실수 및 지연이 발생할 수 있습니다. 프로젝

트 시작 부분에 프로젝트 용어집을 만들어 용어를 정의하면 모든 사람이 같은 내용을 이해하는 데 도움이

 됩니다. 

모든 용어가 나열되어 있는지, 서로 모순되지 않는지, 사용자와 개발자의 언어가 일치하는지 확인하세요. 

​요구 사항을 작성하는 동안 이 용어집은 기준점으로서 모든 이해 관계자가 일관성 있게 참고할 수 있습니다.

​

4)  Accurate (정확하게)

정확함을 강조하는 것은 반복하여 설명할 가치가 있습니다. 

요구 사항이 필요하다고 가정한다고 해서 그 가정이 실제로 정확하다는 의미는 아닙니다. 요구 사항에 포함

된 정보가 정확한지, 그리고 명시된 가정이 올바른 지 항상 확인해야 합니다.

​

5)  Feasible (실현 가능성)

요구 사항의 가정이 올바른 지 확인한 후에는 기술적으로 실현 가능한 지 확인해야 합니다. 먼저 프로젝트 

예산과 일정을 살펴본 다음 사용 가능한 리소스를 살펴 실현 가능여부를 판단하세요. 

요구사항이 현재의 조건에 실제 구현되도록 설정하는 것을 목표로 합니다.

​

6)  Prioritized (우선 순위)

요구사항은 각 유형별로 구분한 이후, 우선 순위를 지정해야 합니다.

주로 기능적, 비 기능적, 비즈니스적, 시스템적으로 나뉘어지는 요구사항 유형의 분류는 이해관계자의 판단

에 따라 우선 순위를 지정하고 프로젝트의 범위와 실행 일정을 준수할 수 있도록 하는데 도움이 됩니다.

​

7)  Verifiable (검증 가능성)

요구사항을 구성할 때 염두에 두어야 할 또 다른 사항은 요구사항이 검증 가능해야 한다는 것입니다. 시스

템이 문제의 요구사항을 충족하는지 보여주기 위해 테스트할 수 있어야 합니다. 이는 요구사항이 가능한 

한 명확하고 모호하지 않아야 하는 또 다른 이유이기도 합니다. ​

예를 들어, '최대화' 또는 '최소화', '쉽다', '유연하다', '안전하다'와 같은 모호한 용어로 가득 차 있다면, 시스

템 성능을 분석하여 구체적으로 확인하는 것은 더욱 어려워집니다. 

또한 다음 중요한 측면인 추적 가능성과도 연관이 있습니다.

​

8)  Traceable (추적성)

요구사항 추적성은 요구사항과 프로젝트의 다른 개체 사이에 링크가 있는지 확인하는 것을 의미합니다. 이

를 통해 프로젝트 관리자, 개발자 및 이해관계자는 모든 방향에서 각기 다른 구성요소와 관련하여 요구사항

 전체 라이프사이클을 문서화하고 추적할 수 있습니다. ​

Traceability를 적절하게 관리하면 요구사항과 관련이 없는 코드를 가질 수 없으며, 모든 요구사항이 테스트 

단계까지 온전하게 포함되는지 추적할 수 있습니다. 이러한 요구사항을 추적 가능하게 하려면 항상 고유한

 식별자로 레이블을 지정해야 하며 해당 소스 정보를 항상 작성해야 합니다.

이 모든 것은 모든 팀원이 액세스할 수 있는 공유 저장소에서부터 주의 깊게 추적해 나가야 합니다.

이러한 추적성 기능은 Change management 및 규정 준수 목적에 매우 중요한 부분입니다. 또한 범위, 복

잡성 및 그 영향을 이해하는 데 도움이 됩니다. 마지막으로 추적성을 통해 요구 사항 수행의 불일치, 격차

또는 오류를 식별할 수 있습니다.

마치며…

기술적으로 어렵지는 않지만, 가능한 한 최선의 방법으로 요구사항을 정리하는 것은 매우 힘든 과정이 될 

수 있습니다. 

하지만, 시간을 들여 프로젝트를 올바르게 진행하는 것은 프로젝트가 실패하지 않고 정상 궤도에 오를 수 있

도록 하는 큰 차이를 의미할 수 있습니다. 

이 글을 보시는 많은 분들의 노력이 프로젝트의 성공을 이끌 수 있도록 응원합니다. 

출처 : 8 Tips for Writing Better Requirements I PTC

📧 codebeamer@mdsit.co.kr ✍️교육 신청하기

MDS인텔리전스

Digital Transformation을 위한 SW 개발 프로젝트 관리 솔루션,

Codebeamer