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

🟡 4. Tasks in RE

 

1) idenfifying and analyzing potential sources for requirements

2) elicitating the requirements from these sources.

3) confilct resolution

4) validation of requirements

 

 

 

🟡 4.1 Sources for Requirements

* 3 major categories of sources *

1) Stakeholders

2) Documents

3) (Other) Systems

 

 

✅ 4.1.1 Stakeholders

 

stakeholder의 기준을 정의하게 되는데 첫 출발점인 onion model

 

*snowball principle : stakeholder를 더 많이 찾을 수록 새로운 것들을 찾기 훨씬 쉬워진다.

 

* stakeholder

1) 요구공학자의 물음에 답하기

2) 요구공학자를 위해 시간을 내기

3) 이들의 피드백을 잘 반영하기

 

 

위와 같이 stakeholder's list 만들어두기

 

 

🔆 4.1.1.1 A Special Stakeholder : The User

 

User의 두 가지 분류

 

1) internal users : staff, management, subcontractor처럼 직접적으로 조직과 연관이 있는 사람들.

연락하기 쉽고 더 밀접하게 연관돼있어서 영향력이 있음.

2) external users : customers, business partners, civilians 처럼 회사 밖에 있는 사람들.

수가 매우 많고 formal channel를 통해서 영향을 미칠 수는 없음.

 

 

🔆 4.1.1.2 Personas

 

페르소나를 만들기 위한 두 가지 접근 방법

 

1) Data-driven : interview, focus groups, data collection tech와 같은 마케팅 기술과 함께 발전됨.

Qualitative personas. 만약 통계적 분석으로 만들어진 건 quantative persona라고 부름

2) Imagination : brainstorming, ad hoc(즉석) pesonas or proto-personas.

 

 

 

✅ 4.1.2 Documents

 

- internal documents : 쉽게 얻을 수 있지만 보안 유지의 문제로 밖으로 반출하기는 어려움

- external documents : 찾기는 어렵지만 공공의 것으로 쓰기 쉬움.

-> 버전과 문서 번호를 입력하여 분류하는 것도 매우 중요한 일.

-> 모든 사람들이 이해관계자로서의 역할이 있음. 이를 요구공학자는 알고 있는 것이 필요. 어떤 문서가 어떤 이해관계자와 연관이 있는지 등등

 

 

 

✅ 4.1.3 Other Systems

 

similar systems

Interfacing systems

 

 

 

🟡 4.2 Elicitation of Requirements

 

 

알맞는 elicitation 기술을 선택하기 위해 고려해야 할 요소들 예시

 

 

 

✅ 4.2.1 The Kano Model

 

 

1) Delighters(excitement factors, unconcious requirements) : 고객이 인지하지 못하는 feature.

처음 스마트폰이 나왔을 때 대부분 사람들은 의심했지만 몇몇 얼리 어답터들이 사용해보면서 이를 퍼뜨림으로써 지금처럼 보편화할 수 있었던 것.

 

2) Satisfier(performance factors, concious requirements) : 고객이 명확하게 요청한 사항. 스마트폰에 렌즈랑 비디오 옵션이 탑재 됐을 때 사람들이 이를 사용할 가치가 있다고 느낀것처럼.

 

3) Dissatisfiers(basic factors, subconcious requirements) : 이 역시 delighter 처럼 고객이 요청하지 않은 사항이지만, feature는 너무 명확한데 고객에 상상하지 못한 부분.

반드시 고려되어야 할 사항이지만 그러지 못한 것.

스마트폰에 GPS가 없는 것은 있을 수 없는 일이지만 사람들은 인지하지 못할 수 있음.

 

좋은 예시

 

=> 즉, Delighters는 무의식, Satisfiers는 의식, Dissatisfiers는 잠재의식이라고 볼 수 있음.

 

 

 

 

 

✅ 4.2.2 Gathering Techniques

 

Gathering Tech의 4가지 종류

 

