Requirements .. How should I write it?(요구사항.. 어떻게 작성해야 좋을까?)


Issues related to requirements include the following:

  1. How can you divide the boundaries between requirements and design? What content should be recorded in the requirements document and what should be recorded in the design document?
  2. How can we separate the boundaries between system requirements and software requirements?
  3. How can I write good requirements? (How can I make a bad requirement?)

In relation to Issue 1, it is premised that there can not be a clear boundary between requirements and design. In other words, there is no right answer. What I’m talking about here is a recommended approach, but not necessarily.

A requirement is a specification described in terms of ‘What’ and a design is a specification described in terms of ‘how’. (Not necessarily so, but if you have these principles, it’s a little easier to distinguish requirements from design.)

In other words, what features should be implemented? This is a requirement if you need the ability to reduce the sensitivity of the values to the sensor. It is a goal that must be achieved in software. A specific strategy to achieve that goal can be a design. For example, it is possible to recognize a value obtained by cumulatively averaging five values. Alternatively, it can be a way to filter the hardware design to slightly reduce reactivity. This can be included in the design as a strategy to achieve the goal.

I think it is easy to understand up to this point and everyone will be easy to follow. However, if the safety mechanism required by ISO 26262 should be described as a requirement, the situation becomes somewhat complicated.

You need a function to detect the fault for the sensor. Specifically, when it is necessary to detect stuck situations such as stuck at 5V and stuck at ground of sensor, the goal is to detect the fault of the sensor in some way, and how is the function to detect 5V and 0V? I can think of that. Is it the design, not the requirement, to detect the 5V and 0V of the sensor? Wait … Is not it possible to see 5V detection itself as a goal in some way? …

It is like this. It is not always a statement that has a goal attribute, but a statement is a goal from a certain point of view, and a strategy from another point of view. If so, draw a hierarchy for the goal-strategy and divide the boundary at the appropriate level. Up to this point we have categorized it as a requirement, so far we have classified it into a design.

If you add a point to help you break the boundary, you need to think about how you can test it to test the statement. Consider whether the test environment needs to be tested with the integration completed, or whether it is necessary to test during the integration process.

In the aircraft side domain of DO-178C or DO-278A, requirement and design are regarded as high level requirement and low level requirement. That is, high-level requirements are described in the requirement specification and low-level requirements are described in the design specification. This view means that there is no clear classification criteria that is always formal and always applicable to requirements and designs. Some statements can be high level for somebody and low level for others …

Therefore, I do not think it is necessary to apply too strict standards or standards. Even if it is appropriate, nobody says anything. However, the basic principles of goal and strategy (goal, requirement, strategy, design) must be observed.

 

As for issue 2, if most of the system is made up of software, would it make sense to describe it as two kinds of documents? If a particular function is assigned to a hardware chip, motor, or mechanism, the scope of the statement represented by the system and the scope of the statement represented by the software are distinctly different. For example, from the system point of view, if the user input x is input, the motor can be driven at 200 rpm. From a software point of view, when x ‘of the software corresponding to the system-level input x comes into the input, it should be expressed as the motor-related output variable y’ corresponding to 200 rpm.

However, if most of the system is composed of software, the level of description does not seem to be significantly different.

 

Regarding issue 3, it will help you to write good requirements from a testability standpoint.

Examples of bad requirements are:

1) If input x comes in, y should be output as much as possible. – if possible / if possible / if possible / if possible

-> Are you going out? Is it dry? Is it okay if we have to send out y as much as possible?

2) If the input x comes in, you can send out y.

I do not think I will be able to do it if I do not send out the word y.

3) Do not always allow values greater than y.

-> if (condition 1) then do do (action 1) If you have a requirement to describe the requirements from the point of view of action A, and you have created a situation that satisfies condition 1, Do you test? This representation can be useful in formal verification, but it is a worst-case requirement in testing. (That’s why I like formal verification, you’re so perfect …)

-> The safety goal is actually expressed in such a way. “Unintentional acceleration should not occur.” From a testing perspective, when? I want to ask.

