Systems Requirements


<Systems Engineering의 lecture를 정리한 내용>

Logical description 방식과 Physical description방식이 있음.

먼저 Logical description을 한다.

system이 구현해야 하는 기능을 logical하게 표현하고, 그것을 어떻게 realize할 것인지에 대해서는 physical description에서 고민한다.

Logical description이 upper level이고 physical description이 lower level이라고 볼 수 있음

upper level에서의 trade off 및 feasibility analysis가 수행되고 그 결과가 lower level에 영향을 미쳐야 한다.

(마치 ISO26262의 Concept phase에서의 수행 결과가 Technical phase의 수행에 영향을 미치는 것과도 유사함)

Logical description에서는 systems engineering 및 business case사이의 interface를 맞추는 일을 한다.

logical description의 변경은 다른 단계에서의 변경에 비해 비교적 느린 편이다. physical description이 보다 더 빠르게 변경이 발생한다.

System의 표현을 계층적으로 표현하는 것도 좋은 practice임

 

System을 문제에 대한 해결책으로 생각할 수도 있음. 그렇다면

problem domain: logical description을 사용하는 영역

Solution domain: physical description을 사용하는 영역

problem domain의 활동들은 고객에게 책임이 있음

solution domain의 활동은 그것을 구현하는 조직에 책임이 있음

 

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중