요구 사항 관리 개론: 단계별 가이드

금요일 밤, 피자를 주문하려고 합니다. 한 손에는 핸드폰을, 다른 한 손에는 친구들의 요청 목록을 들고 있습니다. 하지만 먼저, 모든 사람의 선호도를 정렬하고 어떤 종류의 피자를 주문할지 결정해야 합니다. 페퍼로니? 치즈? 채식주의자?

피자를 주문하는 것이 최신 제품 출시를 위한 요구 사항을 관리하는 것과 비슷하게 느껴지기 시작했습니다. 위의 상황과 마찬가지로, 요구 사항 관리는 이해관계자의 의견을 경청하고 그들의 요구를 가장 잘 충족시킬 수 있는 방법을 이해하는 것입니다. 

요구 사항 관리란?

요구 사항 관리는 최종 프로젝트 결과물이 고객과 내부 이해관계자의 요구를 충족하는지 확인하는 방법입니다. 이 경우, 요구 사항은 이해관계자가 제품에서 필요로 하거나 원하는 것입니다. 이해관계자는 내부(교차 기능 파트너 등) 또는 외부(고객 또는 클라이언트 등)일 수 있습니다. 

요구 사항 관리는 소프트웨어 제품 및 기능을 다루는 개발 팀에서 가장 자주 사용하지만, 프로젝트 관리에 더 일반적으로 적용할 수도 있습니다. 예를 들어, 요구 사항은 고객이 제품을 성공적으로 사용할 수 있도록 하는 기능이나 교차 기능 파트너가 비즈니스 목표를 달성하는 데 도움이 되는 제품의 측면일 수 있습니다. 

제품 작업을 시작하기 전에 이해관계자에게 필요한 것을 제공할 수 있도록 정확한 요구 사항에 동의해야 합니다. 요구 사항 관리는 요구 사항을 문서화하고 우선순위를 지정하며 변경 사항을 추적하고 프로젝트 라이프 사이클 전반에 걸쳐 이해관계자와 일관성을 유지하는 데 도움이 됩니다. 또한 변화하는 요구 사항을 관리하고 프로젝트가 범위 내에서 유지되도록 하는 데 도움이 됩니다. 

요구 사항이란? 

요구 사항은 기능이나 제품을 완료된 상태로 만들기 위해 구현해야 하는 구성 요소입니다. 즉, 제품이 이해관계자의 요구를 충족시키기 위해 갖춰야 하거나 수행해야 하는 것입니다. 소프트웨어 제품에는 수백 가지의 요구 사항이 있을 수 있습니다. 그러나 제품의 요구 사항 수에 관계없이 모든 요구 사항은 다음과 같아야 합니다. 

• 필수: 비즈니스 또는 제품 목표를 달성하기 위해 이 요구 사항이 필요합니다. 

• 구체적: 요구 사항이 상세하고 명확한 목적을 가지고 있습니다. 

• 이해 가능: 요구 사항이 명확하게 작성되어 있고 이해하기 쉬워야 합니다. 

• 정확성: 요구 사항이 해결해야 하는 문제나 필요에 대해 충분히 정확한 정보가 있습니다. 즉, 수행해야 할 작업을 설명하는 대신 요구 사항이 중요한 이유를 명확히 해야 합니다. 

• 실행 가능: 현재 기술 스택과 코드 인프라로 구현할 수 있는지 확인하기 위해 요구 사항을 조사해야 합니다.

• 테스트 가능: 사용자 테스트, A/B 테스트 또는 다른 방법을 통해 요구 사항을 테스트할 수 있어야 합니다. 

다음은 예시입니다. 앱을 만들고 있다고 가정해 보겠습니다. 앱의 요구 사항 중 하나는 앱 전체를 영어, 중국어, 일본어, 프랑스어로 번역해야 한다는 것입니다. 이러한 언어는 주요 비즈니스 시장에 부합하기 때문입니다.

• 이 요구 사항은 회사의 주요 시장에서 앱을 출시하고 비즈니스 목표를 달성하기 위해 필요합니다. 