4) When the input x comes in, you have to send out y. – fast / slow / proper / comfortable

-> What is the standard of fast? If you can not quantify it is the worst requirement in terms of testing.

 

요구사항과 관련된 이슈들은 다음과 같은 것들이 있다.

  1. 요구사항과 설계의 경계를 어떻게 구분지을 수 있을까? 어떤 내용을 요구사항 문서에 기록하고 어떤 내용을 설계 문서에 기록해야 할까?
  2. 시스템 요구사항과 소프트웨어 요구사항과의 경계는 어떻게 구분지을 수 있을까?
  3. 어떻게 하면 좋은 요구사항을 작성할 수 있을까? (어떻게 하면 망한 요구사항을 만들 수 있을까?)

1번 이슈와 관련되어서는, 요구사항과 설계의 명확한 경계는 있을 수 없다는 전제를 한다. 다시 말하면 정답이 있다는 것은 아니다. 여기에서 언급하는 것도 어디까지나 recommended approach일 뿐이지 반드시 따라야 하는 것은 아니다.

요구사항은 What의 관점에서 기술되는 specification이고 설계는 How의 관점에서 기술되는 specification이다. (반드시 꼭 그렇다는 것은 아니지만, 이런 원칙을 가진다면 요구사항과 설계를 구분하기가 조금 더 쉬워진다.)

다시 말하자면, 구현되어야 하는 기능이 무엇이냐? 센서에 대한 값의 민감도를 줄이는 기능이 필요하다면, 이 것이 바로 요구사항이다. 소프트웨어에서 달성되어야 하는 목표(goal)이다. 그 목표를 달성하기 위한 구체적 전략(strategy)은 설계가 될 수 있다. 예를 들면 5개의 값을 누적 평균한 값을 인식하는 것이 하나의 방법이 될 수 있다. 혹은 하드웨어 설계상으로 필터를 달아서 반응성을 살짝 떨어트리는 것도 방법일 수 있다. 이런 내용이 목표를 달성하기 위한 전략으로서 설계서에 들어갈 수 있다.

여기까지는 쉽게 이해할 수 있고, 다들 따라하기 쉬울 것이라고 생각한다. 그런데 ISO26262에서 요구하는 safety mechanism이 요구사항으로 기술되어야 한다고 할 때에는 약간 상황이 복잡해진다.

센서에 대한 fault를 감지할 수 있는 기능이 필요하다. 구체적으로 센서의 stuck at 5V 및 stuck at ground등과 같은 stuck상황에 대해서 감지를 해야 할 경우, 어떻게 보면 센서의 fault를 감지하는 기능이 goal이고 5V및 0V를 감지하는 기능은 how가 아닌가? 하는 생각이 들 수 있다. 그러면 센서의 5V및 0V를 감지하는 기능이 요구사항이 아니라 설계인가? 잠깐.. 어떻게 보면 5V를 탐지하는 것 자체가 하나의 goal이 되는 것으로 볼 수도 있는 것 아닌가? …

뭐 이런식이다. 항상 어떠한 statement가 goal의 속성을 가지는 것이 아니라 어떤 statement는 어떤 관점에서 보면 goal이기도 하고, 다른 관점에서 보면 strategy이기도 하다. 그런 경우 goal-strategy에 대한 hierarchy를 그려서 적절한 수준에서 경계를 나눈다. 여기까지는 요구사항으로 분류하고, 여기까지는 설계로 분류하고.. 이런 식이다.

경계를 나눌 때 도움이 될 만한 point를 추가하자면, 그 statement를 시험하기 위해서는 어떻게 시험을 할 수 있는지를 고민해봐야 할 필요가 있다. 그 시험 환경이 통합이 완료된 상태에서 시험을 해야 할 필요가 있는 것인지 아니면 통합 과정중에서 시험을 해야 할 필요가 있는 것인지를 생각해본다.

