(A-SPICE 11회차) SYS.2: "고객이 시키지도 않았는데 우리끼리 망함"

🔍 11회차: "고객이 시키지도 않았는데 우리끼리 망함"

SYS.2 – 시스템 요구사항 분석, 왜 내부 의견도 요구사항일까?

고객 요구만 들어줬는데 왜 또 혼나죠…?
🧑‍💼: “왜 품질팀 의견은 반영 안 했죠?”
👩‍💻: “그건 시스템 요구사항 아니잖아요…”

---

🎯 오늘의 주제: SYS.2 – 시스템 요구사항 분석

시스템 요구사항 분석은 고객 요구사항을 기반으로 시스템 차원에서 어떤 기능과 제약 조건을 만족시킬지를 도출하는 단계입니다.

하지만 여기서 중요한 한 가지!

고객만 고객이 아니다!
내부 QA, 생산팀, AS부서, 심지어 영업팀도 요구사항의 주인공일 수 있습니다!

---

👨‍👩‍👧 내부 이해관계자의 요구사항도 중요하다!

자동차 부품 개발에서 시스템 요구사항은 단지 고객사(OEM) 문서만 해석한다고 끝이 아닙니다.

이해관계자	예시 요구사항
QA팀	진동 시험 조건 추가, 전압 허용오차 확대
생산팀	조립 공정 시 나사 위치 조정
물류팀	패키징 크기 제약 조건
유지보수팀	펌웨어 업데이트 인터페이스 추가
보안팀	통신 암호화 요구사항

✨ 이 모든 것들이 "시스템 요구사항"이 될 수 있습니다!

---

🧨 흔한 실수: 시스템 요구사항 분석의 취약점

❌ 1. 고객 문서만 추출하는 분석

• 📉 고객이 준 요구사항만 추출하고 끝.
• ✔ 내부 부서 협의 없이 진행 → 나중에 QA, 생산, 인증 단계에서 대혼란

❌ 2. 기능 요구만 있고, 비기능 요구 없음

• 예: 성능, 신뢰성, 유지보수성, 보안 등 빠짐
• ⚠ 특히 기능안전, 사이버보안 관련 요구사항 누락 시 재인증 리스크!

❌ 3. 요구사항의 출처/근거 불분명

• “이건 누가 왜 넣은 거죠?” → 몰라요, 그냥 있었어요…
• 평가자 질문에 답 못하면 치명적 감점 포인트

❌ 4. 요구사항 간 충돌 확인 안 함

• 예: OEM은 버튼을 가운데 놓으라 하고, 생산팀은 그 위치에 리벳 박음…
• 요구사항 상호검토 및 조정 절차 부재

---

🧠 시스템 요구사항 도출은 이렇게!

1. 🗂 고객 요구사항 분석
   • OEM 문서를 체계적으로 해석
   • 기능 요구 + 비기능 요구 파악
2. 🤝 내부 이해관계자 인터뷰
   • 품질팀, 생산팀, 물류, 보안 등과 실무 기반 요구사항 수집
   • 도출된 사항은 명확한 근거와 함께 문서화
3. 🧩 요구사항 통합 정리
   • 충돌 여부 확인
   • 우선순위/분류 설정 (기능, 성능, 제약, 보안 등)
4. 🔗 추적 가능성 확보
   • SYS.1 → SYS.2 → SWE.x 로 이어지는 추적 매트릭스 관리

---

📌 A-SPICE 심사 중 SYS.2에서 묻는 질문들

• 요구사항 도출에 다양한 이해관계자가 참여했나요?
• 모든 요구사항이 출처와 근거를 가지고 있나요?
• 요구사항 간 상충은 어떻게 조정되었나요?
• 시스템 요구사항은 소프트웨어 요구사항(SWE.1)으로 잘 이어졌나요?

✅ 이 네 가지가 없다면, 심사에서 SYS.2는 위험 신호입니다.

---

✅ 실천 미션: 우리 팀의 SYS.2 셀프체크

• 내부 이해관계자의 요구사항을 별도로 수집하고 문서화하고 있는가?
• 요구사항의 출처(고객사, 내부부서 등)를 명확히 기록하고 있는가?
• 요구사항 간 충돌을 사전에 분석하고 해결하고 있는가?
• 요구사항 문서가 소프트웨어 요구사항으로 명확히 이어지고 있는가?

---

💬 마무리 한 줄

"고객이 원하는 것만 하면 된다"는 말은
A-SPICE에서는 "프로세스를 버린 자의 선언"입니다.

내부 요구까지 분석하는 것이 진짜 ‘시스템’ 분석입니다.
📈 품질과 일정, 모두를 지키는 열쇠!

---

🔜 다음 회차 예고

12회차에서는
“이거 시스템 설계가 아니라 도면 아닌가요?”
를 주제로
SYS.3 – 시스템 아키텍처 설계의 실제 사례와
소프트웨어/하드웨어 나눔의 어려움을
재미있게 풀어봅니다!

설계는 그림이 아니라
의도를 설계하는 것!