1) Questioning : Interviews, Questionnaires

 

* interviews : 요구공학자와 인터뷰어가 1대1로 진행하는 것(small group은 옵션).

가장 자주 쓰이는 elicitation 기술.

상세한 정보를 밝힐 수 있고 답변에 따라 유연한 제안을 할 수 있음.

시간이 소요되는 일이기 때문에 많은 이해관계자를 대상으로 한다면 적합하지 않음.

 

* questionnaires : quantative-다수를 대상으로 쉽게 답변을 얻을 수 있음. 빠르게 취합 가능.

Qualitative-복잡한 답변(open-ended)을 통해 새로운 요구사항 생성.

-> 이미 인터뷰를 통해 주요한 아이이어를 얻은 후, 다수를 대상으로 검증하는 용도로 쓰이면 좋음. 인터뷰 다음 스텝으로!

 

 

2) Collaboration : workshops, crowd-based RE

 

* Workshops : meeting. Get a good global insight in short time, 참여자들 간의 상호작용 가능.

Creativity techniques. 자세한 정보가 얻고 싶다면 questioning이 더 적합하긴 함.

 

* Crowd-based RE : 여러 전문지식, 재능을 통해서 얻는 것들. 지식 공유, collaboration이 가능

 

 

3) Observation : field observation, apprenticing

 

* Field observation : 프로세스를 방해하거나 user를 산만하게 할만한 상황에서 사용됨. 예를 들어, 치과 대기실에서 다른 환자들과 함께 앉아있으면서 그 행동을 관찰하는 것. 

-> Dissatisfier 확인을 위한 best elicitation 기술!

 

* Apprenticing : RE가 인턴십처럼 직접 경험해보고 배우면서 관찰하는 것. 

 

 

4) Artifact-based : Sytem archeology, Feedback analysis, Reuse of requirements --> find dissatisfier, satisfier을 찾을 수 있음

 

* System archeology : legacy, competitor 등의 존재하는 시스템으로부터 추출됨. 시간이 매우 오래걸리지만 상세한 요구사항과 제약사항을 찾을 수 있음. 

 

* Feedback analysis : user와 customer로부터 받은 피드백을 모아서 existing system이나 prototype에 적용. Data 양이 많아서 시간이 오래 소요되긴 함. But 이를 통해 인식하지 못했던 dissatisfier를 찾을 수 있다는 장점도 있음.

 

* Requse of Requirements : 이미 갖고 있는 요구사항을 재사용. 

 

 

 

✅ 4.2.3 Design and Idea-Generating Techniques

 

Design and Idea-Generating Tech의  두 가지 종류

 

 

1) Creativity Tech : chacne for an idea, knowledge of the subject matter, Motivation, safety and security가 가장 중요한 요인들

 

* Brainstorming : question or problem을 통해 아이디어를 찾아내고 분석하는 과정.  

브레인 스토밍의 가이드라인

 

* Analogy(비유) tech : 중요하고 복잡한 주제의 아이디어를 발전시키는데 좋은 방법.

유사한 내용을 자세히 묘사 -> 이를 다시 원래꺼로 전송 -> 결과적으로 나온 아이디어와 컨셉을 starting point로 사용

 

 

2) Design Tech : explore and elaborate ideas

 

* Prototyping : 미리 정의된 요구사항이 제대로 맞게 시행되는지 체크하기 위해서 쓰임. 비기능적 요구사항과 dissatisfier, constraints등을 감지하기에 매우 유용함. 

 

* Scenarios and storyboards : 시나리오는 system 동작의 흐름을 묘사하는 것. 이 시나리오가 visual form으로 작성될 수 있는데 이를 storyboard라고 함. 스토리보드는 만화 같이 그려지는 걸 말함.

아래 예시 참조.

 

 

 

3) Design thinking : Empathy, Creativity

 

* Empathy : try to understand what stakeholders really think, feel, and do when they interact with a system

 

* Creativity

 

 

 

 

 

 

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