(A-SPICE 14회차) SWE.1: “이건 시스템이 한다며요?” vs “근데 결국 우리가 해야 해요...”

💻 14회차: “이건 시스템이 한다며요?” vs “근데 결국 우리가 해야 해요...”

SWE.1 – 시스템 요구사항에서 소프트웨어 요구사항 뽑기!

🧑‍💻 “요구사항 분석이요? 그냥 상무님 말씀 받아 적으면 되는 거 아닌가요?”
👻 “그렇게 해서 생긴 기능이 30개인데... 서로 충돌해요...”

---

🔍 SWE.1이 뭐길래?

A-SPICE의 SWE.1은 소프트웨어 요구사항 분석 단계입니다.
한 마디로 말해, "시스템에서 떨어진 요구사항을 S/W 개발자 눈높이에 맞게 번역하는 것"!

🚧 주의! 그냥 시스템 요구사항을 Ctrl+C, Ctrl+V 하면?
→ 개발 지옥 입성입니다.

---

🧠 소프트웨어 요구사항, 어떻게 추출하나요?

🎯 Step 1: 시스템 요구사항에서 SW 관련 내용만 추려내기

• 예시 시스템 요구사항:
  “차량이 시속 5km 이하일 때 자동으로 도어 잠금 해제 불가”

→ SW 요구사항 추출:
“도어 잠금 제어 소프트웨어는 차량 속도가 5km/h 이하일 때 잠금 해제를 요청받으면 무시한다.”

👉 시스템 요구는 ‘무엇을’, 소프트웨어 요구는 ‘어떻게’를 말해요!

---

🎯 Step 2: 인터페이스 정리

• 센서는 누구한테 값을 주나요?
• 액추에이터는 누가 제어하나요?

💡 시스템 설계 조직이 있다면 여기가 깔끔하게 정의되어 있겠지만...

---

🤦 시스템 설계 조직이 없어요. 우리 팀이 다 해야 해요...

✅ 그럴 땐 이렇게 대응하자!

1. 🌐 시스템 요구사항을 “기능 블록”으로 쪼개기

• 예: '도어 락 제어' / '속도 판단' / '사용자 입력 처리'
• 각 블록이 어떤 데이터를 주고받는지 명확히!

2. 👥 관련 부서 사람들 소환!

• HW, 기구, QA 들과 인터페이스 정의 워크숍
• 그림 그리고 말하면서 정리하면 금방 이해됨

3. 📄 템플릿으로 정리하자

• 요구사항 ID, 우선순위, 소스, 설명, 유즈케이스, 테스트 기준까지
• 누가 봐도 “이게 뭐하는 기능이구나” 싶게 정리

---

🧱 SWE.1의 핵심: 요구사항 품질 3요소

요소	설명	체크 질문
명확성	애매한 표현이 없나요?	“빠르게”가 몇 초인가요?
일관성	시스템 요구사항과 충돌하지 않나요?	상반된 조건이 없나요?
검증가능성	테스트할 수 있나요?	이걸 어떻게 확인할 거죠?

---

⚠️ 현업에서 자주 발생하는 이슈

문제	결과
시스템 요구사항 없음	개발자가 기획서를 보고 바로 코딩 시작
요구사항 추적 없음	어떤 기능이 어디서 나왔는지 모름
테스트 기준 없음	나중에 QA가 와서 “이건 왜 이렇게 만들었어요?”

---

💪 SWE.1 대응 전략 – 특히 중소기업이라면!

• 시스템 요구가 없으면 요구사항부터 직접 뽑자!
  • 유저 스토리, 시나리오 기반으로 기능화
• 고객 요청 문서도 요구사항으로 변환해두기
  • “이건 시스템이 알아서 해준대요” → 대부분 S/W 몫입니다
• 협업 툴 적극 사용
  • Notion, Confluence, Excel도 좋고, Traceability Matrix 활용하면 최고!

---

🎯 요약 정리!

SWE.1 = 소프트웨어의 “정체성 찾기” 단계!

• 시스템이 뭘 하라고 하는지 정확히 파악하고,
• 우리가 어떤 기능을 어떻게 구현할지 명확히 정의하고,
• 나중에 테스트와 연계할 수 있게 요구사항을 문서화해야 합니다!

---

🔜 다음 회차 예고

15회차에서는 SWE.2 – 소프트웨어 아키텍처 설계로 넘어갑니다!

“자동차 소프트웨어는 아키가 생명입니다!”
구조 없이 코드 짜면 유지보수 지옥행,
깔끔한 아키텍처 설계 방법과 실무의 비밀, 낱낱이 공개합니다!