시스템 요구사항 예시 - siseutem yogusahang yesi

시스템 요구사항은 일반적으로 고객과 당신 회사의 마케팅 부서에 의해서 제공되지만 그 개발은 상당히 복잡하다. 요구사항은 Preliminary TAC analysis, Human factors, Operator tasks, Operational hazard analysis, System hazard analysis, Safety verification 그리고 Operational analysis와 같은 여러 소스로부터 올 수 있다. 그것은 시스템 요구사항과 시스템 컨셉의 한 세트를 만들어 낸다.

역주) 여기서 영어로 된 부분은 시스템 안전성 분석과 관련된 복잡한 용어들이어서 억지로 한글 번역을 하지 않고 영문 그대로 적었다. DO-178을 진행하기 위해서 시스템 안전성 분석에 대해서 잘 알고 있다면 좋기는 하겠지만 너무 방대하고 복잡한 내용들이다. 일단 시스템 요구사항은 기본적으로 시스템 안전성 분석에서 출발한다는 점, 그리고 그 과정이 상당히 복잡하다는 정도로만 이해하고 넘어가자. (참고 포스팅: 29 DO-178과 System Safety (1))

소프트웨어는 시스템 설계에 맞도록 준수되어야 한다. 함수를 분석해서 기술하고 아키텍처를 설계하라. 모든 컴포넌트들을 보여주는 정의와 블록다이어그램과 함께 일반적으로 여러 개의 백업 프로세스들과 컴포넌트들을 보여주는 시스템 아키텍처를 설계하는 엔지니어들이 있다.

예를 들어 우리가 작업했던 한 프로젝트는 운송용 항공기상의 모터컨트롤러에 대한 시스템이었다. 그것은 환경 시스템의 컨트롤을 위한 FPGA였다. 비록 시스템 설계는 이루어 졌지만 소프트웨어 요구사항이 아직 개발되지 않은 상태였다. 프로세스의 출력은 확실히 시스템 기능 요구사항 데이터이다. 일반적으로 우리는 이것을 고객으로부터의 요구사항, 즉 시스템이 무엇을 하기로 되어 있는가에 대한 것이라고 생각한다. 어떤 경우에는 시스템 요구사항을 개발하고 설계하며 그것의 타당성을 확인하는 조직이 있을지 모른다. 실제 물리적인 제품 혹은 프로토타입이라도 가지는 것이 도움이 된다. 왜냐하면 타당성이 확인되거나 증명되지 않은 요구사항들로 소프트웨어를 개발하는 것은 어렵기 때문이다. 요구사항에 대한 타당성 입증은 단지 소프트웨어 레벨에서가 아니라 시스템 레벨에서 수행된다.

시스템 프로세스

단지 하드웨어와 소프트웨어 개발뿐만 아니라 시스템에 대한 요구사항 개발 과정에서도 문제점 리포트가 생성된다. 시스템 엔지니어들은 시스템 레벨 문서를 추적하는데 익숙해야 한다.

또한 System Accomplishment Summary가 있다. 이 데이터는 전체 시스템 개발과 확인 그리고 시험 단계 동안에 달성된 것들을 취합한다. FAA는 시스템 명세 프로세스에 대해서는(소프트웨어에 대한 DO-178B와 같은) 요구사항을 가지고 있지 않다. 그래서 그것은 어떤 시스템들이 항공기에 탑재되는지를 말해주는 제품에 대한 인증 계획에서 참조된다. 그리고 그들은 소프트웨어 관점에서 당신에게 필요한 모든 것들이라고 할 수 있는 ATP, DO-160 그리고 시스템 레벨 통합과 시험을 포함하는 시스템 검증을 요구할 것이다. 소프트웨어 검증뿐만 아니라 시스템 상위 레벨 시험이 당신 전략의 일부가 될 수 있다.