• 어떤 언어가 필요한지, 앱 전체를 번역해야 하는지 개략적으로 설명하기 때문에 구체적입니다. 

• 기술적 세부 사항을 다루지 않고 팀원과 교차 기능 이해관계자가 이해할 수 있는 방식으로 작성되어 있기 때문에 이해할 수 있습니다. 

• 영어, 중국어, 일본어, 프랑스어가 회사의 주요 시장에 부합하기 때문에 요구 사항이 중요한 이유를 명확하게 설명했기 때문에 정확합니다. 

• 다른 언어로 프로토타입과 테스트 케이스를 이미 구축했기 때문에 현지화가 가능하고 예상대로 수행될 수 있다는 것을 알기 때문에 실현 가능합니다. 

• 테스트 가능: 각 번역된 버전의 정확성을 테스트하고 확인할 수 있는 시스템이 마련되어 있기 때문에 테스트할 수 있습니다. 

요구 사항 관리가 중요한 이유는 무엇인가요? 

훌륭한 제품을 만들려면 요구 사항 관리가 필요합니다. 그 이유는 다음과 같습니다. 

• 올바른 기능을 제공합니다. 요구 사항 관리 프로세스는 사용자가 제품과 상호 작용하는 방식을 이해하여 사용자에게 필요한 것을 정의하는 데 도움이 됩니다. 이를 통해 고객의 필수적인 니즈에 맞게 결과물을 조정할 수 있습니다. 

• 비즈니스 목표에 맞게 조정합니다. 요구 사항을 문서화하고 우선순위를 지정할 때 각 요구 사항이 전반적인 비즈니스 목표에 부합하는지 확인하세요. 예를 들어, 앱을 12개 언어로 번역해야 한다는 요구 사항은 국제 시장으로 확장하려는 비즈니스 목표를 지원합니다. 요구 사항이 비즈니스 목표를 지원하지 않는다면, 리소스를 다른 곳에 투자해야 하거나 요구 사항이 중요한 이유를 명확히 해야 합니다. 

• 범위 변동 을 방지합니다 . 정의된 요구 사항은 프로젝트 범위 의 역할을 합니다. 즉, 경계를 설정하고 목표와 결과물을 정확히 정의합니다. 사전에 요구 사항을 정의하면 잠재적인 장애물을 식별하고 이해관계자가 추가 요구 사항을 추가하려고 할 때 이를 반발하는 데 도움이 됩니다.

• 장애물을 피하세요. 제품을 만드는 일은 복잡합니다. 소프트웨어 개발, 디자인, 테스트는 물론 복잡한 코드 스택과 엔지니어링 시스템도 있습니다. 요구 사항 관리는 코드 스택의 제약 내에서 제품을 개발하는 방법을 계획하고 제품 개발 프로세스의 모든 단계에서 달성해야 하는 사항을 추적하는 데 도움이 됩니다.

요구 사항 관리는 누가 담당하나요? 

요구 사항 관리를 담당하는 사람은 개별 프로젝트 또는 팀에 따라 다릅니다. 즉, 제품 소유자 또는 제품 매니저는 일반적으로 개발 팀의 요구 사항을 관리합니다. 이 두 역할은 유사하지만, 제품 소유자는 스크럼 팀의 표준 역할인 반면, 제품 매니저는 팀이 애자일 방법론을 사용하는지 여부와 관계없이 보다 보편적인 역할을 합니다. 제품을 개발하는 것이 아니라 보다 일반적인 프로젝트를 진행하는 경우, 프로젝트 매니저가 요구 사항 관리를 담당합니다. 

요구 사항 관리를 위해서는 팀과 프로젝트 이해관계자 간의 교차 기능 협업이 필요합니다. 이해관계자로부터 피드백을 수집하고, 각 요구 사항을 이해하기 위해 협력하고, 팀이 각 요구 사항을 해결할 방법을 계획하도록 도와야 합니다. 이는 프로젝트의 요구 사항을 관리하는 사람이 강력한 협업 스킬을 갖추고 교차 기능 커뮤니케이션에 탁월해야 한다는 것을 의미합니다.

