클로즈 아키텍처 메커니즘 기반의 요구사항 추적성 매트릭스 (Requirement Traceability Matrix Based on Closed Architecture Mechanism) 2017. 11. 04 홍익대학교 소프트웨어 공학 연구실 변 은 영 안녕하세요 홍익대학교 소프트웨어 공학 연구실 변은영입니다. 클로즈 아키텍처 메커니즘 기반의 요구사항 추적성 매트릭스에 대해 발표하겠습니다. 요구사항 추적성이란 소프트웨어 개발 전체 프로세스의 산출물들간의 연결성을 보장하는 것으로, 특정 단계에서의 산출물들이 인접한 단계의 어떤 산출물에 영향을 주는지를 추적할 수 있습니다.

Contents I. 연구 배경 II. 관련 연구 III. 클로즈 아키텍처(Closed Architecture) 목차는 다음과 같습니다. 연구 배경, 관련 연구, 클로즈 아키텍처, 요구사항 추적성 매트릭스, 결론 및 향후 연구 순서로 발표하겠습니다. IV. 요구사항 추적성 매트릭스 V. 결론 & 향후 연구

요구사항의 중요성 연구 배경 “A good percentage of errors occur at the requirements stage, and if they’re not discovered until later on, the cost of fixing them is substantially higher.” “요구 사항 단계에서 많은 오류가 발생하며, 나중에 발견되면 상당한 수정 비용이 필요하다.” - Dave Gluch “As many as 51% of software projects that fail do so because of poor requirements management, making it the single biggest reason for project failure.” “부실한 요구사항 관리는 소프트웨어 프로젝트의 51%가 실패로 돌아가도록 만들고 있으며, 이는 프로젝트 실패의 가장 큰 원인” 연구 배경입니다. Dave 는 “요구 사항 단계에서 많은 오류가 발생하며, 나중에 발견되면 수정하는 비용이 상당히 높다.”라고 말했습니다. 소프트웨어 개발 프로세스인 Requirement, Analysis, Design, Implementation, Testing 단계 중에서 뒷 단계로 갈수록 버그는 급속이 증가하게 되고 많은 버그들을 수정하기 위해서는 많은 시간과 비용이 소모될 수 밖에 없습니다. Christopher는 “부실한 요구사항 관리는 소프트웨어 프로젝트의 50%가 실패로 돌아가도록 만들고 있으며, 이는 프로젝트 실패의 가장 큰 원인”이라고 말했습니다. 2014년 ESI International survey 에 따르면 Poor한 Requirement Definition이 프로젝트 실패의 원인 요인들 중 50%로 가장 높은 것을 볼 수 있습니다. 프로젝트 성공률을 좌우할 정도로 매우 중요한 SW 요구사항의 - Christopher Lindquist [ESI International survey, 2014]

소프트웨어 요구사항 관리(SW Requirement Management) 요구사항의 중요성 연구 배경 소프트웨어 요구사항 관리(SW Requirement Management) 요구사항 관리를 통해 소프트웨어 개발 단계 중 빠르게 버그를 발견 마지막 개발 단계(테스팅)로 갈수록 버그 수정 시 드는 시간과 비용 절감 이를 통해, 프로젝트의 성공률 향상 & SW 품질 향상 관리가 중요합니다. 요구사항 관리를 통해서 소프트웨어의 전체 개발 프로세스 중 빠르게 버그를 발견할 수 있습니다. 또, 마지막 개발 단계인 테스팅으로 갈수록 버그 수정시에 드는 많은 시간과 비용을 절감시킬 수 있습니다. 따라서 프로젝트의 성공률과 소프트웨어의 품질을 향상 시킵니다. Program Bug Time Project Success decrease Requirement Money Quality

