요구사항 분석 및 요구사항 정의서

요구사항 분석은 소프트웨어 공학에서 이해관계자로부터 수집된 초기 요구사항을 체계적으로 검토, 정리, 명확히 하고 문서화하는 과정이다. 이 과정은 모호하거나 충돌하는 요구사항을 식별하여 명확한 시스템 요구사항으로 정제하는 것을 목표로 한다. 요구사항 분석의 핵심은 '무엇을' 개발해야 하는지에 대한 공통된 이해를 모든 이해관계자 사이에 구축하는 것이다.

분석 활동은 단순한 정보 수집을 넘어, 요구사항의 타당성을 검토하고, 서로 다른 이해관계자 간의 요구사항 충돌을 해결하며, 구현 가능한 수준으로 상세화하는 작업을 포함한다. 이를 통해 프로젝트 후반 단계에서 발생할 수 있는 오해와 변경 비용을 크게 줄일 수 있다. 효과적인 분석 없이는 프로젝트 범위가 불분명해지고, 최종 제품이 사용자의 실제 필요를 충족하지 못할 위험이 높아진다.

이 과정의 결과물은 요구사항 명세서의 초안이 되며, 이후 설계 및 구현 단계의 근간을 이룬다. 따라서 요구사항 분석은 단순한 전달자가 아닌, 문제 영역을 깊이 이해하고 해결 방안을 창의적으로 모색하는 중요한 설계 활동으로 간주된다.

소프트웨어 개발 생명주기에서 요구사항 분석은 초기 단계에 위치하는 핵심 활동이다. 이 단계는 프로젝트의 성공을 결정짓는 기초를 마련하며, 이후 모든 개발 활동의 방향과 범위를 정의한다. 불명확하거나 잘못된 요구사항은 설계, 구현, 테스트 단계에서의 수정 비용을 기하급수적으로 증가시키므로, 생명주기의 초기에 정확한 요구를 파악하는 것이 가장 경제적이고 효율적인 접근법이다.

요구사항 분석은 사용자와 개발자 간의 가교 역할을 한다. 사용자의 비즈니스 니즈와 기대를 기술적인 시스템 요구사항으로 변환하는 과정이다. 이 과정이 제대로 수행되지 않으면, 최종 제품이 사용자의 실제 필요를 충족시키지 못하는 상황이 발생할 수 있다. 따라서 이 단계는 단순한 정보 수집을 넘어, 이해관계자들 간의 합의를 도출하고 공통의 비전을 수립하는 중요한 협업 단계이다.

다양한 소프트웨어 개발 방법론에 따라 요구사항 분석의 형태와 반복성은 달라진다. 폭포수 모델과 같은 전통적 방법론에서는 명확하게 구분된 단일 단계로 진행되지만, 애자일 방법론에서는 프로젝트 전반에 걸쳐 지속적으로 반복되고 개선되는 활동이다. 그러나 방법론에 관계없이, 요구사항 분석의 근본적인 목표는 '올바른 제품을 구축하는 것'의 토대를 마련한다는 점에서 동일하다.

기능적 요구사항은 시스템이 반드시 수행해야 하는 구체적인 행동, 작업 또는 서비스를 명시한다. 이는 사용자가 시스템을 통해 무엇을 할 수 있는지, 시스템이 입력에 대해 어떻게 반응해야 하는지를 정의한다. 기능적 요구사항은 주로 동사로 표현되며, 시스템의 기능과 능력을 직접적으로 기술한다. 예를 들어, "사용자는 아이디와 비밀번호를 입력하여 시스템에 로그인할 수 있다" 또는 "시스템은 매일 자정에 판매 데이터를 기반으로 일일 보고서를 자동 생성한다"와 같은 명세가 포함된다.

이러한 요구사항은 종종 유스케이스 다이어그램, 시퀀스 다이어그램, 활동 다이어그램과 같은 모델링 기법을 통해 시각적으로 표현되거나, 자연어로 작성된 유스케이스 시나리오의 형태로 문서화된다. 기능적 요구사항은 시스템의 핵심 비즈니스 로직을 구성하며, 최종적으로 설계와 구현의 근간이 된다. 따라서 명확성, 검증 가능성, 일관성이 매우 중요하다.

