소프트웨어 요구사항을 구성하는 중요 속성 10가지

원문: https://www.businessanalystlearnings.com/blog/2017/2/26/10-key-attributes-for-describing-software-requirements

 

요구사항 속성은 요구사항에 관한 다양한 정보를 제공하기 때문에 아주 유용하다. 이를 이용하여 이해관계자는 객관적인 의사결정하는데 활용하기도 하고 또는 요구사항간 중요도를 구분하는데도 유용하게 활용될 수 있다. 그럼에도불구하고 이러한 요구사항 속성이 언제 어떻게 정의하는 것이 좋을지에 대한 의견은 여전히 분분한 실정이다. 본 고를 통해 언제 요구사항 속성을 정의하는 것이 좋을지 논의 해 보도록 한다.

기본적인 요구사항 속성을 Common Set of Attributes (CRA)라고 한다면, 이 CRA는 요구사항 자체에 대한 메타데이터 설계가 이루어질 때 수행되어야 한다. 다만, 상황에 따라 속성 자체가 추가/변경될 수 있으므로, 이를 위한 확장성을 염두에 두어 최소화된 CRA를 구성하는 것이 필요하다.

 

It is impossible to Track Everything

요구사항에 부여된 속성은 기본적으로 요구사항을 관리하기 위한 목적으로 정의된다. 여기서 요구사항 관리란 어떤 요구사항이 어떤 요구사항과 연관성(relationship)을 가지며, 그 연관성이 갖는 의미는 무엇인지 등을 파악하여, 분명하고 정확한 요구사항을 개발/유지하는 것을 기본 기능으로 하는 활동이다. 하지만 관리 자체에만 집착하게 되면 그 또한 바람직하지 않은 결과를 초래 할 수 있다. 

따라서 최소한의 핵심 요구사항 속성을 선택하여 반영하고 추후 필요에 따라 추가할 수 있는 개념으로 접근하는 것이 바람직하다.

 

Main Requirements Attributes

1. Unique ID
   각각의 요구사항은 유일한 식별자를 이용하여 구분될 수 있어야 하며, 이 식별자를 기반으로 하여 상위의 비즈니스 목표와 하위의 테스트케이스와도 추적성이 확보되어야 한다.
   요구사항 ID는 아주 중요한 속성이지만, 어떤식으로 ID를 정의해야 하는지가 고민되는 경우가 있다.
   예를 들어, 처음부터 누적해서 넘버링하는 형태로 ID를 정의하는 것이 좋을지? 아니면 특정 카테고리를 선정하고 카테고리별로 ID를 부여한 후, 해당 카테고리내에서 다시 누적해서 ID를 정의하는 것이 좋을지?
   사실 이부분에 대한 정답은 없겠지만, 최근 고민이 되는 부분중 한 포인트 임
2. Date Created
   일부 요구사항은 프로젝트가 시작하면서 정의되기도 하지만, 또 어떤 요구사항들은 이후에 추가/삭제/변경되기도 한다. 따라서 특정 요구사항이 언제 생성되었으며, 어디서 기인하는 요구사항인지를 알게 되면 변경관리 및 그 요구사항의 중요도를 판단하는데 유용한 정보로 활용될 수 있다.
3. Current Version
   요구사항이 도출되고 분석하는 과정을 거치다보면 일부는 완전히 다른 형태로 변형될 수 있다. 따라서 최초 니즈가 반영된 요구사항을 중심으로 단계별로 강건화된 요구사항을 결정 또는 versioning 할 수 있어야 한다. 
4. Requirements Author
   요구사항을 작성한 사람도 식별되어야 한다.
5. Assigned To
   요구사항을 중심으로 설계와 구현이 이루어 지고 또한 관리 측면에서도 업무 할당이 적절하게 이루어졌는지도 확인할 수 있다.