요구사항 관리의 어려움 연구 배경 요구사항 관리의 어려움 시장 변화, 신기술, 경쟁업체의 대응, 설계 결함, 테스트 실패 등의 다양한 외부적 요인 -> 잦은 요구사항 변경 요청 SW 개발 과정의 마지막 단계인 ‘테스팅’에서 요구사항의 충족 여부인 커버리지 측정 -> 요구사항과 테스트의 연계성 부족으로 테스팅이 어려움 소프트웨어 개발 프로세스 Requirement Analysis Design Coding Testing 하지만, 현대 소프트웨어 산업에서는 요구사항 관리에 많은 어려움이 있습니다. 그 대표적인 이유는 다음의 두 가지와 같습니다. 먼저 첫 번째는 시장 변화, 신기술, 경쟁 업체의 대응, 설계 결함, 테스트 실패 등의 다양한 외부적 요인으로 인해서 이해관계자들로부터 잦은 요구사항 변경을 요청하게 됩니다. 만약, 코딩 단계가 모두 완료된 후, 요구사항 변경을 요청 받는다면 , 변경된 요구사항과 관련된 Coding, Design, Analysis, Requirements의 요소들을 모두 수정해야 하는 어려움이 있습니다. 변경 요구사항이 각 단계의 어떤 항목에 영향을 주는지 알 수 없다는 게 어려움의 주요한 원인이 됩니다. 요구사항 변경 요청 변경된 요구사항과 관련된 요소들 모두 수정

테스트 케이스 작성 (요구사항 충족 커버리지) 요구사항 관리의 어려움 연구 배경 요구사항 관리의 어려움 시장 변화, 신기술, 경쟁업체의 대응, 설계 결함, 테스트 실패 등의 다양한 외부적 요인 -> 잦은 요구사항 변경 요청 SW 개발 과정의 마지막 단계인 ‘테스팅’에서 요구사항의 충족 여부인 커버리지 측정 -> 요구사항과 테스트의 연계성 부족으로 테스팅이 어려움 소프트웨어 개발 프로세스 Requirement Analysis Design Coding Testing 두 번째는 SW 개발 과정의 마지막 단계인 테스팅에서 요구사항의 충족 여부인 커버리지를 측정할 때, 요구사항과 테스트의 연계성 부족으로 테스팅이 어렵습니다. 또한, 테스트 단계에서 실패할 시 첫 번째와 마찬가지로 수정해야 하는 각 단계의 영향 받는 요소들을 파악하기가 어렵습니다. 이러한 문제들을 해결하기 위해 요구사항 추적성이 필요합니다. 테스트 케이스 작성 (요구사항 충족 커버리지) 연계성 부족

Traceability 연구 배경 요구사항 관리의 하위 기능으로, 1) SW 개발 전 프로세스의 요소, 산출물들 간의 연결성을 보장한다. 2) 산출물들의 파생 경로를 식별한다. 3) 각 산출물들이 SW에 필요한 요소인지를 확립한다. 소프트웨어 개발 프로세스 Forward Requirement Analysis Design Coding Testing Traceability는 요구사항 관리의 하위 기능으로 SW 개발 전체 프로세스의 요소, 산출물들 간의 연결성을 보장합니다. 따라서 한 단계의 산출물들이 다음 단계의 어떤 산출물들을 파생시키는지 경로를 식별할 수 있습니다. 또, 각 단계의 산출물들이 요구사항을 만족시키기 위해 필요한 요소인지를 확립할 수 있습니다. 추적성은 아래 그림과 같이 요구사항에서부터 테스팅으로 추적하는 Forward Traceability와, 테스팅에서 부터 요구사항으로 추적하는 Backward Traceability로 나누어집니다. 먼저 Forward의 경우는 앞에서 말씀 드렸던 첫 번째 문제인 잦은 요구사항 변경 요청에 대응할 수 있습니다. 요구사항이 변경된다면 Forward Traceability를 통해서 변경된 요구사항에 영향을 받는 Analysis, Design, Coding, Testing 단계의 요소들을 구분할 수 있습니다. Backward Traceability로는 테스팅 단계에서 요구사항과의 연계성을 확보할 수 있고 테스팅이 실패했을 때 수정해야 하는 요소들을 추적할 수 있습니다. Backward

관련 연구 요구사항 관리 도구 효율적인 요구사항 관리를 위한 다양한 요구사항 관리 도구 대표적인 상용 제품으로 CASE Spec, Polarion, Requisite Pro, DOORS, Caliber RM, Aligned Elements Forward & Backward Traceability 다음은 관련 연구입니다. 효율적인 요구사항 관리를 위해 다양한 상용 도구들이 존재하는데, 대표적으로는 CASE Spec, Polarion, Requisite Pro, DOORS< Caliber RM, Aligned Elements 가 있습니다. 아래 표는 이 도구들이 각 기능을 지원하는지, 하지 않는지를 나타내고 있습니다. 그 중에서 Multi-dimensional Traceability는 앞에서 설명했던 Forward와 Backward Traceability를 모두 지원하고 있는지를 나타내고 있습니다. 지원하는 도구들도 있지만, 지원하지 않는 도구들도 많습니다.

