@neobiotechlabs/neobiotech-dev-agent 0.1.7

package/vendor/dev-docs-templates/templates/mdr_docs/EA/software-architecture-description.md

@@ -0,0 +1,307 @@
+# Software Architecture Description (SAD): {PRODUCT_NAME}
+
+<!-- AI AGENT 작성 지침
+이 문서는 IEC 62304 Cl.5.3 기반 SW 아키텍처 설계서입니다.
+작성 전 반드시 다음 문서를 참조하세요:
+  - 시스템 요구사항 명세서(system-requirements-spec.md): 시스템 요구사항 및 안전등급 확인
+  - SOUP 리스트(soup-list.md): 외부 라이브러리 목록 확인
+  - 위험 관리 계획서(risk-management-plan.md): 위험 통제 관련 아키텍처 결정 반영
+
+작성 지침:
+1. 모든 SW 아이템은 고유 식별자를 부여하세요 (예: ITEM-001)
+2. 안전 등급(Class A/B/C)을 아이템마다 명시하세요
+3. SOUP는 반드시 격리 전략을 기술하세요 (IEC 62304 Cl.5.3.5)
+4. 다이어그램은 아래 PlantUML 지침에 따라 작성하세요
+5. 보안 아키텍처 섹션을 반드시 채워주세요 (MDR Annex I 17.2)
+
+PlantUML 다이어그램 작성 지침:
+- 컴포넌트 다이어그램: SW 아이템 간 관계 표현 -> 섹션 2.3에 작성
+- 시퀀스 다이어그램: 주요 데이터 흐름 표현 -> 섹션 4에 작성
+- 배포 다이어그램: 실행 환경 구성 표현 -> 섹션 5에 작성
+
+PlantUML 문법 예시 (```plantuml ... ``` 블록 사용):
+```
+@startuml Component_Overview
+package "Medical Device Software" {
+  component [Frontend Module] as FE
+  component [Backend Module] as BE
+  component [AI Algorithm Module] as AI
+}
+FE --> BE : REST API
+BE --> AI : Internal Call
+@enduml
+```
+-->
+
+**문서 번호**: {DOC_ID}
+**버전**: {VERSION} | **상태**: Draft
+**작성일**: {DATE} | **작성자**: {AUTHOR}
+**검토자**: {REVIEWER} | **승인자**: {APPROVER}
+
+---
+
+## 표준 요건 매핑 (Standard Requirements Mapping)
+
+| IEC 62304 조항     | 제목                         | 해당 섹션                  | Class |
+| ------------------ | ---------------------------- | -------------------------- | ----- |
+| Cl. 5.3.1          | SW 아키텍처 변환             | 2. SW 시스템 구조          | B, C  |
+| Cl. 5.3.2          | SW 아이템 간 인터페이스 정의 | 3. 인터페이스 정의         | B, C  |
+| Cl. 5.3.3          | 공개된 알려진 이상 식별      | 2. SW 시스템 구조          | B, C  |
+| Cl. 5.3.4          | 추가 위험 평가 실시          | 6. 위험 관련 아키텍처 결정 | B, C  |
+| Cl. 5.3.5          | SOUP 소프트웨어 아이템 격리  | 5. SOUP 격리 전략          | B, C  |
+| Cl. 5.3.6          | 형상 항목 식별               | 7. 형상 항목 목록          | B, C  |
+| MDR Annex II 3.(c) | 설계 및 제조 정보            | 전체                       | -     |
+| MDR Annex I 17.2   | IT 보안 고려                 | 4. 보안 아키텍처           | -     |
+
+---
+
+## 1. 개요 (Overview)
+
+### 1.1 목적
+
+이 문서는 {PRODUCT_NAME}의 SW 아키텍처를 정의한다.
+IEC 62304의 안전 등급 결정에 따라 SW 시스템을 아이템(Item) 단위로 분해하고, 아이템 간 인터페이스 및 SOUP 격리 전략을 명시한다.
+
+### 1.2 연관 문서
+
+| 문서명                 | 문서 ID         | 비고                 |
+| ---------------------- | --------------- | -------------------- |
+| 시스템 요구사항 명세서 | {SRS_DOC_ID}    | 아키텍처의 입력      |
+| SW 요구사항 명세서     | {SRS_SW_DOC_ID} | 기능 요구사항 출처   |
+| 위험 관리 계획서       | {RMP_DOC_ID}    | 위험 통제 조치 반영  |
+| SOUP 리스트            | {SOUP_DOC_ID}   | 외부 라이브러리 목록 |
+
+### 1.3 SW 안전 등급 요약
+
+<!-- AI AGENT: 시스템 요구사항 명세서의 등급 분류 결과를 옮겨 기재하세요 -->
+
+| SW 아이템     | IEC 62304 등급 | 근거        |
+| ------------- | -------------- | ----------- |
+| {ITEM_1_NAME} | Class {A/B/C}  | {RATIONALE} |
+| {ITEM_2_NAME} | Class {A/B/C}  | {RATIONALE} |
+
+---
+
+## 2. SW 시스템 구조 (SW System Architecture)
+
+> IEC 62304 Cl.5.3.1: SW 시스템을 SW 아이템으로 분해하고 각각의 기능, 인터페이스, 안전 등급을 정의해야 함
+
+### 2.1 전체 구조 요약
+
+<!-- AI AGENT: 제품의 주요 SW 아이템을 나열하고 각각의 역할을 간략히 기술하세요
+예시:
+- Frontend (ITEM-001): 사용자 인터페이스, 웹 브라우저 기반
+- Backend API (ITEM-002): 비즈니스 로직 처리, REST API 제공
+- AI/ML 추론 모듈 (ITEM-003): 진단 보조 알고리즘 실행
+- 데이터베이스 (ITEM-004): 환자 데이터 영구 저장
+-->
+
+{ARCHITECTURE_SUMMARY}
+
+### 2.2 SW 아이템 목록
+
+| 아이템 ID | 아이템 명     | 기능 설명         | 안전 등급     | 기술 스택    | 배포 방식    |
+| --------- | ------------- | ----------------- | ------------- | ------------ | ------------ |
+| ITEM-001  | {ITEM_1_NAME} | {ITEM_1_FUNCTION} | Class {CLASS} | {TECH_STACK} | {DEPLOYMENT} |
+| ITEM-002  | {ITEM_2_NAME} | {ITEM_2_FUNCTION} | Class {CLASS} | {TECH_STACK} | {DEPLOYMENT} |
+
+### 2.3 컴포넌트 다이어그램
+
+<!-- AI AGENT: 아래 PlantUML 블록 안에 SW 아이템 간 관계를 컴포넌트 다이어그램으로 작성하세요
+IEC 62304 Cl.5.3.1 요구: SW 아이템 간 관계 및 인터페이스를 시각적으로 정의해야 함
+
+지침:
+- 각 SW 아이템은 component 또는 package로 표현
+- 아이템 간 통신 방향과 프로토콜을 화살표에 명시
+- SOUP는 별도 영역(package)으로 표현하여 격리 관계를 명시
+- 외부 시스템(HW, 외부 서비스)은 actor 또는 boundary로 표현
+
+예시: -->
+
+```plantuml
+@startuml SAD_Component
+skinparam componentStyle rectangle
+
+package "Medical Device Software (IEC 62304)" {
+  component [Frontend\nITEM-001\nClass B] as FE #LightBlue
+  component [Backend API\nITEM-002\nClass B] as BE #LightGreen
+  component [AI Algorithm\nITEM-003\nClass C] as AI #Orange
+}
+
+package "SOUP (외부 라이브러리)" {
+  component [React v18\n(SOUP-001)] as REACT
+  component [PyTorch v2\n(SOUP-002)] as TORCH
+}
+
+actor "Healthcare User" as USER
+actor "EHR System" as EHR
+
+USER --> FE : HTTPS
+FE --> BE : REST API (JSON)
+BE --> AI : Internal gRPC
+BE --> EHR : HL7 FHIR
+
+FE ..> REACT : uses
+AI ..> TORCH : uses
+
+note right of AI
+  Class C: 진단 보조 출력
+  오분류 시 환자 위해 가능성
+end note
+@enduml
+```
+
+---
+
+## 3. 인터페이스 정의 (Interface Definitions)
+
+> IEC 62304 Cl.5.3.2: 각 SW 아이템 간 인터페이스를 명확하게 정의해야 함
+
+### 3.1 내부 인터페이스 (Internal Interfaces)
+
+| 인터페이스 ID | 송신 아이템         | 수신 아이템        | 프로토콜   | 데이터 형식 | 보안 요건     |
+| ------------- | ------------------- | ------------------ | ---------- | ----------- | ------------- |
+| INT-001       | ITEM-001 (Frontend) | ITEM-002 (Backend) | HTTPS REST | JSON        | JWT 인증 필수 |
+| INT-002       | ITEM-002 (Backend)  | ITEM-003 (AI)      | gRPC       | Protobuf    | mTLS          |
+
+### 3.2 외부 인터페이스 (External Interfaces)
+
+<!-- AI AGENT: 외부 시스템과의 연동 규격을 기술하세요. 없으면 해당 없음으로 기재 -->
+
+| 인터페이스 ID | 대상 시스템       | 프로토콜   | 표준       | 데이터 형식 | 비고   |
+| ------------- | ----------------- | ---------- | ---------- | ----------- | ------ |
+| EXT-001       | {EXTERNAL_SYSTEM} | {PROTOCOL} | {STANDARD} | {FORMAT}    | {NOTE} |
+
+---
+
+## 4. 보안 아키텍처 (Security Architecture)
+
+> MDR Annex I 17.2 (IT 보안), IEC 81001-5-1 Cl.5.3
+
+<!-- AI AGENT: 보안 아키텍처를 데이터 흐름 관점에서 기술하세요.
+아래 항목을 반드시 포함하세요:
+- 인증/인가 방식
+- 데이터 암호화 (저장/전송)
+- 네트워크 격리 방식
+- 감사 로그 전략 -->
+
+### 4.1 데이터 보호
+
+| 구분                             | 방식                | 표준/알고리즘 |
+| -------------------------------- | ------------------- | ------------- |
+| 전송 중 데이터 (Data in Transit) | TLS 1.3             | AES-256-GCM   |
+| 저장 데이터 (Data at Rest)       | {ENCRYPTION_METHOD} | {ALGORITHM}   |
+| 민감 데이터 마스킹               | {MASKING_METHOD}    | {STANDARD}    |
+
+### 4.2 인증 및 접근 제어
+
+<!-- AI AGENT: RBAC/ABAC 방식, MFA 적용 여부, 세션 관리 방식을 기술하세요 -->
+
+{AUTH_AND_ACCESS_CONTROL_DESCRIPTION}
+
+### 4.3 보안 데이터 흐름 다이어그램
+
+<!-- AI AGENT: 인증 흐름을 시퀀스 다이어그램으로 표현하세요
+
+예시: -->
+
+```plantuml
+@startuml SAD_Security_Sequence
+actor "User" as USER
+participant "Frontend\n(ITEM-001)" as FE
+participant "Auth Service\n(ITEM-002)" as AUTH
+participant "Backend API\n(ITEM-002)" as BE
+database "Database\n(ITEM-004)" as DB
+
+USER -> FE : Login (ID/PW)
+FE -> AUTH : POST /auth/login
+AUTH -> DB : Verify credentials (hashed)
+DB --> AUTH : User record
+AUTH --> FE : JWT Access Token (exp: 1h)
+FE -> BE : API Request + Bearer Token
+BE -> AUTH : Token validation
+AUTH --> BE : Valid (User Role: {ROLE})
+BE --> FE : Response data (encrypted)
+@enduml
+```
+
+---
+
+## 5. SOUP 격리 전략 (SOUP Isolation Strategy)
+
+> IEC 62304 Cl.5.3.5: SOUP 소프트웨어 아이템을 격리하여 잠재적 결함이 안전 기능에 미치는 영향을 최소화해야 함
+
+<!-- AI AGENT: SOUP 리스트(soup-list.md)를 참조하여 각 SOUP의 격리 전략을 기술하세요 -->
+
+| SOUP ID  | SOUP 명       | 버전      | 사용 아이템 | 격리 방식          | 고장 시 영향 | 알려진 취약점    |
+| -------- | ------------- | --------- | ----------- | ------------------ | ------------ | ---------------- |
+| SOUP-001 | {SOUP_1_NAME} | {VERSION} | ITEM-001    | {ISOLATION_METHOD} | {IMPACT}     | CVE 검토: {DATE} |
+| SOUP-002 | {SOUP_2_NAME} | {VERSION} | ITEM-003    | {ISOLATION_METHOD} | {IMPACT}     | CVE 검토: {DATE} |
+
+### 5.1 배포 환경 구성도
+
+<!-- AI AGENT: 실제 배포 환경(컨테이너, 네트워크 경계 등)을 배포 다이어그램으로 표현하세요
+
+예시: -->
+
+```plantuml
+@startuml SAD_Deployment
+node "User Device" {
+  artifact "Web Browser" as BROWSER
+}
+
+node "Cloud (VPC - Private Network)" {
+  node "API Server" {
+    artifact "Backend API\n(Docker Container)" as BE_APP
+    artifact "AI Module\n(Docker Container)" as AI_APP
+  }
+  database "Database\n(Encrypted at rest)" as DB
+}
+
+node "CDN" {
+  artifact "Frontend\n(Static Assets)" as FE
+}
+
+BROWSER --> FE : HTTPS
+BROWSER --> BE_APP : HTTPS REST API
+BE_APP --> AI_APP : gRPC (Internal)
+BE_APP --> DB : TLS (Internal)
+@enduml
+```
+
+---
+
+## 6. 위험 관련 아키텍처 결정 (Risk-Related Architecture Decisions)
+
+> IEC 62304 Cl.5.3.4: 아키텍처 설계 단계에서 추가 위험 평가를 수행해야 함
+
+<!-- AI AGENT: 위험 관리 계획서(risk-management-plan.md) 및 FMEA(risk-table-fmea.md)를
+참조하여 아키텍처 결정이 위험 통제에 기여하는 방식을 기술하세요 -->
+
+| 위험 ID     | 위험 설명   | 아키텍처 통제 결정 | 관련 아이템 |
+| ----------- | ----------- | ------------------ | ----------- |
+| {RISK_ID_1} | {RISK_DESC} | {ARCH_DECISION}    | ITEM-{N}    |
+
+---
+
+## 7. 형상 항목 목록 (Configuration Items)
+
+> IEC 62304 Cl.5.3.6: 형상 관리 대상 SW 아이템을 식별해야 함
+
+| 항목 ID | 항목명           | 유형         | 버전 관리 방식             | 저장소 경로   |
+| ------- | ---------------- | ------------ | -------------------------- | ------------- |
+| CI-001  | {ITEM_1_NAME}    | 소스 코드    | Git (tag: v{VERSION})      | {REPO_PATH}   |
+| CI-002  | {ITEM_2_NAME}    | Docker Image | Container Registry         | {IMAGE_URL}   |
+| CI-003  | 시스템 구성 파일 | 설정         | Git (암호화된 secret 제외) | {CONFIG_PATH} |
+
+---
+
+## 8. 변경 이력 (Revision History)
+
+| 버전 | 날짜   | 작성자   | 변경 내용 |
+| ---- | ------ | -------- | --------- |
+| 0.1  | {DATE} | {AUTHOR} | 초안 작성 |
+
+---
+
+> Template based on IEC 62304:2006/AMD1:2015 Clause 5.3, MDR 2017/745 Annex I/II, IEC 81001-5-1

