비기능 요구사항은 아키텍처에서 어떻게 표현되나?

이전 주제와 관련 없는 질문을 할건데, 자동차의 aspice, 기능안전 프로세스를 적용하는 프로젝트에서 소프트웨어 아키텍처에는 비기능 요구사항이 어떤 식으로 표현이 돼?

 

ChatGPT의 말:

좋은 질문이에요.
**ASPICE(Automotive SPICE)**와 **기능안전(ISO 26262)**이 적용되는 자동차 소프트웨어 개발에서,
**소프트웨어 아키텍처(Software Architecture, SWE.2)**에 **비기능 요구사항(NFR, Non-Functional Requirements)**을 어떻게 표현하고 추적하는지는 실무적으로 매우 중요합니다.

---

✅ 핵심 요약:

소프트웨어 아키텍처에서는 비기능 요구사항을 다음과 같은 방식으로 명시적 요소로 구조화하여 반영합니다.

---

🔸 1. 아키텍처 다이어그램의 구성 요소 속성으로 표현

예:

• Task 주기 (Periodicity),
• Memory 제한,
• Execution time
• Safety ASIL 수준
• Redundancy,
• RTOS Scheduling 특성

➡ 이런 속성은 각 소프트웨어 컴포넌트(예: SWC) 혹은 아키텍처 블록에 태그처럼 달리거나
**속성 테이블(attribute table)**에 정리돼요.

---

🔸 2. 아키텍처 문서에서 비기능 요구사항 매핑 테이블(NFR Traceability Table)

• 비기능 요구사항 ID (예: REQ-NFR-001)
• 요구사항 설명 (예: “시스템은 100ms 이내에 응답해야 함”)
• 관련 컴포넌트/모듈 (예: SWC_01)
• 대응 설계 방식 (예: 우선순위 Task, 빠른 인터럽트 핸들러)

➡ 이는 **SWE.2 (Software Architecture Design)**와 SWE.5 (Software Integration and Test) 사이의 연결고리 역할

---

🔸 3. ISO 26262에서의 비기능 요구사항 표현

특히 기능안전 관점에서는 아래처럼 연결됩니다:             

비기능 요구사항 유형                                   아키텍처에서의 반영 방식  

시간 제약 (응답 시간 등)	Task 주기, Watchdog 구조, Real-Time scheduling
리소스 제약 (RAM/ROM 등)	Memory Partitioning, MPU 구성, SWC memory limit
진단 커버리지	SWC 내에 안전 메커니즘 삽입, ASIL 별 컴포넌트 분리
오류 감지/처리 로직	Diagnostic SWC, Safe-State Handler 등

 

---

🔸 4. 모델 기반 개발 도구에서도 표현 가능

• Simulink / AUTOSAR Builder / Rhapsody / EA 등을 쓸 경우
  → 각 블록/포트에 Tagged Value, Stereotype, Constraints 등을 달아서
  → 비기능 요구사항을 정형적으로 표현하고 도출 가능

---

📌 실무에서 자주 쓰이는 예시

 

---

✅ 결론

소프트웨어 아키텍처에서 비기능 요구사항은 속성, 제약조건, 태그, 문서화된 추적표 등으로 구조화되어 명시됩니다.
ASPICE 기준에서는 **SWE.2 Base Practice 3 (BP3: Allocate software requirements)**에서 특히 강조되고,
ISO 26262 관점에서는 ASIL 추적성 및 Safety Mechanism 요구사항과 직접 연결됩니다.