요구 사항에는 어떤 유형이 있나요? 

요구 사항에는 비즈니스 요구 사항, 사용자 요구 사항, 시스템 요구 사항의 세 가지 주요 유형이 있습니다. 업무가 시작되기 전에 다양한 유형의 요구 사항을 정의하는 것이 중요합니다. 왜냐하면 이를 통해 협업해야 하는 이해관계자를 결정할 수 있기 때문입니다. 

다양한 유형의 요구 사항에 대한 개요는 다음과 같습니다. 

비즈니스 요구 사항

비즈니스 요구 사항은 제품이 제공하는 전반적인 비즈니스 목표 또는 지표입니다. 이는 반드시 제품이 해야 할 일이 아니라, 내부 및 외부 이해관계자를 모두 만족시키기 위해 비즈니스가 해야 할 일입니다. 

예를 들어, 온라인 소매 업체에서 근무하고 있으며 영업팀이 콘텐츠 관리 시스템을 사용하여 웹사이트에서 제품 페이지를 생성하고 업데이트한다고 가정해 보겠습니다. 증가하는 인벤토리를 처리하기 위해 제품 팀은 CMS 내에서 검색 기능을 개선하고 있습니다.

제품팀의 프로젝트는 다음과 같은 비즈니스 요구 사항을 충족합니다. 1분기에 제품 인벤토리를 50% 확장합니다. 이와 같은 요구 사항을 체계적인 단일 형식으로 파악하려면 비즈니스 요구 사항 문서 템플릿을 사용해 보세요.

사용자 요구사항

사용자 요구 사항은 사용자가 제품에서 무엇을 필요로 하는지, 어떻게 상호작용하는지를 정의합니다. 고객이 달성하고자 하는 불만 사항이나 행동을 설명하고, 제품이 불만 사항을 어떻게 완화하거나 고객이 원하는 행동을 달성하도록 어떻게 도울 수 있는지 설명합니다.  

애자일 팀은 일반적으로 사용자 요구 사항을 사용자 스토리 형식으로 작성합니다. 사용자 스토리는 최종 사용자의 관점에서 작성된 소프트웨어 기능에 대한 비공식적인 설명입니다. 사용자 스토리는 ‘나는 [페르소나]로서 [소프트웨어 목표]를 하여 [결과]를 얻고 싶다’라는 형식을 따릅니다. 

앞서 설명한 CMS 예제로 돌아가 보겠습니다. 다음은 최종 사용자의 관점에서 작성된 사용자 스토리의 예입니다. 이 경우, CMS를 사용하여 직무를 수행하는 영업 사원을 예로 들 수 있습니다. 

“나는 영업 사원으로서, 증가하는 온라인 재고를 업데이트하고 관리할 수 있도록 CMS에서 특정 제품 목록을 쉽게 검색하고 찾고 싶습니다.” 

시스템 요구 사항

시스템 요구 사항은 제품이 무엇을 할 것인지 정의합니다. 사용자 요구 사항은 사용자의 관점에서 제품 기능의 '이유'와 '무엇'을 설명하는 반면, 시스템 요구 사항은 엔지니어링 팀의 관점에서 해당 기능을 구축하는 '방법'을 정의한다고 생각하면 됩니다. 

시스템 요구 사항은 종종 기능적 요구 사항 과 비기능적 요구 사항 으로 세분화됩니다. 기능적 요구 사항은 제품이 무엇을 할 것인지 정의하고, 비기능적 요구 사항은 제품이 기능을 얼마나 잘 수행하는지를 정의합니다. 이는 비기능적 요구 사항이 일반적으로 보안, 성능 및 신뢰성과 관련이 있음을 의미합니다. 

예를 들어, 엔지니어링 팀이 위의 CMS 사용자 요구 사항을 시스템 요구 사항으로 세분화하는 방법은 다음과 같습니다. 

기능적 요구 사항

• 각 제품 목록에는 제품 유형, 생성 날짜, 작성자, URL 및 게시 상태와 같은 정보가 저장됩니다.

• 작성자가 드롭다운 메뉴에서 제품 유형을 선택하지 않으면 새 제품을 생성할 수 없습니다. 