관련 연구 DOORS Gartener Dataquest 자료에 의하면 세계 시장 점유율 37.1%로 1위 요구사항 정의 관점보다는 관리에 가까운 도구 요구사항 기반으로 프로젝트 관리, 설계, 개발, 테스트 등을 수행할 수 있도록 하는 것이 목적 단점 요구사항 한 문장에 모두 ID가 할당되므로 대규모 시스템에서는 복잡 Forward 추적성만 제공 가격이 비쌈 이 도구들 중 DOORS와 Polarion에서 제공하고 있는 추적성에 대해 알아봤습니다. 먼저 DOORS는 Gartener Dataquest 자료에 의하면 세계 시장 점유율 37.1%로 1위를 차지하고 있는 요구사항 관리 도구 입니다. 이 도구는 요구사항 기반으로 프로젝트 관리, 설계, 개발, 테스트 등을 수행할 수 있도록 하는 것이 목적입니다. 하지만, 다음과 같은 단점이 있습니다. 요구사항 한 문장에 모두 ID가 할당되기때문에 대규모 시스템에서는 너무 많은 ID로 관리가 복잡해 질 수 있습니다. 추적성은 아래의 그림과 트리로 가시화하여 식별을 쉽게 한다는 장점이 있지만 Forward 추적성만을 제공하고 있습니다. DOORS의 추적성

관련 연구 Polarion 요구사항 재사용 추적성 테이블 제공(요구사항-테스트 케이스 – defect) 단점 링크(클릭)로만 추적성 제공 Forward 추적성만 제공 가격이 비쌈 Polarion은 다른 도구와는 다르게, 요구사항 재사용 서비스를 제공하고 있고, 추적성 테이블을 제공합니다. 하지만, 오픈쪽 그림과 같이 요구사항-테스트 케이스-defect 간의 추적성 테이블만을 제공하고 있고, 소프트웨어 개발 전체 프로세스에서는 제공하지 않습니다. 이 도구의 단점은 제약된 추적성 테이블, 링크로만 추적성을 제공하고, Forward Traceability만 가능합니다. Polartion의 추적성 Polartion 추적성 테이블

클로즈 아키텍처(Closed Architecture) 오픈 아키텍처 (Open Architecture) 모든 레이어에 접근할 수 있다. 레이어 간의 종속성을 높여 복잡해질 수 있다. 클로즈 아키텍처 (Closed Architecture) 인접한 레이어만 접근할 수 있다. 레이어 간의 종속성을 줄임으로써 독립성을 향상 시킨다. 소프트웨어 개발 프로세스 오픈 아키텍처 Requirement Analysis Design Coding Testing 다음은 클로즈 아키텍처입니다. 이 논문에서 언급하는 요구사항 추적성 매트릭스는 클로즈 아키텍처 메커니즘을 기반으로 하고 있습니다. 이와는 반대의 의미를 갖는 것이 오픈 아키텍처 입니다. 오픈 아키텍처는 모든 레이어에 접근할 수 있습니다. 따라서 레이어 간의 종속성을 높이기 때문에 복잡해 질 수 있습니다. 아래의 그림에서도 오픈 아키텍처는 연결 선이 매우 많고 복잡함을 알 수 있습니다. 반대로 클로즈 아키텍처는 인접한 레이어만 접근할 수 있습니다. 레이어 간의 종속성을 줄임으로써 독립성을 향상 시킵니다. 아래의 그림에서 클로즈 아키텍처는 인접한 레이어들 간의 접근만 가능하고, 5개의 단계에서는 4개의 링크가 생기게 됩니다. 클로즈 아키텍처