역주) 여기서 중요한 것은 시스템 요구사항은 공식적으로 DO-178의 일부가 아니라는 점이다. 저자의 말처럼 그냥 참고하는 자료일 뿐이고 거기서 소프트웨어 위험레벨만 잘 받아올 수 있으면 된다. 일종의 참고자료로만 활용되는 것이다. 그리고 또 하나 중요한 점은 소프트웨어에 대한 시험을 할 때, 시스템 레벨에서의 시험이 중요하다는 점이다. 소프트웨어 레벨에서만 시험을 하게 되면 완전한 시험이 될 수 없다. 소프트웨어가 탑재된 시스템에서 그 소프트웨어의 기능이 확인되어야 제대로 된 시험이 된다는 의미이다. 시스템에 대해서 설명하는 이번 절 전반적으로 이런 철학이 기반이 된다는 점을 기억하자.

시스템 요구사항

시스템 요구사항 상세. 시스템 안전성 분석은 우리에게 안전성과 관련된 요구사항을 제공한다. 일단 두 개의 프로세스가 완료되면 하드웨어와 소프트웨어에 대한 할당이 이루어 진다. 어떤 요구사항은 중복되고 따라서 하드웨어 혹은 소프트웨어 어느 쪽으로든 혹은 필요하다면 양쪽 모두로의 추적이 이루어져야 한다. 이에 대한 다양한 방법들이 있다. 어떤 사람들은 그저 시스템 요구사항을 하드웨어와 소프트웨어로 분리하고 구분해서는 요구사항에 대한 스펙을 만들어 낸다. 만약 당신이 툴을 사용한다면 그것은 가장 좋은 방안이다. 만약 DOORS를 사용한다면 당신의 표에 또 다른 칼럼을 생성하고 소프트웨어와 하드웨어를 구분한 다음 나누어서 관리하라. 만약 당신이 하나의 프로세스로써 문서를 사용한다면 분리된 문서를 작성하라. 그러한 모든 요구사항들은 시스템 요구사항과 설계로의 추적성을 가지고 있어야 한다.

시스템 요구사항 할당

만약 당신이 할당 프로세스를 하고 있다면 그것이 전이 시점이다. 진입과 진출 기준은 무엇이었는가? 당신은 그런 기준 혹은 전이 프로세스를 만족했는가? 만약 요구사항을 작성할 수 있는 시스템 요구사항 기술자 혹은 시스템 엔지니어를 발견한다면 그 사람에게 돈을 더 많이 주고 계속 옆에 두어라. 그는 정말 그럴 만한 가치가 있다. 시스템 요구사항을 작성하는 것은 단지 과학적인 방법이 아니라 하나의 예술이다.

역주) 중간중간 ‘전이’라는 말이 나온다. 한글로 번역하면 좀 어색한데 쉽게 말해서 개발과정의 한 단계에서 다른 단계로 넘어간다는 말이다. ‘설계’ 단계에서 ‘코딩’ 단계로 넘어간다와 같은 식이다. DO-178에서는 이렇게 한 단계를 넘어갈 때 정해진 기준을 만족하고 그것을 증명할 증빙을 제출해야 한다. 원칙적으로는 기준을 만족하지 못한다면 다음 단계로 넘어갈 수 없다.

잘 작성된 요구사항이 핵심이다. 당신은 그것을 요구하지 않으면 필요한 것을 얻지 못할 가능성이 많다. 만약 시스템이 구체화되지 않으면 엔지니어는 자신의 방식으로 구체화할 것이다. 만약 어떤 것이 50ms의 사이클로 구동해야 한다면 그렇게 분명히 언급하고 특정되어야 한다. 마음속에 특정 사이클을 가지고 있을 때에는 “빠르게”라는 말을 사용하지 마라.

