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를 작성한다면 그 사람은 능력자일 것이다.!! (여기서 ‘능력자일 것이다. !!’ 라는 의미는 그런식으로 일을 하는 것이 일반적으로 불가능하다는 의미로 쓴 것이고 쉬울 것 같으면 그렇게 해보라는 의미로 쓴 것이다. 쉽지 않을 것이라고 생각함.)

Advertisements

답글 남기기

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

WordPress.com 로고

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

Twitter 사진

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

Facebook 사진

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

Google+ photo

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

%s에 연결하는 중