System, Software 및 요구사항 및 설계의 경계를 명확하게 정하기


일반 개발자들 입장에서는 사소한것이고 별로 중요하지 않다고 생각할지 모르겠다. 막상 Safety 표준대로 준수하려고 하면 boundary를 명확하게 잡지 못해서 혼돈에 빠지는 경우를 종종 보게 된다.

요구사항과 설계의 명확한 경계란 것은 없지만, 일반적으로 통용되는 규칙은 다음과 같다.

Requirement는 Problem domain이다.  반면 Design은 solution domain이다.

이게 가장 큰 틀인데, ISO26262나 IEC61508의 경우 Safety측면이 강화되어 Safety를 강화하기 위한 구체적인 방법까지도 problem domain에 속한다. (Functional safety표준들이 요구사항에 대한 범위를 safety에 한해서는 약간 넓혔다고 생각해도 무방하다)

Software와 System 간의 경계는 이전 포스팅에서도 언급했으나, Software및 System의 interface를 정의하면 명확해진다. Software의 interface는 입출력 ‘변수’이다. 하지만 system의 interface는 physical한 실체가 존재해야 한다.(일반적으로는)

그러나 여전히 scope에 대한 불명확함이 생길 수 있다. 그렇다면 모호한 그것이 언제 태어났는지(출생일)를 기준으로 생각해 볼 수 있다. 시스템 설계에서 태어난 것이면, 그 녀석은 system의 범위에 있는 것이고, 소프트웨어 설계동안 태어난 것이면 그 녀셕은 software의 범위에 있는 것이다.

누구에게는 사소하지만, 다른 누구에게는 심각한 고민거리..

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