[IREB CPRE] Chapter 3. Work Products and Documentation Practices 2️⃣

🟡 3.4 Model-Based Work Products

자연어로만 요구사항을 표현하기에는 한계가 있음

 

 

 

✅ 3.4.1 The Role of Models in Requirements Engineering

-> visual representation of reality

 

 

🔆 3.4.1.1 Syntax and Semantics

 

 

🔆 3.4.1.2 Properties of a Model

Modeling의 특성

 

-> 정보를 간추려서 표현할 수 있는 두 가지 방법

 

 

 

 

🔆 3.4.1.3 Advantages and Disadvantages of Modeling Requirements

 

* Advantages *

1) Easy to understand and remember

2) Reduced amount of information - focus on a single aspect

3) Restricted syntax - simple, so confusion and omissions is smaller

4) Formal - Higher potentail for automated analysis and processing of requirements

 

* Disadvantages *

1) Not easy to keep model consistent with each other

2) Information from different models needs to be integrated for casual understanding

3) Describing quality requirements and constraints are limited

4) Restricted syntax can't imply every relevant item of information

 

 

 

 

🔆 3.4.1.4 Application of Requirements Models

모델 적용시 이점

 

 

 

🔆 3.4.1.5 Quality Aspects of a Requirements Model

model의 품질을 결정하는 기준

 

문법에 맞게 쓰였는지, 그 의미가 맞게 쓰였는지, 의도에 맞게 잘 사용이 되었는지(실용적인)

 

 

 

🔆 3.4.1.6 Best of Both Worlds

-> textual/graphical form을 둘 다 함께 적절하게 쓰는 것이 젤 좋다!

 

 

 

 

✅ 3.4.2 Modeling System Context

 

data flow diagrams, UML use case diagrams, Tailored box-and-line diagrams

 

 

 

🔆 3.4.2.1 Data Flow Diagram

 

* 네모박스(terminator) -> 동그라미(system) : Source

* 네모박스(terminator <- 동그라미(system) : Sink

 

* DFD 장점 : interface 역할, 시스템으로부터 받는, 제공하는 tangible&intangible object

-> indicates a clear boundary between system and its environment.

-> can help to structure the context to reach shared understanding of the system context and system boundary.

 

 

 

 

🔆 3.4.2.2 UML Use Case Diagram

 

-> 사용자 관점에서 정의된 범위 안에서 다양한 기능을 질서정연하게 묘사하기 쉬운 방법

-> 여기서 association은 direction이나 data flow를 나타내는 것(DFD와의 차이점)이 아니라 actor가 use case로부터 받는 이익만을 설명한 것.

-> UML Use Case Diagram은 system이 environment에 제공하는 functionality를 묘사한 것.

 

 

 

 

✅ 3.4.3 Modeling Structure and Data

 

commom models for depicting structure and data : ERD, UML Class diagrams, SysML Block Definition Diagrams

 

 

🔆 3.4.3.1 UML Class Diagrams

class, attribute, associations, multiplicities, role

 

시간 있으면 p.53 읽어보기

 

instock : class diagram으로 표현되는 데에는 한계가 있음. 이건 시스템에 대한 기능적 요구사항이기 때문.

work product에 대한 문서로 상세히 정리하는 것이 필요함.

 

 

 

 

✅ 3.4.4 Modeling Function and Flow

 

* input/output -> diagram type으로는 한계가 있기 때문에 다른각도에서 바라봐야 함.

 

UML use case diagram, UML activity diagram, Data flow diagram, Domian story models, Business Process Modeling

---> Notation(BPMN) BPMN은 비즈니스 프로세스나 기술적인 프로세스를 묘사할 때 많이 쓰임.

 

 

 

🔆 3.4.4.1 UML Activity Diagram

 

p.56 참고

 

 

 

 

✅ 3.4.5 Modeling State and Behavior

 

Statecharts, UML state diagram

 

 

🔆 3.4.5.1 UML State diagram

 

-> Order cannot be Sent before it is completely picked

-> Sent 다음은 오직 Paid

-> initial state, final state, state, transition

-> class diagram이 표현하지 못한 상태 변화 및 행동에 대한 내용을 묘사할 수 있음.

-> class diagram에서 변수들은 리스트업 되고 설명 되어있었지만 state diagram은 상태 사이의 transition을 시각화할 수 있음. 시퀀스를 더 잘 볼 수 있음.

 

 

 

 

✅ 3.4.5 Supplementary models (시험엔 안나옴)

p.59 참고

 

 

 

 

 

🟡 3.5 Glossaries

Glossary Rules

 

 

 

🟡 3.6 Requirements Documents and Documentation Structures

Reruiements documents 가 자주 사용되는 곳

 

대안으로 자주 사용되는 documentation structures

 

알맞은 documentation form을 고를 때 고려하는 요소들

 

 

 

🟡 3.7 Prototypes in Requirement Engineering

 

* 3가지 주요 목적 *

1) Exploratory prototype : to create shared understanding, clarify requirements, validate requirements

