Stakeholder Requirement

V-Cyclce, Process 등 많은 좋은 말(?)들이 많지만, 결국은 말하고자 하는 점은 요구사항대로 개발하고 구현하고 검증해야 한다. 일 겁니다.

 

ASPICE에서 SYS (System) 에서는 요구사항 시작 단계에 아래와 같이 SYS.1 Requirements Elicitation 이 명기되어 있습니다. 역시 여기서도 요구사항으로 시작합니다.

 

오늘은 간단하게 Requirements 를 대할 때 어떻게 해야 하는지 말해보고자 합니다.

Requirements는 누가 줄까요? 고객이 주는 걸까요? 고객만 주는 걸까요? 고객이 주는 요구사항(Requirements)는 충분할까요? 개발하는데 상세화는 어떤 기준으로 해야 할까요? 요구사항 명세 시 관리해야 하는 수준은 어떻게 해야 할까요? 우리 조직에서 관리할 수 있는 수준은 어느 레벨일까요?... 

 

(꼬리에 꼬리를 무는 질문을 계속 할 수 있습니다)

 

저는 오늘 이러한 부분을 아래와 같이 이해한 수준으로 간략히 정리해 봅니다.

우리가 개발하는 제품, 서비스의 라이프사이클을 보았을 때, 이와 관련한 이해관계자들이 내부, 외부에 있을 거에요. 그리고 환경적인 부분들, 즉 시장에서 요구하는 수준 (e.g., 자율주행 레벨, 경쟁사 기술 수준 등)이 복합적으로 엮여 있을 거라고 생각합니다.

 

이러한 이해관계자들의 요구하는 사양 및 제약/제한 사항, 정보 등을 취합해서 Stakeholder Requirements로 관리할 수 있습니다. 

취합 시 위 그림에 인터뷰, 워크샵, 문서 등의 방법과 고려할 수 있는 부분을 기록하였습니다. 과거 이전 프로젝트/유사 제품 개발 시 고려되었던 Risk/Issue List 또는 Lessons Learned도 참고할 수 있는 대상입니다.

 

이렇게 취합된/추출된 이해관계자들의 요구사항은 어느 수준으로 관리되어야 할까요?

저희가 구분했던 Functional requirements, Non-Functional requirements 등 그리고 Verification method, Verification criteria 등의 속성 값들을 가지고 여기서 논의할 필요는 없을 것입니다. (그렇게 하기 어렵고, 할 목적이 있나 싶네요)

 

 

Heading (제목)

요구사항 구조(structure)를 잡고, 정렬/구분 하기 위해서 Heading이 필요 했었습니다.

 

예를 들면, Introduction, Definitions, Functional Safety, Regulation 등이 있을 수 있습니다.

 

Information (정보)

요구사항으로 분류하기에는 어떤 action을 취하거나, 전개해가기에는 어려운, 그러나 해당 정보를 고려해야 하는 부분들이 있는 경우 이러한 카테고리를 고려했었습니다.

 

예를 들면, Scope, Reference (documents) 등이 있을 수 있습니다.

 

Stakeholder Requirements (이해관계자 요구사항)

결국은 우리가 다루어야 하는 기능/서비스에 대해서 명세가 되어야 하는 요구사항입니다. 가능한 수준(?) 최대한(?) 자세하게 기술하는게 좋습니다. 모호하고 애매할수록 System requirements를 구체화하기 어렵기 때문이죠.

 

예를 들면 OEM마다 라인 별 요구사항이 다를 수 있을 것입니다. 이런 부분은 반드시 명시가 되어야 겠죠.

또는 Over temperature에 대해서, 리소스 사용율 등이 될 수 있습니다.

 

Stakeholder Constraints (이해관계자 제한사항)

기술적으로 조직적인 차원에서 제한되는 부분을 명세합니다. 

 

예를 들면, 무게, 중량도 될 수 있고, 성능 면에서 구현하기 어려운 부분들도 될 수 있을 것입니다.

 

 

이해관계자 요구사항을 포함해서 앞으로 전개/개발/구현하는 요구사항들로 이어질 때 요구사항은 agreed 되어야 합니다. "Agreed stakeholder requirements are defined and baselined"

 

이런 부분을 어떻게 해야 할까요? 어렵게 생각하지 않고 간단하게 생각하면 agreed 되었다고 표기하면 되지 않을까요?

 

Requirements status의 속성 값으로 agreed를 표기하면 될 것입니다.

agreed 되기위해서는 review를 해야 할 것입니다. --> In review

모호하거나 필요한 정보가 더 있어야 하는 경우도 있을 것입니다. --> To be clarified

검토하다 보니 이번에 고려해도 되지 않는 경우도 있을 겁입니다. --> Not application

난 동의 못해, 말도 안돼.. 라는 것은 아니지만 동의 못할 수 도 있을 것입니다. --> Not agreed

아... 가장 처음 아직 아무런 검토도 되지 않은 초기 등록된 요구사항도 있겠네요. --> Init

 

상황 별로 더 상세하게 고려할 수도, 위의 내용 중 일부만을 고려할 수도 있습니다. 

In review, Agreed, Not agreed 만을 사용할 수도 있습니다.

 

이전에도 말씀 드렸지만, 프로세스는 우리가 감당할 수 있는 수준을 고려하셔야 합니다. 표준이나 타 조직의 프로세스를 그대로 받아들이시는 경우, 조정(Tailoring)되지 않는 경우.. 문서상으로는 멋져보이고 구현된 것처럼 보일 수 있겠지만 이는 50점도 아닌 10점도 아닌 0점이라고 생각합니다. (위험한 발언인가요? 개인 생각이니 이 사람은 이렇게 생각하는 구나 라고 넘어가주시기 정중히 부탁 드립니다.)

 

좀 더 그림으로 이해하기 쉽게 그렸으면 좋겠는데, 그렇게 하기에는 일도 해야 하고 육아도 해야 하고.. 와이프 눈치도 봐야 하고... (저도 이해관계자가 많이 있습니다) 이해해 주세요^^;

 

이상 읽어 주셔서 감사합니다.