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관점에서는 최악의 요구사항이다.


“Requirements .. How should I write it?(요구사항.. 어떻게 작성해야 좋을까?)”에 대한 4개의 생각

답글 남기기

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

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

Twitter 사진

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

Facebook 사진

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

Google+ photo

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

%s에 연결하는 중