• 검색 바에는 제품 유형, 생성 날짜, 작성자, URL 및 게시 상태와 같은 추가 필터를 적용하는 옵션이 있습니다. 

• 한 번에 여러 개의 필터를 선택할 수 있습니다. 

비기능적 요구 사항

• 검색 결과는 5초 이내에 반환됩니다. 

• 검색 결과는 100% 정확합니다. 

7���계 요구 사항 관리 프로세스

요구 사항 관리가 부담스럽게 느껴질 필요가 없습니다. 팀을 위한 표준화된 프로세스를 만들면 언제 어떤 이해관계자를 참여시켜야 하는지 고민할 필요 없이 매번 동일한 단계를 따를 수 있습니다. 

시작하기 위해 프로세스를 7단계로 간소화했습니다. 그런 다음, 팀에 적합한 것을 시도하고 학습하면 그에 따라 요구 사항 관리 프로세스를 조정할 수 있습니다. 

1단계: 요구 사항 관리 계획 개발하기

요구 사항 관리 계획(RMP)을 수립하여 프로젝트를 시작하세요. 이 계획은 프로젝트 라이프사이클 전반에 걸쳐 요구 사항을 처리하기 위한 로드맵입니다. RMP에서 다음을 정의하세요.

• 요구 사항 수집에 관여하는 사람은 누구인가요?

• 어떻게 요구 사항을 수집하고 문서화할 것인가?

• 요구 사항 변경 사항을 추적하는 프로세스는 무엇인가요?

• 목표에 맞춰 프로젝트를 성공적으로 수행하려면 어떻게 해야 하나요?

좋은 RMP는 프로젝트 팀이 개발 수명 주기 전반에 걸쳐 조직력을 유지하고 조율할 수 있도록 도와줍니다.

2단계: 요구 사항 도출 및 정의

수집은 프로젝트 요구 사항을 수집하고 정의하는 것을 포함합니다. 이해관계자 및 고객과 소통하여 엔드투엔드 니즈를 이해하는 데 필수적인 단계입니다.

요구 사항 수집

• 이해관계자와 소통: 이해관계자와 직접 만나거나 비동기식으로 소통합니다. 생성 중인 제품, 기능 또는 이니셔티브를 소개하고, 고객을 지원하거나 비즈니스 목표를 달성하는 데 필요한 것이 무엇인지 물어보세요.

• 최종 사용자 요구 사항 수집: 가능하다면 사용자 테스트를 수행하세요. 최소한 개발팀과 상의하여 인사이트를 얻으세요.

• 기대치 관리: 요청된 모든 요구 사항이 반드시 구현되는 것은 아님을 설명하세요. 이 단계는 정보 수집 단계임을 명확히 하세요.

요구 사항 정의

요구 사항을 정의하면 개발 팀이 이니셔티브나 제품을 완료된 상태로 만들기 위해 달성해야 하는 모든 구성 요소를 개략적으로 파악하는 데 도움이 됩니다. 

• 수집된 정보를 바탕으로 명확하고 구체적인 요구 사항을 작성하세요.

• 사용 사례를 만들어 사용자가 최종 제품과 상호작용하는 방식을 보여주세요.

• 각 요구 사항이 하나의 특정 요구 사항이나 기능을 설명하는지 확인하세요.

또한 각 요구 사항에 대한 사용자 스토리를 작성하여 사용자에게 필요한 것과 제품 또는 기능과 상호 작용하는 방법을 명확히 할 수 있습니다.

그런 다음 이러한 사용자 요구 사항을 보다 구체적인 시스템 요구 사항으로 세분화할 수 있습니다. 이 과정에서 각 요구 사항을 완료할 수 있는 충분한 맥락을 확보하기 위해 이해관계자로부터 추가 정보를 수집해야 할 수 있습니다.

요구 사항 관리 워크플로의 이 단계에서는 잠재적인 니즈와 요구 사항을 수집한다는 점을 기억하세요. 팀은 요구 사항 관리 프로세스의 후반부에서 가장 중요한 요구 사항을 우선적으로 선택합니다.