요구사항 추적성 매트릭스 요구사항 추적성 매트릭스 소프트웨어 개발 프로세스 단계별 산출물 정의 클로즈 아키텍처 기반이므로 인접한 두 단계에서의 산출물간의 추적성을 매트릭스로 표기 각 항목들은 아이디(R, UC, US, O, MD, TC, TS)로 표기 전체 개발 프로세스에서 총 6개의 매트릭스 생성 다중 체크를 통해서 추적성의 관계가 1대 다(one to many) 일 때 쉽게 추적 Software Life Cycle step name output 1 Requirement Requirement(R) 2 Analysis UseCase(UC) 3 Design UseCaseScenario(US) 4 Implementation Object(O) Method(MD) 5 Test TestCase(TC) Test Script(TS) ① 유스 케이스(UC) 요구 사항(R) 우선 순위 UC1 UC2 UC3 UC4 UC5 UC6 R1 5 R2 2 R3 R4 4 R5 R6 1 R7 R8 R9 ② 다음은 클로즈 아키텍처 메커니즘을 기반으로 하는 요구사항 추적성 메트릭스 입니다. 먼저 소프트웨어 개발 전체 프로세스의 단게별 산출물을 정의합니다. 프로세스는 Requirement, Analysis, Design, Implementation, Test로 구분되고 각각의 산출물은 Requirement, UseCase, UseCaseScenario, Object, Method, TestCase, Test Script로 구성됩니다. Implementation과 Test 단계에서 처럼 산출물은 하나가 아닌 여러 개 일 수도 있습니다. 각 항목들은 R, UC, US, O, MD, TC, TS로 아이디를 표기합니다. 산출물이 7개로 구성되기 때문에 인접한 단계들 간의 추적성 매트릭스는 총 6개가 생성됩니다. 대표적으로 첫번째 추적성 매트릭스인 요구사항과 유스케이스 간의 매트릭스를 보게 되면 오른쪽과 같습니다. 각 요소들이 서로 영향을 준다면 체크 표기하여 나타냅니다. 또한, 다중 체크를 통해서 추적성의 관계가 1대 다 일때도 쉽게 추적이 가능합니다. ③ ④ ⑤ ⑥ 소프트웨어 개발 프로세스 단계별 산출물 ① 요구사항 & 유스 케이스 간의 추적성 매트릭스

요구사항 추적성 매트릭스 – 적용사례(타겟 : 건물 도어락 시스템) 건물주와 주거자가 도어락 비밀번호를 통해 건물에 출입 출입 시 입구 조명 제어 요구사항(R) – 유스 케이스(UC) 유스 케이스(UC) 요구 사항(R) 우선 순위 UC1 UC2 UC3 UC4 UC5 UC6 R1 5 R2 2 R3 R4 4 R5 R6 1 R7 R8 R9 다음은 건물 도어락 시스템에 요구사항 추적성 매트릭스를 적용한 결과 입니다. 이 시스템은 건물주와 주거자가 도어락 비밀번호를 통해 건물에 출입하고 출입 시에 입구 조명이 제어됩니다. 먼저 요구사항과 유스 케이스는 다래와 같이 구성되고 각각의 요소들은 보이지는 않지만 서로 영향을 주는 연결되어 있는 상태입니다. 이들을 기반으로 오른쪽과 같이 추적성 매트릭스를 구성합니다.

요구사항 추적성 매트릭스 – 적용사례(타겟 : 건물 도어락 시스템) 건물주와 주거자가 도어락 비밀번호를 통해 건물에 출입 출입 시 입구 조명 제어 유스 케이스(UC) – 유스 케이스 시나리오(US) 유스 케이스 시나리오(US) 유스 케이스(UC) 우선 순위 US1 US2 US3 US4 US5 UC1 5 UC2 2 UC3 UC4 4 … UC5 UC6 1 마찬가지로 유스 케이스-유스 케이스 시나리오

요구사항 추적성 매트릭스 – 적용사례(타겟 : 건물 도어락 시스템) 건물주와 주거자가 도어락 비밀번호를 통해 건물에 출입 출입 시 입구 조명 제어 유스 케이스 시나리오(US) – 객체(O) ③ 유스 케이스 시나리오(US) – 객체(O) 객체(O) 유스 케이스 시나리오(US) 우선 순위 O1 O2 O3 O4 O5 US1 5 US2 2 US3 US4 4 … US5 US6 1