기능적 요구사항은 일반적으로 다음과 같은 범주로 세분화하여 정리할 수 있다.

이러한 명세는 개발팀, 테스트팀, 이해관계자 모두가 시스템이 무엇을 해야 하는지에 대한 공통된 이해를 형성하는 데 필수적이다. 잘 정의된 기능적 요구사항은 프로젝트의 범위를 명확히 하고, 이후 단계에서의 오해와 재작업을 줄이는 데 기여한다.

비기능적 요구사항은 시스템이 수행해야 하는 기능 자체보다는, 그 기능이 어떻게 수행되어야 하는지에 대한 품질 속성, 제약 조건, 운영 환경 등을 규정한다. 이는 시스템의 성능, 보안, 사용성, 신뢰성 등 전반적인 품질과 관련된 기준을 정의한다. 기능적 요구사항이 '무엇을' 하는지에 초점을 맞춘다면, 비기능적 요구사항은 그 작업의 '수준'이나 '방식'을 명시한다.

비기능적 요구사항은 주로 다음과 같은 범주로 분류된다.

• 성능: 시스템 응답 시간, 처리량, 자원 사용률 등을 포함한다. 예를 들어, "주문 처리 시 95%의 경우 2초 이내에 응답해야 한다"와 같은 명세가 해당한다.

• 보안: 접근 제어, 데이터 암호화, 인증 및 권한 부여 요구사항을 정의한다.

• 사용성: 사용자 인터페이스의 학습 용이성, 오류 처리, 사용자 가이드의 필요성 등을 포함한다.

• 신뢰성: 시스템 가용성, 평균 고장 간격, 복구 시간 목표 등을 명시한다.

• 호환성: 특정 하드웨어, 운영체제, 다른 소프트웨어와의 연동 가능성을 규정한다.

• 유지보수성: 시스템의 모듈화 정도, 코드 문서화 요구사항, 향후 변경의 용이성 등을 포함한다.

비기능적 요구사항은 종종 측정 가능하고 검증 가능한 형태로 명세화되어야 한다. 모호한 표현보다는 정량적 지표를 사용하는 것이 바람직하다. 예를 들어, "시스템이 빨라야 한다"는 명세보다는 "동시 사용자 1000명 환경에서 페이지 로딩 시간이 3초를 초과하지 않아야 한다"와 같이 구체적으로 작성한다. 이러한 요구사항은 시스템 아키텍처 설계, 기술 스택 선택, 테스트 케이스 정의에 직접적인 영향을 미치며, 프로젝트의 성공을 좌우하는 핵심 요소가 된다.

사용자 요구사항은 시스템을 통해 사용자가 달성하고자 하는 목표나 필요를 사용자의 관점에서 기술한 것이다. 이는 일반적으로 자연어로 작성되며, 구체적인 기술적 구현보다는 '무엇'을 해야 하는지에 초점을 맞춘다. 예를 들어, "사용자는 이메일을 통해 주문 확인을 받을 수 있어야 한다"는 문장은 사용자 요구사항에 해당한다. 이는 비기술적 이해관계자와의 의사소통에 용이하지만, 모호하고 해석의 여지가 있을 수 있다.

반면, 시스템 요구사항은 사용자 요구사항을 바탕으로 시스템이 반드시 충족시켜야 하는 상세한 조건, 기능, 성능, 제약사항 등을 기술한 것이다. 이는 보다 정형화되고 검증 가능한 형태로 표현된다. 시스템 요구사항은 다시 기능적 요구사항과 비기능적 요구사항으로 세분화된다. 앞의 예시를 시스템 요구사항으로 변환하면 "시스템은 주문 완료 후 5분 이내에 고객의 등록된 이메일 주소로 확인 메일을 자동 발송해야 한다"와 같이 구체적이고 측정 가능한 형태가 된다.

두 요구사항의 관계는 계층적 구조를 이룬다. 사용자 요구사항은 상위 수준의 요구사항으로, 시스템 요구사항은 이를 구체화하고 구현 가능하도록 만든 하위 수준의 요구사항이다. 효과적인 요구사항 분석은 사용자의 진정한 필요(사용자 요구사항)를 정확히 포착하고, 이를 명확하고 모호함이 없는 시스템 요구사항으로 정제하는 과정을 포함한다.