역주) 개발자라면 실제 현장에서 코딩을 할 때 각자가 알고 있는 것을 머릿속에 떠올리고 그것을 기준으로 코딩을 하는 경우가 많을 것이다. 가만히 생각해보면 그런 식으로 코딩을 하다 보면 어떤 값(value)과 관련된 부분을 코딩해야 할 때 대충 짐작으로 값을 생각해서 코딩하게 되는 경우가 있을 수 있다. DO-178에서는 이것을 허용하지 않는다. 만약 그 값을 모르겠다면 팀장 혹은 책임자에게 근거를 물어보고 확인해서 근거를 가지고 코딩을 해야 한다. 위의 설명은 바로 이런 부분을 이야기하는 것이다.

                                                   요구사항 작성

“잘 작성된 요구사항은 모든 종류의 시스템에 핵심이다. 당신은 요구하지 않으면 당신이 원하는 것을 얻지 못할 가능성이 높다.”

Ian Alexander, Richard Stevens

“어떤 제품의 품질은 그것에 투입되는 원재료의 질에 달려있다. 빈약한 요구사항으로는 훌륭한 소프트웨어를 만들어 낼 수 없다.

Karl E. Wiegers

각각의 요구사항은 적절하게 끌어내고 분석되고 문서화되고 검증되어야 한다.

각각의 요구사항은 정확성, 타당성, 필요성, 우선순위, 모호하지 않음 그리고 검증가능성과 같은 요구되는 특성들이 평가되어야 한다.

품질은 원재료에 의지한다. 따라서 빈약한 요구사항으로는 훌륭한 소프트웨어를 만들어 낼 수 없다. DO-178B는 요구사항으로 시작하고 당신은 요구사항으로부터 소프트웨어를 작성한다. 그룹의 조직화된 이론이 수행될 때 일부 시스템 엔지니어들은 요구사항을 요구사항툴에 작성하기를 원한다. 그렇게 할 수 있다면 우리는 개발 사이클에서 잘 진행되는 것이다. 시스템 엔지니어들은 데이터를 변경하기 위한 요구사항을 추적하지 않거나 문제점 리포트를 작성하지 않음으로써 개발 프로세스의 사이클을 줄이기를 원할 지 모른다. 하지만 이것은 많은 문제점을 낳을 것이다. 시스템 엔지니어들은 프로세스를 정의하고 따라야 한다. 각각의 요구사항은 적절하게 유도되고 분석되고 문서화되고 검증되어야 한다.

역주) 사실 개발에서 요구사항의 중요성은 누구나 인정할 것이다. 하지만 현실에서는 그 중요한 요구사항이 단순히 문서로 정리하는 것 만으로 끝나는 경우가 많다. DO-178은 요구사항에서 출발해서 요구사항으로 끝이 난다. 그 만큼 모든 과정이 요구사항에 기반해서 돌아간다는 말이다. 그런데 현장에서 보면 DO-178을 진행하면서도 이를 명확하게 인식하지 못한다는 느낌을 많이 받게 된다. 지금까지 해 오던 대로 똑같이 진행하는 것이다. 이런 자세로는 인증과정을 제대로 거칠 수가 없다. 대충하면 되겠지라고 생각하고 넘어가다가는 모든 것을 다시 처음부터 시작해야 할 수도 있다. 돈도 부족하고 시간도 부족한 개발 현실에서 이는 모두에게 불행한 상황을 만들게 될 것이다.

상세 요구사항 작성

정확성 – 기능이 명확히 전달될 수 있도록 정확하게 작성되어야 함

실행가능성 – 시스템과 환경의 알려진 허용치와 제약내에서 구현가능해야 함

필요성 – 실제 “고객”의 필요성 혹은 외부 장비, 외부 인터페이스 혹은 표준을 준수할 필요가 있는 것을 문서화해야 함

우선순위 – 필수인가? 얼마나 필수인가?

모호하지 않음 – 한 사람이든 여러 사람이든 요구사항에 대해서 오직 하나의 해석만이 있어야 함

검증가능한 – 각각의 요구사항이 제품에 제대로 구현되었는지를 확인하기 위해 디바이스상의 시험 혹은 검사, 시연과 같은 접근이 가능해야 함