요구사항 추적성 매트릭스 – 적용사례(타겟 : 건물 도어락 시스템) 건물주와 주거자가 도어락 비밀번호를 통해 건물에 출입 출입 시 입구 조명 제어 객체(O) – 메소드(MD) ④ 객체(O) – 메소드(MD) 메소드(MD) 객체(O) 우선 순위 MD1 MD2 MD3 MD4 MD5 O1 5 O2 2 O3 … O4 4 O5 객체와 메소드의 추적성 매트릭스를 구성합니다. 해당 시스템이 테스트 단계는 아직 진행하지 않았기 때문에 테스트 케이스와 스크립트의 추적성은 나타내지 않았습니다.

요구사항 추적성 매트릭스 – 적용사례(타겟 : 건물 도어락 시스템) 요구사항 (Requirement) 유스 케이스 (Use Case) 유스 케이스 시나리오 (Use Case Senario) 구현 (Implementation) ① 요구사항(R) – 유스 케이스(UC) 그 결과 요구사항, 분석, 설계, 구현 단계에서의 추적성 매트릭스는 다음과 같이 생성됩니다. 요구사항과 유스 케이스 간의 매트릭스, 유스 케이스와 유스 케이스 시나리오의 메트릭스, 구현 단계에서는 산출물이 객체와 메소드로 나누어지기 때문에 유스 케이스 시나리오와 구현 단계에서의 매트릭스는 유스 케이스 시나리오와 객체, 객체와 메소드로 2개가 생성됩니다. ② 유스 케이스(UC) – 유스 케이스 시나리오(US) ③ 유스 케이스 시나리오(US) – 객체(O) ④ 객체(O) – 메소드(MD) 유스 케이스(UC) 요구 사항(R) 우선 순위 UC1 UC2 UC3 UC4 UC5 UC6 R1 5 R2 2 R3 R4 4 R5 R6 1 R7 R8 R9 유스 케이스 시나리오(US) 유스 케이스(UC) 우선 순위 US1 US2 US3 US4 US5 UC1 5 UC2 2 UC3 UC4 4 … UC5 UC6 1 객체(O) 유스 케이스 시나리오(US) 우선 순위 O1 O2 O3 O4 O5 US1 5 US2 2 US3 US4 4 … US5 US6 1 메소드(MD) 객체(O) 우선 순위 MD1 MD2 MD3 MD4 MD5 O1 5 O2 2 O3 … O4 4 O5

요구사항 추적성 매트릭스 – 적용사례(타겟 : 건물 도어락 시스템) MD1 O1 MD2 Forward O2 MD3 … R2 UC2 US3 O3 MD4 O4 … MD5 ① 요구사항(R) – 유스 케이스(UC) ② 유스 케이스(UC) – 유스 케이스 시나리오(US) ③ 유스 케이스 시나리오(US) – 객체(O) ④ 객체(O) – 메소드(MD) 유스 케이스(UC) 요구 사항(R) 우선 순위 UC1 UC2 UC3 UC4 UC5 UC6 R1 5 R2 2 R3 R4 4 R5 R6 1 R7 R8 R9 유스 케이스 시나리오(US) 유스 케이스(UC) 우선 순위 US1 US2 US3 US4 US5 UC1 5 UC2 2 UC3 UC4 4 … UC5 UC6 1 객체(O) 유스 케이스 시나리오(US) 우선 순위 O1 O2 O3 O4 O5 US1 5 US2 2 US3 US4 4 … US5 US6 1 메소드(MD) 객체(O) 우선 순위 MD1 MD2 MD3 MD4 MD5 O1 5 O2 2 O3 … O4 4 O5 UC2 US3 O1 O2 O3 O4 MD1 MD2 MD3 MD4 MD5 O1 R2 UC2 O2 US3 O3 O4 요구사항 추적성 매트릭스로 Forward와 Backward Traceability의 과정은 다음과 같습니다. 먼저 Forward에서 Requirement2의 추적성을 보면 UC2로 UC2는 US3로 US3는 O1,2,3,4로 O1,2,3,4는 MD1,2,3,4,5로 연결성을 갖습니다. Backward