인터뷰는 이해관계자와의 일대일 또는 소그룹 대화를 통해 요구사항을 도출하는 직접적인 기법이다. 사전에 준비된 질문 목록을 바탕으로 구조화된 인터뷰를 진행하거나, 자유로운 대화를 통해 새로운 통찰을 얻는 비구조화된 인터뷰를 활용할 수 있다. 이 기법은 복잡한 의견이나 숨겨진 요구를 심층적으로 탐색하고, 즉각적인 피드백을 얻는 데 유리하다. 그러나 시간과 비용이 많이 소요되며, 인터뷰어의 주관이나 인터뷰이의 표현 능력에 따라 결과가 편향될 수 있는 단점이 있다.

설문조사는 표준화된 질문지를 다수의 이해관계자에게 배포하여 광범위한 의견을 수량적으로 수집하는 기법이다. 온라인 설문 도구를 활용하면 효율적으로 데이터를 수집하고 통계 분석을 수행할 수 있다. 설문조사는 많은 응답자를 대상으로 일반적인 경향이나 통계적 데이터를 빠르게 얻을 때 효과적이다. 그러나 사전에 질문지를 매우 신중하게 설계해야 하며, 개방형 질문보다는 주로 객관식이나 척도형 질문을 사용한다. 따라서 응답의 깊이가 부족하고, 모호한 질문은 잘못된 해석을 초래할 수 있다.

두 기법은 상호 보완적으로 사용되는 경우가 많다. 예를 들어, 초기 탐색 단계에서는 소수의 핵심 이해관계자와 인터뷰를 진행하여 주요 이슈를 파악한 후, 이를 바탕으로 폭넓은 의견을 수집하기 위한 설문조사를 설계한다. 효과적인 도출을 위해 다음 사항을 고려해야 한다.

워크샵과 브레인스토밍은 이해관계자들의 집단 지성을 활용하여 요구사항을 효과적으로 도출하는 협업 기법이다. 워크샵은 주요 이해관계자들이 한자리에 모여 구조화된 회의를 통해 아이디어를 교환하고 합의를 도출하는 방식이다. 진행자는 사전에 명확한 목표와 의제를 설정하고, 다양한 시각을 가진 참여자들(예: 최종 사용자, 개발자, 기획자, 마케팅 담당자)을 초대한다. 워크샵은 실시간으로 의견 충돌을 해결하고 공동의 비전을 빠르게 수립할 수 있다는 장점이 있다.

브레인스토밍은 창의적인 아이디어를 최대한 많이 생성하는 데 초점을 맞춘 기법이다. 이 과정에서는 비판이나 평가를 보류하고, 아이디어의 양을 중시하며, 다른 사람의 아이디어를 발전시키는 것을 장려한다. 요구사항 도출 초기 단계에서 시스템의 가능성과 잠재적 기능을 탐색하는 데 유용하게 활용된다. 효과적인 브레인스토밍을 위해 마인드맵이나 아이디어 보드 같은 시각적 도구를 함께 사용하기도 한다.

두 기법은 종종 결합되어 사용된다. 예를 들어, 워크샵의 일환으로 브레인스토밍 세션을 진행하여 자유로운 아이디어 발산 단계를 거친 후, 이를 토대로 논의와 수렴 작업을 진행한다. 성공을 위해서는 모든 참여자가 적극적으로 소통할 수 있는 개방적이고 안전한 분위기를 조성하는 것이 중요하다. 이 과정에서 도출된 아이디어는 이후 유스케이스나 시나리오 분석을 위한 중요한 입력 자료가 된다.

유스케이스는 특정 액터가 시스템과 상호작용하여 달성하려는 하나의 목표를 기술한 것이다. 시스템이 사용자나 외부 시스템과의 상호작용을 통해 제공해야 하는 기능적 동작을 구조적으로 묘사하는 데 사용된다. 각 유스케이스는 일반적으로 성공 시나리오와 여러 가지 예외 또는 오류 시나리오를 포함한다. 이는 시스템의 기능적 요구사항을 이해하고 문서화하는 데 매우 효과적인 도구이다.

