@neobiotechlabs/neobiotech-dev-agent 0.1.7

package/vendor/dev-docs-templates/templates/mdr_docs/ER/sprint/software-detailed-design.md

@@ -0,0 +1,321 @@
+# Software Detailed Design (SDD): {PRODUCT_NAME}
+
+<!-- AI AGENT 작성 지침
+이 문서는 IEC 62304 Cl.5.4 기반 SW 상세 설계서 (Class B/C 필수)입니다.
+작성 전 반드시 다음 문서를 참조하세요:
+  - SAD(software-architecture-description.md): 아키텍처 및 아이템 구조 확인
+  - SW 요구사항 명세서(software-requirements-list.md): 각 요구사항 ID 확인
+  - FMEA(risk-table-fmea.md): 위험 통제 관련 설계 반영 여부 확인
+
+작성 지침:
+1. 유닛(Unit)별로 섹션 3.x를 반복 작성하세요
+2. Class C의 경우 알고리즘, 분기 조건, 오류 처리를 상세히 기술해야 합니다
+3. Class B의 경우 인터페이스 수준까지 기술합니다
+4. 모든 유닛은 SRS 요구사항 ID와 추적 연결을 명시해야 합니다 (Cl.5.4.2)
+5. SOUP 연동 유닛의 경우 격리 전략과 오류 처리를 반드시 기술하세요
+
+PlantUML 다이어그램 작성 지침:
+- 클래스 다이어그램: 유닛 간 의존성 표현 -> 섹션 2.2에 작성
+- 활동 다이어그램: 유닛 처리 흐름 표현 -> 각 유닛 섹션(3.x)에 작성
+- 시퀀스 다이어그램: 유닛 간 상호작용 표현 -> 섹션 4.1에 작성
+- 상태 다이어그램: 상태 전이가 있는 유닛에 사용
+
+PlantUML 블록 형식: ```plantuml ... ```
+-->
+
+**문서 번호**: {DOC_ID}
+**버전**: {VERSION} | **상태**: Draft
+**작성일**: {DATE} | **작성자**: {AUTHOR}
+**검토자**: {REVIEWER} | **승인자**: {APPROVER}
+
+---
+
+## 표준 요건 매핑 (Standard Requirements Mapping)
+
+| IEC 62304 조항 | 제목                      | 해당 섹션          | Class |
+| -------------- | ------------------------- | ------------------ | ----- |
+| Cl. 5.4.1      | SW 유닛 구현 및 검증 계획 | 1. 설계 개요       | B, C  |
+| Cl. 5.4.2      | SW 유닛 검증              | 5. 유닛 검증 계획  | B, C  |
+| Cl. 5.4.3      | SW 유닛 추가 상세 설계    | 3. 유닛 상세 설계  | C     |
+| Cl. 5.3.2      | 아키텍처 인터페이스       | 4. 인터페이스 설계 | B, C  |
+| Cl. 5.5.2      | 유닛 구현 검증            | 5. 유닛 검증 계획  | B, C  |
+| ISO 14971 Cl.6 | 위험 통제 조치            | 6. 위험 관련 설계  | -     |
+
+---
+
+## 1. 설계 개요 (Design Overview)
+
+### 1.1 목적 및 범위
+
+이 문서는 {PRODUCT_NAME}의 {SW_ITEM_NAME} 아이템을 구성하는 SW 유닛의 상세 설계를 기술한다.
+
+- **대상 SW 아이템**: {SW_ITEM_NAME} ({ITEM_ID})
+- **IEC 62304 SW 안전 등급**: Class {IEC62304_CLASS}
+- **참조 SAD 문서**: {SAD_DOC_ID}
+
+### 1.2 포함 유닛 목록
+
+<!-- AI AGENT: SAD에서 정의된 아이템 내 유닛 목록을 가져와 작성하세요 -->
+
+| 유닛 ID  | 유닛 명       | 안전 등급     | 주요 기능         |
+| -------- | ------------- | ------------- | ----------------- |
+| UNIT-001 | {UNIT_1_NAME} | Class {CLASS} | {UNIT_1_FUNCTION} |
+| UNIT-002 | {UNIT_2_NAME} | Class {CLASS} | {UNIT_2_FUNCTION} |
+
+---
+
+## 2. 유닛 구조 (Unit Structure)
+
+### 2.1 유닛 분해 구조
+
+```
+{SW_ITEM_NAME} ({ITEM_ID})
+  |-- {MODULE_1_NAME}
+  |     |-- UNIT-001: {UNIT_1_NAME}
+  |     |-- UNIT-002: {UNIT_2_NAME}
+  |-- {MODULE_2_NAME}
+        |-- UNIT-003: {UNIT_3_NAME}
+```
+
+### 2.2 유닛 의존성 다이어그램
+
+<!-- AI AGENT: 유닛 간 의존 관계를 클래스 다이어그램 형태로 표현하세요
+유닛이 다른 유닛의 함수를 호출하거나 인터페이스를 사용하는 경우 화살표로 표현합니다
+
+지침:
+- 각 유닛을 class로 표현
+- 의존 방향을 -->  또는 ..> 으로 표현
+- SOUP 의존성은 <<external>> 스테레오타입 사용
+
+예시: -->
+
+```plantuml
+@startuml SDD_Unit_Dependencies
+skinparam classStyle rectangle
+
+class "UNIT-001\nDataInputHandler" as U1 {
+  + validate(input: InputData): bool
+  + preprocess(data: InputData): ProcessedData
+}
+
+class "UNIT-002\nInferenceEngine" as U2 {
+  + predict(data: ProcessedData): Result
+  - loadModel(): void
+}
+
+class "UNIT-003\nResultFormatter" as U3 {
+  + format(result: Result): OutputDTO
+  + applyThreshold(result: Result): RiskLevel
+}
+
+class "PyTorch v2.0\n(SOUP-002)" as SOUP <<external>>
+
+U1 --> U2 : passes ProcessedData
+U2 --> U3 : passes Result
+U2 ..> SOUP : uses (isolated via wrapper)
+
+note bottom of U2
+  Class C: 오분류 시 환자 위해 가능성
+  SOUP 격리: InferenceWrapper 래퍼 클래스 사용
+end note
+@enduml
+```
+
+---
+
+## 3. 유닛 상세 설계 (Unit Detailed Design)
+
+> IEC 62304 Cl.5.4.3 (Class C 필수): 알고리즘, 데이터 구조, 처리 조건 상세 기술
+
+---
+
+### 3.1 {UNIT_1_NAME} (UNIT-001)
+
+#### 3.1.1 목적 (Purpose)
+
+<!-- AI AGENT: 이 유닛이 수행하는 단일 책임(Single Responsibility)을 한 문장으로 기술하세요 -->
+
+{UNIT_1_PURPOSE}
+
+#### 3.1.2 알고리즘 / 처리 흐름 (Algorithm / Processing Flow)
+
+<!-- AI AGENT: 처리 로직을 활동 다이어그램으로 표현하고, 아래에 설명을 추가하세요
+Class C: 분기 조건(if/else, try/except)을 모두 명시해야 합니다
+
+예시: -->
+
+```plantuml
+@startuml UNIT001_Activity
+start
+:입력 데이터 수신;
+if (입력 유효성 검사?) then (통과)
+  :데이터 전처리\n(정규화, 포맷 변환);
+  :처리 결과 반환;
+else (실패)
+  :유효성 오류 로깅;
+  :ValidationError 발생;
+  stop
+endif
+:정상 반환;
+stop
+@enduml
+```
+
+**처리 단계 설명:**
+
+1. **입력 검증**: {INPUT_VALIDATION_DESCRIPTION}
+2. **전처리**: {PREPROCESSING_DESCRIPTION}
+3. **핵심 처리**: {CORE_PROCESSING_DESCRIPTION}
+4. **출력**: {OUTPUT_DESCRIPTION}
+
+#### 3.1.3 데이터 구조 (Data Structures)
+
+<!-- AI AGENT: 유닛이 처리하는 주요 입출력 데이터 구조를 정의하세요
+범위 제한이 있는 필드는 반드시 허용 범위를 명시하세요 (안전 관련 값의 경우 필수) -->
+
+**입력 (Input)**
+
+| 필드명    | 타입   | 허용 범위 / 값 | 필수 여부 | 설명   |
+| --------- | ------ | -------------- | --------- | ------ |
+| {FIELD_1} | {TYPE} | {RANGE}        | 필수      | {DESC} |
+| {FIELD_2} | {TYPE} | {RANGE}        | 선택      | {DESC} |
+
+**출력 (Output)**
+
+| 필드명           | 타입   | 범위    | 설명   |
+| ---------------- | ------ | ------- | ------ |
+| {OUTPUT_FIELD_1} | {TYPE} | {RANGE} | {DESC} |
+
+#### 3.1.4 오류 처리 (Error Handling)
+
+<!-- AI AGENT: 가능한 모든 오류 조건과 처리 방법을 기술하세요
+IEC 62304 Cl.5.4.3: 안전 관련 오류는 반드시 Fail-Safe 동작을 정의해야 합니다 -->
+
+| 오류 조건         | 오류 코드 | 처리 동작                | Fail-Safe 여부 | 로그 레벨    |
+| ----------------- | --------- | ------------------------ | -------------- | ------------ |
+| {ERROR_1}         | ERR-{N}   | {ACTION}                 | Yes / No       | ERROR / WARN |
+| 입력 값 범위 초과 | ERR-001   | 처리 중단 후 기본값 반환 | Yes            | ERROR        |
+
+#### 3.1.5 요구사항 추적 (Requirements Traceability)
+
+| SRS 요구사항 ID | 요구사항 설명 | 구현 방법     |
+| --------------- | ------------- | ------------- |
+| {SRS_ID_1}      | {REQ_DESC}    | {IMPL_METHOD} |
+
+---
+
+### 3.2 {UNIT_2_NAME} (UNIT-002)
+
+<!-- AI AGENT: 3.1 양식을 반복하여 각 유닛을 기술하세요 -->
+
+---
+
+## 4. 인터페이스 설계 (Interface Design)
+
+> IEC 62304 Cl.5.3.2 아키텍처 인터페이스, Cl.5.4.3 상세 인터페이스
+
+### 4.1 유닛 간 인터페이스 시퀀스
+
+<!-- AI AGENT: 유닛 간 주요 상호작용을 시퀀스 다이어그램으로 표현하세요
+요청-응답 사이의 데이터 타입과 오류 분기를 포함하세요
+
+예시: -->
+
+```plantuml
+@startuml SDD_Unit_Sequence
+participant "Caller\n(ITEM-001)" as CALLER
+participant "UNIT-001\nDataInputHandler" as U1
+participant "UNIT-002\nInferenceEngine" as U2
+participant "UNIT-003\nResultFormatter" as U3
+
+CALLER -> U1 : process(rawInput: RawInput)
+activate U1
+  U1 -> U1 : validate(rawInput)
+  alt 유효하지 않은 입력
+    U1 --> CALLER : raise ValidationError(ERR-001)
+  else 유효한 입력
+    U1 -> U1 : preprocess(rawInput)
+    U1 -> U2 : predict(processedData: ProcessedData)
+    activate U2
+      U2 -> U2 : loadModel()
+      U2 -> U2 : inference(processedData)
+      U2 --> U1 : Result
+    deactivate U2
+    U1 -> U3 : format(result: Result)
+    activate U3
+      U3 -> U3 : applyThreshold(result)
+      U3 --> U1 : OutputDTO
+    deactivate U3
+    U1 --> CALLER : OutputDTO
+  end
+deactivate U1
+@enduml
+```
+
+### 4.2 SOUP 연동 인터페이스
+
+> IEC 62304 Cl.5.3.5 (SOUP 격리)
+
+| SOUP ID  | SOUP 명     | 연동 방식        | 래퍼 클래스     | 고장 시 동작       |
+| -------- | ----------- | ---------------- | --------------- | ------------------ |
+| SOUP-001 | {SOUP_NAME} | {INTERFACE_TYPE} | {WRAPPER_CLASS} | {FAILURE_BEHAVIOR} |
+
+---
+
+## 5. 유닛 검증 계획 (Unit Verification Plan)
+
+> IEC 62304 Cl.5.4.2, Cl.5.5.2 (유닛 검증 방법 및 합격 기준)
+
+### 5.1 검증 방법
+
+| 방법           | 설명                          | 적용 유닛          | 담당자     |
+| -------------- | ----------------------------- | ------------------ | ---------- |
+| 코드 리뷰      | 정적 분석 및 피어 리뷰        | 전체               | {REVIEWER} |
+| 유닛 테스트    | pytest / unittest 기반 자동화 | UNIT-001, UNIT-002 | {DEV}      |
+| 정적 분석 도구 | {STATIC_ANALYSIS_TOOL}        | 전체               | CI/CD      |
+
+### 5.2 합격 기준 (Acceptance Criteria)
+
+<!-- AI AGENT: SW 안전 등급에 따른 커버리지 기준을 적용하세요
+Class A: 요구사항 기반 테스트 / Class B: Statement 커버리지 / Class C: Branch 커버리지 -->
+
+| 유닛 ID            | 커버리지 기준      | 최소 기준값 | 허용 정적 분석 경고  |
+| ------------------ | ------------------ | ----------- | -------------------- |
+| UNIT-001 (Class B) | Statement Coverage | >= 80%      | 0건 (정당화 시 허용) |
+| UNIT-002 (Class C) | Branch Coverage    | 100%        | 0건                  |
+
+---
+
+## 6. 위험 관련 설계 고려사항 (Risk-Related Design Considerations)
+
+> ISO 14971 Cl.6 (위험 통제 조치), IEC 62304 Cl.7.1
+
+<!-- AI AGENT: FMEA(risk-table-fmea.md)의 Risk Control Measures를
+이 섹션에서 어떻게 구현하는지 연결하세요 -->
+
+| 위험 ID     | 위험 설명   | 설계 통제 방법   | 구현 유닛 | 검증 방법      |
+| ----------- | ----------- | ---------------- | --------- | -------------- |
+| {RISK_ID_1} | {RISK_DESC} | {DESIGN_CONTROL} | UNIT-{N}  | {VERIFICATION} |
+
+---
+
+## 7. 추적성 매트릭스 요약 (Traceability Summary)
+
+> IEC 62304 Cl.5.1.1(c), Cl.5.7.4
+
+| SRS 요구사항 ID | 유닛 ID  | 유닛 테스트 ID | 위험 ID   |
+| --------------- | -------- | -------------- | --------- |
+| {SRS_ID_1}      | UNIT-001 | TEST-{N}       | {RISK_ID} |
+| {SRS_ID_2}      | UNIT-002 | TEST-{N}       | -         |
+
+---
+
+## 8. 변경 이력 (Revision History)
+
+| 버전 | 날짜   | 작성자   | 변경 내용 |
+| ---- | ------ | -------- | --------- |
+| 0.1  | {DATE} | {AUTHOR} | 초안 작성 |
+
+---
+
+> Template based on IEC 62304:2006/AMD1:2015 Cl.5.4, ISO 14971:2019

