안녕하세요. 오랜만에 글을 적습니다.
퇴근하기에 앞서서 몇 가지 저도 오해한 부분과 이해하지 못했던 부분을 간략하게 아래와 같이 정리를 해봅니다.
1. 시스템 요구사항 ≠ 소프트웨어 요구사항
소프트웨어 요구사항과 시스템 요구사항이 비슷하다고 생각되기도 했었습니다. 물론 정확히는 다름을 알고 있지만, 그래도 명세한 문서를 보면 많이 유사한 부분을 언급하는 경우가 많았습니다. (짧은 경험상으로는 말이죠)
IEEE Std 1233에는 다음과 같이 시스템 요구사항은 외부와의 인터페이스, 상호작용에 대해서 명세하는 것이라고 되어 있습니다.
To provide a "black-box" description of what the system should do, in terms of the system's interactions or interfaces with its external environment.
반면에 소프트웨어 요구사항은 소프트웨어 제품, 프로그램, 모듈 등이 특정 환경에서 동작해야 요구사항에 대해서 명세하는 것이라고 되어 있습니다. (IEEE 830 참고)
The Software Requirements Specification is a specification for a particular software product, program, or set of programs that performs certain functions in a specific environment
추가적으로 소프트웨어 요구사항은 다음의 내용들이 포함됩니다.
1. Functionality
2. External interface
3. Performance
4. Design constraints imposed on an implementation
자 그러면 시스템 요구사항과 소프트웨어 요구사항이 작성될 때 주의/유의 사항에 대해서 다음과 같이 기억하고 넘어가도록 하겠습니다.
시스템 요구사항의 경우
1. Unique set: 요구사항은 중복되지 않고 단일 세트로 구성되어야 합니다. 정확히는 하나의 요구사항은 하나의 ID를 가지고 있는다고 생각하시면 됩니다. 동일한 요구사항은 여러개의 ID를 가지고 있으면 추적 및 관리(수정, 생성 등) 또는 검증이 어렵게 됩니다.
2. Normalized: 요구사항의 내용이 겹쳐져서는 안됩니다. 물론 일부 내용이 겹쳐질 경우도 생길 수 있습니다. 그러나 이러한 부분은 최소 또는 없도록 관리하는 것이 중요합니다. Preliminary architecture를 고려한다면 이와 관련하여 보다 명확히 정리할 수 있습니다.
3. Linked set: 각 개별 요구사항들 간에 관계가 명확해야 합니다. Diagnostic 요구사항, Fail Safe 요구사항 등의 구분에 따라 각 요구사항은 분명하게 작성되어야 합니다.
4. Complete: 시스템 요구사항은 고객의 요구사항을 고려하여 필요한 요구사항을 모두 작성하여야 합니다. 요구사항 작성 시 참고로 Non functional Requirement는 이에 대해서 충분한지를 확인할 수 없습니다. 여기서는 Functional Requirements를 확인하는 것을 목표로 하셔야 합니다.
5. Consistent: 요구사항은 일관성을 갖추고 작성되어야 합니다.
6. Bounded: 시스템 요구사항의 범위가 명확히 정의되어야 합니다. 그래야 수행할 기능 요구사항, 인터페이스, 인풋, 아웃풋에 대한 내용을 정의할 수 있습니다.
7. Modifiable: 요구사항은 수정될 수 있습니다.
8. Configurable: 버전/베이스라인 관리가 필요합니다.
9. Granular: 요구사항은 해당 레벨에 맞게 내용을 가지고 작성되어야 합니다. 고객의 요구사항과 시스템 요구사항, 그리고 하드웨어 소프트웨어 요구사항이 다릅니다. 해당 레벨을 고려하여 작성하여야 합니다.
소프트웨어 요구사항은
1. Correct
2. Unambiguous
3. Complete
4. Consistent
5. ranked for importance and/or stability
6. Verifiable
7. Modifiable
8. Traceable
시스템 요구사항과 많이 겹치는 부분도 있고 아닌 부분도 있습니다.
위 내용을 딱 나누어서 이것만 지키면 된다. 이것만 고려하면 된다. 이렇게 이해하시지 마시고, 대략적으로 시스템 요구사항은 범위를 명시하고 외부와의 인터페이스, 상호작용을 위해 이런 것들이 고려되어야 하는구나
소프트웨어는 이보다는 기능을 분명하고, 모호하지 않고 일관되게 작성되어 관리되어야 하는 구나 라고 이해하시면 좋을 것 같습니다.
2. Functional Requirements VS. Non-Functional Requirements
Functional requirements는 결국 시스템/또는 하위 시스템, 하드웨어, 소프트웨어의 주체 Subject 또는 Actor가 해야 하는 것을 명시한 것이라고 생각하면 됩니다.
Non-Functional Requirements는 How 적인 측면에서 이를 보충하는 / 보완하는 그리고 설명하는 요구사항입니다.
그래서 위 그림은 다음과 같이 추가 Arrow를 고려할 수 있습니다.
다음으로 요구사항이 작성되는 문법을 살펴보면,
Subject (Actor) + Requirement verb + Action / Object + Negotiated Value + Conditions 으로 정의할 수 있습니다.
이는 Functional, Non-Functional 구분없이 사용될 수 있습니다.
단, Requirement verb가 다음과 같이 달라질 수 있습니다.
참고적으로 위에 기술된 Shall 이외에 Will, Should, Could, Can, May 등의 동사는 사용하지 않으시기 바랍니다.
요구사항을 작성할 때 명확하지 않은 해석이 가능한 경우는 모두 제외하시고 작성하시기 바랍니다.
3. Non-functional requirement는 Complete하게 확인할 수 없다.
다음 그림을 보시죠.
외부의 시스템과 운전자로부터 정보를 받아서 System이라는 부분에서 처리를 거치고 HMI로 전달되는 구성을 가지고 있습니다.
위 그림보다 이전에 더 General한 요구사항에서 위와 같이 그림을 그리는 경우 위에 표시되지 않은 엘리먼트/컴포넌트는 제외되며, Flow도 위와 같이 정의되게 되어 집니다.
조금 더 제약을 걸어본다면 다음과 같이 될 수 있습니다.
우리의 System을 Sensing, Converting, Logic으로 구분짓고, 외부의 인터페이스로부터 들어오는 정보도 Sensing에서 받고 처리하는 것으로 되어 있습니다. Logic에서는 들어오는 정보의 Compare를 하기 위해 양쪽으로부터 전달 받고, HMI로 전달하게끔 되어 있습니다.
그리고 우리가 진행하는 프로젝트에서 Scope을 정의함으로써 Bounded가 좁아지게 되었습니다.
───────────────────────────────────────────
위 에서 요구사항에 대해서 조금 말씀 드렸지만, 이보다 훨~~~~~~~~~~씬 많은 내용들이 있습니다.
이러한 부분을 다 알지도 못하거니와 설명 드리는 것이 오늘 글의 목적이 아니기에 이상 생략하도록 하겠습니다.
이상입니다. 읽어주셔서 감사합니다.
'기능안전(Functional Safety)' 카테고리의 다른 글
| Level 3 monitoring concept (0) | 2018.11.15 |
|---|---|
| ASIL Capability and Assumption (0) | 2018.11.15 |
| Systematic fault (1) | 2018.08.24 |
| Speed and Severity (0) | 2018.08.24 |
| Exchange of information (4) | 2018.08.10 |