시나리오는 유스케이스의 구체적인 인스턴스 또는 실행 경로로, 특정 조건 하에서 시스템과 액터 간의 상호작용 순서를 단계별로 서술한다. 예를 들어, '로그인'이라는 유스케이스에는 '정확한 자격 증명으로 로그인하는 시나리오', '잘못된 비밀번호 입력 시나리오', '존재하지 않는 아이디 입력 시나리오' 등이 존재할 수 있다. 시나리오 분석은 잠재적인 오류 상황과 대체 흐름을 발견하는 데 도움을 준다.

유스케이스 및 시나리오 분석의 주요 단계와 산출물은 다음과 같다.

이 분석 기법은 이해관계자, 특히 최종 사용자와의 의사소통을 원활하게 한다. 시각적 다이어그램과 구체적인 이야기 형식의 시나리오는 추상적인 요구사항을 구체화하여 공유된 이해를 형성하는 데 기여한다. 또한, 개발 후반부에 테스트 케이스를 설계하는 중요한 입력 자료가 되기도 한다.

요구사항 식별은 이해관계자로부터 수집된 초기 정보와 요구사항을 체계적으로 찾아내고 문서화하는 과정이다. 이 단계에서는 인터뷰, 워크샵, 유스케이스 분석 등 다양한 요구사항 도출 기법을 통해 얻은 원자료를 바탕으로 명확한 요구사항 항목을 도출한다. 식별된 요구사항은 종종 모호하거나 충돌할 수 있으므로, 이를 명확한 문장으로 재구성하고 관련 정보를 보완하는 작업이 필요하다.

식별된 요구사항은 일관된 기준에 따라 분류되어야 한다. 가장 일반적인 분류 체계는 기능적 요구사항과 비기능적 요구사항으로 구분하는 것이다. 기능적 요구사항은 시스템이 수행해야 할 구체적인 동작이나 서비스(예: "사용자는 아이디와 비밀번호로 로그인할 수 있어야 한다")를 기술한다. 반면, 비기능적 요구사항은 시스템의 품질 속성, 제약 조건, 성능, 보안, 사용성 등을 규정한다(예: "시스템은 동시에 1000명의 사용자를 처리할 수 있어야 한다").

분류는 다음과 같은 추가적인 관점에서도 이루어질 수 있다.

이러한 분류 작업은 요구사항의 속성을 명확히 하고, 이후의 우선순위 설정, 분석, 설계 단계에서 효율적으로 관리하는 데 기초를 제공한다. 특히 비기능적 요구사항은 구현 단계에서 간과되기 쉬우므로 초기부터 명시적으로 식별하고 분류하는 것이 중요하다.

요구사항 분석 과정에서 수집된 요구사항들은 종종 서로 충돌하거나 중복되는 경우가 발생한다. 이러한 모순과 중복을 해결하지 않고 방치하면, 개발 과정에서 지연과 비용 증가를 초래하며 최종 제품의 품질을 저하시킨다. 따라서 분석 단계에서 이를 체계적으로 식별하고 조정하는 작업은 필수적이다.

모순은 주로 서로 다른 이해관계자[1]로부터 상반된 요구가 제시될 때 발생한다. 예를 들어, 사용자 인터페이스의 화려함을 요구하는 요구사항과 시스템의 빠른 응답 속도를 요구하는 요구사항은 기술적으로 충돌할 수 있다. 분석가는 이러한 충돌을 이해관계자들과 협의하여 타협점을 찾거나, 명확한 우선순위 기준에 따라 하나를 선택해야 한다. 중복은 동일한 기능이나 조건이 서로 다른 용어나 형식으로 반복 기술되는 경우로, 이를 통합하지 않으면 불필요한 개발 작업과 유지보수의 혼란을 야기한다.

모순과 중복을 해결하기 위한 체계적인 접근법은 다음과 같다.

이 과정을 통해 명확하고 일관된 요구사항 집합이 확보되며, 이는 이후 설계 및 구현 단계의 튼튼한 기초가 된다. 효과적인 해결은 단순히 문제를 제거하는 것을 넘어, 프로젝트의 핵심 목표와 제약 조건에 대한 이해관계자들의 공유된 인식을 강화하는 역할도 한다.