소스로부터 요구사항으로 추적가능해야 한다!

모든 요구사항은 우선순위가 필요하다. 훌륭한 아키텍처 설계에서 시동에 대한 요구사항은 첫 번째 우선순위를 부여받는다. 만약 이성적인 두 사람이 요구사항을 보았을 때 그들 사이에 모호함이 없어야 하며 동일한 답을 얻어야 한다. 만약 요구사항이 검증받을 수 없다면 제대로 작성된 것이 아니다. 요구사항을 보았을 때 그 요구사항에 대한 시험을 작성할 수 있어야 한다.

파생 요구사항은 엔지니어링 경험에서 그려진 설계 결정사항이지만 정당성이 필요하다. 이러한 파생된 기능들이 구현될 것이다. 시스템에 포함될 코드는 하위레벨 요구사항으로 추적되어야 한다.

역주) 설명이 좀 중구난방인 느낌이 있지만 어쨌든 여기에서도 DO-178 요구사항 작성의 원칙을 설명하고 있다. DO-178만의 고유한 항목으로 파생요구사항이라는 것이 있는데 이것은 상위레벨 요구사항으로의 추적성을 가지고 있지 않은 일종의 독자적인 요구사항이다. 자세한 설명은 다른 곳에서 나오겠지만 고객이 요구하는 것이 아니라 개발자가 자신들의 필요에 의해서(대체로 설계과정에서 선택되는 경우가 많다) 정의하는 요구사항이라고 설명할 수 있다.

그리고 위에서 “하위레벨 요구사항으로 추적되어야 한다”는 것은 소스코드가 하위레벨에 근거해서 작성되는 것이기 때문에 파생된 기능에 대한 소스코드는 하위레벨 요구사항 중 파생요구사항과 추적성으로 연결되어야 한다는 말이다.

이것은 정의와 의미의 세계이다

당신의 계층을 이해하라

내가 소스 일부를 가지고 설계 내용을 작성한다고 가정해보자. 그것이 요구사항인가? 누가 말하느냐에 따라서 다를 것이다. 누군가는 그렇다고 말하고 반면에 우리는 그렇지 않다고 말하고 싶다. 그것은 하나의 설계 내용이고 소프트웨어 개발자에게 맡겨야 할 부분이다. 설계는 반드시 코드 이전에 작성되어야 한다.

역주) 소스코드를 가지고 설계나 요구사항을 작성하는 것은 리버스 엔지니어링이라고 할 수 있다. DO-178에서도 그것이 가능하다. 그런데 리버스 엔지니어링을 실제로 진행하는 케이스를 보게 되면 대체로 설계와 요구사항이 코드를 그대로 따라가는 경향이 있다. 설계든 요구사항이든 이런 식으로 작성하는 것은 좋은 방법이 아니다. 원칙적으로 설계는 코드 이전에 작성되어야 하는 것이며 따라서 리버스 엔지니어링의 결과도 그런 형태로 설계와 요구사항이 작성될 수 있어야 한다. 물론 실제로 진행하기에 상당히 어려운 작업이 아닐 수 없다.

특성(Feature)이 하나의 요구사항인가? 만약 그렇다면 그것이 어디에 명시되어 있는가에 달려있다. 할당자, 기능, 고객, 개념, 상위레벨 하드웨어, 아키텍처, 설계 그리고 상세 요구사항이라는 말들이 있다. 당신이 무엇이라고 부르든 상관없이 그것들은 모두 일정 부분 요구사항이다. 기능과 관련되고 코드를 생성하는 것과 관련된다면 어떤 사람들에게는 어떤 형태에서는 요구사항인 것이다. 