package/vendor/dev-docs-templates/templates/mdr_docs/EA/software-requirements-list.md

@@ -0,0 +1,156 @@
+# Software Requirements List (SRS): {PRODUCT_NAME}
+
+<!-- AI AGENT 작성 지침
+이 문서는 IEC 62304 Cl.5.2 기반 SW 요구사항 명세서입니다.
+A/B/C 전체 등급에서 필수 산출물입니다.
+
+작성 전 반드시 다음 문서를 참조하세요:
+  - 시스템 요구사항 명세서(system-requirements-spec.md): 시스템 요구사항 및 SRS로 분해할 항목 확인
+  - 사용 목적 정의서(intended-use.md): 의도된 사용자, 사용 환경 확인
+  - FMEA(risk-table-fmea.md): 위험 통제 조치(Risk Control Measure)가 SRS에 반영되었는지 확인
+
+작성 지침:
+1. 모든 요구사항에 고유 ID를 부여하세요 (예: SRS-F-001, SRS-S-001)
+2. IEC 62304 카테고리를 정확히 분류하세요:
+   - Functional (기능 요구사항)
+   - Performance (성능 요구사항)
+   - User Interface (사용자 인터페이스)
+   - Security (보안 요구사항)
+   - Interface (외부 인터페이스)
+   - Regulatory (규제 준수 요구사항)
+3. 보안 요구사항(IEC 81001-5-1)은 Security 카테고리로 반드시 포함하세요
+4. 위험 통제 조치(Risk Control Measure)를 요구사항으로 추가할 때는
+   Risk Control Measure 열을 Yes로 표시하고 FMEA의 Risk ID를 연결하세요
+5. 각 요구사항은 독립적으로 검증 가능해야 합니다 (Verifiable)
+
+예시 요구사항 ID 체계:
+  SRS-F-001: 기능 요구사항 #001
+  SRS-P-001: 성능 요구사항 #001
+  SRS-UI-001: 사용자 인터페이스 요구사항 #001
+  SRS-S-001: 보안 요구사항 #001
+  SRS-I-001: 인터페이스 요구사항 #001
+  SRS-R-001: 규제 요구사항 #001
+-->
+
+**문서 번호**: {DOC_ID}
+**버전**: {VERSION} | **상태**: Draft
+**작성일**: {DATE} | **작성자**: {AUTHOR}
+**검토자**: {REVIEWER} | **승인자**: {APPROVER}
+
+---
+
+## 표준 요건 매핑 (Standard Requirements Mapping)
+
+| 표준 조항            | 제목                        | 해당 섹션        | Class   |
+| -------------------- | --------------------------- | ---------------- | ------- |
+| IEC 62304 Cl.5.2.1   | SW 요구사항 정의            | 1~3              | A, B, C |
+| IEC 62304 Cl.5.2.2   | SW 요구사항 내용            | 1~3              | A, B, C |
+| IEC 62304 Cl.5.2.3   | SW 요구사항 검토            | 전체             | A, B, C |
+| IEC 62366-1 Cl.5.2   | 사용 오류 관련 UI 특성 식별 | 2. UI 요구사항   | -       |
+| IEC 62366-1 Cl.5.6   | 사용자 인터페이스 사양      | 2. UI 요구사항   | -       |
+| IEC 81001-5-1 Cl.5.2 | 보안 요구사항               | 3. 보안 요구사항 | -       |
+| MDR Annex I 17.2     | IT 보안 고려                | 3. 보안 요구사항 | -       |
+| ISO 13485 Cl.7.2.1   | 고객 관련 프로세스          | 전체             | -       |
+
+---
+
+## 1. 기능 및 성능 요구사항 (Functional & Performance Requirements)
+
+<!-- AI AGENT: 시스템 요구사항 명세서의 SYS-F-xxx 항목을 SW 수준으로 분해하여 작성하세요
+각 요구사항은 "SW는 [조건]에서 [동작]을 [기준]으로 수행해야 한다" 형식으로 작성하면 좋습니다
+
+예시:
+- SRS-F-001: 사용자가 로그인 후 대시보드를 요청할 경우, 시스템은 3초 이내에 결과를 반환해야 한다.
+- SRS-P-001: 시스템은 동시 사용자 100명 이상을 처리할 수 있어야 한다. -->
+
+| ID        | SW 시스템   | 카테고리    | 요구사항 설명                     | 위험 통제 조치? | 관련 Risk ID | 검증 방법        |
+| --------- | ----------- | ----------- | --------------------------------- | --------------- | ------------ | ---------------- |
+| SRS-F-001 | {SW_SYSTEM} | Functional  | {REQ_DESC}                        | Yes / No        | {RISK_ID}    | System Test      |
+| SRS-P-001 | {SW_SYSTEM} | Performance | 시스템은 {N}초 이내 응답해야 한다 | No              | -            | Performance Test |
+
+---
+
+## 2. 사용자 인터페이스 요구사항 (User Interface Requirements)
+
+<!-- AI AGENT: IEC 62366-1 관점에서 사용 오류(Use Error)를 방지하는 UI 요구사항을 작성하세요
+다음 항목을 고려하세요:
+- 위험 관련 정보의 가시성 (색상, 크기, 위치)
+- 사용자 확인(Confirmation) 절차가 필요한 위험 동작
+- 오류 메시지의 명확성
+
+예시:
+- SRS-UI-001: 위험 등급 HIGH 결과는 빨간색 배경과 경고 아이콘으로 표시해야 한다.
+- SRS-UI-002: 데이터 삭제 동작 전 사용자 확인(Confirmation Dialog)을 표시해야 한다. -->
+
+| ID         | SW 시스템   | 카테고리       | 요구사항 설명 | 위험 통제 조치? | 관련 Risk ID | 검증 방법      |
+| ---------- | ----------- | -------------- | ------------- | --------------- | ------------ | -------------- |
+| SRS-UI-001 | {SW_SYSTEM} | User Interface | {UI_REQ_DESC} | Yes / No        | {RISK_ID}    | Usability Test |
+
+---
+
+## 3. 보안 요구사항 (Security Requirements)
+
+<!-- AI AGENT: MDR Annex I 17.2 및 IEC 81001-5-1 기준으로 사이버보안 요구사항을 작성하세요
+다음 항목을 필수로 포함하세요:
+- 인증 및 접근 제어
+- 데이터 암호화 (전송/저장)
+- 감사 로그
+- 취약점 패치 정책
+
+예시:
+- SRS-S-001: 시스템은 모든 사용자 세션에 JWT 기반 인증을 적용해야 한다 (exp: 1시간).
+- SRS-S-002: 모든 API 통신은 TLS 1.2 이상을 사용해야 한다.
+- SRS-S-003: 로그인 실패 5회 이상 시 계정을 30분간 잠금 처리해야 한다. -->
+
+| ID        | SW 시스템   | 카테고리 | 요구사항 설명                                      | 위험 통제 조치? | 관련 Risk ID | 검증 방법     |
+| --------- | ----------- | -------- | -------------------------------------------------- | --------------- | ------------ | ------------- |
+| SRS-S-001 | All         | Security | 모든 사용자 인증은 {AUTH_METHOD}을 사용해야 한다   | Yes             | {RISK_ID}    | Security Test |
+| SRS-S-002 | All         | Security | 모든 API 통신은 TLS 1.2 이상을 사용해야 한다       | Yes             | {RISK_ID}    | Security Test |
+| SRS-S-003 | {SW_SYSTEM} | Security | 환자 데이터는 AES-256으로 암호화하여 저장해야 한다 | Yes             | {RISK_ID}    | Security Test |
+
+---
+
+## 4. 인터페이스 요구사항 (Interface Requirements)
+
+<!-- AI AGENT: 시스템 요구사항 명세서의 SYS-I-xxx 항목을 SW 수준으로 구체화하세요
+외부 시스템(EHR, PACS, DICOM 서버 등)과의 연동 사양을 포함하세요 -->
+
+| ID        | SW 시스템 | 카테고리  | 요구사항 설명                                           | 위험 통제 조치? | 관련 Risk ID | 검증 방법        |
+| --------- | --------- | --------- | ------------------------------------------------------- | --------------- | ------------ | ---------------- |
+| SRS-I-001 | Backend   | Interface | 시스템은 {EXTERNAL_SYSTEM}과 {PROTOCOL}로 연동해야 한다 | No              | -            | Integration Test |
+
+---
+
+## 5. 규제 준수 요구사항 (Regulatory Compliance Requirements)
+
+<!-- AI AGENT: MDR 및 적용 표준에서 요구하는 SW 준수 사항을 명시하세요 -->
+
+| ID        | SW 시스템 | 카테고리   | 요구사항 설명                                            | 근거 표준 | 검증 방법       |
+| --------- | --------- | ---------- | -------------------------------------------------------- | --------- | --------------- |
+| SRS-R-001 | All       | Regulatory | SW는 IEC 62304:2006/AMD1:2015를 준수하여 개발되어야 한다 | IEC 62304 | Document Review |
+| SRS-R-002 | All       | Regulatory | SW는 ISO 14971:2019에 따른 위험 관리를 수행해야 한다     | ISO 14971 | Document Review |
+
+---
+
+## 6. 추적성 (Traceability)
+
+이 문서의 요구사항은 다음 문서와 연결된다:
+
+| 연결 방향         | 연결 문서                                                 |
+| ----------------- | --------------------------------------------------------- |
+| 입력 (Input from) | 시스템 요구사항 명세서 (system-requirements-spec.md)      |
+| 입력 (Input from) | FMEA 위험 통제 조치 (risk-table-fmea.md)                  |
+| 출력 (Input for)  | SW 아키텍처 설계서 (software-architecture-description.md) |
+| 출력 (Input for)  | 시스템 테스트 계획서 (software-system-test-plan.md)       |
+
+---
+
+## 7. 변경 이력 (Revision History)
+
+| 버전 | 날짜   | 작성자   | 변경 내용 |
+| ---- | ------ | -------- | --------- |
+| 0.1  | {DATE} | {AUTHOR} | 초안 작성 |
+
+---
+
+> Template based on IEC 62304:2006/AMD1:2015 Clausee 5.2, IEC 81001-5-1, MDR 2017/745 Annex I

