요구사항의 분석과 건강한 의심

** 본 글은 차성덕 교수님의 소프트웨어공학이야기 책을 정리한 글입니다. **

소프트웨어웨어의 품질: reliability / correctness

• SRS 요구사항 문서 = 판단의 기준
  - 명확하지 않은 요구사항: 품질 판단 불가능
  - 틀린 요구사항: reliability 정의상으로는 옳지만 고객 입장 X
  - 중의적 요구사항: 테스트 케이스 오류 가능
• 신뢰도 정량적 측정 지표 (MTBF)

Software Requirement Specification

• 가능한 정량적으로 기술되어야 한다.
  - 정량적이고 독립적인 검증 가능한 품질 지표 산출
• 주관적 해석, 애매한 표현은 적절치 않다.
• 특히 비기능적 요구사항 NFR을 기술할 때 주의가 필요하다.

요구공학이 어려운 이유

1. 요구사항을 기술할 때, 자신의 관점에서 자신이 이해하고 있는 만큼, 자신의 용어와 방식으로 기술한다.
   → 특히 예외 상황에 대한 요구사항이 문제가 된다. (상황에 대한 정의, 기준, 탐지 방법 등)
2. 자연어로 요구사항을 기술하는데, 자연어는 태생적으로 애매모호함을 포함하고 있다.
   → 안전성이 매우 중요한 경우라면 정형 명세 / 모델링 기법을 사용하기도 한다.
3. 요구사항 자체가 관계자의 판단과 견해에 따라서 달라질 수 있다.
   
4. 초기에 알려진 요구사항이 명확하지 않거나 변경되는 사례가 자주 발생한다.
5. 요구사항을 분석하는 과정에서 incomplete 누락되었거나 inconsistent 상반된 요구사항이 있다.

Lauda Air 004의 추락 사고: thrust reverser 오작동 (비행기 착륙 후 제트엔진 반대로 출력)

- 센서 오작동 없다고 가정
- 양쪽 바퀴가 모두 착륙 / 양쪽 바퀴가 모두 착륙 X / 한쪽 바퀴만 착륙

   한쪽만 착륙한 경우, thrust reverser를 어떻게 작동할 것인가? → 전문가나 회사의 판단에 따라 달라진다.

 

Lufthansa 2904의 사고: thrust reverser와 spoiler가 늦게 동작하여 활주로 끝까지 주행함

- 사고 후 에어버스 회사는 spoiler의 작동 조건을 조정함 (6.3t → 2t)

- 요구사항을 올바르게 정의하는 과정은 어렵다.

요구공학에서 먼저 해야 하는 일

• 핵심적인 개념, 기술적인 용어 정의
• 소프트웨어 개발 범위에 대한 정의
• 세심함, 꼼꼼함, "건강한 의심" - 끊임없이 질문하는 자세

 예시

• 예외상황 시 경고나 알람을 생성하는 경우: 언제까지 유효한지, 어떻게 마무리 해야 하는지
• 기차표 예매 시스템
• 로봇청소기 (NFR)

---

추가 자료 리스트

• 1번
• 2번