DO-178C나 DO-278A의 항공기쪽 domain에서는 requirement와 design을 High level requirement 및 low level requirement로 간주한다. 즉, high-level requirement는 requirement specification에서 기술하고 low level requirement는 design specification에서 기술한다. 이런 관점은 요구사항과 설계의 언제나 그렇듯 공식적이며 언제나 적용할 수 있는 명확한 분류기준이라는 것이 없다는 것을 의미한다. 어떤 statement가 누구에게는 high level일 수 있고 다른 누구에게는 low level일 수가 있으니까…

그러므로 너무 엄격한 잣대나 기준을 들이댈 필요는 없다고 생각한다. 적당하게 해도 누가 뭐라고 하지 않는다. 다만 goal과 strategy의 기본 원칙(goal은 requirement, strategy는 design)은 준수해야 한다.


2번 이슈와 관련해서는 시스템의 대부분이 software로 이루어진 경우에는 두 종류의 문서로 기술하는 것이 의미가 있겠는가 싶다. 하드웨어 chip이나 모터 혹은 기구부에 특정 기능이 할당된다고 하면 시스템에서 표현하는 statement의 scope과 소프트웨어에서 표현하는 statement의 scope는 명백하게 달라진다. 예를 들면 시스템 관점에서는 사용자 입력 x가 들어오면 200rpm으로 모터를 구동시킨다 등의 표현이 가능할 것이다. 소프트웨어 관점에서는 시스템 수준의 입력 x에 대응되는 소프트웨어의 x’이 입력으로 들어오면 200rpm에 해당하는 모터 관련 출력쪽 변수 y’가 되어야 한다의 식으로 표현해야 할 것이다.

그런데, 시스템의 대부분이 software로 이루어져 있다면 description 수준이 크게 차이날 것 같진 않아보인다.


3번 이슈와 관련해서는 testability관점에서 바라보면 좋은 요구사항을 작성하는데 도움이 될 것이다.

좋지 않은 요구사항의 예는 다음과 같은 것들이 있다.

1) 입력 x가 들어오면 가급적 y를 내보내야 한다. —- 가급적/웬만하면/가능하면/할 수 있으면

–> 내보내라는건가? 말라는 건가? 가급적 y를 내보내야 하니까 형편이 여의치 않으면 안해도 되는건가?

2) 입력 x가 들어오면 y를 내보내면 좋다.

–> 내보내면 좋다는 표현이 웬지 y를 내보내지 않아도 크게 여의치 않을 것 같다.

3) 항상 y보다 큰 값이 나오게 해서는 안된다.

–> if (condition 1) then do action A관점으로 요구사항을 기술해야 condition 1를 만족하는 상황을 만들었을 때 action A를 수행하는지의 여부를 판단하는데, y보다 큰 값이 나오는 상황을 알려주지 않으면 어떻게 시험하는가? 이런 표현 방식은 formal verification에서는 유용할 수 있지만, testing에서는 최악의 요구사항이다. (바로 이것이 내가 formal verification을 좋아하는 이유이다. 넌 너무 완벽해…)

–> safety goal이 사실 저런식으로 표현된다. “의도되지 않는 가속이 발생해서는 안된다.” testing관점에서는 그 때가 언제입니까? 라고 묻고 싶다.

4) 입력 x가 들어오면 빨리 y를 내보내야 한다.  —— 빨리/천천히/적절하게/편안하게

–> 빨리의 기준이 무엇인가? quantify할 수 있지 않으면 testing관점에서는 최악의 요구사항이다.

Advertisements

time triggered architecture vs event triggered architecture ?


scheduling방식과 관련해서 Time triggered approach가 있고 event triggered approach가 있다.

time triggered approach는 어떤 task에 작업을 수행할 수 있는 시간을 할당하고 매 주기마다 수행할 수 있도록 하는 방식이고 event triggered approach는 주기적으로 작업을 하는 것은 아니기 때문에 주기적인 시간을 할당하지는 않고 event가 발생할 때에 바로 처리하도록 하는 방법이다.

두 아키텍처간의 비교를 하면 다음과 같다.

____________ Time Triggered                          Event Triggered

Overload                  High                                                Low