2) Experimental prototype : explore technical design solution concepts

3) Evolutionary prototype : pilot systems that from the core of a system to be developed

-> 요구공학자들은 주로 exploratory prototype을 사용(elicitation and validation)

-> Prototype을 통해 stakeholder가 요구하는 것이 무엇인지 명확히 할 수 있고 요구사항의 전체 틀을 잡을 수 있음.

 

 

* 정확도에 따라 사용될 수 있는 Exploratory Prototype *

1) "Wireframes" : low-fidelity(낮은 정확도) 프로토 타입을 의미. 간단히 종이로 작성되기도 함.

디지털 툴이나 뭐 스케칭 툴? 디지털 툴 사용하면 매우 빠르게 그릴 수 있고 수정을 쉽게 할 수 있음.

 

2) "Mock-ups" : medium-fidelity. 디지털 시스템을 명세화할 때 real screen과 click flows를 사용.(실제 기능 없이)

사용자에게 실제와 유사한 경험을 줌으로써 user interface를 통해 어떻게 시스템 상호작용을 할 수 있는지 감 잡게 도와줌.

 

3) "Native prototype" : high-fidelity. 실제 시스템이 예상한 대로 잘 도착하는지 볼 때 사용하고 시스템의 가장 중요한 부분을 시행할 때 사용.

===> 신뢰도의 정도에 따라서 exploratory prototype들은 돈이 많이 드는 work product가 될 수 있음.

 

 

 

 

🟡 3.8 Quality Criteria for Work Products and Requirements

1. 요구사항은 모든 quality criteria를 반드시 만족할 필요는 없다.

2. 어떤 quality criteria는 다른 것 보다 더 중요할 수 있다. (우선순위가 앞선 기준이 존재할 수 있다는 뜻)

 

* Quality Criteria for single requirements *

1) Adequate : 요구사항은 true를 작성해야 하고 agreed stakeholder needs를 알맞게 작성해야 함.

2) Necessary : system scope이랑 관련된 부분만 잘 기록해야 됨.

3) Unambiguous : 모든사람이 같은 뜻으로 해석할 수 있어야 함.

4) Complete : 이해가 되지 않는 부분이 있어서는 안됨.

5) Understandable : target audience가 이해할 수 있는 요구사항이어야 함.

6) Verifiable : 검증 가능해야 함. Indisputably(명백하게)

-> 볼드체가 특히 중요한 quality criteria임.

 

 

* Quality Criteria for RE work products *

1) Consistent : no 2 requirements contradict each other

2) Non-redundant : documented only once and doesn't overlap

3) Complete : work product contains all relevant requirements

4) Modifiable : can be modified

5) Traceable : can be traced back to their origins

6) Conformance(일치, 부합) : mandatory structure or format을 잘 따라서 써야 함.

 

 

 

 

 

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