카테고리 보관물: Introduction to Systems Engineering

Requirement Engineering


<Systems Engineering의 강의 내용 요약>

System을 기술할 때, needs와 requirement를 구분해야 할 필요가 있다.

Needs는 business operations level에서 business management의 언어로 기술됨

Requirement는 formal statement로서 구조화되고 평가 될 수 있음.

Requirement를 5가지의 layer로 나눌 수 있음

  1. Enterprise – operation concept
  2. Business Management – business needs, constraints
  3. Business Operations – stakeholder가 그들의 needs와 requirement를 정의
  4. System – logical, physical view로 정의됨
  5. Sub-system – lower level
Responsibility description focus on description type
Problem domain those who have ownership of the problem to be solved in the language of the
customer’s business management and business operations
what the system needs to be able to do, how well it should be done, and why logical (or often
functional) descriptions
Solution domain those implementing the solution engineering and physical terms how the problem is to be solved how it will look once it has been implemented physical descriptions

Logical/functional description은 2,3 layer(Business Management, Business Operations)에서 기술되는 방식
Physical description은 4,5 layer(System, subsystem description)에서 기술되는 방식

requirement layer

Requirement란 무엇인가?

the result of a formal transformation of one or more needs into an agreed to obligation for an entity to perform some function or possess some quality (within specified constraints)

constraints는 일종의 non-functional requirement의 범주에 포함되기도 하고 별도로 표현하기도 하는 요구사항임

성능 요구사항

시스템이 해야 하는 것을 결정했다면, 설계자는 시스템이 어떻게 각각의 기능적 요구사항을 잘 수행하도록 할지를 결정해야 한다. 좋은 원칙은 모든 기능적 요구사항이 식별될 때마다 적어도 하나의 성능적 요구사항을 대응시키는 것이다. (속도, 정확도, endurance, acceleration)

검증 요구사항

기능적 요구사항을 식별할 때마다 해당 요구사항을 검증하기 위한 기준을 수립하는 것은 좋은 practice이다. (격하게 공감함)

Rationale Statement

[정말 중요하다고 생각하는 부분인데, 실제 컨설팅을 하면서 이 부분을 제대로 작성하도록 유도하지 못했다. 아마도 requirement analysis 활동을 수행하고 컨설턴트가 requirement analyst로의 role을 담당하여 시범을 보인다면 좋은 사례가 될 수 있을거라고 생각함. ]

Other types of requirements

  • operational requirements
  • stakeholder requirements
  • environmental requirement
  • interface requirement
  • system requirement
  • regulatory requirement
  • safety requirement
  • design requirement

요구사항 속성

  • 식별자
  • 제목
  • 우선순위
  • 위험
  • 출처
  • 이유
  • 히스토리
  • 다른 요구사항과의 관계
  • 작성날짜
  • 작성상태(proposed, reviewed, accepted, rejected)

Requirement의 계층 구조

Requirement를 decomposition하여 계층적으로 만드는 것은 좋은 practice가 될 수 있다.

  • Function 1
    • Function 1.1
    • Function 1.2
    • Function 1.2
  • Function 2
    • Function 2.1
    • Function 2.2

계층 구조화 하기 위한 방법: Elicitation과 elaboration을 통해

elaboration은 아래의 두 가지 방법을 통해서 된다.

  • Decomposition entails breaking a higher-level function into those lower-level functions that are explicitly required by it.
  • Derivation entails requirements engineers drawing some inference. That is, business management or the stakeholders did not state the function directly, but the derived function is a necessary part of the system design if one or more of the directly stated functions are to be met.

여기서의 derivation이란 의미를 보면 ISO26262에서 derived라는 표현과 헷갈릴 소지가 있을 거 같다는 생각이 다시금 …26262에서의 derived는 traced의 의미로 사용되었음..

Elicitation 및 Elaboration을 하기 위해서 requirement engineer는 다음을 이해할 수 있어야 한다.

  • business
  • application domain
  • specific problem
  • needs and constraints of system stakeholders
  • technologies and engineering involved

needs및 requirements식별하기 위한 방법

  • workshops
  • brainstorming, problem solving sessions
  • interviews
  • surveys/questionnaires
  • use cases, operational scenarios
  • simulations, models, prototypes
  • etc

Requirement의 flowdown

Requirement flowdown

계층적 요구사항

1. Requirement Breakdown Structure(RBS)의 example

RBS example

2. Function block diagram의 example – Simulink나 Stateflow로도 표현이 가능함

HFBD

요구사항을 작성할 때 언제나 요구사항들이 external interface의 입출력으로만 표현가능한 것은 아님. 사실 그렇게 되면 여러모로 유익한 점들이 많기는 하지만, 세상이 그렇게 쉽지는 않음..

internal interface가 필요하여 pipe방식의 처리를 해야 하는 경우도 생김. (복잡한 시스템의 경우나 fail-safe 혹은 filtering기능이 있는 시스템의 경우 대부분 이런 방식이다. 이런 경우 external interface를 이용하여 requirement를 작성한다면 그 사람은 능력자일 것이다.!! (여기서 ‘능력자일 것이다. !!’ 라는 의미는 그런식으로 일을 하는 것이 일반적으로 불가능하다는 의미로 쓴 것이고 쉬울 것 같으면 그렇게 해보라는 의미로 쓴 것이다. 쉽지 않을 것이라고 생각함.)

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의 활동은 그것을 구현하는 조직에 책임이 있음