금요일 밤이고 곧 피자를 주문하려고 합니다. 한 손에는 전화기가, 다른 한 손에는 친구들의 요청 목록이 있습니다. 하지만 먼저 모두의 선호 사항을 정리하고 어떤 유형의 피자를 주문할지 결정해야 합니다. 페퍼로니? 치즈? 채식 피자?
피자를 주문하는 것이 최근 제품 출시를 위한 요구 사항을 관리하는 것과 묘하게 비슷하게 느껴지기 시작합니다. 위의 상황과 마찬가지로, 요구 사항 관리는 이해관계자의 의견을 경청하고 이들의 니즈를 가장 잘 충족하는 방법을 파악하는 것이 핵심입니다.
요구 사항 관리는 최종 프로젝트 결과물이 고객과 내부 이해관계자의 요구를 충족하도록 하는 방법입니다. 이 경우 요구사항이란 이해관계자가 제품에서 필요로 하거나 원하는 것을 말합니다. 이해관계자는 내부(예: 교차 기능 파트너) 또는 외부(예: 고객 또는 클라이언트)일 수 있습니다.
요구 사항 관리는 소프트웨어 제품 및 기능을 개발하는 개발팀에서 가장 많이 사용되지만, 더 일반적으로 프로젝트 관리에도 적용할 수 있습니다. 예를 들어, 요구 사항은 고객이 제품을 성공적으로 사용할 수 있도록 하는 기능이거나 교차 기능 파트너가 비즈니스 목표를 달성하는 데 도움이 되는 제품의 측면일 수 있습니다.
제품 작업을 시작하기 전에 정확한 요구 사항에 대해 합의해야 이해관계자에게 필요한 것을 제공할 수 있습니다. 요구 사항 관리는 요구 사항을 문서화하고 우선순위를 지정하고, 변경 사항을 추적하고, 프로젝트 라이프 사이클 전반에 걸쳐 이해관계자와 일관되게 협업하는 데 도움이 됩니다. 또한 변경되는 요구 사항을 관리하고 프로젝트가 범위 내에서 진행되도록 하는 데 도움이 됩니다.
요구 사항 추적 매트릭스 템플릿 만들기요구 사항은 기능이나 제품을 완료하기 위해 구현해야 하는 구성 요소입니다. 즉, 이해관계자의 요구 사항을 충족하기 위해 제품이 갖추어야 하거나 수행해야 하는 것을 말합니다. 소프트웨어 제품에는 수백 가지의 요건이 있을 수 있습니다. 하지만 제품에 요구 사항이 몇 개이든 관계없이 모든 요구 사항은 다음과 같아야 합니다.
필수적: 비즈니스 또는 제품 목표를 달성하기 위해 이 요구 사항이 필요합니다.
구체적: 요구 사항이 상세하고 명확한 목적을 가집니다.
이해 가능: 요구 사항이 명확하게 서술되어 있고 이해하기 쉽습니다.
정확성: 요구 사항이 해결하려는 과제 또는 니즈에 대한 충분하고 정확한 정보를 포함하고 있습니다. 즉, 무엇을 해야 하는지 단순히 설명하는 대신, 요구 사항이 중요한 이유도 명확히 해야 합니다.
실현 가능성: 현재 기술 스택과 코드 인프라로 요구 사항을 구현할 수 있는지 확인하기 위해 요구 사항을 조사해야 합니다.
테스트 가능: 사용자 테스트, A/B 테스트 또는 다른 방법을 통해 요구 사항을 테스트할 수 있어야 합니다.
다음은 그 예시입니다. 앱을 제작하고 있다고 가정해 보겠습니다. 요구 사항 중 하나는 앱 전체를 영어, 중국어, 일본어, 프랑스어로 번역해야 한다는 것입니다. 이러한 언어는 주요 비즈니스 시장과 일치하기 때문입니다.
이 요구 사항은 회사의 주요 시장에서 앱을 출시하고 비즈니스 목표를 달성하기 위해 필요합니다.
어떤 언어가 필요한지, 앱 전체를 번역해야 하는지 명시했기 때문에 구체적입니다.
기술적인 세부 사항을 다루지 않고 팀원과 여러 부서의 이해관계자가 이해할 수 있는 방식으로 작성되었기 때문에 이해할 수 있습니다.
영어, 중국어, 일본어, 프랑스어가 회사의 주요 시장과 부합하기 때문에 요구 사항이 중요한 이유를 명확히 설명했기 때문에 정확합니다.
이미 다른 언어로 프로토타입과 테스트 케이스를 구축했기 때문에 현지화가 가능하고 예상대로 작동할 것이라는 것을 알고 있으므로 실현 가능합니다.
각 번역 버전의 정확성을 테스트하고 확인할 수 있는 시스템이 마련되어 있으므로 테스트 가능합니다.
뛰어난 제품을 만들려면 요구 사항 관리가 필요합니다. 그 이유는 다음과 같습니다.
적합한 기능을 출시합니다. 요구 사항 관리 프로세스는 사용자가 제품과 상호 작용하는 방식을 이해하여 사용자가 필요로 하는 것을 정의하는 데 도움이 됩니다. 이를 통해 무엇보다도 결과물을 고객의 필수적인 니즈에 맞출 수 있습니다.
비즈니스 목표에 맞게 조정합니다. 요구 사항을 문서화하고 우선순위를 지정할 때 각 요구 사항이 중요한 비즈니스 목표와 부합하는지 확인하세요. 예를 들어, 앱을 12개 언어로 번역하려는 요구 사항은 국제 시장으로 진출하려는 비즈니스 목표를 뒷받침할 것입니다. 요구 사항이 비즈니스 목표를 뒷받침하지 않는다면, 이는 아마도 리소스를 다른 곳에 투자해야 하거나 요구 사항이 중요한 이유가 정말 타당해야 함을 의미합니다.
범위 변동을 예방합니다 . 정의된 요구 사항은 프로젝트 범위 의 역할을 합니다. 즉, 경계선을 설정하고 달성하고자 하는 목표와 결과물을 정확히 정의합니다. 요건을 사전에 정의하면 잠재적인 장애물을 파악하고 이해관계자가 추가 요건을 추가하려고 할 때 이를 거부하는 데 도움이 됩니다.
문제를 방지하세요. 제품을 만드는 것은 복잡합니다. 소프트웨어 개발, 디자인, 테스트가 있으며, 복잡한 코드 스택과 엔지니어링 시스템은 말할 것도 없습니다. 요구 사항 관리는 코드 스택의 제약 내에서 제품을 개발하는 방법을 계획하고 제품 개발 프로세스의 모든 단계에서 달성해야 할 사항을 추적하는 데 도움이 됩니다.
요구 사항 관리를 담당하는 사람은 개별 프로젝트나 팀에 따라 다릅니다. 그렇지만 일반적으로 제품 소유자나 제품 매니저가 개발팀의 요구 사항을 관리합니다. 이 두 역할은 비슷하지만, 제품 소유자는 스크럼 팀의 표준 역할인 반면, 제품 매니저는 팀이 애자일 방법론을 사용하는지 여부와 관계없이 더 보편적인 역할입니다. 제품을 개발하는 것이 아니라 보다 일반적인 프로젝트를 진행 중이라면 프로젝트 매니저 가 요구 사항 관리를 담당합니다.
요구 사항 관리는 팀과 프로젝트 이해관계자 간의 교차 기능적 협업이 필요합니다. 이해관계자로부터 피드백을 수집하고, 이해관계자와 협력하여 각 요구 사항을 이해하고, 팀이 각 요구 사항을 해결하는 방법을 계획하도록 도와야 합니다. 즉, 프로젝트의 요구 사항을 관리하는 사람은 모든 것의 중심에 서게 되므로 뛰어난 협업 스킬을 갖추고 교차 기능 커뮤니케이션에 능숙해야 합니다.
참고: 성공에 필수적인 25가지 핵심 프로젝트 관리 스킬요구 사항에는 비즈니스 요구 사항, 사용자 요구 사항, 시스템 요구 사항의 세 가지 주요 유형이 있습니다. 업무를 시작하기 전에 다양한 유형의 요구 사항을 정의하는 것이 중요합니다. 이는 종종 협업해야 하는 이해관계자를 결정하기 때문입니다.
다양한 유형의 요구 사항에 대한 개요는 다음과 같습니다.
비즈니스 요구 사항은 제품이 제공하는 포괄적인 비즈니스 목표 또는 지표입니다. 이는 반드시 제품이 해야 할 일이 아니라, 내부 및 외부 이해관계자를 모두 만족시키기 위해 비즈니스가 해야 할 일입니다.
예를 들어, 온라인 소매업체에서 근무하고 있고 영업팀이 콘텐츠 관리 시스템을 사용하여 웹사이트의 제품 페이지를 생성하고 업데이트한다고 가정해 보겠습니다. 늘어나는 재고를 처리하기 위해 제품팀이 CMS 내 검색 기능을 개선하고 있습니다.
제품 팀의 프로젝트는 다음과 같은 비즈니스 요구 사항을 충족합니다. 1분기에 제품 재고를 50% 늘립니다. 이러한 요건을 하나의 체계적인 형식으로 파악하려면 비즈니스 요건 문서 템플릿을 사용해 보세요.
참고: 예시를 통해 알아보는 비즈니스 요건 문서 템플릿의 7가지 핵심 요소사용자 요구 사항은 사용자가 제품에서 무엇을 필요로 하는지, 그리고 사용자가 제품과 어떻게 상호작용할지를 정의합니다. 사용자 요구 사항은 고객이 해결하고자 하는 문제점이나 달성하고자 하는 행동을 설명하고, 제품이 해당 문제점을 어떻게 해결하거나 고객이 원하는 행동을 달성하도록 어떻게 도와야 하는지를 설명합니다.
애자일 팀은 일반적으로 사용자 요구 사항을 사용자 스토리로 작성합니다. 사용자 스토리는 최종 사용자의 관점에서 작성된 소프트웨어 기능에 대한 비공식적인 설명입니다. 사용자 스토리는 '나는 [페르소나]로서 [소프트웨어 목표]를 하여 [결과]를 얻고 싶다'는 형식을 따릅니다.
앞서 설명한 CMS 예시로 돌아가 보겠습니다. 다음은 최종 사용자의 시점에서 작성된 사용자 스토리의 예시입니다. 이 경우 CMS를 사용하여 업무를 수행하는 영업 사원이 이에 해당합니다.
“나는 영업 사원으로서, 증가하는 온라인 재고를 업데이트하고 관리할 수 있도록 CMS에서 특정 제품 목록을 쉽게 검색하고 찾고 싶다.”
시스템 요구 사항은 제품의 기능을 정의합니다. 이렇게 생각해 보세요. 사용자 요구 사항은 사용자의 관점에서 제품 기능의 '이유'와 '내용'을 설명하는 반면, 시스템 요구 사항은 엔지니어링 팀의 관점에서 해당 기능을 구축하는 '방법'을 정의합니다.
시스템 요구 사항은 일반적으로 기능적 요구 사항과 비기능적 요구 사항으로 나뉩니다. 기능적 요구 사항은 제품이 수행할 기능을 정의하는 반면, 비기능적 요구 사항은 제품이 기능을 얼마나 잘 수행하는지를 정의합니다. 즉, 비기능적 요구 사항은 일반적으로 보안, 성능, 안정성과 관련이 있습니다.
예를 들어, 엔지니어링 팀이 위의 CMS 사용자 요구 사항을 시스템 요구 사항으로 세분화하는 방법은 다음과 같습니다.
각 제품 목록에는 제품 유형, 생성 날짜, 작성자, URL, 게시 상태와 같은 정보가 저장됩니다.
작성자가 드롭다운 메뉴에서 제품 유형을 선택하지 않으면 새 제품을 생성할 수 없습니다.
검색창에는 제품 유형, 생성일, 작성자, URL, 게시 상태와 같은 추가 필터를 적용할 수 있는 옵션이 있습니다.
여러 개의 필터를 한 번에 선택할 수 있습니다.
검색 결과가 5초 이내에 반환됩니다.
검색 결과는 100% 정확합니다.
요구 사항 관리가 부담스럽게 느껴질 필요는 없습니다. 팀을 위한 표준화된 프로세스를 만들면 언제 어떤 이해관계자를 참여시켜야 할지 걱정할 필요 없이 매번 동일한 단계를 따를 수 있습니다.
시작하는 데 도움이 되도록 프로세스를 7단계로 간소화했습니다. 그런 다음, 여러 가지를 시도해 보고 팀에 적합한 방식을 파악한 후 그에 맞게 요구 사항 관리 프로세스를 맞춤 설정할 수 있습니다.
요구 사항 관리 계획(RMP)을 수립하여 프로젝트를 시작하세요. 이 계획은 프로젝트 라이프사이클 전반에 걸쳐 요구 사항을 처리하기 위한 로드맵입니다. RMP에서 다음 사항을 정의하세요.
요구 사항 수집에 관여하는 사람이 누구인가요?
요구 사항을 어떻게 수집하고 문서화할 것인가요?
요구 사항 변경 사항을 추적하는 프로세스는 무엇인가요?
목표에 부합하여 프로젝트의 성공을 어떻게 보장할 것인가요?
우수한 RMP는 프로젝트 팀이 개발 수명 주기 전반에 걸쳐 업무를 체계적으로 관리하고 보조를 맞출 수 있도록 도와줍니다.
요구 사항 도출에는 프로젝트 요구 사항을 수집하고 정의하는 것이 포함됩니다. 이해관계자 및 고객과 소통하여 이들의 엔드투엔드 니즈를 파악하는 필수적인 단계입니다.
이해관계자와 소통: 이해관계자와 대면으로 만나거나 비동기적으로 소통합니다. 현재 개발 중인 제품, 기능 또는 이니셔티브를 소개하고 고객을 지원하거나 비즈니스 목표를 달성하는 데 무엇이 필요한지 물어보세요.
최종 사용자 요건 수집: 가능하다면 사용자 테스트를 수행하세요. 적어도 개발팀과 상의하여 인사이트를 얻으세요.
기대치 관리: 요청된 모든 요건이 반드시 구현되는 것은 아니라고 설명하세요. 이 단계가 정보 수집 단계임을 명확히 설명하세요.
요구 사항을 정의하면 개발팀이 이니셔티브 또는 제품을 완료하기 위해 달성해야 하는 모든 구성 요소를 개략적으로 파악하는 데 도움이 됩니다.
수집한 정보를 바탕으로 명확하고 구체적인 요구 사항을 작성합니다.
사용자가 최종 제품과 어떻게 상호작용할지 보여주는 사용 사례를 만듭니다.
각 요구 사항이 하나의 특정 요구 사항이나 기능을 설명하는지 확인하세요.
또한 사용자가 무엇을 필요로 하는지, 사용자가 제품이나 기능과 어떻게 상호작용할 것인지 명확히 설명하기 위해 각 요구 사항에 대한 사용자 스토리를 생성할 수도 있습니다.
그런 다음 이러한 사용자 요구 사항을 보다 구체적인 시스템 요구 사항으로 세분화할 수 있습니다. 진행하면서 각 요구 사항을 완료하는 데 필요한 충분한 배경 정보를 확보하기 위해 이해관계자로부터 추가 정보를 수집해야 할 수 있습니다.
요구 사항 관리 워크플로의 이 단계에서는 잠재적인 니즈와 요구 사항을 수집하고 있다는 점을 기억하세요. 팀은 요구 사항 관리 프로세스의 후반부에 가장 중요한 사항에 우선순위를 부여하고 이를 선택할 것입니다.
참고: 프로젝트 성공을 위한 요구 사항 수집을 위한 6단계 가이드이제 모든 피드백을 검토하고 제품 및 비즈니스 목표에 부합하는 요구 사항을 결정할 차례입니다. 궁극적으로 모든 요구 사항은 매출 증대, 신규 시장 진출, 고객 만족도 향상과 같은 포괄적인 비즈니스 목표에 기여해야 합니다.
요건 검증에는 다음이 포함됩니다.
모든 기술적 요구사항이 필요하고, 실현 가능하며, 서로 모순되지 않는지 확인합니다.
기술적 요구 사항이 프로젝트 목표와 일치하는지 확인합니다.
그런 다음 이해관계자와 함께 요구 사항을 검증합니다. 이는 요구 사항이 이해관계자의 모든 요구 사항을 진정으로 반영하는지 확인하는 것을 의미합니다.
요구 사항이 검증되면 기준선을 설정합니다. 이 단계의 문서는 승인된 모든 요구 사항을 요약하여 제공하며 다음과 같은 사항을 제공합니다.
요구 사항 관리 솔루션의 출발점
향후 의사 결정 및 변경 사항 측정에 대한 참고 자료
요구 사항을 문서화하고 추적하는 정해진 방법은 없습니다. 제품팀은 과거에 소프트웨어 요구 사항 사양 (SRS), 제품 요구 사항 문서 (PRD) 또는 요구 사항 추적 매트릭스 (RTM)를 사용했을 수 있습니다.
하지만 팀이 모든 프로젝트 요구 사항에 대한 실시간 인사이트를 파악할 수 있도록 하려면 Asana와 같은 프로젝트 관리 툴 을 사용해 보세요. 즉, 더 이상 요구 사항을 감사하기 위해 오래된 스프레드시트를 사용할 필요가 없으며, 대신 팀과 이해관계자 모두 각 요구 사항에 대한 최신 설명을 확인할 수 있습니다. 또한 프로젝트를 진행하면서 각 요구 사항의 상태를 추적할 수 있으며, 진행 상황이 있을 때 이해관계자에게 알림을 보내도록 자동화 를 설정할 수도 있습니다.
또한 Asana를 Jira 및 GitHub와 같은 보다 전문적인 앱 및 요구 사항 관리 툴과 연동할 수도 있습니다. 개발자 도구에 액세스할 권한이 없는 이해관계자와 함께 일하는 경우 특히 유용합니다.
이제 요구 사항을 작성했으니 팀과 협력하여 우선순위를 지정하고 이를 해결할 방법을 계획하세요. 이러한 우선순위 지정을 통해 가장 중요한 작업을 먼저 처리할 수 있습니다. 특히, 해당 작업이 진행 과정에서 다른 작업을 방해하는 경우 더욱 그렇습니다.
이 단계에서는 요구 사항이 서로 어떻게 연관되어 있는지 파악합니다. 흔히 추적성이라고 하는 이 프로세스에는 다음이 포함됩니다.
관련 요건 연결하기
요구 사항을 설계 문서 및 테스트 케이스와 같은 다른 프로젝트 요소에 연결
팀이 애자일 을 사용하는 경우, 요구 사항을 제품 백로그에 추가한 다음 스프린트 플래닝 세션을 열어 다음 스프린트에 포함할 작업을 결정합니다. 스프린트 방식으로 일하지 않는 경우에도 괜찮습니다. 프로젝트 타임라인을 생성하여 각 요구 사항이 언제 완료되어야 하는지, 종속성이 있는지 여부를 파악할 수 있습니다.
요건 관리는 프로젝트를 시작하기 전에 요건을 계획하는 것뿐만 아니라 프로젝트를 진행하는 동안 변경되는 요건을 관리하는 것과도 관련이 있습니다. 즉, 프로젝트 범위에 영향을 미칠 추가 작업을 어떻게 통합할지 계획해야 합니다.
프로젝트가 진행됨에 따라 요구 사항이 변경될 수 있습니다. 다음과 같은 방법으로 이러한 변경 사항을 관리하세요.
변경 요청을 제출하고 검토하는 프로세스를 설정합니다.
제안된 각 변경 사항이 다른 요구 사항 및 프로젝트 요소에 어떤 영향을 미칠 수 있는지 분석하기
변경 사항이 승인된 경우 기준 업데이트하기
종속성 맵을 사용하여 영향 분석을 수행하세요. 이를 통해 변경 사항을 구현하기로 결정하기 전에 변경 사항의 전체적인 영향을 파악할 수 있습니다.
또 다른 옵션은 변경 관리 프로세스를 수립하는 것입니다. 이를 통해 이해관계자가 프로젝트 범위에 영향을 미칠 새로운 요구 사항을 제출할 수 있는 방법을 제공하고, 해당 요청을 승인하거나 거부해야 하는 사람이 누구인지 명시할 수 있습니다.
명확하게 정의된 변경 관리 프로세스는 변경 사항을 추적하면서 요구 사항을 효과적으로 관리하는 방법을 이해하는 데 도움이 됩니다.
마지막 단계에서는 완성된 제품이 모든 기술 요구 사항을 충족하는지 확인합니다.
검증: 각 기능이 요구 사항에 명시된 대로 작동하는지 테스트합니다.
검증: 제품이 이해관계자의 니즈와 기대치를 충족하는지 확인합니다.
이 단계는 제품을 확정하기 전에 문제를 파악하는 데 도움이 되므로 나중에 비용이 많이 드는 재작업이 필요할 가능성을 줄여줍니다.
이 과정 전반에 걸쳐 Asana와 같은 요구 사항 관리 소프트웨어 를 사용하는 것이 좋습니다. 이 소프트웨어는 단일 정보 소스로서 요구 사항을 관리하고, 변경 사항을 추적하며, 프로젝트를 더 잘 감독할 수 있도록 보고서와 대시보드를 생성하는 데 도움이 됩니다.
요구 사항 관리에는 많은 진행 요소가 있지만, 통제 불능 상태가 될 필요는 없습니다. 적합한 툴을 사용하면 프로젝트 라이프사이클 전반에 걸쳐 누구와 언제 소통해야 하는지, 요구 사항을 어떻게 기록하고 체계적으로 관리해야 하는지를 정확히 명시하는 반복 가능한 프로세스를 설정할 수 있습니다.
Asana에서 요구 사항을 추적하면 모든 프로젝트의 요구 사항을 관리하는 데 도움이 되는 표준화된 템플릿을 생성할 수 있습니다. 즉, 매번 처음부터 프로세스를 시작하는 대신 미리 정의된 워크플로를 재사용할 수 있으며, 중요한 부분을 놓치지 않았다는 사실을 알고 안심할 수 있습니다.
요구 사항 추적 매트릭스 템플릿 만들기요구 사항 관리란 무엇인가요? 요구사항 관리란 개발 라이프 사이클 전반에 걸쳐 프로젝트 요구사항을 정의하고, 추적하고, 관리하는 프로세스를 말합니다. 이를 통해 모든 이해관계자가 프로젝트의 요구 사항을 이해하고 이에 동의하도록 합니다.
요구 사항 관리 계획이란 무엇인가요? 요구 사항 관리 계획은 프로젝트를 진행하는 동안 요구 사항을 수집하고, 추적하고, 관리하는 방법을 요약한 것입니다. 변경 사항, 문서화, 커뮤니케이션을 처리하기 위한 가이드 역할을 합니다.
요건 관리 프로세스의 주요 기능은 무엇인가요? 요구 사항 관리 프로세스의 핵심 기능에는 요구 사항 수집, 분석 및 검증, 변경 사항 추적, 최종 제품이 합의된 요구 사항을 충족하는지 확인하는 것이 포함됩니다.
좋은 요구 사항은 어떤 모습인가요? 좋은 요구사항은 명확하고 구체적이며 측정 가능합니다. 쉽게 이해할 수 있고, 테스트할 수 있으며, 프로젝트의 전반적인 목표와 부합해야 합니다.