package/vendor/dev-docs-templates/templates/mdr_docs/EA/soup-list.md

@@ -0,0 +1,82 @@
+# SOUP List (Software of Unknown Provenance)
+
+<!-- AI AGENT 작성 지침
+이 문서는 IEC 62304 Cl.8.1.2 기반 SOUP 목록입니다. EA 단계에서 초안 작성 후 매 Sprint 업데이트합니다.
+
+작성 전 반드시 다음 문서를 참조하세요:
+  - SW 아키텍처 설계서(software-architecture-description.md): SOUP 격리 전략 확인
+  - 프로젝트 requirements.txt / package.json: 실제 사용 라이브러리 목록 확인
+
+작성 지침:
+1. SOUP ID 체계: SOUP-{N:3d} (예: SOUP-001)
+2. 프로젝트에서 실제 사용하는 모든 서드파티 라이브러리/프레임워크를 포함하세요
+   (직접 의존성 + 주요 간접 의존성)
+3. 위험 등급 판단 기준:
+   - Low: 고장 시 환자 위해 없음 (로깅, UI 유틸리티 등)
+   - Medium: 고장 시 가역적 위해 가능 (데이터 처리 라이브러리 등)
+   - High: 고장 시 비가역적 위해 가능 (인증, 암호화, 진단 알고리즘 라이브러리 등)
+4. CVE 취약점은 최소 6개월마다 검토하고 "Last verified at" 날짜를 업데이트하세요
+   (SOP Integrated Software Development 참조)
+5. IEC 81001-5-1 관점: 보안 관련 SOUP(인증, 암호화 등)는 Known Anomalies를 반드시 확인하세요
+
+SOUP 추가 체크리스트 (신규 추가 시):
+  [ ] 버전 고정 (pinned version) 여부 확인
+  [ ] CVE 데이터베이스 조회 (https://nvd.nist.gov)
+  [ ] 라이선스 호환성 확인
+  [ ] SBOM(Software Bill of Materials) 업데이트
+  [ ] SAD의 SOUP 격리 전략 섹션에 반영
+-->
+
+
+> The 62304 requires you to document your SOUP, which is short for Software of Unknown Provenance. In human
+> language, those are the third-party libraries you're using in your code, typically in your
+> `requirements.txt` or `Gemfile`.
+
+| Classes | IEC 62304:2006 Section                          | Document Section |
+| ------- | ----------------------------------------------- | ---------------- |
+| B, C    | 5.3.3 (Functional and Performance Requirements) | 2                |
+| B, C    | 5.3.4 (Hardware and Software Requirements)      | 2                |
+| B, C    | 7.1.2 (Hazardous Situations)                    | 2                |
+| B, C    | 7.1.3 (SOUP Anomaly Lists)                      | 2                |
+| A, B, C | 8.1.2 (Identify SOUP)                           | 2                |
+
+## 1 Risk Level Definitions
+
+> The 62304 requires you to assess risks associated with SOUP. The simplest way to do this is to classify each
+> SOUP as a certain risk level. Unless you're developing software which shoots radiation at patients, it's
+> likely that your SOUP risk levels remain "low" or "medium".
+
+| Risk Level | Definition                                                 |
+| ---------- | ---------------------------------------------------------- |
+| Low        | Malfunction in SOUP can't lead to patient harm.            |
+| Medium     | Malfunction in SOUP can lead to reversible patient harm.   |
+| High       | Malfunction in SOUP can lead to irreversible patient harm. |
+
+## 2 SOUP List
+
+> This is the actual SOUP list. For each third-party library you use, add an entry in the table below. The
+> idea is to only have one "global" SOUP list for your medical device even though the code may actually live
+> in multiple repositories. That's what the "software system" column is for; you could also mention your (git)
+> repository there.
+
+> When specifying requirements, the 62304 requires you to mention functional, performance, hard- and software
+> requirements. However, you may not have to re-state certain requirements if they apply to all SOUP,
+> e.g., "runs on Linux". So prefer to keep the requirements simple, in a way in which you would communicate them
+> to colleagues on your development team when answering the question "why did we import this library?".
+
+> As with all templates: It's more about the content (i.e., the columns you see below) than the tool (filling
+> this out in Google sheets / markdown / wherever). Nobody says that you have to maintain this as a Google
+> sheet. If you can find a way to integrate this in your workflow in a better way, e.g., in a markdown file in
+> your git repository, go for it! Just keep in mind that you need to be able to export it to send it to
+> auditors.
+
+| ID  | Software System | Package Name | Programming Language | Version | Website                                          | Last verified at | Risk Level | Requirements               | Verification Reasoning                                                      |
+| --- | --------------- | ------------ | -------------------- | ------- | ------------------------------------------------ | ---------------- | ---------- | -------------------------- | --------------------------------------------------------------------------- |
+| 1   | Mobile App      | react-native | JavaScript           | 0.61    | [Link](https://facebook.github.io/react-native/) | 23.10.2020       | Low        | * Runs JS on Android / iOS | Commonly used, maintained by a large organisation, sufficient test coverage |
+
+---
+
+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/EA/usability-evaluation-plan.md

@@ -0,0 +1,103 @@
+# Usability Evaluation Plan
+
+The Usability Evaluation Plan describes the Usability Evaluation activities and their required resources which
+will be performed for the device.
+
+## 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. Relevant Processes
+
+Usability Engineering and Evaluation activities are defined in the **SOP Integrated Software Development**.
+
+## 2. Related Documents
+
+ * List of Hazard-Related Use Scenarios
+ * Usability Evaluation Report
+
+## 3. Roles
+
+| Title                                           | Name(s) |
+|-------------------------------------------------|---------|
+| Head of Usability                               |         |
+| Context / Subject Matter Expert, e.g., physician |         |
+
+## 4. Formative Usability Evaluation
+
+### 4.1 Methods
+
+Formative Usability Evaluation is performed with the following methods:
+
+ * **Presentation of mockups or prototypes to subject matter experts:** E.g., by demonstrating the
+   functionality in an in-person or remote screen sharing session.
+ * **Feedback sessions with UX/UI experts:** Showing concepts, designs, mockups or prototypes to internal or
+   external UX/UI experts with the goal of gathering feedback on potential usability problems and
+   improvements.
+ * **User Tests:** Letting users of the intended target user group use the device based on a Usability
+   Evaluation protocol, observing them and documenting potential Usability problems. This is essentially the
+   same methods as the Summative Usability Evaluation, with the only difference being that it's being done on
+   a development (non-final, non-release) version of the device with the goal of gathering knowledge for
+   improving the final device.
+
+### 4.2 Planning (Overview)
+
+| Date       | Description                                                                               |
+|------------|-------------------------------------------------------------------------------------------|
+| 01.01.2021 | *Formative Evaluation 1*<br>(Description of methods incl. environment, participants etc.) |
+
+## 5 Summative Usability Evaluation
+
+### 5.1 Method
+
+Summative Usability Evaluation is conducted by performing User Tests.
+
+User Tests must comply with the following requirements:
+
+ * The user profile is the one specified in the Device Description.
+ * All Hazard-Related Use Scenarios must be covered by test cases (see IEC 62366, para. 5.7.3 / 5.9).
+ * Sufficient stakeholder requirements / user needs must be covered by test cases to ensure that the product
+   meets its intended use (see ISO 13485, para. 7.3.7)
+ * At least five test participants.
+ * The Usability Test Protocol must be filled out which descriptions of each use scenario and
+   instructions. It is also used to document the observations and discovered hazards.
+
+The following requirements are optional:
+
+ * Usability Tests are recorded, e.g., video/audio (either in-person or remotely) and screen recording (of
+   phone / desktop computer)
+
+Results of Summative Usability Evaluation are summarized in the Usability Evaluation Report, most importantly:
+
+ * Could all tasks in the Usability Test Protocol be achieved?
+   * If not, why?
+ * Which Use Errors occurred and could they lead to Hazardous Situations? --> Risk analysis of use errors
+
+## 5.2 Planning (Setting)
+
+#### Participants
+
+#### Setting
+
+#### Methods and Analysis
+
+> Describe whether it's done in person or remotely and how you will document the results (have a protocol at
+> the minimum), optionally also record the sessions.
+>
+> Also, describe how you plan to analyse the data.
+
+## 5.3 Planning (Overview)
+
+| Date       | Description                                                                               |
+|------------|-------------------------------------------------------------------------------------------|
+| 02.01.2021 | *Summative Evaluation 1*<br>(Description of methods incl. environment, participants etc.) |
+
+---
+
+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.