역주) DO-178에서는 요구사항을 상위레벨 요구사항과 하위레벨 요구사항으로 구분한다. 합쳐서 요구사항이라고 할 수도 있겠지만 개념적으로 차이가 많아서 두 개를 통칭하는 경우는 잘 없다. 그런데 위의 그림과 설명은 그 두 가지가 다소 혼재되어 있다. 시스템 요구사항의 개념도 포함되어 있다. 사실 왜 이렇게 설명하는지 잘 이해가 안되지만 어쨌든 그런 구분을 고려하지 않고 통칭해서 볼 때 요구사항에 대한 용어가 이렇게 다양할 수 있다는 점을 보여주려는 의도가 아닌가 싶다.

소프트웨어는 상위레벨 요구사항과 하위레벨 요구사항으로 구분한다. 하드웨어는 개념설계 요구사항과 상세설계 요구사항을 가진다. 서로 다른 이름으로 불리지만 사실 같은 것이다. 중요한 점은 분리된다는 것이다. DO-178B는 요구사항에 대해서 둘 혹은 그 이상 레벨을 요구한다는 점에서 소프트웨어 “표준” 중에서 독특하다. 대부분의 회사들은 상위와 하위의 두 레벨을 제공한다. 하지만 당신이 원한다면 중간 레벨들을 가질 수 있다. 핵심은 더 하위 레벨의 요구사항을 고려하기 전에 더 상위 레벨의 요구사항(단순하게 “상위레벨” 요구사항이라고 칭함)을 먼저 고려해야 한다는 것이다. 이것은 요구사항 개발에 대한 빅뱅 방식의 포괄적인 접근에 대비해서 단계별 개선 프로세스를 보장한다. 간단하지 않고(그리고 요구사항 작성은 사실 하나의 예술적 과학이다) 요구사항에 대한 이러한 두 레벨이 순서대로 필요하다는 것은 적어도 약간의 개선이 진행될 것이라는 것을 보장한다.

역주) DO-178에서는 요구사항을 상위레벨 요구사항과 하위레벨 요구사항으로 구분한다고 했다. 그리고 작성 순서는 상위레벨을 먼저 작성하고 하위레벨을 작성하게 된다. 이를 단순한 구분이 아니라 상위레벨은 고객 관점, 하위레벨은 개발자 관점으로 이해하자. 개발자 관점이라는 것은 결국 개발자가 소스코드를 작성하기 위한 기준이 된다는 의미이다.

상세 요구사항 작성

얼마나 깊게 분해할지에 대해서 유의하라. 몇 년 전 우리는 공군폭격기를 위한 자체방어 및 디스플레이 시스템에 대해서 일한 적이 있다. 주요 엔지니어로써 우리는 방법론을 살펴보고 구조적 코딩 및 구조적 명세 분석을 사용했다. 비행기가 제작되는데 왜 100억불이나 소요되었는지 이해하려고 확인하다 보니 코드의 모든 라인마다 거품이 있었다. 그들은 소위 거품이 될 때까지 계속해서 분해하고 또 분해한 것이었다. 우리는 10에서 12 레벨까지 내려가는 분해를 확인했는데 그것은 불필요하고 효율적이지 않으며 너무 많은 유지가 필요했다. 평균적으로 하나의 요구사항에 적어도 15 ~ 20라인의 코드로 충분하다라고 하는 우리의 경험법칙을 기억하라.

역주) 위의 설명은 결국 소스코드 한 줄 마다 요구사항이 정의되어 있더라는 말을 하는 것으로 이해가 된다. 그야말로 요구사항과 소스코드가 1:1로 매칭되는 수준인 것이다. 누가 이렇게까지 하겠냐 싶지만, 세상에는 우리가 상상하지 못하는 수많은 일이 일어나고 있는 것도 사실이다.

