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

Requirement Engineering

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

one2ye 2023. 3. 1. 10:16

728x90

🟡 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

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

* stakeholder

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

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

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

🔆 4.1.1.1 A Special Stakeholder : The 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

🟡 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

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