■ 소프트웨어 안전 요구사항 개요
■ sw 안전 요구사항 개발 시 고려사항
- 외부 인터페이스: 센서들은 타당성 검증이 가능하도록 설계되어야 함
- 명세된 시스템과 하드웨어 설정
- HSI 명세서
- 하드웨어 설계 명세서와 관련된 요구사항
- 시간 제약(FTTI): 모니터링 제어기의 inquiry 명령을 수신. 만약, 정해진 시간 범위 내(300ms)에 응답을 송신하지 못할 경우, 모니터링 제어기는 응답 미수신에 대한 오류 조치를 수행
- HW와 SW 사이의 안전과 관련된 종속 관계 기술
- 안전 요구사항의 명세 및 관리
- 정량적 - 순서 존재, ex) 성적 산출(100점, ABC, 가나다 등)
- 정성적 - 순서가 존재하지 않음, ex) 참 잘했다
■ sw 안전 요구사항에 포함되어야 하는 항목
- (a) 시스템이 안전한 상태를 달성하거나 유지하는 기능
- (b) 안전관련 HW, 엘리먼트의 결함을 검출, 표시, 처리하는 것과 관련된 기능
- (c) SW 자체에 있는 결함의 검출, 통지, 완화와 관련된 기능
- (d) on-broad 및 off-broad 시험과 관련된 기능
- (e) 생산 및 서비스 동안 소프트웨어 수정을 허용하는 기능
- (f) 성능이나 시간 결정적인 작업과 관련된 기능
■ E-GAS Monitoring 시스템 - 3 Level 아키텍처
- level 1: 기능 수준
-엔진 제어 기능 수행
-입출력에 대한 진단을 수행하고 오류가 감지되면 오류 조치를 수행 - level 2: 기능 모니터링 수준
-레벨 1의 오류를 모니터링하고 오류가 발생하면 오류 조치를 수행
-프로그램 흐름 진단을 수행 - level 3: 제어기 모니터링 수준
-모니터링 모듈은 기능 제어기와는 독립적인 모니터링 제어기에서 수행
-기능 제어기와 모니터링 제어기 간의 질의-응답을 통해서 각각의 제어기 오류를 감지
-메모리 테스트를 수행, 명령어 테스트를 수행
- 이중화된 입력이 레벨1과 레벨 2에 독립적으로 제공됨
- 레벨 2에서는 제공받은 입력을 토대로 레벨 1에서 계산된 이중화된 출력을 검증
- 레벨 1의 출력은 레벨 2와 레벨 3의 Enable 신호로 검증
- 레벨 3는 제어기의 결함을 감지하기 위해 기능 제어기와 모니터링 제어기로 나누어 수행
■ SW 안전 요구사항 도출 사례(AA 제어기)
- Desc. 이전은 일반적인 요구사항들
- ASIL부터는 안전 요구사항들
- 이 예제에서는 timeover에 대해서는 논하지 않고 있음(잠재적인 위험) 즉, 10ms가 넘어갔을 경우 어떻게 처리한다에 대한 내용이 존재해야 함
- 일반 요구사항과는 다르게 a,b,c 패턴은 안전 요구사항에 포함되어 있는지 판단해야 함, 3 level 아키텍처 판단도 필수
- level 3에서는 보통 메모리가 중점
■ SW 안전 요구사항 표기법
-
Informal Notation
-자연어를 이용하여 서술형으로 기술된 요구사항 -
Semiformal Notation
-UML 등의 모델링 언어를 이용하여 기술된 요구사항 -
Formal Notaion
-수학적 기호나 수식으로 기술된 요구사항
■ EARS(easy approach to requirements syntax)
- Informal Notation을 좀 더 패턴화해서 사용하는 양식
- 1) 요구사항 분석 2) EARS 형태로 변환 3) cause effect graph 구성
-
UB(ubiqutous) 주요 일반 기능
-entity는 functionality해야 한다
-entity는 entity의 functionality를 위해(대해) functionality해야 한다 -
EV(event-driven) 이벤트 기능
-precondition일 때 entity는 functionality해야 한다
-entity가 functionality하면 entity는 functionality해야 한다 -
UW(unwanted behavior) 의도하지 않은 동작
-만약 preconditions이면 entity는 functionality해야 한다
-만약 preconditions이면 functionality의 functionality는 functionality와 functionality에 대해 functionality해야 한다. -
ST(state driven) 상태
-in a specific state 동안, entity는 functionality해야 한다
-in a specific state 동안, functionality는 functionality해야 한다
5. OP(optival features) 추가 기능
-feature is included 경우에는 entity는 functionality해야 한다
-preconditions 경우에너는 functionality는 functionality에 대해 functionality해야 한다
- HY(hybrid) 복합 기능
-in a specific state 동안, preconditions일 때 entity는 functionality해야 한다
-preconditions일 때 (발생하면), 만약
precondition이면(하면),
functionality는 functionality해야 한다
-in a specific state 동안, 만약
precondition이면, functionality는
functionality해야 한다
※ 예시
- preconditions가 많은 경우
-아래의 조건일 경우 entitiy는 functionality해야한다(조건 ~~~ / 약 3개 이상일 때)
■ SW 요구사항이 갖추어야 할 품질 조건 - by IEEE 830
-
Correct
-사용자 요구와 명시된 요구사항이 중첩되는 부분이 정확한 요구사항
-SW 프로젝트에서 자주 발생하는 현상(사용자 요구에 대한 정보가 일부 생략, 명시된 요구사항에 불필요한 정보 추가) -
Unambiguous
-오직 한 가지 해석만이 존재하는 명확한 요구사항
-요구사항이 자연어로 씌어진 경우에 문화에 따라 해석이 다양하기 때문에 의도하지 않은 문제 발생 가능 -
Complete
-완전한 요구사항의 요건(사용자가 관심 있는 모든 중요한 요구사항이 명시되어 있어야 함, 모든 입력에 대해 요구되는 출력이 정의되어 있어야 함)
-완전함의 확인(유능한 검토자, 특별 지식이 없는 개발자에 의해 검토받을 수 있음)
-비기능적 요구사항의 완전함(사용성, 신뢰성, 성능 등에 대한 가이드라인을 따르는 체크리스트를 만들어 확인)
-기능적 요구사항의 완전함(유즈케이스 기술 이용)
-프로토타입을 통한 완전함(실제 프로토타입을 만들어봄으로써 정의된 요구사항의 문제점을 파악) -
Consistent
-각각의 요구사항들이 서로 다른 것들과 충돌하지 않아야 일관된 요구사항
-개발자, 비개발자 등의 신중한 검토와 분석이 이루어져야 함 -
Ranked for Importance and Stability
-고객에게 있어서 중요도와 안정성을 기준으로 개발자와 고객, 그리고 다른 참여자들이 각각의 요구사항에 순위를 매김 -
Modifiable
-기존의 구조와 양식을 유지하면서 쉽고, 완전하며, 일관성 있게 변화를 줄 수 있는 수정 가능한 요구사항(중복되지 않고 적절한 목차와 색인 등으로 잘 구성되어야 함) -
Traceable
-요구사항 구성 요소 각각의 시작점이 명확하고, 또한 차후 개발 단계에서 요구 사항의 참조가 가능한 장치가 있으면 추적 가능한 요구사항
-요구사항에 대한 순방향/역방향 추적이 모두 필요
-프로젝트에 대한 이해와 요구사항을 모두 구현하고 있다는 높은 신뢰를 제공하기 위해 개발자들이 추적성을 사용할 수 있음 -
Understandable
-사용자와 개발자가 각각의 요구사항과 종합된 기능을 완전히 이해할 수 있으면 이해하기 쉬운 요구사항
-요구사항이 정제될수록 기술적인 용어들이 명세 가능
-요구사항을 기록하는 사람은 사용자와 개발자 모두 이해할 수 있는 용어 선택
■ 정리 및 명세 실습
■ 요구사항의 중요성
- 비용 관점
- 시스템 전 개발 과정에 많은 영향을 끼침
- 요구사항이 갖추어야 할 품질 조건 - by IEEE 830
- 모든 모델링의 기본 원칙을 세 가지 관점(기능, 구조, 동적)
■ 요구사항의 속성
- 계속적으로 진화하고 변경되는 속성을 가짐
- 사용자의 성향에 많이 좌우됨
- 기대 사항이 포함되어 있음
- 기능, 비기능 요구사항이 있음
■ 요구사항 vs 기대사항
- 요구사항: 사용자가 제품 또는 서비스를 받아들일만 하다고 판단하기 위해 충족해야 할 조건
- 기대사항: 사용자가 제품 또는 서비스에 완전히 만족하기 위해 충족되어야 할 조건
■ SW 요구사항 모델링
● 모든 모델링의 기본 원칙을 세 가지 관점에서 출발
-
기능적인 관점
-자연어, use case diagram, DFD, process diagram
-Sequence diagram, Flowchart -
구조적인 관점
-Class diagram, Component diagram, Deploy diagram, ER- diagram, Structure diagram -
동적인 관점
-State chart, Flow chart
■ SW 기능안전 요구사항 명세 시 고려사항
- 기술 안전 요구사항에 위배되는 고장을 야기하는 모든 SW 기능들을 평가
- HW-SW 인터페이스 명세와의 의존성 고려
- 반응 시간, 내/외부 인터페이스 (사용자 인터페이스 포함) 및 운영 모드에 대한 모니터링
- SW 안전 요구사항 명세는 기능 안전 검증 및 심사 활동의 입력으로 사용됨
- SW에 영향을 주는 차량시스템 HW의 개별 동작 모드 고려
