시스템 및 소프트웨어 요구사항 관리 방법?


휴가중에 최근 어떤 분이 다음과 같은 문의를 해주셨다.

“어떤 경우 시스템 요구사항과 소프트웨어 요구사항이 겹치는 것 같다. ”

이 부분은 어느정도 사실이다. 그리고 좋은 현상이다. 다만 시스템의 scope와 소프트웨어의 scope간의 경계를 어떻게 정할 것인지에 대해서 약간은 명확하지 않아서 어려움을 겪고 계신 것이라고 생각한다.

요구사항을 작성하려면 그게 sys일지 sw일지에 대해서 생각해 보지 말고, 일단 interface가 어떤 형태일지 생각해보자. interface가 작성하고자 하는 요구사항의 scope가 된다. 꼭 sys로 작성하고 sw로 한번 더 작성해야 한다고 생각할 필요는 없다. 장난감을 만드는 경우라면 굳이 분리하는 것이 의미가 없을 수도 있고, 거대한 것을 만드는 경우라면 분리를 해야만 관리가 용이할 것이다.

그리고 interface를 정의했으면, 그 interface를 가지고 검증을 한다고 생각을 하라. 우리의 신체를 예를 들어서 설명하자면, 췌장에 염증이 있는지 없는지를 확인하기 위해서 배를 갈라서 뱃속을 뒤적거리면서 정상인지 확인할 수 있는 방법이 있다.

소프트웨어에 인터페이스가 정의되어 있지 않으면 췌장 검사하듯이 소프트웨어의 배를 갈라야 할 것이다.  무슨 이야기를 하고 싶은거냐면, 저렇게 하면 안된다는 얘기를 하고 싶은거다. 머리가 좀 아프면 두개골을 열어보고 어디 문제 있는지 확인할건가? 그런 생각을 가지고 있는 사람은 별로 없을 것이다.

결국 요구사항을 정의할 때 검증 가능성에 대해서 생각을 해 봐야 한다는 의미가 된다. 그게 가능할지의 여부는 정의한 interface에 의해 결정이 된다. 또한 어떤 장비를 사용하느냐에 따라서 관찰 가능성의 범위가 달라질 수 있다. 디버그 장비를 이용해서 trace를 이용하거나 디버그 장비를 이용해서 오실로스코프를 이용해서 검증할 수도 있겠다. 혹은 대상 시스템의 출력 인터페이스를 이용해서 관측한 결과를 가지고 검증할 수도 있다.

어떻게 하더라도 상관은 없다. 불편하게 검증하고 싶으면 불편한 거고, 편리하게 검증하고 싶으면 편리한 것이고 개인적인 취향일 수도 있으니까.

여기까지 제대로 따라왔다면 interface가 정의되었고, 대상의 boundary가 정의된 것이기 때문에 작성하고자 하는 scope가 결정된것이다. 여기서 requirement라는 것을 작성한다고 하면 interface및 boundary를 감안해서 정의를 하도록 가급적 노력해야 한다.

물론 모든 경우에 적용할 수 있는 그런 법칙같은 것은 없다고 생각해야 하겠으나, 일반적으로 적용 가능한 법칙은 다음과 같다.

interface를 INPUT_SET, OUTPUT_SET으로 정의를 하고, INPUT_SET은 입력 interface의 집합, OUTPUT_SET은 출력 interface의 집합으로 정의를 하자면,

요구사항의 집합인 REQUIREMENT_SET은 다음과 같이 정의를 할 수 있다.
OUTPUT_SET = function of (State, INPUT_SET)

다만, 시스템 범위의 비기능 요구사항들이 저런 방식으로 정의가 가능한지는 확실치는 않고, 기능적 요구사항은 저렇게 정의할 수 있다. Simulink나 stateflow를 떠올려보면 쉽게 상상이 될 것이다. state machine의 수학적 정의가 저렇게 된다.

여기서 이 글을 쓰게 된 동기인 요구사항 겹침 문제로 돌아가보자.

sys간 요구사항과 sw간 요구사항은 겹친다. 겹칠 수 있다. 그것이 자연스러운 것이고 정상적이다. 그런데, 장난감을 만드는 것이 아니라면 sys요구사항이 sw요구사항을 전부 포함하거나 sys요구사항 및 설계에서 sw요구사항 및 설계를 포함한다면 그것은 바람직하지는 않은 것 같다.

그럼 정확하게 어떻게 분리를 시킬 것인가?

sys의 기능적 요구사항 중 일부분(REQ_SYS_FUNC1)이 sw로 구현한다면 REQ_SYS_FUNC1은 시스템 요구사항이면서도 sw요구사항이 될 수 있다.

여기서 한 단계 더 나아가자면, sys로부터 할당받은 sw 요구사항은 보다 상세화시킬 수 있다.

여기서 좀 다른 얘기로 들릴 수 있지만, sw요구사항을 작성한다는 것은 기술 문서를 작성하는 것이다. 기술 문서를 작성하기 위해서는 문서 작성 교육을 받아야 한다. 주제를 잡고, 개요를 짜서 문서의 뼈대를 만들고, 스타일을 적용해서 두괄식으로 할지 미괄식으로 할지….

sys로부터 할당받은 sw요구사항을 어떻게 상세화 시킬 것인가? 이 부분은 그 주제로 어떻게 기술문서를 작성하도록 하느냐와 유사하다. 그리고 그것은 분명히 sys 수준과는 차이가 있어야 한다. 어떻게 하냐고 묻는다면 그것은 위에서 이야기 했던 것들을 고려하고 기술문서 작성을 위한 고민을 해봐야 한다.

아무래도 무슨 말인지는 대충 알겠는데, 그래서 어떻게 하라는지 좀 이해가 잘 안될 것이다. 그렇다면 이제부터 고민해보시길 !

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s