요구사항의 우선순위 설정은 제한된 자원과 시간 내에 핵심 가치를 먼저 제공하기 위해 각 요구사항의 상대적 중요도와 시급성을 평가하여 순위를 부여하는 과정이다. 이 과정은 프로젝트의 성공 가능성을 높이고 이해관계자 간의 기대치를 조정하는 데 필수적이다.

일반적으로 우선순위는 비즈니스 가치, 구현 복잡도, 위험도, 이해관계자의 요구 강도 등의 기준을 종합적으로 고려하여 결정된다. 널리 사용되는 기법으로는 MoSCoW 기법이 있다. 이 기법은 요구사항을 Must have(필수), Should have(권장), Could have(있으면 좋음), Won't have(이번에는 안 됨)의 네 가지 범주로 분류한다. 다른 방법으로는 상대적 가중치를 부여하는 100점법이나, 각 요구사항의 가치와 비용을 비교하는 비용-편익 분석도 활용된다.

우선순위는 정적이지 않으며, 프로젝트 진행 중에 변경될 수 있다. 시장 환경 변화, 새로운 기술적 통찰, 자원 제약의 변동 등에 따라 재평가가 필요하다. 특히 애자일 방법론에서는 각 스프린트 계획 단계에서 백로그 항목의 우선순위를 지속적으로 조정한다. 명확한 우선순위는 개발팀이 가장 중요한 기능에 집중하게 하고, 프로젝트 일정과 예산 관리의 실질적인 기준을 제공한다.

요구사항 정의서의 문서 개요는 문서의 정체성과 기본 정보를 명확히 하는 서문 역할을 한다. 일반적으로 문서의 제목, 버전, 작성일, 작성자, 승인자, 프로젝트 명, 참조 문서 목록 등을 포함한다. 이는 문서의 공식성을 확립하고, 변경 이력을 관리하며, 관련자 간의 명확한 소통 채널을 제공하는 데 목적이 있다.

문서의 목적 섹션은 이 문서가 왜 작성되었으며, 어떤 문제를 해결하고자 하는지를 기술한다. 주로 요구사항을 명확히 정의하고 이해 관계자 간의 합의를 도출하며, 이후 설계, 구현, 테스트 단계의 기준이 되도록 하는 것을 목표로 한다. 또한, 프로젝트 범위를 공식화하고 개발 팀과 고객 사이의 계약적 근거를 마련하는 중요한 기능을 수행한다.

이러한 개요와 목적은 문서의 나머지 부분을 이해하고 해석하는 데 필요한 기본적인 맥락을 제공한다. 따라서 명확하고 간결하게 작성되어 모든 이해 관계자가 문서의 취지와 범위에 대해 동일한 이해를 공유할 수 있도록 해야 한다.

시스템 범위는 개발 대상 소프트웨어 시스템이 무엇을 포함하고 무엇을 포함하지 않는지를 명확히 정의한 경계이다. 이는 프로젝트의 목표와 한계를 이해관계자 모두가 공유할 수 있도록 하는 핵심 요소이다. 시스템 범위는 일반적으로 포함 기능과 제외 기능의 목록으로 구체화된다. 예를 들어, '온라인 쇼핑몰 시스템은 상품 조회, 장바구니, 결제 기능을 포함하지만, 물류 배송 추적 기능은 제3자 API에 의존한다'와 같이 기술한다. 명확한 범위 설정은 프로젝트의 크기를 통제하고 불필요한 기능 크리프[2]를 방지하는 데 필수적이다.

제약 조건은 시스템 개발과 운영을 제한하는 외부적, 내부적 요소를 의미한다. 이는 주로 기술적, 비즈니스, 운영적, 법적 측면에서 발생한다. 대표적인 제약 조건으로는 예산, 일정, 사용할 기술 스택(예: 특정 DBMS 사용), 성능 목표(예: 동시 사용자 수), 호환성 요구사항(예: 특정 웹 브라우저 지원), 그리고 관련 법규 및 표준 준수(예: 개인정보 보호법, 접근성 지침) 등이 있다. 이러한 제약들은 시스템 설계와 구현에 직접적인 영향을 미치므로 초기 단계에서 명시적으로 식별되어야 한다.

