근데 시스템 아키텍처가 설계서 문서가 아니라 그 상위 문서인 시스템 요구사양서 문서에 system state descripiton 카테고리에 initialization state, normal state, wating sleep state, sleep state로 나누어서 각 state마다 그 상태에 대한 설명과 검증 기준을 명세했고, System transition description 카테고리에 Transition_initialization mode, Transition_normal mode, Transition_waiting sleep mode, Transition_sleep mode로 나누어서 각 천이 조건에 대한 설명과 검증 기준을 명세했거든? 그랬을 때 각 system mode에 대한 것을 하위 문서인 시스템 아키텍처 설계서에 더 자세하게 명세해야 하는거야? 아니면 지금 시스템 요구사양서에 명세된 수준이면 충분한거야?
네, SYS.3 BP2의 "in different system modes" 부분을 실무적으로 해석하면, 당신이 시스템 요구사양서(System Requirements Specification, SRS 또는 SYS.2 출력물) 에 이미 System State Description (Initialization, Normal, Waiting Sleep, Sleep)과 System Transition Description (각 Transition 조건 + 검증 기준)을 상세히 명세했다면, 그 수준이 SYS.3 BP2의 요구를 충족하는 경우가 대부분입니다.
하지만 ASPICE PAM 4.0 SYS.3 BP2의 의도는 "architecture-level" 관점에서 dynamic aspects를 문서화하라는 거라서, 하위 문서(시스템 아키텍처 설계서, SAD) 에 추가로 더 구체적으로 명세해야 할지 여부는 아래 기준으로 판단하세요.
1. ASPICE PAM 4.0 SYS.3 BP2의 핵심 요구사항 (직접 인용)
- "Specify and document the dynamic aspects of the system architecture with respect to the functional and non-functional system requirements including the behavior of the system elements and their interaction in different system modes."
- Note 1: "Examples of interactions of system elements are timing diagrams reflecting inertia of mechanical components, processing times of ECUs, and signal propagation times of bus systems."
→ "system modes" 는 시스템 아키텍처 요소(system elements) 들이 모드별로 어떻게 행동하고, 서로 어떻게 상호작용(interaction) 하는지를 architecture 관점에서 설명하라는 뜻입니다. → SYS.2(SRS)에서 요구사항 수준의 "이 모드에서는 이런 상태/천이"는 이미 다루었지만, SYS.3에서는 "이 모드에서 ECU A → ECU B → Actuator의 timing, latency, concurrency, fallback" 같은 구체적인 architecture-level dynamic 을 문서화해야 합니다.
2. 당신의 현재 문서화 수준 평가

→ 결론:
- SYS.2에 명세된 수준만으로는 SYS.3 BP2를 완전히 충족하지 못합니다. (assessor가 "SRS에 mode/state는 있지만, architecture 설계서에 dynamic aspects가 architecture 관점으로 반영되지 않았다" → PA 2.1 Partially Achieved로 평가할 가능성 높음)
3. 실무에서 SYS.3 (SAD)에 추가로 명세해야 할 내용 (권장 수준)
SYS.3 BP2를 Fully Achieved로 만들기 위해 SAD에 아래 항목을 추가/상세화 하는 게 표준입니다.

4. assessor가 실제로 보는 포인트 (PAM 4.0 기준)
- SYS.2의 mode/state → "What" (요구사항)
- SYS.3의 dynamic aspects → "How" (architecture에서 어떻게 구현/상호작용하는지)
- Traceability : SYS.2의 mode 관련 요구사항 → SAD의 dynamic description으로 bidirectional traceability 증명
- Analysis : SYS.3 BP3 (Analyze system architecture)에서 mode-dependent timing/resource 분석 결과도 SAD에 포함
최종 판단 기준 (실무 팁)
- 충분한 경우 : SRS에 mode/state + transition이 상세하고, SAD에 간단히 참조 (e.g., "Refer to SYS.2 for mode definitions; architecture-level interactions are as follows...") + timing/sequence diagram만 추가하면 OK인 프로젝트 (OEM이 SYS.2/SYS.3을 거의 하나로 취급할 때)
- 추가 명세 필요한 경우 (대부분) : SAD에 architecture elements 중심의 mode별 dynamic behavior/interaction을 별도 섹션으로 작성. → 이는 SYS.3 BP2의 "in different system modes" 를 제대로 충족하는 표준 접근.
결론적으로, SYS.2에 명세된 수준만으로는 부족하니, SAD에 architecture-level dynamic aspects 를 더 자세히 명세하는 게 안전하고, assessment 시 Fully Achieved를 노릴 수 있습니다.
'ASPICE 기본 이론' 카테고리의 다른 글
| 고객 요구사양서 vs 이해관계자 요구사항 명세서 (0) | 2026.04.02 |
|---|---|
| QA가 실질적인 영향을 만드려면? (0) | 2026.03.31 |
| system mode, 시스템/운영 모드란? (0) | 2026.01.16 |
| 테스트 케이스 자동화 (0) | 2026.01.13 |
| 동시개발 (0) | 2025.12.23 |