당신은 하위레벨 요구사항을 결정하면 거기에서 멈추어야 한다. 요구사항으로부터 코드를 작성할 수 있다면 멈추어라. 그 후에 그것이 하위레벨인지 상위레벨인지 논쟁하지 마라. 아무도 신경쓰지 않는다. 하지만 기억할 것은 가정은 제거되어야 한다는 점이다. 개발자가 더 이상 가정하지 않아도 될 정도까지 분해하라. 만약 고객이 제공한 특성으로부터 코드를 작성할 수 있고, 그것을 이해할 수 있고 그런 레벨로 분해되어 있다면 당신은 당신 자신을 위한 상위 그리고 하위레벨 요구사항을 만들 필요가 없다. 그런 요구사항들로부터 코드로의 흐름과 추적을 보여줄 수 있는 한 당신은 멈출 수 있다. DO-178B와 DO-254는 하위레벨 요구사항이 첫 번째 코드를 구현할 수 있다고 말한다. 요구사항은 식별 가능하고 추적가능해야 한다.

역주) DO-178에서 상위레벨 요구사항과 하위레벨 요구사항을 무조건 작성해야 하는 것은 아니다. 저자의 말처럼 고객 요구사항에서 바로 코딩을 할 수 있다면 굳이 중간단계의 형식적인 문서를 만들 필요가 없다. 물론 그럼에도 불구하고 그것을 허용하고 그렇게도 인증을 받을 수 있다. DO-178의 철학을 보여주는 부분이라고 할 수 있다.

상세 요구사항 작성

“하위레벨 요구사항은 소소코드를 구현하는데 사용될 수 있다.” DO-178B Section 5.2

“상세 설계 데이터는 요구사항과 일치하는 하드웨어 아이템을 구현하기 위해 필요한 데이터를 기술한다.” DO-254 Section 10.3.2.2

요구사항은 식별 가능하고 추적가능해야 한다.

그래픽 혹은 문서화를 표시하기위한 툴 사용은 필수이다.

식별하고 추적하기 위한 툴 사용은 필수이다.

하위레벨 요구사항과 설계 구문을 어떻게 식별할 지에 대해서 유의하라.

분해 레벨은 마지막 아이템을 정의한다.

우리는 현대화된 항공 시스템에서의 추적성이 툴 없이도 수행될 수 있다고 믿지 않는다. 우리는 요구사항을 기술하면서 “shall”이라는 단어를 사용한 회사와 일한 적이 있다. 그들은 그것을 설계 구문이라고 부르기를 원했지만 회사 관례에서는 “shall”은 요구사항에 대한 구분이었다. 설계 구문의 모든 “shall”은 요구사항이 되었고 각각은 시험을 요구한다. 그래서 그들은 수많은 추가 시험을 작성했다. 우리는 그 요구사항들을 제거하고 설계 구문이 되도록 만드는 것을 해결하는 데 6개월을 소비했다. 어떻게 분해하고 얼마나 깊게 할 것인지에 대해서 조심하라. 왜냐하면 그것은 매우 비용이 많이 들 수 있기 때문이다. 당신은 모든 요구사항을 시험해야 하지만 설계 결정사항에 대해서 불필요한 요구사항 기반의 시험을 추가적으로 작성하기를 원하지는 않는다.

역주) 갑자기 “shall”이 나와서 무슨 말인가 싶은 분들이 있을 것 같은데 이것은 DO-178에서 요구사항을 작성할 때 요구사항 문구에 “shall”을 포함하도록 하기 때문에 나온 내용이다. 예를 들면 아래와 같은 식이다.(보통 아래와 같이 shall을 굵게 표시해서 눈에 띄게 하는 경우가 많다.)

“ABC software shall receive 32bit data from DEF module.”

저자의 사례는 설계 문서를 작성하면서 일반적인 설명과 요구사항을 작성한 구문을 구분없이 모두 “shall”을 넣어서 작성했다는 말이다. 보통 설계문서가 수백 페이지가 된다고 보면 문서 전체가 요구사항으로 뒤덮힌 상태가 된 것이다. 그런 상태로 DO-178 인증을 진행한다면 DER은 “shall”이 포함된 모든 문구를 요구사항으로 인식하고 그 모든 것들에 대한 시험을 요구하게 된다. 문서부터 새로 뜯어고쳐야 하는 상황인 것이다.