시스템 범위와 제약 조건은 서로 긴밀하게 연결되어 있다. 제약 조건은 종종 시스템 범위의 경계를 형성하거나 특정 기능의 구현 방식을 결정한다. 예를 들어, 예산과 일정이라는 제약은 시스템 범위에서 일부 기능의 우선순위를 낮추거나 제외시키는 근거가 될 수 있다. 따라서 요구사항 정의서에서 이 두 요소는 별도의 절로 구분되더라도 통합적으로 고려되어야 한다. 명확한 범위와 현실적인 제약 조건의 문서화는 프로젝트 성공의 초석을 마련하고, 향후 발생할 수 있는 이해 상충과 변경 요청을 관리하는 기준을 제공한다.

상세 요구사항 명세는 요구사항 정의서의 핵심 부분으로, 식별된 모든 요구사항을 체계적이고 명확하게 기술하는 영역이다. 이 명세는 개발팀, 테스트팀, 이해관계자 모두가 공통의 이해를 바탕으로 작업할 수 있는 기준을 제공한다. 명세는 일반적으로 기능적 요구사항과 비기능적 요구사항으로 구분하여 상세히 기술하며, 각 요구사항은 고유 식별자, 설명, 우선순위, 수용 기준 등을 포함한다.

기능적 요구사항 명세는 시스템이 수행해야 할 구체적인 동작, 기능, 업무 흐름을 기술한다. 각 요구사항은 가능한 한 검증 가능하고 모호하지 않게 서술되어야 한다. 예를 들어, "사용자는 상품을 검색할 수 있다"라는 표현보다는 "사용자는 상품명, 카테고리, 가격 범위를 조건으로 하여 상품 목록을 조회할 수 있으며, 결과는 등록일자 순으로 20개씩 페이징되어 표시된다"와 같이 구체적으로 작성한다. 유스케이스 다이어그램이나 활동 다이어그램을 부록에 포함하여 시각적으로 보완하는 경우도 많다.

비기능적 요구사항 명세는 시스템의 품질 속성과 제약 조건을 정의한다. 이는 성능, 보안, 사용성, 호환성, 안정성 등과 관련된 요구사항을 포함한다. 각 항목은 정량적 또는 정성적으로 측정 가능한 기준을 명시해야 한다. 예를 들어, 성능 요구사항은 "시스템은 최대 1,000명의 동시 사용자를 지원하며, 주요 트랜잭션의 평균 응답 시간은 2초 이내여야 한다"와 같이 명시한다. 보안 요구사항은 인증 정책, 데이터 암호화 기준 등을 포함할 수 있다.

명세화 작업 시에는 다음 표와 같은 형식을 활용하여 요구사항을 구조화하는 것이 일반적이다. 이는 요구사항의 추적성과 관리를 용이하게 한다.

이러한 상세 명세는 이후 설계, 구현, 테스트의 기초가 되며, 특히 수용 테스트의 기준으로 직접 활용된다. 따라서 명확성, 완전성, 일관성, 검증 가능성을 갖추는 것이 중요하다.

• 위키백과 - 요구사항 분석

• 위키백과 - 요구사항 명세

• NIA 소프트웨어공학센터 - 요구사항 정의서 작성 가이드

• 정보통신산업진흥원 - 요구사항 명세서 작성법

• 한국데이터산업진흥원 - 요구사항 분석 및 명세 가이드

• Google Scholar - Requirements Analysis and Specification

• IEEE Xplore - Requirements Engineering

• IBM Developer - 요구사항 분석 기초

• Microsoft Docs - 요구사항 수집 및 분석

• Oracle Help Center - 시스템 요구사항 정의

요구사항 검토 및 확인은 분석된 요구사항이 올바르고 완전하며 일관성을 갖추었는지 평가하는 공식적인 과정이다. 이 단계는 요구사항 정의서의 품질을 보증하고, 이후 설계 및 구현 단계에서 발생할 수 있는 오류와 재작업 비용을 사전에 방지하는 데 핵심적인 역할을 한다. 주요 이해관계자, 개발자, 품질 보증 담당자 등이 참여하여 문서를 면밀히 검토한다.

검토 활동은 일반적으로 검토 회의를 통해 이루어지며, 다음과 같은 기준에 초점을 맞춘다.

• 정확성: 요구사항이 사용자의 실제 필요를 정확히 반영하는가?