3단계: 요구 사항 분석 및 검증

이제 모든 피드백을 분류하고 제품 및 비즈니스 목표에 부합하는 요구 사항을 결정할 차례입니다. 궁극적으로 모든 요구 사항은 매출 증대, 새로운 시장으로의 확장 또는 고객 만족도 개선과 같은 전반적인 비즈니스 목표에 기여해야 합니다. 

요구 사항 검증에는 다음이 포함됩니다.

• 모든 기술적 요구 사항이 필요하고 실행 가능하며 서로 모순되지 않는지 확인합니다.

• 기술적 요구 사항이 프로젝트 목표와 일치하는지 확인합니다.

그런 다음 이해관계자와 함께 요구 사항을 검증합니다. 이는 요구 사항이 이해관계자의 엔드투엔드 요구를 실제로 반영하는지 확인하는 것을 의미합니다.

4단계: 요구 사항 기준 수립하기

요구 사항이 검증되면 기준을 설정합니다. 이 단계의 문서는 승인된 모든 요구 사항과 제안 사항을 한눈에 보여줍니다.

• 요구 사항 관리 솔루션의 출발점

• 향후 의사 결정 및 변경 사항 측정의 기준

요구 사항을 문서화하고 추적하는 방법이 한 가지는 아닙니다. 제품 팀은 과거에 소프트웨어 요구 사항 사양 (SRS), 제품 요구 사항 문서 (PRD) 또는 요구 사항 추적 매트릭스 (RTM)를 사용했을 수 있습니다. 

하지만 팀이 모든 프로젝트 요구 사항에 대한 실시간 인사이트를 확보할 수 있도록 Asana 와 같은 프로젝트 관리 툴을 사용해 보세요. 이는 더 이상 요구 사항을 감사하기 위해 오래된 스프레드시트를 사용할 필요가 없음을 의미합니다. 대신 팀과 이해관계자 모두 각 요구 사항에 대한 최신 설명을 볼 수 있습니다. 또한 프로젝트를 진행하면서 각 요구 사항의 상태를 추적하고 진행 상황이 있을 때 이해관계자에게 알리도록 자동화를 설정할 수도 있습니다.  

Asana를 Jira 및 GitHub와 같은 보다 전문적인 앱 및 요구 사항 관리 툴과 연동할 수도 있습니다. 이는 개발자 도구에 액세스할 수 있는 권한이 없는 이해관계자와 협력하는 경우 특히 유용합니다. 

5단계: 우선순위 지정 및 종속성 매핑

이제 요구 사항을 작성했으므로 팀과 협력하여 우선순위를 정하고 해결 방법을 계획하세요. 이 우선순위 지정은 특히 다른 작업을 차단하는 경우 가장 중요한 작업을 먼저 처리할 수 있게 해줍니다.

이 단계에서는 요구 사항이 서로 어떻게 연관되어 있는지 파악합니다. 흔히 추적성이라고 하는 이 프로세스에는 다음이 포함됩니다.

• 관련 요구 사항 연결

• 요구 사항을 설계 문서 및 테스트 케이스와 같은 다른 프로젝트 요소에 연결

팀이 애자일 방식을 사용하는 경우, 제품 백로그에 요구 사항을 추가한 다음 스프린트 플래닝 세션을 개최하여 다음 스프린트에 포함할 작업을 결정합니다. 스프린트에서 작업하지 않는 경우, 각 요구 사항을 완료해야 하는 시기와 종속성이 있는지 여부를 나타내는 프로젝트 타임라인을 만들 수 있습니다. 

6단계: 변경 관리, 버전 관리, 영향 분석

요구 사항 관리는 프로젝트를 시작하기 전에 요구 사항을 계획하는 것뿐만 아니라 프로젝트를 진행하는 동안 요구 사항을 변경하는 방법에 대한 것입니다. 즉, 프로젝트 범위에 영향을 미치는 추가 작업을 통합할 방법을 계획해야 합니다. 

프로젝트가 진행됨에 따라 요구 사항이 변경될 수 있습니다. 다음과 같은 방법으로 이러한 변경 사항을 관리하세요.

