AUTOSAR 개발자 실전 가이드

# MUST vs SHALL vs SHOULD — 스펙 용어 해석법

## AUTOSAR 스펙을 읽을 때 가장 먼저 알아야 하는 것

AUTOSAR 표준 문서를 처음 펼치면 MUST, SHALL, SHOULD, MAY 같은 단어들이 가득하다. 이 단어들의 강제 수준이 다르다. 잘못 이해하면 "이거 해도 돼?"를 놓친다.

---

## 용어별 의미

### MUST / MUST NOT
**절대적 의무/금지.** 시스템의 정상 작동에 직결된다. 이를 어기면 기능적 문제나 안전 문제가 발생한다.

```
[SWS_Os_00001]
A task SHALL MUST call TerminateTask() or ChainTask() at the end of its execution.
```

위반하면 OS 스택 손상이나 하드폴트로 이어진다.

### SHALL / SHALL NOT
**표준 준수 의무.** 이를 따르지 않으면 AUTOSAR 표준 준수 ECU가 아니다. 기능은 돌아갈 수 있지만 인증이 안 된다.

```
[SWS_Rte_00100]
The RTE SHALL generate Rte_Read_* functions for all required Sender-Receiver ports.
```

개발자 입장에서 SHALL은 "구현해야 한다"와 같다.

### SHOULD / SHOULD NOT
**강력 권장/비권장.** 따르지 않아도 되지만, 그 이유를 문서화해야 한다. 성능, 이식성, 유지보수성에 영향을 준다.

```
[SWS_Os_00050]
Category 2 ISR SHOULD NOT perform long operations.
```

### MAY
**선택 사항.** 구현해도 되고 안 해도 된다. 확장 기능이나 특정 상황에만 유용한 기능에 붙는다.

---

## 비교표

| 용어 | 의미 | 어기면? |
|------|------|--------|
| MUST | 절대 의무 | 시스템 오동작/안전 문제 |
| MUST NOT | 절대 금지 | 시스템 오동작/안전 문제 |
| SHALL | 표준 준수 의무 | 비준수 ECU, 인증 불가 |
| SHALL NOT | 표준 준수 금지 | 비준수 ECU |
| SHOULD | 강력 권장 | 이유 문서화 필요 |
| SHOULD NOT | 강력 비권장 | 이유 문서화 필요 |
| MAY | 선택 | 아무 영향 없음 |

---

## MUST vs SHALL — 실무에서 구별 포인트

| 구분 | MUST | SHALL |
|------|------|-------|
| 관점 | 시스템 안전/정확성 | 표준 준수 |
| 예시 | "브레이크 SWC는 MUST 반응시간 내 동작" | "RTE SHALL 인터페이스를 생성" |
| 어기면 | 즉각적 기능 문제 | 인증/감사 통과 실패 |

---

## 스펙 읽는 실용적인 팁

1. **SWS(Software Specification) 문서** — 구현해야 할 API와 동작을 정의한다. SHA, MUST 위반 항목은 반드시 구현한다.

2. **\[SWS_Module_XXXXX\] 태그** — 각 요구사항에는 고유 번호가 있다. AUTOSAR 인증 심사에서 이 번호로 추적한다.

3. **SHOULD 항목 기록** — 프로젝트에서 SHOULD를 따르지 않기로 했다면, 이유를 설계 문서에 기록해 둔다. 심사 때 "왜 안 했냐"는 질문에 대비.

4. **Deviation 관리** — AUTOSAR 표준에서 이탈(deviation)하는 경우 `[Constr_XXXXX]`로 constraint 항목을 따로 기록하는 프로젝트도 있다.

MUST vs SHALL vs SHOULD — 스펙 용어 해석법

// COMMENTS

ON THIS PAGE