[IREB CPRE] Chapter 4. Practices for Requirements Elaboration 2️⃣

🟡 4.3 Resolving Conflicts regarding Requirements

 

 

 

 

✅ 4.3.1 How Do You Resolve a Requirements Conflict?

 

* Requirements Conflict 해결 방법 *

Conflict identification -> Conflict analysis -> Conflict resolution -> Documentation of conflict resolution

 

conflict 분석 시 참고할 수 있는 측면들

 

conflict resolution을 문서화 할 때 참고해야 할 부분들

 

 

 

✅ 4.3.2 Conflict Types

 

1) Subject matter conflict : 서로 다른 환경, 다른 지역에서부터 오는 차이점으로 인해 발생하는 갈등.

이 사실들을 자세히 정리하고 분석해서 충돌되는 부분들에 대한 합의점을 찾는 것이 해결방법

 

2) Data conflict : 다른 source에서 가져온 데이터가 불일치하거나 같은 data를 다른 방식으로 해석한 경우에 발생하는 충돌.

문화적 차이, 의사소통의 부족으로 인해 발생하는 경우로서 요구공학자가 미리 발생할 수 있는 타입의 갈등을 의심해보고 empathy하는게 중요. 자기만의 확고한 주장과 증거를 갖고 있는것도 필요.

 

3) Interest conflict : 각기 다른 포지션을 바탕으로 그들의 관심사가 다를 수 있는 부분.

해결책을 찾기 위해서는 양 측의 소득과 고충이 무엇인지 상호간의 이해가 출발점이 될 수 있음.

 

4) Value conflict : stakeholders가 포함되는 가치과 원리의 차이에서 발생하는 충돌.

3번 갈등과 비교했을 때 value conflict는 더 개별적이고 장기적 관점에서 연관되어 있다는 것이 차이점.

사람들을 통합할 수 있는 가장 높은 레벨의 value를 찾는 것이 해결책.

 

5) Relationship conflict : 사람들 사이의 잘못된 소통과 감정이 담긴 부정적 경험이 원인이 되는 갈등.

Uniting parties around a higher value is successful. 사람들을 바꾸는 것은 잠재적인 해결책. 근본적인 원인을 찾아서 분석하고 해결하는 것이 가장 좋은 방법.

 

6) Structural conflict : 권력의 불평등, 한정된 자원에 대한 경쟁, 서로 간의 구조적 의존성을 포함하는 갈등.

불균형에 의한 갈등은 의사소통 및 의사 결정에서 비롯되는 것. 이 문제를 확대하거나 높은 레벨의 권위가 필수적일 때가 있음.

 

 

 

✅ 4.3.3 Conflict Resolution Techniques 

 

1) Agreement : 모든 사람들이 선호하는 특정 선택지로 합의를 보는 것. 시간이 오래 걸림.

Long lasting.

 

 

2) Compromise : agreement란 비슷하지만 선호하지 않는 결과더라도 받아들인다는 점에서 차이가 있음. Long lasting. 

 

 

3) Voting : 투표를 통해 둘 중 하나를 결론으로 제시. 가장 중립적인 해결책. 

 

 

 

4) Overruling(기각) : 여전히 동의 못하고 거부하는 사람이 있는데 시간은 없을 때 우선순위에서 벗어난 의견을 기각.

 

 

5) Definition of variants : subject matter, interest, value conflicts에 자주 쓰이는 해결방법. 모든 충돌 요구사항에 분리해서 해결책을 제시하는 것. 정말 최고의 솔루션 같지만 비용이 매우 많이 든다는 단점이 있음. 

 

 

 

6) Auxiliary techniques : 보조 기술이라 단독으로 쓰이진 않지만 1~5까지의 기술을 뒷받침할 때 씀. 

- CAF(Consider-All-Facts) : 모든 전제 조건들을 다 고려해보는 것. 

- PMI(Plus-Minus-Interesting) : 브레인스토밍/의사결정 tool. 아이디어와 컨셉을 여러 관점에서 검토할 수 있도록 해줌. 

이를 통해 하나하나 따져가면서 비교해 볼 수 있음. 하지만 이건 언제까지나 보조 수단일 뿐.

 

 

 

 

🟡 4.4 Validation of Requirements

 

 

 

✅ 4.4.1 Important Aspects for Validation

 

1) Involving the correct stakeholders : 검증에 참여할 인원을 정의하고 이들이 어느정도로 연관돼있는지 고려해야 함.

따라서 더 큰 리스크가 있는 프로젝트 범위에서는 가장 높은 독립성을 요구해야 한다.

 

2) Seperating the identification and the corretion of defects : 어떤 요구사항을 검증하기 위해 선택한 후 발견한 디펙을 수정할 지 말지 결정하는 것은 그 이후에 따로 분리해서 해야함. 왜냐하면 이 defect이 다른 곳에 영향을 미칠 수 있기 때문

 

3) Validation from different views : 여러 사람의 관점에서 검증하는 것이 필요함.

여러 학문 간의 연구 및 팀을 이뤄서 검증? 그래야 그들의 전문 지식이 기여되면서 보다 정확한 검증을 할 수 있는 것.

 

4) Repeated validation : sequential project에서는 대부분 가장 마지막에 검증을 하는데 이게 단순 일회성으로 끝나면 안됨.프로젝트가 진행되는 나머지 기간 동안에도 insight를 통해 update, detailed, expanded 할 수 있음.

Iterative project에서는 여러 검증 방법이 요구사항을 발전시킬 수 있음. 하지만 이 때 너무 세세한거에 집중하다보면 큰 틀을 해칠 수가 있어서 주의해야 함. 

 

 

 

✅ 4.4.2 Validation Techniques

 

 

- Review Tech

1) informal review : author-revier cycle. Peer review

 

2) formal review : walkthroughs, Inspections

 

* walkthroughs : 검토 회의 전에 요구사항 명세서를 미리 배포하여 사전에 빠르게 검토한 후 짧은 결함을 발견

 

 

 

* inspection : 요구사항 작성자를 제외한 다른 검토 전문가들이 RS를 확인하면서 결함을 발견

 

 

 

- Exploratory tech

1) Prototyping : early bersion of the system이 stakeholder에게 배포된 후 평가를 받음. 실제 개발된 sw의 견본품을 만들어 개발 결과를 예측

 

2) Elicitation and validation go together : 도출 및 검증을 동시에

 

3) Alpha testing and beta testing : Alpha는 개발자 관점에서 시뮬레이션 하는 것.

Beta는 사용자 관점에서 실제 상황처럼 테스팅 하는 것. 피드백을 자유롭게 받는 것이 중요.

 

4) A/B testing : 릴리즈된 버전의 시스템을 가지고 수행하는 경우가 많음. 두 그룹에 두 가지 다른 변수를 주고 다른 방식으로 검증하는 것. 

 

 

- Sample development

: static, 개발자를 통해 input을 넣고 이에 기반하여 여러가지 것들을 생성. 그런 후 의도된 output과 맞게 됐는지 확인. 뭐 그냥 여러 샘플가지고 직접 테스트하는건가 

 

 

 

 

 

 

Reference

Handbook for the CPRE Foundation Level according to the IREB Standard

Version 1.1.0

September 2022

 

위 책 내용을 챕터별 중요한 포인트 위주로 screenshot을 통해 정리한 자료입니다.

스스로 공부하기 위한 요점정리 노트이므로 상업적인 사용 목적은 전혀 없음을 알려드립니다:)

 

이 시험에 대한 정보 및 각종 자료는 아래 사이트에서 확인하실 수 있습니다. ⬇⬇⬇

http://www.kstqb.org/sw/lreb.asp