• 명확성: 요구사항이 모호하지 않고 명확하게 서술되었는가?

• 완전성: 모든 기능적, 비기능적 요구사항과 제약 조건이 포함되었는가?

• 일관성: 요구사항 간에 상충되거나 모순되는 부분이 없는가?

• 검증 가능성: 각 요구사항이 테스트나 검사, 분석 등을 통해 확인될 수 있는가?

• 추적 가능성: 각 요구사항이 고유 식별자를 가지고 있어 변경 영향을 추적할 수 있는가?

검토 결과 발견된 문제점은 결함 추적 시스템에 기록되고, 수정, 보완, 삭제 등의 조치를 거쳐 요구사항 정의서에 반영된다. 확인 활동은 검토를 넘어 요구사항이 실제 비즈니스 목표와 사용자 요구를 충족시킬 수 있는지 검증하는 것을 포함한다. 이는 프로토타이핑, 모의 사용자 시나리오 실행, 개념 증명 등을 통해 이루어질 수 있다. 효과적인 검토 및 확인은 프로젝트 성공 가능성을 크게 높이는 필수 단계이다.

변경 관리 프로세스는 요구사항 정의서가 승인된 이후 발생하는 모든 요구사항의 변경을 체계적으로 통제하고 관리하는 절차이다. 소프트웨어 개발 과정에서 요구사항 변경은 불가피한 현상이며, 이를 효과적으로 관리하지 않으면 프로젝트 범위가 무제한으로 확대되는 범위 밀림 현상이 발생하거나 일정과 비용이 초과될 수 있다. 따라서 변경 요청을 공식적으로 접수, 평가, 승인, 구현, 추적하는 일련의 프로세스가 필수적이다.

일반적인 변경 관리 프로세스는 다음과 같은 단계로 구성된다.

1. 변경 요청 제출: 이해관계자가 공식적인 변경 요청서를 제출한다. 요청서에는 변경 내용, 이유, 예상 영향 등이 포함된다.

2. 변경 요청 접수 및 기록: 변경 관리 위원회 또는 담당자가 요청을 접수하고 추적 가능한 고유 식별자로 등록한다.

3. 영향 분석 및 평가: 기술적 타당성, 비용, 일정, 리소스, 다른 요구사항에 미치는 영향 등을 종합적으로 분석한다.

4. 승인 또는 거부 결정: 분석 결과를 바탕으로 권한을 가진 위원회나 책임자가 변경을 승인하거나 거부한다.

5. 승인된 변경의 구현 및 통합: 승인된 변경 사항을 요구사항 정의서에 반영하고, 관련 설계, 구현, 테스트 작업을 수행한다.

6. 변경 결과 확인 및 통보: 변경이 완료된 후 결과를 확인하고 모든 이해관계자에게 변경 상태를 통보한다.

이 프로세스의 효과적인 운영을 위해 변경 관리 위원회가 구성되는 경우가 많다. 위원회는 프로젝트 관리자, 개발 리더, 주요 고객 대표 등으로 구성되어 객관적인 의사결정을 담당한다. 또한 모든 변경 요청과 결정 사항은 추적성 행렬에 기록되어 변경의 출처와 결과를 명확히 추적할 수 있도록 한다. 이를 통해 프로젝트의 통제력을 유지하면서도 필요한 변경을 신속하게 수용할 수 있는 유연성을 확보한다.

추적성 행렬은 요구사항과 다른 개발 산출물 간의 관계를 추적하고 관리하기 위한 도구이다. 일반적으로 행과 열로 구성된 표 형태로, 특정 요구사항이 어떤 설계 요소, 구현 모듈, 테스트 케이스와 연결되는지를 명확히 보여준다. 이 행렬을 통해 요구사항이 시스템 전체에 어떻게 반영되고 검증되었는지를 일목요연하게 확인할 수 있다.

주요 추적 관계는 다음과 같이 분류된다.

추적성 행렬을 구축하고 유지함으로써 여러 이점을 얻을 수 있다. 첫째, 요구사항 변경 시 영향을 받는 모든 설계, 코드, 테스트를 신속하게 식별하여 변경 관리 효율성을 높인다. 둘째, 모든 요구사항이 구현되고 테스트되었는지 확인하여 누락을 방지하고 품질 보증에 기여한다. 마지막으로, 프로젝트 이해관계자에게 투명한 의사소통 채널을 제공한다.