1. 변경 요청을 제출하고 검토하기 위한 프로세스를 설정합니다

2. 제안된 각 변경 사항이 다른 요구 사항과 프로젝트 요소에 어떤 영향을 미칠 수 있는지 분석합니다

3. 변경 사항이 승인되면 기준 업데이트하기

종속성 맵을 사용하여 영향 분석을 수행하세요. 이를 통해 변경 사항을 구현하기로 결정하기 전에 변경 사항의 전체 영향을 이해할 수 있습니다.

또 다른 옵션은 변경 관리 프로세스를 만드는 것입니다. 이를 통해 이해관계자는 프로젝트 범위에 영향을 미치는 새로운 요구 사항을 제출할 수 있으며, 이러한 요청을 승인하거나 거부할 사람을 지정할 수 있습니다.

잘 정의된 변경 관리 프로세스는 변경 사항을 추적하면서 요구 사항을 효과적으로 관리하는 방법을 이해하는 데 도움이 됩니다. 

7단계: 시스템 검증 및 검증

마지막 단계에서는 완성된 제품이 모든 기술적 요구 사항을 충족하는지 확인합니다.

• 검증: 각 기능을 테스트하여 요구 사항에 지정된 대로 작동하는지 확인합니다.

• 검증: 제품이 이해관계자의 요구와 기대에 부합하는지 확인합니다.

이 단계는 제품을 완성하기 전에 문제를 파악하는 데 도움이 되므로 나중에 비용이 많이 드는 재작업이 필요하지 않습니다.

이 프로세스 전반에 걸쳐 Asana와 같은 요구 사항 관리 소프트웨어 를 사용하는 것이 좋습니다. 이 소프트웨어는 단일 정보 소스로 사용할 수 있으며, 요구 사항을 관리하고, 변경 사항을 추적하고, 보고서와 대시보드를 생성하여 프로젝트를 더 잘 감독할 수 있도록 도와줍니다.

요구 사항 관리를 간소화하는 도구

요구 사항 관리는 많은 부분이 변화하지만, 통제할 수 없는 것은 아닙니다. 적절한 툴을 사용하면 프로젝트 라이프 사이클 전반에 걸쳐 누구에게 이야기해야 하는지, 언제 해야 하는지, 요구 사항을 문서화하고 정리하는 방법을 정확히 제시하는 반복 가능한 프로세스를 설정할 수 있습니다. 

Asana에서 요구 사항을 추적하는 경우 표준화된 템플릿을 생성하여 모든 프로젝트의 요구 사항을 관리할 수 있습니다. 즉, 매번 처음부터 프로세스를 시작하는 대신 미리 정의된 워크플로를 재사용할 수 있으며, 중요한 부분을 잊지 않고 있다는 사실을 쉽게 알 수 있습니다. 

자주 묻는 질문: 요구 사항 관리

요구 사항 관리란? 요구 사항 관리는 개발 수명 주기 전반에 걸쳐 프로젝트 요구 사항을 정의, 추적 및 제어하는 프로세스입니다. 이를 통해 모든 이해관계자가 프로젝트의 필요 사항을 이해하고 이에 동의할 수 있습니다.

요구 사항 관리 계획이란 무엇인가요? 요구 사항 관리 계획은 프로젝트 중에 요구 사항을 수집, 추적 및 관리하는 방법을 설명합니다. 변경 사항, 문서, 커뮤니케이션을 처리하기 위한 가이드 역할을 합니다.

요구 사항 관리 프로세스의 주요 기능은 무엇인가요? 요구 사항 관리 프로세스의 주요 기능에는 요구 사항 수집, 분석 및 검증, 변경 사항 추적, 최종 제품이 합의된 요구 사항을 충족하는지 확인하는 것이 포함됩니다.

좋은 요구 사항은 어떤 모습일까요? 좋은 요구 사항은 명확하고 구체적이며 측정 가능합니다. 쉽게 이해하고 테스트할 수 있으며 프로젝트의 전반적인 목표에 부합해야 합니다.