요구공학 프로세스, Requirements Engineering

출처: Guide to the Software Engineering Body of Knowledge

참고: 블로그 주인장 마음대로 그림으로 작성하여 업로드

 

소프트웨어 (또는 시스템) 개발에 있어서 무엇이 개발되어야 하는지를 결정하는 공정을 요구공학 (Requirements Engineering)이라고 부른다. 

 

요구공학은 크게, Requirements Development와 Requirements Management로 구성된다고 볼 수 있다.

 

쉽게 생각해서 요구사항을 개발하고 검증 (Development)하면서 이는 프로세스적으로 관리되어야 한다는 것이다. (Management)

 

Development와 Management의 주요 단계를 보면 아래와 같다.

Development 부분을 간략히 설명하면,

1. 고객이 무엇을 원한다. --> 요구사항 도출 (제약사항 포함)

2. 요구사항을 명확하고 상세화 한다. --> 모호하거나 모순되는것은 없는지, 명확한지 등 (우선순위화도 가능)

3. 요구사항을 작성한다. --> 결국은 정제된 요구사항으로 프로젝트에서 활용되어야 하니까

4. 요구사항을 검증한다. --> 그래서 결국은 요구사항을 만족하는 개발이었는지 평가해야 하니까!

 

Management 부분을 간략히 설명하면,

프로젝트는 한시적, 제한적으로 운영되기 때문에 결국은 관리가 필요하다.

(돈도 없고, 시간도 없고, 인력도 없는게 일반적인 경우이다)

 

그렇기 때문에,

1. 요구사항 범위 설정 및 합의

--> 관리해야 하는 범위를 설정한다. 그리고 이는 반드시 고객과 합의 해야 한다.

(내 마음대로 설정하고 시작 땅! 하는건... 말도 안되니까)

2. 요구사항 베이스라인

--> 마일스톤을 설정해야 한다. Proto까지는 어떤 요구사항이, Pilot까지는 어떻게.. 등 고객의 마일스톤이 있을 것이고, 내부적으로 이를 달성하기 위한 마일스톤이 있을 것이다. 세부적으로 관리해야 한다.

3. 요구사항 변경관리

--> 요구사항은 변경된다. 변경안되는 경우를 본 적이 없다. 추가가 되는 것도 변경이고, 수정되는 경우도 변경이다. 물론 삭제되는 경우에도 마찬가지다. 변경되는 사항이 어떤 영향을 미치는지 평가해야 한다. 그리고 이러한 부분에 대해서 의사결정은 PM, DL 등 개인의 판단으로 그치는 것이 아니다. 이해관계자들끼리 논의해서 변경을 받아들일지, 수락해서는 안되는지 판단해야 한다.

4. 요구사항 추적

--> 이 부분은 Management 뿐만 아니라 Development 부분에서도 매우 중요하다. 시스템 요구사항이 소프트웨어, 하드웨어, 기구와 같은 도메인으로 전개되는 경우, 무슨 요구사항 때문에 이를 이렇게 설계하고 구현했는지 근거자료가 된다. 즉 요구사항은 가장 처음의 시초이가 기준이 된다. 

시스템 레벨에서는 소프트웨어에서 요구사항과 연결, 소프트웨어는 반대로 시스템 요구사항과 연결 양방향 추적성을 통해서 어떤 요구사항이든지 상위/하위 상관관계를 확인할 수 있어야 한다.

 

위 설명한 내용을 그려보면 아래와 같다.

1. 요구사항 추적은 요구사항 명세, 검증 등에 녹여져 있다고 간주하였다.

2. 요구사항 변경관리는 이벤트적인 요소이며, 결국은 요구사항 분석 단계 부터 이어진다고 생각하자.

---

조금 더 상세하게 풀어보자. 그래도 뭐 결국은 일반적인 내용이다. 그렇구나 하고 가볍게 읽어보자.

 

---

 

 

 

---

 

 

 

 

---

 

---

 

 

 

 

 

 

 

 

 

 

현재 저는 시스템 엔지니어로서, 요구사항과 많이 밀접한 일들을 하고 있습니다.

 

실무에서의 상세한 내용들을 기술하기에는 어려울 것 같아서 그래도 두리뭉실하게 말씀드리면,

 

1. Tool 없이는 힘들다

--> Excel, Word 등의 문서를 통해서 요구사항을 관리가 가능한 경우는 많지 않을 것 같습니다. 센서 하나부터도 다양한 요구사항들이 존재하고 관리해야 하는데 현실적으로 문서 툴로는 어렵다 입니다.

 

2. 속성(Attribute) 값을 최소로 하자.

각 요구사항 마다 Status, Target, ImpactedDispline, ASIL 등 다양한 속성 값을 표기하여 요구사항이 Live하게 되는 것은 좋은데... 관리가 어렵다. 였습니다. 

 

요구사항 중요하죠. 그런데 중요한 것은 엄청 많습니다.

모두를 챙길 수가 없습니다. 최소한 필수적인 요소들을 가지고 관리하시는 것을 적극 권장 드립니다.

 

3. 시스템 엔지니어, 소프트웨어 엔지니어 뿐만 아니라 다 같이 좀 보자.

마치 시스템과 소프트웨어 엔지니어의 산유물인양,.. 같은 프로젝트에 참여하는 사람들께서는 잘 안보시더라고요.

기구엔지니어 뭐 안볼 수 있죠. 해당 기구 요구사항이 시스템에서 관리되지 않는다면요. 관련이 없다면요.

그런데 프로젝트 매니저, 검증 VnV 담당자들도 안보더군요.

 

이런 질문을 드리고 싶습니다. 이럴거면 왜 힘들게 관리하는거죠? 그냥 문서로 하면 편할텐데요?

 

4. 요구사항 대로 개발하자.

생각보다 요구사항대로 개발이 잘 안되더라고요.

초기에 요구사항에서 변경되어 업데이트 되는 경우, 베이스라인 설정을 위해서 리뷰 요청하는 경우 등 모두를 포함해서 잘 안보고, 그냥 개발하는 경우가 있더군요.

 

뭐 그럴 수 있다고는 생각됩니다. 업데이트 된 요구사항을 메일/구두상 으로 공지(Notice) 하지만, 현업이 바쁘니까 놓칠 수 있죠. 몇 번의 Remind를 날려도 그럴 수 있죠. 회의 시간에 얘기해도 그럴 수 있죠. 프로젝트 미팅에서 LOP로 남겨 놓아도 그럴 수 있죠....

 

5. 효율적으로 관리하자.

프로젝트마다 Variant 마다, 제품마다, 각 분기점에 놓이는 것마다 별도로 요구사항을 관리할 수 없습니다.

그런데 이를 다 시스템에 각각 관리하기에는 우리는 리소스가 없습니다. 인원과 시간이 없습니다.

골드 샘플로 만들고 이에 따라 Branch, Variant 등의 방법을 통해서 관리하는 방법이 반드시 고려되어야 합니다.

 

현업에서 나오는 이슈, 보완 점 들을 놓고서 얘기하고 싶지만, 그럴 수 없는 점을 이해해주시기 바랍니다.

 

날씨가 춥네요. 새해 복 많이 받으세요.

감사합니다.