그러나 추적성 행렬을 수동으로 관리하는 것은 시간과 노력이 많이 들며, 복잡한 프로젝트에서는 행렬 자체가 방대해질 수 있다. 따라서 요구사항 관리 도구를 활용하여 관계를 자동으로 기록하고 시각화하는 것이 일반적이다. 효과적인 추적성 관리는 소프트웨어 개발 생명주기 전반에 걸쳐 요구사항의 일관성과 완전성을 보장하는 핵심 활동이다.

요구사항 관리 도구는 요구사항의 수집, 분석, 명세, 추적, 변경 관리 등을 지원하는 소프트웨어 애플리케이션이다. 이러한 도구는 복잡한 프로젝트에서 수많은 요구사항을 체계적으로 관리하고, 팀원 간 협업을 용이하게 하며, 요구사항 추적성을 보장하는 데 필수적이다. 전통적인 문서 기반 관리 방식에 비해 중앙 집중식 저장소를 제공하여 정보의 일관성과 최신 상태 유지를 가능하게 한다.

주요 도구들은 일반적으로 다음과 같은 핵심 기능을 제공한다.

시장에는 다양한 상용 및 오픈소스 도구가 존재한다. 상용 도구로는 IBM DOORS, Jama Connect, Modern Requirements 등이 있으며, 강력한 추적성과 엔터프라이즈급 기능을 제공한다. 반면, Jira(와 그 플러그인), Confluence, Azure DevOps Boards와 같은 애자일/DevOps 플랫폼도 기본적인 요구사항 관리 기능을 통합하여 널리 사용된다. 오픈소스 옵션으로는 ReqSuite, OSLC 호환 도구들도 있다.

도구 선택은 프로젝트 규모, 방법론(예: 애자일, 폭포수 모델), 예산, 팀의 기술 숙련도, 조직의 기존 툴체인과의 통합 필요성 등 여러 요소를 고려하여 결정해야 한다. 효과적인 도구 도입은 요구사항 관리 프로세스의 형식화와 자동화를 촉진하여, 의사소통 오류를 줄이고 프로젝트 성공 확률을 높이는 데 기여한다.

애자일 방법론과 폭포수 모델 같은 전통적 방법론은 요구사항 분석과 명세화에 서로 다른 접근 방식을 취한다.

전통적 방법론에서는 프로젝트 초기에 모든 요구사항을 완벽하게 정의하고 문서화하는 것을 중시한다. 요구사항 정의서는 계약서와 같은 구속력 있는 문서로 간주되며, 개발 단계로 넘어가기 전에 고객의 최종 승인을 받는 경우가 많다. 이 접근법은 요구사항이 명확하고 변경 가능성이 낮은 프로젝트에 적합하지만, 초기 명세의 오류나 변경 요청이 발생할 경우 대응이 어렵고 비용이 크게 증가할 수 있다는 단점이 있다.

반면, 애자일 방법론은 변화에 대응하는 유연성을 핵심으로 한다. 요구사항은 제품 백로그에 사용자 스토리 형태로 기록되며, 상세한 내용은 개발이 임박한 시점에 협의를 통해 구체화된다. 스프린트 단위로 반복적인 개발과 검증을 진행하며, 고객의 피드백을 지속적으로 반영하여 요구사항을 진화시킨다. 이 방식은 시장 요구나 사용자 니즈가 빠르게 변하는 프로젝트에 효과적이지만, 진화하는 요구사항을 체계적으로 관리하고 전체 범위를 파악하는 데 어려움이 있을 수 있다.

두 접근법의 차이점은 다음 표와 같이 요약할 수 있다.

최근에는 하이브리드 형태로 두 방법론의 장점을 결합하려는 시도도 나타나고 있다. 예를 들어, 초기에는 전통적 방식으로 큰 그림과 핵심 요구사항을 정의한 후, 세부 개발은 애자일 방식으로 진행하는 것이다. 프로젝트의 성격, 규모, 불확실성 수준에 따라 적절한 접근법을 선택하거나 조합하는 것이 중요하다.