Category Archives: review

Identification of Safety requirements in a product requirements

My main job is to review all kinds of functional safety documents. Although I don’t know much detail of products, I can help engineers to make our products more safer.

Identifying safety requirement is a 2nd step of functional safety activity. Of course, 1st step is safety planning, and it is very important but many people don’t realize its importance.

Anyway, when I review requirements that regards as ‘safety’, I always ask this question to engineers;

“If this requirement doesn’t meet, it directly leads to violate safety goal?”

If it is safety requirement, it shall be always “yes”, but I experienced to get an answer “no” in many cases.  Then it is not real safety requirement.

Engineers seem to have a custom to identify them as ‘safety requirement’ which look ‘critical’.

For system which control vehicle, it is critical not to ‘sleep’. But not always for system which report to system which has a responsibility to control.

For control system, detecting who is liar is very important because it directly leads to incorrect decision, which results to control unsafely. Of course ‘not to sleep for a long time’ is also important.

But these principles are not always applicable to “reporters”. To tell a lie is worst. To tell nothing is better.

So, “to be honest” is a very important characteristic for “Subordinates”

To summarize, ask this question always. Do Not determine it with your custom.

the question is “If this requirement doesn’t meet, it directly leads to violate safety goal?”


Examples of conflicts with engineers in review meeting and solutions (산출물 검토시 엔지니어와의 갈등 사례 및 해결방법)

한글 버전은 아래로. korean version is below.

When I work as a consultant, I do a lot of different things. The original scope did not have to do this, but when I saw my customers are drowning I have no choice but to save them.

Anyway … If you review the output, you will be in a fate that can not help but posing a problem with the contents expressed inevitably. Then, when the situation that is really common comes up a lot of questions like “Why can not you do this?”

There is a problem like this, and it is good to express it this way. I’m talking about it, but most engineers are a little annoyed at the time. It means that you have to do again what you did.

In general, engineers are awkward in writing technical documentation. But do not you think it’s annoying because you have to write a document? I understand too. But is any alternatives? This is important in the company, and the company trust you to do that important thing.

Most of the time I asked from my customers was to show them examples. And finally, I will work with the customers.

Again, the conflicts often arise in the review meetings, and inevitably there will be conflicts with the engineers who identify their products with oneself.

At this time, I change my role as a certification assessor. At this point, I should be able to explain what he can accept. If that does not work, the consultant can be seen as an incompetent consultant who does not know well.

It is important as a consultant to pass this part well.

Consultant should not only provide DO-178C solutions but also provide judgments as a certification assessor. Obviously, this is not easy, but in order to do this in this area, you have to have this.

컨설턴트로 일하다보면, 진짜 별의별 일을 다 한다. 원래 scope에는 하기로 한 일은 아니었으나 고객이 허우적 거리고 있는데 나 몰라라하고 발뺌하고 있을 수도 없다. 계약 전에는 자기는 수영 전문가이고 1시간 자유 이용권에 해당하는 비용만 지불하겠다고 떼를 써서 그런가보다 하고 계약을 했는데, 입수 후 10분도 안돼 맥주병처럼 되어버린 상황이다.

어쨌건..산출물에 대해 검토를 하다보면 필연적으로 표현된 내용에 문제를 제기할 수 밖에 없는 운명에 놓이게 되고, 이 부분에 대해 지적질을 할 수 밖에 없다. 그때 정말 흔하게 나오는 상황이 “왜 이렇게 하면 안되는 것이냐?”라는 식의 질문을 많이 하게 된다.

그때 이런 저런 문제가 있고, 이런식으로 표현을 하는게 좋다. 는 식으로 이야기를 하게 되는데, 그 때 대부분의 엔지니어는 좀 많이 짜증이 나는가보다. 자기가 한 일을 다시 해야 하게 되는 것을 의미하기 때문이다.

일반적으로 엔지니어들은 기술문서작성에 서투르다. 국어를 못하니까 이과로 온 것이고(나또한 그러하다.) 그런데, 회사와서 국어하라니까 좀 짜증나지 않겠는가? 나도 이해 한다. 하지만 어쩌겠는가? 회사에서 이게 중요한 일이고, 그 중요한 일을 당신을 믿고 맡긴 것인데..대부분 이때 example을 보여달라고 요청을 하기도 한다. 그러다가 결국 컨설턴트와 공동 작업을 하게 되는 결론을…ㅎㅎ

다시 원래대로 돌아가서, 검토 회의에서 이런 갈등이 자주 발생하게 되고 자신이 만든 산출물을 자기와 동일시 여기는 엔지니어들에 대해서는 필연적으로 갈등이 생길 수 밖에 없다.

이때는 마치 인증 평가자의 입장으로 전환하게 된다. 그리고 DO-178C 요구사항에 대한 부적합 사항을 제시하게 된다. 이 때 엔지니어가 받아들일 수 있도록 설명을 해 줄 수 있어야 된다. 만약 그게 잘 안되면, 그 엔지니어에게 컨설턴트는 ‘잘 알지도 못하는 무능한 컨설턴트’로 비춰질 수 있다.

이 부분을 잘 넘기는게 컨설턴트로서 중요하다.

DO-178C에 대한 솔루션을 제공함과 동시에 인증 평가자로서의 판단력도 동시에 가지고 있어야 한다. 당연히 쉽지 않은 일이지만, 이 분야에서 이런 일을 하려면 이정도는 갖춰야 한다.