요구사항 추적성 매트릭스 – 적용사례(타겟 : 건물 도어락 시스템) MD1 O1 MD2 Forward O2 MD3 … R2 UC2 US3 O3 MD4 O4 … MD5 ① 요구사항(R) – 유스 케이스(UC) ② 유스 케이스(UC) – 유스 케이스 시나리오(US) ③ 유스 케이스 시나리오(US) – 객체(O) ④ 객체(O) – 메소드(MD) 유스 케이스(UC) 요구 사항(R) 우선 순위 UC1 UC2 UC3 UC4 UC5 UC6 R1 5 R2 2 R3 R4 4 R5 R6 1 R7 R8 R9 유스 케이스 시나리오(US) 유스 케이스(UC) 우선 순위 US1 US2 US3 US4 US5 UC1 5 UC2 2 UC3 UC4 4 … UC5 UC6 1 객체(O) 유스 케이스 시나리오(US) 우선 순위 O1 O2 O3 O4 O5 US1 5 US2 2 US3 US4 4 … US5 US6 1 메소드(MD) 객체(O) 우선 순위 MD1 MD2 MD3 MD4 MD5 O1 5 O2 2 O3 … O4 4 O5 UC1 UC2 US1 US2 US3 O1 MD3 R1 R2 R3 R4 R5 UC1 UC2 US1 US2 US3 O1 요구사항 추적성 매트릭스로 Forward와 Backward Traceability의 과정은 다음과 같습니다. 먼저 Forward에서 Requirement2의 추적성을 보면 UC2로 UC2는 US3로 US3는 O1,2,3,4로 O1,2,3,4는 MD1,2,3,4,5로 연결성을 갖습니다. R1 US1 R2 UC1 O1 MD3 US2 R3 UC2 US3 R4 R5 Backward

요구사항 추적성 매트릭스 요구사항 추적 시스템 일감 추적을 통해 각 개발 프로세스의 항목들을 추적 전체 개수와 진행 중, 완료된 항목들을 구분 프로젝트의 전체 일정 관리는 Gantt 차트로 수행 정의한 매트릭스를 적용하여 클로즈 아키텍처 기반의 추적성 보장 클로즈 아키텍처 기반의 요구사항 매트릭스를 기반으로 구현한 요구사항 추적 시스템입니다. 일감 추적을 통해서 각 개발 프로세스의 항목들 추적이 가능합니다. 아래 표에서와 같이 진행 중인 항목, 완료된 항목, 전체 항목 개수를 구분할 수 있습니다. 프로젝트 전체 일정 관리는 Gantt 차트로 수행됩니다. 또한, 정의한 매트릭스를 적용하여 클로즈 아키텍처 기반의 추적성을 보장합니다. 일감 추적 Gantt 차트 추적성 매트릭스

결론 및 향후 연구 결론 향후 연구 요구사항 관리 상용 도구들은 Backward 추적성을 보장하지 않음 또는, 소프트웨어 개발 단계 일부분에서 추적성을 제공함 이를 보안하기 위한 클로즈 아키텍처 기반의 요구사항 추적성 매트릭스 제안 소프트웨어 개발 전 단계의 산출물들간의 추적성 보장 이를 통해 빈번한 요구사항 변경, 테스트 실패 시의 많은 시간과 비용의 소비 문제 해결 소프트웨어 개발의 효율성 향상 마지막으로 결론 및 향후 연구입니다. 요구사항 관리 상용 도구들은 Backward 추적성을 보장하지 않는 도구들이 많았고, 또는 소프트웨어 개발 단계 일부분에서 추적성을 제공하고 있었습니다. 이런 문제들을 보안하기 위해 클로즈 아키텍처 기반의 요구사항 추적성 매트릭스를 제안했습니다. 따라서, 빈번한 요구사항 변경, 테스트 실패 시의 많은 시간과 비용이 소비되는 문제를 해결할 수 있습니다. 결과적으로 소프트웨어 개발의 효율성을 향상시킵니다. 향후에는 요구사항 추적성을 오픈 아키텍처로 개선하여 소프트웨어 개발 전 단계에서 추적성을 제공하고자 합니다. 또한 현재 Forward 추적성만 제공하고 있는 DOORS의 추적성 트리 가시화를 개선하여 Backward 트리 가시화에 대한 연구를 하고자 합니다. 그리고 기존 연구 주제인 ‘코드 재사용＇을 ‘요구사항 재사용＇으로 확장하여 연구할 예정입니다. 향후 연구 요구사항 추적성을 오픈 아키텍처 개선하여 소프트웨어 개발 전 단계에서 추적성 제공 DOORS의 추적성 트리 가시화를 개선하여 Backward 트리 가시화에 대한 연구 기존 연구 주제 ‘코드 재사용＇을 ‘요구사항 재사용’으로 확장