package/vendor/dev-docs-templates/templates/mdr_docs/ER/sprint/software-system-test-plan.md

@@ -0,0 +1,155 @@
+# Software System Test Plan & Protocol: {PRODUCT_NAME} v{VERSION}
+
+<!-- AI AGENT 작성 지침
+이 문서는 IEC 62304 Cl.5.7 기반 시스템 테스트 계획서입니다.
+Sprint마다 테스트 케이스를 추가/업데이트하세요.
+
+작성 전 반드시 다음 문서를 참조하세요:
+  - SW 요구사항 명세서(software-requirements-list.md): 모든 SRS ID를 테스트 케이스로 커버해야 함
+  - FMEA(risk-table-fmea.md): 위험 통제 조치가 구현되었는지 검증하는 테스트 포함
+  - 사이버보안 체크리스트(risk-management-cybersecurity-checklist.md): 보안 테스트 항목 반영
+
+작성 지침:
+1. 모든 SRS 요구사항(SRS-F-xxx, SRS-P-xxx 등)에 최소 1개의 테스트 케이스가 있어야 합니다
+2. 테스트 ID 체계: TST-SYS-{N:3d} (예: TST-SYS-001)
+3. 테스트 결과 컬럼은 실제 테스트 실행 후 채워주세요 (계획서는 Expected까지만)
+4. 위험 통제 조치에 대한 테스트는 "위험 통제 검증?" 열을 Yes로 표시하세요
+5. Pass/Fail 외에 Blocked(사전 조건 미충족), N/A(해당 없음)도 사용 가능합니다
+
+테스트 카테고리:
+  - Functional: SRS-F-xxx 기능 요구사항 검증
+  - Performance: SRS-P-xxx 성능 요구사항 검증
+  - Security: SRS-S-xxx 보안 요구사항 검증
+  - Regression: 이전 버전에서 동작하던 기능이 유지되는지 확인
+  - Boundary: 경계값 조건 검증 (허용 범위 초과/미만 입력)
+
+테스트 환경 (필수 기재):
+  - 테스트 환경은 실제 사용 환경과 유사해야 합니다 (IEC 62304 Cl.5.7.2)
+  - 사용된 SOUP 버전을 명시하세요 (SOUP 리스트와 일치 확인)
+-->
+
+**문서 번호**: {DOC_ID}
+**버전**: {VERSION} | **상태**: Draft (계획) / Final (프로토콜)
+**Sprint**: {SPRINT_NUMBER} | **작성일**: {DATE}
+**테스터**: {TESTER} | **검토자**: {REVIEWER}
+
+---
+
+## 표준 요건 매핑
+
+| 표준 조항          | 제목                          | 해당 섹션          |
+| ------------------ | ----------------------------- | ------------------ |
+| IEC 62304 Cl.5.7.1 | 통합 시스템 테스트 절차 수립  | 전체               |
+| IEC 62304 Cl.5.7.2 | 소프트웨어 시스템 테스트 수행 | 3. 테스트 케이스   |
+| IEC 62304 Cl.5.7.4 | 테스트 결과와 요구사항 추적성 | 4. 추적성 매트릭스 |
+| MDR Annex II 6.1   | 제품 검증                     | 전체               |
+
+---
+
+## 1. 테스트 환경 (Test Environment)
+
+<!-- AI AGENT: 실제 테스트를 수행한 환경을 정확하게 기재하세요 -->
+
+| 항목               | 사양                               |
+| ------------------ | ---------------------------------- |
+| OS / 환경          | {OS_VERSION}                       |
+| 주요 SOUP 버전     | {SOUP_NAME} v{VERSION} (SOUP-{ID}) |
+| 브라우저 / 런타임  | {BROWSER_OR_RUNTIME}               |
+| 테스트 데이터 출처 | {TEST_DATA_SOURCE}                 |
+| 테스트 실행 일시   | {TEST_DATE}                        |
+
+---
+
+## 2. 테스트 범위 (Test Scope)
+
+| 포함                         | 제외                                 |
+| ---------------------------- | ------------------------------------ |
+| {IN_SCOPE_TEST}              | {OUT_OF_SCOPE_TEST}                  |
+| SRS-F-xxx 전체 기능 요구사항 | 유닛 레벨 테스트 (별도 SDD에서 관리) |
+
+---
+
+## 3. 테스트 케이스 (Test Cases)
+
+### 3.1 기능 테스트 (Functional Tests)
+
+<!-- AI AGENT: 각 SRS-F-xxx 요구사항에 대한 테스트 케이스를 작성하세요
+테스트 단계(Steps)는 재현 가능하도록 구체적으로 작성해야 합니다
+예시:
+  Steps: 1. {URL}에 접속한다 2. 사용자 ID {ID}와 비밀번호 {PW}를 입력한다 3. 로그인 버튼을 클릭한다
+  Expected: 대시보드 페이지로 이동하고 사용자 이름이 표시된다 -->
+
+| 테스트 ID   | SRS ID    | 테스트 카테고리 | 테스트 설명   | 사전 조건   | 테스트 단계                | 예상 결과    | 위험 통제 검증? | 실제 결과 | Pass? |
+| ----------- | --------- | --------------- | ------------- | ----------- | -------------------------- | ------------ | --------------- | --------- | ----- |
+| TST-SYS-001 | SRS-F-001 | Functional      | {TEST_DESC_1} | {PRECOND_1} | 1. {STEP_1}<br>2. {STEP_2} | {EXPECTED_1} | Yes / No        |           |       |
+| TST-SYS-002 | SRS-F-002 | Functional      | {TEST_DESC_2} | {PRECOND_2} | 1. {STEP_1}<br>2. {STEP_2} | {EXPECTED_2} | No              |           |       |
+
+### 3.2 성능 테스트 (Performance Tests)
+
+| 테스트 ID     | SRS ID    | 테스트 카테고리 | 테스트 설명    | 허용 기준 | 측정 방법            | 실제 결과 | Pass? |
+| ------------- | --------- | --------------- | -------------- | --------- | -------------------- | --------- | ----- |
+| TST-SYS-P-001 | SRS-P-001 | Performance     | 응답 시간 측정 | <= {N}초  | {MEASUREMENT_METHOD} | {ACTUAL}  |       |
+
+### 3.3 보안 테스트 (Security Tests)
+
+<!-- AI AGENT: SRS-S-xxx 보안 요구사항에 대한 테스트를 작성하세요
+다음 항목을 포함하는 것을 권장합니다:
+- 인증 실패 케이스 (잘못된 자격증명, 세션 만료)
+- 권한 없는 접근 시도
+- SQL Injection / XSS 방어 확인
+- TLS 통신 암호화 확인 -->
+
+| 테스트 ID     | SRS ID    | 테스트 카테고리 | 테스트 설명          | 예상 결과                              | 위험 통제 검증? | 실제 결과 | Pass? |
+| ------------- | --------- | --------------- | -------------------- | -------------------------------------- | --------------- | --------- | ----- |
+| TST-SYS-S-001 | SRS-S-001 | Security        | {SECURITY_TEST_1}    | {EXPECTED}                             | Yes             |           |       |
+| TST-SYS-S-002 | SRS-S-002 | Security        | TLS 통신 암호화 확인 | Wireshark 캡처 시 암호화된 패킷만 관측 | Yes             |           |       |
+
+### 3.4 경계값 테스트 (Boundary Tests)
+
+| 테스트 ID     | SRS ID    | 테스트 카테고리 | 테스트 조건    | 입력값       | 예상 결과         | 실제 결과 | Pass? |
+| ------------- | --------- | --------------- | -------------- | ------------ | ----------------- | --------- | ----- |
+| TST-SYS-B-001 | SRS-F-{N} | Boundary        | 최대값 입력    | {MAX_VALUE}  | {EXPECTED}        |           |       |
+| TST-SYS-B-002 | SRS-F-{N} | Boundary        | 최소값 입력    | {MIN_VALUE}  | {EXPECTED}        |           |       |
+| TST-SYS-B-003 | SRS-F-{N} | Boundary        | 범위 초과 입력 | {OVER_VALUE} | 오류 처리 및 거부 |           |       |
+
+---
+
+## 4. 추적성 매트릭스 (Traceability Matrix)
+
+<!-- AI AGENT: 모든 SRS 요구사항이 테스트에 의해 커버되는지 확인하세요 -->
+
+| SRS ID    | 요구사항 설명  | 테스트 ID     | 위험 ID   | 커버 여부 |
+| --------- | -------------- | ------------- | --------- | --------- |
+| SRS-F-001 | {REQ_DESC}     | TST-SYS-001   | -         | Yes       |
+| SRS-S-001 | {SEC_REQ_DESC} | TST-SYS-S-001 | {RISK_ID} | Yes       |
+
+---
+
+## 5. 테스트 결과 요약 (Test Results Summary)
+
+<!-- AI AGENT: 테스트 완료 후 아래 표를 채워주세요 -->
+
+| 카테고리    | 전체 | Pass | Fail | Blocked | N/A |
+| ----------- | ---- | ---- | ---- | ------- | --- |
+| Functional  | {N}  |      |      |         |     |
+| Performance | {N}  |      |      |         |     |
+| Security    | {N}  |      |      |         |     |
+| Boundary    | {N}  |      |      |         |     |
+| **합계**    |      |      |      |         |     |
+
+**결론**: Pass / Fail / Conditional Pass
+
+**미해결 결함 목록**: (없음 또는 bug-fixes-documentation-list.md 참조)
+
+---
+
+## 6. 변경 이력
+
+| 버전 | 날짜   | 작성자   | 변경 내용             |
+| ---- | ------ | -------- | --------------------- |
+| 0.1  | {DATE} | {AUTHOR} | 계획서 초안           |
+| 1.0  | {DATE} | {TESTER} | 테스트 결과 입력 완료 |
+
+---
+
+> Template based on IEC 62304:2006/AMD1:2015 Clause 5.7, MDR 2017/745 Annex II 6.1

