(RM 3강) EARS(Easy Approach to Requirements Syntax) 소개

🚀 3강: EARS(Easy Approach to Requirements Syntax) 소개

안녕하세요 여러분! 😀
오늘은 요구사항을 더 쉽고 명확하게 작성하는 방법 중 하나인 EARS(Easy Approach to Requirements Syntax)를 소개해드릴게요.
이 방법은 복잡한 문장을 간단한 패턴으로 정리해 주기 때문에, 개발자와 기획자, 심지어 고객까지 모두 이해하기 쉽게 만들어줍니다.

---

🌟 EARS란 무엇인가?

EARS는 Easy Approach to Requirements Syntax의 약자로,
요구사항을 일정한 문법 패턴에 맞춰 작성하도록 도와주는 기법입니다.

👉 장점은?

• 불필요하게 긴 설명 ❌
• 해석이 제각각인 모호한 표현 ❌
• 누구나 한눈에 이해 가능한 요구사항 ✅

즉, "모호성 줄이기 + 간결성 확보"라는 두 마리 토끼를 동시에 잡을 수 있는 거죠! 🐰🐰

---

🧩 EARS의 기본 패턴

EARS는 요구사항을 5가지 주요 패턴으로 나눕니다.

EARS 주요 패턴

 

1. Ubiquitous 요구사항 (언제나 적용되는 요구사항)

📖 구조:
시스템은 [항상 수행해야 하는 동작]을 한다.

문법 구조: “The <system> shall <response>”

📌 예시:

• “시스템은 항상 시동 버튼이 눌리면 엔진을 시동해야 한다.”
• “시스템은 항상 운전자가 안전벨트를 매지 않으면 경고음을 발생해야 한다.”

👉 특징: 조건이 붙지 않고, 시스템이 항상 수행해야 하는 행동을 정의합니다.

---

2. Event-driven 요구사항 (특정 이벤트 발생 시)

📖 구조:
시스템은 [조건/이벤트]가 발생하면 [동작]을 해야 한다.

문법 구조: “When <trigger>, the <system> shall <response>”

📌 예시:

• “시스템은 배터리 전압이 10V 미만이면 경고를 표시해야 한다.”
• “시스템은 브레이크 페달이 눌리면 브레이크등을 켜야 한다.”

👉 특징: 조건문이 포함되어 특정 상황에서만 동작을 수행합니다.

---

3. State-driven 요구사항 (상태 기반)

📖 구조:
시스템은 [특정 상태]일 때 [동작]을 해야 한다.

문법 구조: “While <precondition(s)>, the <system> shall <response>”

📌 예시:

• “시스템은 주차 모드 상태일 때 후방 카메라 영상을 표시해야 한다.”
• “시스템은 크루즈 컨트롤이 활성화된 상태일 때 설정 속도를 유지해야 한다.”

👉 특징: 이벤트보다는 상태에 따라 시스템의 동작을 규정합니다.

---

4. Optional 요구사항 (조건부, 선택적 상황)

📖 구조:
시스템은 [특정 조건이 충족될 경우] [동작]을 수행해야 한다.

문법 구조: “Where <feature is included>, the <system> shall <response>”

📌 예시:

• “시스템은 야간일 경우 헤드램프 자동 점등 기능을 활성화해야 한다.”
• “시스템은 사용자가 ‘에코 모드’를 선택한 경우 연료 효율성을 우선해야 한다.”

👉 특징: 특정 옵션적 상황에서만 동작이 요구됩니다.

---

5. Complex 요구사항 (복합 조건)

📖 구조:
시스템은 [조건1] AND/OR [조건2]일 때 [동작]을 수행해야 한다.

문법 구조: 예1) 상태 + 이벤트: “While <precondition>, when <trigger>, the <system> shall <response>”

📌 예시:

• “시스템은 차량 속도가 30km/h 이상이고, 차선 이탈이 감지되면 경고음을 울려야 한다.”
• “시스템은 배터리 전압이 10V 미만이거나, 충전 케이블이 분리되면 경고등을 켜야 한다.”

👉 특징: 복수의 조건을 조합하여 좀 더 정교한 요구사항을 표현합니다.

---

🎯 왜 EARS를 써야 할까?

요구사항이 모호하면, 개발팀마다 제각각 해석해서 재작업과 충돌이 발생할 수 있어요. 😵
하지만 EARS는 일정한 문법 틀을 제공하므로, "이게 무슨 뜻이지?"라는 의문을 줄여줍니다.

즉, 품질 좋은 요구사항 → 품질 좋은 소프트웨어로 이어지는 것이죠.

---

💡 정리

EARS는 이렇게 다양한 상황을 명확한 문장 구조로 잡아주는 아주 유용한 도구입니다.

• Ubiquitous: 언제나 동작
• Event-driven: 특정 이벤트 시 동작
• State-driven: 특정 상태에서 동작
• Optional: 조건부/선택 상황에서 동작
• Complex: 복합 조건에서 동작

👉 이 5가지를 익히면, 모호하거나 애매한 요구사항을 줄이고 팀원 모두가 같은 그림을 볼 수 있게 됩니다! 🎉

 

📝 정리 표

Ubiquitous	항상 적용되는 요구사항	🚗 시스템은 시동 버튼이 눌리면 엔진을 시동해야 한다.
Event-Driven	특정 사건(Event)이 발생했을 때 동작	🔋 시스템은 배터리 전압이 10V 미만이면 경고를 표시해야 한다.
State-Driven	특정 상태(State)에서 동작	🅿 차량이 주차 모드일 때 자동 브레이크를 활성화해야 한다.
Optional	조건이 참일 때만 동작	⚙ 사용자가 설정을 활성화한 경우 자동 업데이트를 수행해야 한다.
Complex	복합 조건(여러 이벤트·상태 결합)	🚨 차량 속도가 80km/h 이상이고 차선 이탈 감지 시 경고음을 울려야 한다.

---

🔮 다음 시간 예고

다음 강의에서는
“잘못된 요구사항 사례와 개선하기”라는 주제로
EARS를 활용해 나쁜 요구사항을 어떻게 좋은 요구사항으로 바꿀 수 있는지 알아보겠습니다.

그럼 다음 시간에 만나요~ 🙌