(RM 1강) 좋은 요구사항의 원칙과 INCOSE 규칙

🚗 요구사항 엔지니어링 1강: 좋은 요구사항의 원칙과 INCOSE 규칙

안녕하세요!

오늘은 자동차 소프트웨어 개발에서 좋은 요구사항을 어떻게 정의할 수 있는지 알아보는 첫 번째 강의입니다.

프로젝트를 하다 보면 “애매한 요구사항 한 줄”이 전체 일정과 품질을 뒤흔드는 경우가 있죠. 😅 그래서 국제적으로 통용되는 INCOSE(International Council on Systems Engineering) 규칙을 살펴보고, 실제 자동차 부품사 개발 환경에서 어떻게 적용할 수 있는지 구체적으로 알아보겠습니다.

---

✅ 좋은 요구사항의 4가지 원칙 (INCOSE 기준)

1. 명확성(Clear)
   • 오해의 소지가 없어야 합니다.
   • 문장을 읽는 모든 이해관계자가 같은 의미로 해석할 수 있어야 합니다.
   • 주어와 동작이 명확하게 표현되어야 하며, 축약어나 전문 용어는 정의와 함께 사용해야 합니다.
2. 검증 가능성(Verifiable)
   • 요구사항은 테스트나 리뷰, 분석 등으로 확인할 수 있어야 합니다.
   • “빠르게” 같은 모호한 표현은 검증 불가하지만 “100ms 이내”라면 테스트 계획을 세울 수 있습니다.
   • 검증 수단(시험, 분석, 검토 등)을 함께 정의해두면 더욱 강력해집니다.
3. 일관성(Consistent)
   • 동일 시스템 내에서 충돌하는 내용이 없어야 합니다.
   • 예를 들어, 한 요구사항에서 “0.5초 이내”라고 하고 다른 요구사항에서 “1초 이내”라고 하면 불일치가 발생합니다.
   • 일관성을 유지하려면 요구사항 관리 도구와 리뷰 절차가 필요합니다.
4. 추적성(Traceable)
   • 상위 요구사항과 하위 요구사항을 연결할 수 있어야 합니다.
   • 예를 들어, 고객 요구사항 → 시스템 요구사항 → 소프트웨어 요구사항 → 테스트 케이스까지 이어지는 연결 고리가 확보되어야 합니다.
   • 추적성이 확보되면 변경 요청이 생겼을 때 영향을 신속하게 파악할 수 있습니다.

---

🚦 예시로 보는 좋은 vs. 나쁜 요구사항

• ❌ 잘못된 요구사항: “시스템은 브레이크를 빨리 켜야 한다.”
  → “빨리”라는 단어는 사람마다 기준이 다르기 때문에 테스트가 불가능합니다.
• ✅ 올바른 요구사항: “시스템은 브레이크 페달이 10% 이상 눌리면, 0.5초 이내에 브레이크등을 점등해야 한다.”
  → 누구나 같은 기준으로 이해할 수 있고, 테스트 장비로 검증 가능합니다.

자동차 소프트웨어 개발에서 흔히 발생하는 문제는 “좋은 의도는 담겨 있지만 구체성이 부족한 요구사항”입니다. 그래서 숫자, 조건, 시점 같은 측정 가능한 기준을 반드시 포함해야 합니다.

---

🛠️ 실무 적용 팁

• 금지어 리스트를 운영하세요: “빠르게, 적절히, 충분히, 가능하면” 같은 단어는 문서에서 자동 검색해 제거합니다.
• 검증 수단을 병기하세요: 각 요구사항 옆에 시험(Test), 분석(Analysis), 검토(Review) 같은 검증 방법을 표시하면 품질이 크게 향상됩니다.
• 협업 리뷰를 습관화하세요: 개발자, 테스트 엔지니어, 안전 담당자가 함께 리뷰하면 관점이 달라져 숨은 모호성을 발견할 수 있습니다.

---

💡 오늘의 핵심 포인트

• 좋은 요구사항은 명확성, 검증 가능성, 일관성, 추적성 네 가지 원칙을 만족해야 합니다.
• 모호한 단어는 개발자와 테스터 모두의 공포 대상! 🚫
• 숫자와 조건을 활용한 구체적이고 측정 가능한 요구사항이 프로젝트 품질을 보장합니다.

---

👉 다음 강의(2강)에서는 좋은 요구사항의 5대 원칙 – SMART하게 쓰는 법을 알아보겠습니다.

그럼 지금 바로 여러분의 요구사항 문서를 열어보고, 모호한 표현들을 찾아내는 첫 번째 실습을 시작해보세요! 😉