> [!abstract] Introduction > 소프트웨어 제품은 시장에 맞게 만들어져야 하지만, 고객이 설명하는 자신의 요구사항, 프로젝트 리더가 이해한 요구사항, 프로그래머가 쓴 내용, 문서화된 내용, 실제로 완성된 프로그램, 실제로 고객이 원했던 프로그램이 모두 다를 수 있습니다. 그래서 모든 팀원이 같은 요구사항을 공유하고 제품이 요구사항을 반영하도록 유도하는 과정이 필요합니다. 이번 글에서는 요구사항 관리*Requirements Management*에 대해 알아봅니다. # Requirements Management 요구사항 관리는 목적 제품과 구성요소들의 요구사항이 프로젝트의 계획과 제품에 맞게 유지되도록 관리하기 위한 [[Capability Maturity Model Integration|CMMI(Capability Maturity Model Integration)]]의 프로세스 영역이다. 성숙도*Maturity*를 기준으로 두번째 단계에 해당하며, 프로젝트에서 만들어지거나 사전에 전달받은 요구사항 전체를 관리하는 영역의 프로세스다. 요구사항 관리 프로세스들이 관리하는 요구사항에는 기술적인 요구사항[^1]과 기술적이지 않은 요구사항까지 모두 포함되며, 심지어 조직에 의해 할당된 요구사항들까지 포함된다. 특히 만약 [[Requirements Development|요구사항 개발]] 프로세스가 잡혀 있다면, 그 프로세스는 제품과 그 구성요소에 대한 요구사항도 만들 것이고 그 또한 요구사항 관리 프로세스에 의해 관리될 것이다. ## 주요 목표 CMMI의 모든 프로세스 영역에는 특정한 목표*Specific Goal, SG*가 있고, 그 목표를 이루기 위한 특정 프랙티스*Specific Practice, SP*가 있다. 요구사항 관리의 목표는 단 하나, 요구사항을 관리하는 것이다. 이를 위해 SP 1.1부터 SP 1.5까지 총 5개의 프랙티스가 주어지는데, 이들의 관계는 아래 다이아그램과 같다. ![[RequirementsManagement.png]] ## Understand Requirements 우선 첫번째 프랙티스는 요구사항을 이해하는 것*Understand Requirements*이다. 요구사항을 이해하기 위해서는 요구사항을 제공하는 측과의 합의가 이루어져 있어야 한다. 요구사항이 자꾸 추가되는 일*Requirements Creep*을 피하기 위해 요구사항을 받을 채널을 명확히 설정하도록 평가 기준을 확립해야 하고, 각 요구사항이 무엇을 의미하는지에 대하여 요구사항을 받는 쪽과 주는 쪽이 충분한 대화를 거쳐 공통된 이해에 도달해야 한다. 평가 기준으로는 명료함, 완전함, 고유함, 검증 가능성, 추적 가능성, 비즈니스 가치와의 연결 등을 꼽을 수 있겠다. ![[UnderstandingOfRequirementsBetween.png]] 만약 이러한 평가와 수용 기준이 마련되어 있지 않다면 요구사항을 충분히 확정짓지 못하거나, 추가 비용을 들여 다시 작업해야 할 수도 있고, 고객이 최종 제품을 거부할 수도 있다. ## Obtain Commitment to Requirements 다음 프랙티스는 요구사항을 구현하는 프로젝트 참여자들*Project Participants*에 대한 것이다. 프로젝트 참여자들이 실질적으로 요구사항을 현실로 옮기는 사람들이기 때문에, 요구사항이 변하거나 새로 만들어질 때 그들에게 끼치는 영향을 고려할 필요가 있다. 프로젝트 참여자들이 새로운 요구사항이나 기존의 요구사항의 변화에 대응하기 전에 그들이 하는 일에 변화를 줄 때 충분한 합의가 필요하고, 프로젝트 참여자들이 이미 지난 요구사항이 아닌 현재의 요구사항을 구현하도록 보장해야 한다. ## Manage Requirements Changes 세번째 프랙티스는 프로젝트에 요구사항을 구현해 가는 상황에서 필요한 프랙티스다. 개발 과정에서 고객의 요구가 변하거나 기술이 발전하고 표준이 변하는 등 다양한 이유로 요구사항이 도중에 변하기 때문에 이를 위해서 여러가지 일을 하게 된다. 프로젝트에 대하여 모든 요구사항과 그 변화를 문서로 남기고, 요구사항이 변화해온 기록을 그 근본적 이유와 함께 보존하고, 이해관계자의 입장에서 요구사항의 변화가 어떤 결과를 가져올지 평가해보고[^2], 요구사항과 데이터를 프로젝트에서 이용할 수 있도록 조정하는 일이 여기에 해당된다. ## Maintain Bidirectional Traceability of Requirements 네번째 프랙티스는 요구사항과 작업물이 양방향으로 서로를 추적할 수 있는 상태*Bidirectional Traceability*를 유지하기 위한 프랙티스다. 추적성*Traceability*에는 두가지 방향[^3]이 있는데, 바로 요구사항에서 출발해 설계, 구현, 테스트까지 관계를 수립하는 방향인 순방향 추적성*Forward Traceability*과 테스트에서 출발해 구현, 설계, 요구사항의 순서로 관계를 수립해 출처를 밝히는 방향이 바로 역방향 추적성*Backward Traceability*이다. 이러한 추적성은 요구사항의 변화가 프로젝트 활동과 작업물에 가져오는 영향을 평가할 때 특히 필요하다. ## Ensure Alignment Between Project Work and Requirements 마지막 프랙티스는 프로젝트의 계획와 실제 작업 중인 제품이 요구사항과 나란히 가도록*aligned with requirements* 설정하는 것이다. 만약 요구사항과 프로젝트의 계획, 그리고 실제 제품의 방향이 나란하지 않고 어긋나 있다면 교정해줄 필요가 있다. 이를 위해 네가지 하위 프랙티스가 권장된다. 1. 프로젝트 계획, 활동, 그리고 작업물을 리뷰할 것. 이는 요구사항과 요구사항의 변화를 실제 구현이 계속 따라가도록 하기 위한 것이다. 2. 만약 요구사항과 프로젝트의 계획, 그리고 실제 제품의 방향이 나란하지 않고 어긋나 있다면 그 원인을 찾을 것. 3. 요구사항이 변화함에 따라 프로젝트의 계획이나 실제 작업물에 어떤 변화가 필요한지 파악할 것. 4. 앞서 설명한 맥락 안에서 고쳐야 할 것이 있다면 고칠 것. [^1]: 기술적인 요구사항*Technical requirements*이란, 제품이나 서비스가 갖춰야 하는 특성을 의미한다. [^2]: 특히, 제품의 아키텍처를 바꾸는 요구사항 변화는 수많은 이해관계자에게 영향을 끼칠 수 있다. [^3]: 사실 추적성은 두가지가 아니라 네가지다. 고객 니즈, 시스템 요구사항, 설계, 구현, 테스트 간 관계를 수립하는 수직 추적성*Vertical Traceability*과 요구사항 간, 모듈 간 등 같은 단위 사이의 관계를 수립하는 수평 추적성*Horizontal Traceability*도 있다. 하지만 이번 글에서는 깊이 다룰 필요가 없어 두가지만 적었다.