package/vendor/dev-docs-templates/templates/mdr_docs/ER/sprint/usability-evaluation-protocol.md

@@ -0,0 +1,63 @@
+# Usability Evaluation Protocol
+
+## Mapping of Standard Requirements to Document Sections
+
+| IEC 62366-1:2015 Section | Title                                         | Document Section |
+|--------------------------|-----------------------------------------------|------------------|
+| 4.2                      | Usability Engineering File                    | (all)            |
+| 4.3                      | Tailoring of the Usability Engineering effort | (all)            |
+
+## 1. User Group and Environment
+
+> Describe the user group here, e.g., physicians with experience in a certain field.
+
+> Also, describe the environment in which the user test is being conducted. Obviously, both the user group and
+> environment should match whatever you described in your Intended Use. So, if your app is intended to be used
+> by emergency physicians in a brightly-lit hospital environment, you should also have these people do the
+> usability test in a similar environment.
+
+## 2. Preparation
+
+> Describe whether you prepare users in any way. Again, this should be based on the use context in which your
+> users will be using your device in real life. So, if people typically carefully read the user manual before
+> (not sure in which parallel universe that happens), you can give them the manual and some time to study
+> it. More realistically, you'll probably test how users handle your device when they haven't read the manual.
+
+> If there are official training which are required before users can use your device, you should do this
+> training first, of course.
+
+## 3. List of Tasks
+
+> This table lists the tasks you want your users to perform. It's kind of the master table which will be
+> copy-pasted for each user below - you'll be filling out the observations and hazards encountered by each
+> user.
+
+> As always, using a spreadsheet (e.g., Google Sheets) instead of a document is a very good idea here.
+
+| ID | Description | App State / Environment | Instructions | Acceptance Criteria | Observations | Hazards encountered |
+|----|-------------|-------------------------|--------------|---------------------|--------------|---------------------|
+|    |             |                         |              |                     |              |                     |
+
+## 4. Protocols
+
+> Copy-paste the table above for each user and fill it out during the test. Note down the names and ages (or
+> any other important characteristics) per user.
+
+### User 1 (Name, Age)
+
+| ID | Description | App State / Environment | Instructions | Acceptance Criteria | Observations | Hazards encountered |
+|----|-------------|-------------------------|--------------|---------------------|--------------|---------------------|
+|    |             |                         |              |                     |              |                     |
+
+### User 2 (Name, Age)
+
+| ID | Description | App State / Environment | Instructions | Acceptance Criteria | Observations | Hazards encountered |
+|----|-------------|-------------------------|--------------|---------------------|--------------|---------------------|
+|    |             |                         |              |                     |              |                     |
+
+---
+
+Template Copyright [openregulatory.com](https://openregulatory.com). See [template
+license](https://openregulatory.com/template-license).
+
+Please don't remove this notice even if you've modified contents of this template.

package/vendor/dev-docs-templates/templates/mdr_docs/PA/intended-use.md

@@ -0,0 +1,116 @@
+# Intended Use
+
+<!-- AI AGENT 작성 지침
+이 문서는 MDR Annex II 1.1, ISO 14971 Cl.5.2, IEC 62366-1 Cl.5.1 기반 사용 목적 정의서입니다.
+PA 단계의 첫 번째 핵심 문서로, 모든 이후 문서의 근거가 됩니다.
+
+작성 지침:
+1. "Intended Use": 의료 기기의 核心 기능을 명확하고 간결하게 기술하세요
+   - 무엇을 하는가? (진단/치료/모니터링)
+   - 어떤 방식으로? (AI 분석, 데이터 수집 등)
+   - 어떤 결과를 제공하는가? (점수, 권고사항, 시각화 등)
+   예시: "This software is intended to assist clinicians in detecting {CONDITION} by analyzing {INPUT_DATA} and providing a risk score."
+
+2. "Intended Medical Indication": 대상 질환/상태를 구체적으로 기술하고
+   "제외 기준(Exclusion Criteria)"을 반드시 포함하세요
+
+3. "Patient Population": 나이, 체중, 동반 질환 등 구체적 특성을 기술하세요
+
+4. "User Profile": 의료 종사자인지 일반 사용자인지 명확히 구분하세요
+   - 필요한 교육/자격 요건
+   - 기술 숙련도 수준
+
+5. "Use Environment": 병원 환경인지 재택 환경인지 구분하고
+   소음, 조명, 시간 압박 등 환경적 특성을 기술하세요
+
+6. "Operating Principle": 입력 -> 처리 -> 출력 흐름을 명확히 기술하세요
+   AI/ML 모델을 사용하는 경우 반드시 "보조 진단 도구"임을 명시하세요
+
+완성 체크리스트:
+  [ ] 제품명 및 버전 기재
+  [ ] Medical Indication에 제외 기준(Contraindications) 포함
+  [ ] 의도된 사용자와 환자 집단 구분 명확
+  [ ] MDR 등급 결정을 위한 충분한 정보 제공
+  [ ] IFU(instructions-for-use.md)와 내용 일치 확인
+-->
+
+
+## Mapping of Requirements to Document Sections
+
+| MDR Class | MDR Section                   | Document Section |
+| --------- | ----------------------------- | ---------------- |
+| (All)     | Annex II, 1.1 a) - d), h), i) | (All)            |
+
+| ISO 14971:2019 Section | Document Section |
+| ---------------------- | ---------------- |
+| 5.2                    | (All)            |
+
+| IEC 62366-1:2015 Section | Document Section |
+| ------------------------ | ---------------- |
+| 5.1                      | (All)            |
+
+## Product
+
+ * Name: *\<product name\>*
+ * Version: *\<product version\>*
+ * Basic UDI-DI: *\<insert UDI-DI, if/when available\>*
+
+## Intended Use
+
+> Describe the core medical functionality of your device and how it treats, diagnoses or alleviates a disease.
+> Keep it high-level so that this description is true for as long as possible even when the device is updated.
+
+## Intended Medical Indication
+
+> Describe the condition(s) and/or disease(s) to be screened, monitored, treated, diagnosed, or prevented by
+> your software. Importantly, also list exclusion criteria: Maybe patients with a certain diagnosis should not
+> be using your device.
+
+## Contraindications
+
+> List anything that you want to explicitly exclude from your intended use.
+
+## Patient Population
+
+> Describe the patient population your software is intended to be used on. Note that this may overlap with the
+> user profile (section below), but not necessarily. Your software could be used by physicians to diagnose
+> diseases in patients, so in that case, they don't overlap. Some ideas for characteristics to describe: Age
+> group, weight range, health, condition(s).
+
+## User Profile
+
+> Describe the typical user of the software. Some ideas could be: Qualifications, prior training (for your
+> software), technical proficiency, time spent using the software.
+
+## Use Environment Including Software/Hardware
+
+> Describe the typical use environment. What sort of devices is this running on? Does the software only run on
+> one device or multiple devices? Is it loud and chaotic like in an emergency ward? How's the lighting?
+>
+> Also, add other software or hardware which is required by your device. Most commonly, apps require users to
+> have a smartphone with a compatible operating system (iOS / Android).
+
+## Operating Principle
+
+> It's kind of a stretch to describe the "operating principle" of software. I guess this makes more sense for
+> hardware devices. In any case, I'd just generally state what sort of input goes in and what output comes
+> out, e.g. you could be processing images and returning diagnoses.
+
+The device is stand-alone software. It receives input from the user and outputs information.
+
+## Part of the Body / Type of Tissue Interacted With
+
+The device is stand-alone software. It receives input from the user and outputs information. It doesn't come
+in contact with tissue or bodily fluids.
+
+## Variants / Accessories
+
+> Describe variants and/or accessories of/to this device, if applicable. For typical stand-alone software of
+> startups, this shouldn't be applicable.
+
+---
+
+Template Copyright [openregulatory.com](https://openregulatory.com). See [template
+license](https://openregulatory.com/template-license).
+
+Please don't remove this notice even if you've modified contents of this template.