Flexibility                Low                                                  High

Determinism          High                                                 Low

 

어떤 구조로 소프트웨어를 설계하느냐에 따라서 구현 방법이나 검증 방법이 달라질 수 있다. Event triggered 구조는 검증 입장에서 검증하기가 용이하지는 않다. event가 과중하게 들어올 때에도 software가 올바르게 일을 처리하는지를 확인하기 위해 event를 과하게 걸어봐야 한다. 그런데, WCET를 스터디할 때에 알 수 있었던 사실이지만, event의 처리 수행시간이 일정하지 않기 때문에(정규 분포 곡선을 따르게 됨) pass라고 판단하기 위한 criteria를 주의 깊게 선정해야 할 필요가 있다. 10번 시험해서 문제가 생기지 않았다고 문제가 안 생기는 것이 아니다. !!

 

No real time schedule analysis


출처는 아래와 같다.

http://users.ece.cmu.edu/~koopman/pubs/koopman11_escsv_handouts.pdf

43개를 어떤 근거로 뽑은 것인지는 잘 모르겠지만, 그 중에서 Engineering적인 측면에서 관심있는 것 중 하나를 골라서 서술하고자 한다.

15. No real time schedule analysis

Real time scheduling방식에는 여러가지 방식이 있다. 그 중에서 Rate monotonic 방식은 cost대비 가장 효과적인 것으로 알려져있다.  그런데 회사에서 어떤 알고리즘을 사용하냐고 물어보면 cyclic executives방식을 사용한다고들 한다. 그 이유는 RM방식이 cyclic executive방식보다 직관적이지 않고 분석하기가 쉽지 않기 때문인 것 같다. Rate monotonic방식과 cyclic executive방식에 대한 장단점은 논문 Software Architecture for Hard Real-Time Applications; Cyclic Executives vs. Fixed Priority Executives에 정리되어 있다.

functional safety관점에서는 rate monotonic을 무작정 사용하는 것도 쉽지는 않을 수 있는데, 이유는 여러가지 ASIL을 가진 software의 scheduling시에 낮은 ASIL이 높은 ASIL에게 간섭할 수 있기 때문인데 이와 관련된 논문이 Applying the AUTOSAR timing protection to build safe and efficient ISO 26262 mixed-criticality systems이다. 그런데 이 글을 쓰면서 갑자기 든 생각은, 여러가지 ASIL을 가진 software의 scheduling이 현실적인가? 란 의문이 들기도 한다. partitioning이 되어 있다면 여러 종류의 ASIL을 가진 task간 scheduling은 가능할 것이긴 한데, 이건 나중에 별도의 글로 작성할 기회가 되면 작성하도록 하겠다.

 

real time scheduling을 design하기 위해서는 task를 정의하고 각 task가 달성해야 하는 목표를 수집한다. 예를 들면 task1은 100msec마다 수행되어야 한다는 것이라던지, task2는 200msec마다 수행되어야 한다는 것이겠다. plan에서는 task의 이름, period, 우선순위, maximum execution time등이 기술되어야 한다. maximum execution time을 정의하기 위해서는 상당히 보수적인 관점에서 정의해야 할 필요가 있다. 즉 Worst case execution time(WCET)를 알아야 한다. 현실적으로 정확한 값을 구하기가 어렵다면 어느정도 buffer를 두거나 정말 재수가 없어도 정말 없을 만한 상황을 고려하여 기술하면 될 것이다. (broken pipeline, missed cache, page fault)

scheduling plan을 세웠으면 분석을 통해 그 plan이 실현 가능한지의 여부를 판단해야 한다. 이 때 사용하는 방법이 real time schedule analysis방법이다.

scheduling plan을 세우기 전에 각 scheduling방법의 장단점을 숙지해야 하고, 전략을 짜야 한다. scheduling을 어떻게 짜느냐에 따라서 프로그램의 구조가 많이 달라질 수 있기 때문에 소프트웨어 설계에서 매우 중요하다.

 

ISO26262, DO-178C, DO-278A