6. Requirements Status
   요구사항이 이미 구현되었는지, 혹은 아직 제안단계인지, 또는 이해관계자와 협의를 마친 상태인지 아닌지 등의 현재 상황이 정확하기 파악될 수 있어야 한다.
   요구사항 상태는 크게 "Proposed", "To be Reviewed", "Under Review", "Approved", "Rejected" 등으로 구분할 수 있을것으로 생각된다. 
7. Priority
   모든 요구사항이 모두 중요하거나, 또는 동등한 수준으로 중요도를 갖는 경우는 없다. 따라서 무엇이 더 중요한 요구사항인지를 파악할 수 있어야 한다.
   그렇다고 무작위로 요구사항에 대한 중요도를 선정하는 것은 당연히 아닐 것이다.
   가령 유사한 기능단위 내에서 우선순위를 선정한다든지, 여러 하위 작업에 의해 상위 작업이 완성되는 구조에서 하위 작업들간의 우선순위가 필요한 경우라든지 등의 특정한 상황에 따라 우선순위가 결정되기 때문에 단순이 기능의 중요성만을 중심으로 중요도를 표현하지는 않을듯 하다. 
   그러고 보니 "중요도"라고 번역하는 것 보다는 그냥 "우선순위"라고 번역하는 것이 더 타당해 보인다. 
8. Risk
   이 요구사항이 구현되지 않으면 어떤 상황이 발생할까? 라는 물음에 답하기 위한 사항이다.
   단순히 구현되지 않는 상황에 대해서만 고려하면 곤란하다고 본다. 잘못 구현되거나, 타 요구사항과 충돌이 일어나는 경우 등 추가적으로 Risk화 될 수 있는 상황을 고려해야 한다고 본다.
9. Stability
   하나의 요구사항에 대한 작업을 시작하기에 앞서, 해당 요구사항이 안정적인 수준에 도달했는지를 확인해야 한다. 요구사항 기반의 소프트웨어를 개발함에 있어 요구사항이 불안정하게 변경된다거나 하면 이것은 생산성 관점에서 매우 비효율적인 요인이 될 것이다. 
   경우에 따라서 Statbility는 Requirements Status와 혼동 될 여지가 있다고 본다. 왜냐하면, 이미 Approved 된 요구사항이라면 Stability 관점에서는 안정적이라고 보아야 하지 않은가? 하는 질문을 할 수 있기 때문이다. 그러나 이 두가지는 차이가 있다고 본다. 먼저 Requirements Status는 이해관계자 및 요구사항 엔지니어들간의 합의 또는 리뷰 결과에 따라 결정된 상태를 의미한다. 반면 Statbility는 내용적으로 변경될 여지가 있는지 없는지에 관한 사항으로 예를 들자면, 특정 알고리즘에 대해 이해관계자와 요구사항 엔지니어들의 리뷰 결과 알고리즘 자체에 대해서는 승인을 하여 Requirements Status는 "Approved"가 되었으나, 해당 알고리즘에 대한 입력값이 Calibration되어야 하는 경우에는 해당 입력값에 대한 Stability는 "Unstabe"하다고 볼 수 있다. 이는 단계별로 시험(Test) 또는 실험(Experiment)를 거쳐 결정될 수 있기 때문이다.
   그러므로 이 속성은 각 요구사항별로 부여된 속성으로 관리하기 보다는 별도의 리스트로 관리되거나, 설계 과정에서 정의되는 설계 속성으로 부여되는 것이 맞다고 생각한다. 
   
10. Stakeholders
    이 속성은 해당 요구사항이 변경되었을 때 어떤 이해관계자에게 영향을 미칠 것인지를 식별하기 위함이다.

 

 

 

주 1: 원문을 바탕으로 본인이 의역한 것으로 내용과 상이한 부분이 있을 수 있으며, 개인적 의견은 Italic으로 구분하여 표기하였음.

주 2: 본 posting은 원문을 바탕으로 작성자의 개인적 견해를 적은 글로서, 무단 복제를 금지합니다.