(RM 2강) 좋은 요구사항의 5대 원칙 – SMART하게 쓰자!

🚗 2강: 좋은 요구사항의 5대 원칙 – SMART하게 쓰자!

안녕하세요!

오늘은 요구사항 엔지니어링에서 가장 중요한 주제 중 하나인 좋은 요구사항의 조건에 대해 다루겠습니다. 💡

많은 개발자분들이 “요구사항은 그냥 쓰면 되지 않나?”라고 생각하지만, 실제 현업에서는 좋은 요구사항과 나쁜 요구사항의 차이가 프로젝트의 성공과 실패를 갈라놓기도 합니다. 오늘은 국제적으로 통용되는 INCOSE 원칙과 업계에서 자주 활용되는 SMART 기준을 바탕으로, 자동차 소프트웨어 개발에 꼭 필요한 요구사항 작성 기준을 알아봅시다.

---

✔️ 좋은 요구사항의 5대 원칙 (INCOSE 기준)

INCOSE(International Council on Systems Engineering)는 요구사항 품질을 평가하는 데 다음의 핵심 기준을 제시합니다:

1. 명확성 (Clarity)
   • 한 가지 의미만 가져야 하며 해석의 여지가 없어야 합니다.
   • ❌ 잘못된 예: “시스템은 빠르게 반응해야 한다.”
   • ✅ 올바른 예: “시스템은 200ms 이내에 반응해야 한다.”
2. 검증 가능성 (Verifiable)
   • 시험(Test), 분석(Analysis), 검토(Inspection), 시연(Demonstration) 중 하나로 검증할 수 있어야 합니다.
   • ❌ 잘못된 예: “사용자가 편리해야 한다.”
   • ✅ 올바른 예: “사용자가 메뉴를 3단계 이내로 선택하여 기능을 실행할 수 있어야 한다.”
3. 필요성 (Necessary)
   • 요구사항이 시스템의 목적 달성에 반드시 필요한지 확인해야 합니다.
   • ❌ 잘못된 예: “시스템은 핑크색 배경을 제공해야 한다.” (기능적 목적과 무관)
   • ✅ 올바른 예: “시스템은 안전 경고를 시각적으로 제공해야 한다.”
4. 일관성 (Consistent)
   • 다른 요구사항과 충돌하지 않아야 합니다.
   • ❌ 잘못된 예: “시스템은 최대 속도를 100km/h로 제한해야 한다.” vs. “시스템은 최대 속도를 120km/h로 제한해야 한다.”
5. 추적 가능성 (Traceable)
   • 상위 요구사항이나 법규, 규격과 연결될 수 있어야 합니다.
   • 예: “시스템은 ISO 26262 Part 6의 ASIL-B 요구사항을 만족해야 한다.”

---

📑 SMART 원칙 – 기억하기 쉬운 체크리스트

실무에서는 SMART라는 기준으로 좋은 요구사항을 쉽게 검토할 수 있습니다:

• S (Specific): 구체적인가?
• M (Measurable): 측정 가능한가?
• A (Achievable): 달성 가능한가?
• R (Relevant): 관련성이 있는가?
• T (Time-bound): 시간 제한이 정의되어 있는가?

예를 들어, “ECU는 점화 후 2초 이내에 네트워크 초기화를 완료해야 한다.”는 SMART 원칙을 모두 충족합니다.

---

🧿 자동차 소프트웨어 개발에서의 적용 사례

1. 차량 제어기(ECU) 부팅 시간 요구사항
   • ❌ 잘못된 요구사항: “ECU는 빠르게 부팅해야 한다.”
   • ✅ 좋은 요구사항: “ECU는 점화 후 2초 이내에 정상 동작 상태로 진입해야 한다.”
2. 안전 경고 표시 요구사항
   • ❌ 잘못된 요구사항: “운전자에게 안전하게 정보를 제공해야 한다.”
   • ✅ 좋은 요구사항: “시스템은 제동 시스템 오류 발생 시 1초 이내에 계기판에 적색 경고등을 점등해야 한다.”
3. 네트워크 통신 요구사항
   • ❌ 잘못된 요구사항: “시스템은 차량 네트워크와 통신해야 한다.”
   • ✅ 좋은 요구사항: “시스템은 CAN 통신 속도 500kbps에서 모든 메시지를 손실률 0.1% 이하로 송수신해야 한다.”

---

📝 정리

좋은 요구사항은 명확하고, 검증 가능하며, 반드시 필요하고, 일관성이 있으며, 추적 가능한 것입니다. 또한 SMART 원칙을 활용하면 실무에서 쉽게 점검할 수 있습니다.

👉 오늘 배운 내용을 실제 프로젝트의 요구사항에 적용해 보세요. “빠르게”, “편리하게” 같은 애매한 표현이 있다면, 수치와 조건으로 바꾸는 연습을 해보는 겁니다. 그렇게 하면 고객도, 개발자도, 시험 엔지니어도 모두 웃을 수 있는 진짜 좋은 요구사항이 됩니다. 😃

---

📌 다음 강의 예고: 3강에서는 EARS(Easy Approach to Requirements Syntax)를 활용해 자연어 요구사항을 표준화하는 방법을 배워보겠습니다!