(RM 4강) 잘못된 요구사항 사례와 개선하기

🚦 4강: 잘못된 요구사항 사례와 개선하기

안녕하세요 여러분! 😀

오늘은 "잘못된 요구사항을 어떻게 잡아내고 개선할 수 있을까?" 라는 흥미로운 주제로 이야기를 나눠보겠습니다.
요구사항은 소프트웨어 개발의 뼈대이자 기준인데, 잘못 작성되면 프로젝트 전체에 큰 영향을 주게 되죠. 💥

그래서 이번 강의에서는 모호성, 원자성, 검증 가능성, 일관성을 위반한 요구사항의 사례와, 이를 어떻게 개선할 수 있는지 구체적인 예시를 들어 설명하겠습니다.

---

1. 모호한 요구사항 식별 🌀

잘못된 요구사항:

"시스템은 빠르게 반응해야 한다."

👉 "빠르게"라는 단어는 해석이 제각각일 수 있죠. 개발자는 1초로 생각할 수 있고, 고객은 10ms로 기대할 수도 있습니다.

개선 요구사항 (EARS/INCOSE 규칙 적용):

"시스템은 사용자 입력 발생 후 100ms 이내에 응답 메시지를 송신해야 한다."

✅ 구체적인 수치로 측정 가능하고 검증 가능하게 바꾼 것이 포인트!

---

2. 원자성(Atomic) 위배 사례 ⚛️

잘못된 요구사항:

"시스템은 차량 속도를 표시하고 연료 경고음을 발생시켜야 한다."

👉 이건 사실상 두 개의 요구사항을 하나로 뭉쳐놓은 겁니다. 이렇게 되면 추적성과 테스트 관리가 어려워져요.

개선 요구사항:

1. "시스템은 차량 속도를 계기판에 표시해야 한다."
2. "시스템은 연료가 잔량 기준치 이하일 때 경고음을 발생시켜야 한다."
   
   

✅ 한 문장은 하나의 목적(단일 기능)만 갖도록 쪼개는 것이 원칙입니다.

---

3. 검증 가능성 위배 사례 🔍

잘못된 요구사항:

"시스템은 사용하기 편리해야 한다."

👉 "편리하다"는 검증이 불가능합니다. 어떤 기준으로 테스트할 수 있을까요? 🤔

개선 요구사항:

"시스템은 사용자가 메뉴를 최대 3번 이내의 클릭으로 접근할 수 있도록 제공해야 한다."

✅ 이렇게 하면 테스트 케이스로 실제 검증이 가능해지죠!

---

4. 일관성 위배 사례 🔄

잘못된 요구사항 (상충하는 경우):

RQ-10: "시스템은 60초 동안 유휴 상태일 때 절전 모드로 진입해야 한다."
RQ-25: "시스템은 유휴 상태에서도 항상 네트워크 연결을 유지해야 한다."

👉 하나는 꺼지라고 하고, 다른 하나는 항상 켜져 있으라고 하네요. 🤯 이런 모순은 개발자에게 큰 혼란을 줍니다.

개선 요구사항:

"시스템은 60초 동안 유휴 상태일 때 절전 모드로 진입해야 한다. 단, 네트워크 연결 기능이 활성화된 경우에는 절전 모드 진입 대신 저전력 네트워크 유지 모드로 전환해야 한다."

✅ 충돌을 해결하면서 일관성을 유지한 사례입니다.

---

✨ 정리

이번 강의에서 살펴본 요구사항 오류와 개선 방법:

1. 모호성 → 수치와 조건으로 구체화
2. 원자성 위배 → 하나의 기능만 포함하도록 분리
3. 검증 가능성 위배 → 테스트 가능한 형태로 변환
4. 일관성 위배 → 충돌하지 않도록 통합/조정

요구사항 오류 및 개선안 정리

 

---

🎯 다음 강의 예고

다음 시간에는 "계층적 요구사항 관리 – 시스템에서 SW까지"라는 주제로,
시스템 요구사항이 소프트웨어와 하드웨어 요구사항으로 어떻게 흘러 내려가는지 다루겠습니다. 🌊

---

여러분도 혹시 주변에서 애매하거나 중복되거나 모순된 요구사항을 본 적 있나요? 🤔
댓글로 사례를 공유해주시면 다음 강의에 참고해보겠습니다! 🙌