IREB CPRE Glossary 용어집

인수(Acceptance)	시스템이모든요구사항을만족하는지평가하는프로세스
인수테스트(Acceptance Test)	시스템이모든요구사항을만족하는평가하는테스트
활동다이어그램(Activity diagram)	UML에서사용하는다이어그램의한종류로시스템혹은컴포넌트에서의활동(action)의흐름을모델화한것으로필요한책임요소와관련된데이터흐름과영역을포함한다.
정확성(Adequacyof requirement)	하나의요구사항이이해관계자의실제의지와필요(stakeholder's true desires and needs)를얼마나정확히나타내는가를의미함(즉, 요구사항을언급할때실제이해관계자들이생각하는바를의미함)
어플리케이션도메인(Application Domain)	시스템컨텐츠를결정하는데영향을주는실제세계의부분(parts of the realworld)
인공물(Artifact)	시스템개발의중간혹은최종단계산출물: 예를들면요구사항명세
속성(Attribute)	하나의개체(entity)가가지는특성인자(characteristic property
베이스라인(Baseline)	안정되고, 변화통제가가능한인공물설정환경 베이스라인은릴리스계획, 릴리스정의, 프로젝트관리목적등의기반으로사용된다
행동모델(Behavior model)	시스템혹은컴포넌트의행동을표시하는모델. 예) state machine
버그(Bug)	=오류(defect)
카디날리티(Cardinality)	1. 모델링에서: 하나의관계(relationship)에포함되는최소, 최대객체수(number of objects). UML에서는multiplicity 라는단어를동일한의미로사용한다 2. 수학에서: 하나의집합에포함된원소수
변경통제위원회(Change control board)	클라이언트, 공급자대표위원회로변경요청(change request)을결정한다. 약어CCB
변경요청(Change request)	요구공학에서: 하나혹은그이상의베이스라인요구사항을변경하기위해잘논의된요청사항(a well-argued request)
변경가능성(Changeabilityof an artifact)	인공물이요청된변경을수용할수있는정도를나타내는지표
확인(Checkingrequirements)	(요구사항의) 확인
클래스(Class)	동일한종류의객체집합으로객체의구조, 객체를조작하는방법, 객체의행동을묘사한것
클래스다이어그램(Class Diagram)	클래스모델(class model)을diagram 표현방식으로나타낸것
클래스모델(Class Model)	일련의클래스와클래스사이의관계로구성된모델
완결성(Completeness(of requirements)	1. 하나의요구사항에대해서: 하나의요구사항이필요한모든정보를포함하고있는가 2. 요구사항명세에대해서: 요구사항명세가이해관계자의요구와필요를만족시킬만한시스템을개발하는데필요한모든정보를포함하고있는가
준수성(Compliance)	인공물이표준(standards), 규약(regulations), 법규(laws) 및다른관련문서들을만족시키고있는지를의미함. 시스템들은해당시스템이배포될도메인에적용되는표준, 규약, 법규항목을준수해야한다. 요구사항단계에서부터법규준수관련내용이체계적으로검토되지않으면본항목의달성은불가능하다.
컴포넌트(Component)	1. 일반적으로: 시스템의일부분 2. 소프트웨어아키텍처에서: 관련있는객체혹은클래스들의집합(encapsulated set)으로여러컴포넌트가모여서비스를제공함 Note: 컴포넌트를단독으로놓고보면그하나로하나의시스템임
형상(Configuration)	논리적으로연결된유닛(unit)의집합. 유닛들은개별적으로식별가능한인공물혹은인공물의부분(예, 요구사항)으로하나의unit은하나의version을가진다
적합성(Conformityof requirements)	요구사항이특정표준의규약에대한만족정도
일관성(Consistencyof requirements)	요구사항이자체의모순된내용을담고있지않은정도
제약사항(Constraint)	기능/ 품질요구사항을만족시키지못하게하는제한요구사항
컨텍스트(Context)	1. 일반적으로: 어떠한현상혹은현상의발생을이해하는필요한사고(thought) 혹은의미의집합 2. 요구공학에서: 시스템의주변환경으로시스템과요구사항을이해하는데관련이있음 컨텍스트는시스템컨텍스트라고불림
컨텍스트경계(Context Boundary)	시스템컨텍스트와어플리케이션도메인(해당시스템및요구사항과관계가없는) 사이의경계. 컨텍스트시스템개발과관련이있는부분을그렇지않은부분으로부터분리한다. 즉개발되어야하는시스템에영향을미치지않는부분은요구사항엔지니어링을진행하는데고려하지않아도된다.
컨텍스트다이어그램(Context Diagram)	1. 컨텍스트모델(Context model)를다이어그램으로표현한것 2. 구조적분석(Structured analysis)에서, 컨텍스트다이어그램은데이터플로우다이어그램계층구조의근간이됨
컨텍스트모델(Context model)	컨텍스트상에서시스템을묘사한모델
정확성(Correctness)	인공물에담겨진정보가어느정도정확한지를나타내는지표. 요구공학에서, adequacy와동일한의미로사용함
고객(Customer)	제품이나서비스를최종적으로수령하게되는개인혹은단체. 이해관계자(stakeholder) 참조
고객요구사항명세(Customer requirements specification)	고객관점에서요구한시스템의기능(capability)을기술한것. 일반적으로고객이제공함
데이터흐름다이어그램(Dataflow diagram)	시스템의기능혹은컴포넌트를모델링한다이어그램으로, 프로세스(processes, activity라고도불림), 데이터저장공간(data stores), 데이터흐름(data flows)을사용하여표현한다. 입력되는데이터는프로세스를활성화(trigger)하고, 입력된데이터를소비(consume)하고가공(transform)한다. 또한데이터저장소에보관된영구데이터를읽어나쓰고새로운데이터를생성한다. 새로운데이터는다른프로세스를활성화하거나시스템에서얻어지는최종결과물이된다.
결정테이블(Decision table)	테이블기반의체계적표현방법으로복합적인기준(multiple criteria)에따른결정관계를표시한다
결점(Defect)	부적절하게기술(incorrectly described)/ 혹은구현된(crafted) 인공물의한부분. 동의어: fault, bug
도메인(Domain)	관련된사물들의범위; 예) 어플리케이션도메인(application domain)
유효성(Effectiveness)	어떤상황(혹은사건)이일어나길원하는방향으로실제로발생하는정도를나타내는지표
효율성(Efficiency)	자원의사용을최소화하면서원하는결과를산출할수있는정도를나타내는지표.
(요구사항의) 추출(Elicitation(of requirements))	요구사항추출
최종사용자(End user)	사용자
개체(Entity)	1. 일반적인의미: 하나의요소, 혹은그요소들의집합으로상상할수있는(conceivable) 어떠한아이템을의미하는데, 예를들면시스템, 실제상황의한부분, 하나의사물, 하나의조직, 하나의프로세스등으로설명할수있다. 2. 개체-관계-모델링(entity-relationship-modeling)에서의의미: 개별적인객체로자체의고유성을가지고있으며, 다른객체에의존하지않음
개체-관계다이어그램(Entity-relationship diagram)	개체-관계모델을그래픽적인요소로표현한것 약어: ERD
개체-관계모델(Entity-relationship model)	시스템과관련있는데이터, 혹은하나의어플리케이션도메인데이터의모델. ERM은속성(attributes)에의해특성지어지고계성(relationship)에의해연결된일련의개재종류의집합이다. 약어: ERM, ER Model
에러(Error)	관찰된행동혹은결과와예상된행동혹은결과사이의불일치(discrepancy). 에러는특정인공물에존재하는실패(fault) 혹은결점(defect)으로인해발생한다. 종종영어적인표현에서에러(error)와실패(fault)는동일한의미로사용되기도한다.
실패(Fault)	=결점(Defect)
실패내구성(Fault Tolerance)	시스템이(하드웨어혹은소프트웨어) 시스템의실패상황임에도불구하고정상적인동작을할수이는능력의정도
기능특성(Feature)	시스템이이해관계자에게어떠한가치를제공하는범위를정하는특성. 일반적으로여러가지요구사항으로구성되는데, 상위추상화단계에서이해관계자들과커뮤니케이션을하기위해, 변수를표현하거나선택적인특성들을논의하기위해사용한다
기능적요구사항 (Functional requirements)	시스템(혹은컴포넌트, 서비스)의기능(function)를통해제공되어야 하는 행동의결과와관련한요구사항
기능성(Functionality)	기능적요구사항에의해정의된시스템의능력(성능)
용어집(Glossary)	특정도메인에관련된용어의정의를모아놓은것. 이반적으로용어집은상호참조(cross-reference), 동의어(synonyms), 동음이의어(homonyms), 두문자어(acronyms), 약어(abbreviations)을포함한다.
골(Goal)	사건(affairs)—이해관계자가달성하기원하는—의바람직한상태. 골은이해관계자의의도를반영한다. 때문에다른골들끼리는서로충돌할가능성이있다.
골모델(Goal model)	무언가의골을표현한모델로, 골은일련의하위골들의순차적인구조로나타난다.
동음이의어(Homonyms)	다른용어와형태상으로동일하지만, 실제로다른의미를가지고있는용어. 예를들면bill은지폐라는의미와함께(원소의) 리스트라는의미로도사용된다.
검열(인스펙션, Inspection)	리뷰의한종류로리뷰의대상인인공물(artifact)은전문가그룹이주어진기준에따라검토한다.
요구사항의종류(Kind of requirement)	요구사항에는여러가지가있다. 요구공학엔지니어링은주로시스템요구사항에집중한다. 이외에도프로젝트요구사항(project requirements)와프로세스요구사항(process requirements)가있다. 요구사항은일반적으로기능적요구사항(functional requirements), 품질요구사항(quality requirements) 그리고제약사항(constraints)으로구분된다. 품질요구사항과제약사항을합쳐서비-기능적요구사항(non-functional requirements)라부른다.
언어(Language)	정보를표현하고커뮤니케이션을하기위한표식(sign)의구조적인집합. 표식이란의사소통을하기위해사용되는요소로, 언어에서의표현, 심벌, 제스처등이있다.

page 16 / 38

유지보수성(Maintainability)	특정소프트웨어시스템이오류를수정하거나, 변경요구사항을반영하기위해변경되어야할경우변경의정도가용이한지나타내는척도. 유지보수성은품질요구사항(quality requirements)의하나로언급되기도한다.
모델(Model)	이미실재하거나구현되어야할실재를추상적으로표시한것. 위의정의는요구공학에서다루는대부분의케이스에적용되나, 어떤의미에서는좁은의미의정의이다. 좀더일반적으로, 모델이란존재하는개체혹은구현되어야할개체를추상적으로표시한것으로, 여기서개체란현실의특정부분혹은상상가능한요소혹은상황들—또다른모델들을포함하는—의집합을의미한다. 모델과비교해서, 개체는원본(original)이라고부른다. 요구공학에서요구사항은모델에의해명세화된다. 위의일반적인정의에서사용된개체의의미는개체-관계모델에서사용된개체의의미와다른점에주의한다.
모델언어(Model Language)	특정한종류의모델을표현하는언어. 해당모델언어는문자, 그림, 기호혹은이들의조합으로표현될수있다.
다중도(Multiplicity)	=원소수(cardinality)
비-기능적요구사항(Non-functional requirement)	품질요구사항(quality requirement) 혹은제약사항(constraint). 성능요구사항(performance requirements)는비-기능적요구사항의또다른범주로취급되기도한다. 본용어집에서성능요구사항은, 품질요구사항의하위범주로간주한다. 동의어: 기능외요구사항(Extra-functional requirements)
성능요구사항(Performance requirement)	성능특성(타이밍, 속도, 크기, 용량, 스루풋(throughput) 등)을기술하는요구사항. 성능요구사항은본용어집에서품질요구사항의하위범주로간주하나, 그자체로비-기능적요구사항범주로간주되기도한다.
구문템플릿(Phrase template)	하나의단락으로구성된구문적인구조(syntactic structure)로개별적인요구사항을자연어(natural language)의형태로표현한템플릿.
이식성(Portability)	특정시스템이다른플랫폼(기능성을그대로유지한상태로)으로이전되는경우의용이함정도를나타내는척도. 이식성은품질요구사항의하나로언급되기도한다.
요구사항우선순위(Priority of a requirement)C	주어진기준에따라특정한요구사항이다른요구사항과비교해어느정도중요한지를표시하는지표
프로세스동사(Process verb)	자연어로기술된요구사항에서요청된행동(required action)을특성짓는동사
프로토타입(Prototype)	1. 제조분야에서: 대량생산에앞서제작된시제품 2. 소프트웨어공학에서: 시스템의핵심적인부분을구현하기전에미리구현한실행가능한소프트웨어의부분 요구공학에서프로토타입은요구사항추출과요구사항검증의수단으로사용한다.
품질(Quality)	개체고유특성이요구사항을얼마나만족시키는지나타내는척도. 개체는시스템, 서비스, 제품, 인공물(artifact), 프로세스, 사람, 조직등으로다양할수있다. 개체고유특성(inherent characteristic)이란구분되는기능특성혹은개체의속성으로개체가스스로가지고있는특성을의미하는것으로, 외부에서명시적으로(explicitly) 할당되지않은특성이다. 이것이일반적으로산업군에서의미하는품질의정의이다. 이러한정의에서의품질은의도된사용—요구사항에명시된—환경상에서의적합성만을의미한다는점을알아둔다. 이는좋음(goodness) 혹은뛰어남(excellence) 등과같이표현되는일반적인품질의의미와는대조된다.
품질요구사항(Quality requirement)	기능적요구사항에의해다루어지지못하는품질고려사항과관련된요구사항.
중복(Redundancy)	동일한정보나리소스가반복되어나타나는것.
릴리스(Release)	설치혹은고객사용을위해출하된형상(configuration)
신뢰성(Reliability)	시스템이정해진조건에서사용되는경우, 정해진레벨의기능과성능을유지하는정도를나타내는지표. 신뢰성은품질요구사항의하나로언급되기도함.
요구사항(Requirement)	1. 사용자가문제를해결하거나목적을달성하기위해필요한조건혹은능력(condition or capability) 2. 계약, 표준, 명세혹은다른공식적으로적용된문서들을만족시키기위해시스템혹은시스템컴포넌트가만족시키거나가지고있어야하는조건혹은능력 3. 상기1, 2 항에서언급된내용에대한문서상표현(documented representation) Note: 위의내용은IEEE 표준610.12(1990년)에정의된전통적인요구사항의정이임. 이를대신해, 좀더최신화된정의는아래와같다: 1. 이해관계자가인식한필요 2. 시스템이반드시가지고있어야하는능력혹은속성 3. 상기1, 2항에대한문서적표현
요구사항분석(Requirements analysis)	1. 추출된요구사항을이해하고문서화하기위한분석 2. 동의어: 요구공학
요구사항베이스라인(Requirements baseline)	요구사항집합을위한기준
요구사항발견(Requirements discovery)	=요구사항추출(Requirements elicitation)
요구사항문서(Requirements document)	요구사항명세(requirements specification)을구성하는문서. 요구사항명세와동일한의미로자주사용된다.
요구사항추출(Requirements elicitation)	가능한요구사항소스로부터요구사항을발견하고, 찾고, 통합하는프로세스. 요구사항의재구성혹은신규생성과정이포함되기도한다. 동의어: 요구사항발견(Requirements discovery)
요구공학엔지니어(Requirements engineer)	요구사항을추출하고, 문서화하고, 검증하고, 관리하는엔지니어로이해관계자들과협업을진행한다.
요구공학(Requirements Engineering)	요구사항명세와관리를체계적이고원칙적으로접근하는방법론으로다음과같은골을달성하는것이목표이다: (1) 관련된요구사항파악, 해당요구사항에대한이해관계자들사이의협의달성, 주어진표준에따른요구사항및협의결과의문서화, 산출물들의체계적인관리 (2) 이해관계자의요구와필요를이해하고문서화 (3) 요구사항의명세및관리를통해이해관계자의요구와필요를만족시키지못하는시스템을전달가능성을최소화 약어: RE Note: 상기언급된세가지골은RE의중요한측면을다루는데, (1)프로세스집중(process-orientation), (2) 이해관계자집중(stakeholder focus), 그리고(3) 리스크및가치고려의중요성(importanceof risk and value consideration)을의미한다.
요구사항관리(Requirements management)	존재는요구사항및요구사항과관련된인공물을관리하는프로세스. 요구사항의저장, 변경, 추적(traceability)를포함한다.
요구사항모델(Requirements model)	요구사항의명세를목적으로만들어진모델
요구사항소스(Requirements sources)	요구사항의근원이되는소스. 이해관계자, 문서, 기존시스템그리고관찰등이전통적인요구사항의소스이다.
요구사항명세(Requirements specification)	시스템혹은컴포넌트에대한요구사항의집합을체계적으로표현한것. 어떤상황에서는고객요구사항명세(일반적으로고객에의해작성됨, customer requirements specification)와시스템요구사항명세(system requirements specification) 혹은소프트웨어요구사항명세(공급자에의해작성, software requirements specification)를구분하기도한다. 요구사항명세는요구사항을명세화하는활동자체를의미하기도한다.
요구사항템플릿(Requirements template)	개별적인요구사항의구문적인구조를위한템플릿. 구문템플릿(phrase template)은자연어로기록된요구사항을위한특별한요구사항템플릿의하나이다.
리뷰(Review)	전문가그룹으로구성되어인공물을검토하기위해정형적으로구성된조직. 검토대상은내용, 적합성모두를대상으로수행될수있다.
리스크(Risk)	시스템개발혹은운영노력의성공을위협하는이벤트. 리스크는일반적으로발생가능성과잠재적인위험도로평가된다.
안전(Safety)	사람, 소유물및환경에피해를초래하지않으면서시스템을받아들일수있을만큼의레벨을달성하는능력. 안전은품질요구사항, 혹은기능적요구사항의하나로써언급되기도한다.
시나리오(Scenario)	1. 바람직한(혹은원하지않는) 결과를도출하는이벤트의잠재적인순서를묘사한것 2. 순서흐름으로나타낸파트너—특히, 시스템과외부행위자—들사이의상호작용. 구체적인순서흐름(concrete sequence, instance scenario), 혹은잠재적인순서흐름(potential sequence, use case)으로표현될수있음. 3. UML에서: 유스케이스(use case)의실행흐름
스코프(scope of a system)	시스템을구현할때사물들을설계하는범위
보안성(Security)	시스템이(a)소유하고있는데이터와자원들을인가되지않은사용/ 접근으로부터보호하고(b)인가된사용자들에게서비스가중단되지않도록보장하는능력
내연(Semantics)	언어에서표식(sign) 하나혹은표식의집합이가지는의미
반-정형적(Semi-formal)	일정정도이상정형성을가지고있으나, 완벽하게정형적이지는안은상태. 어떠한인공물이반-정형적이라불리는경우는해당인공물이정형적인요소들을포함하고있으나전체적으로정형성을띠지않는경우를의미한다. 일반적인반-정형적인공물은외연(syntax) 자체의정형성은가지고있으나내연(semantics)은부분적으로정의된다.
순서다이어그램(Sequence diagram)	UML에서사용하는다이어그램타입의하나로선택된객체집합혹은행위자들간에일어나는상호작용을발생순서대로모델링한다이어그램이다.
소프트웨어요구사항명세(Software requirements specification)	소프트웨어시스템에적용되는요구사항명세. 약어: SRS
요구사항소스(Sourceof a requirement)	=요구사항소스(Requirements source)
명세(Specification)	주어진기준을만족시키는개체(시스템, 장비등)의특성을체계적으로표현한것. 명세는요구된속성(요구사항명세)이거나구현된속성(기술제품명세)일수있다.
명세언어(Specification language)	명세사항을표현하기위해만든인공적이언어
이해관계자(Stakeholder)	시스템요구사항에직/간접적인영향을미치는개인혹은조직. 간접적인영향에는해당개인혹은조직이시스템에의해받은영향과같은환경도포함된다.
표준(Standard)	특정대상을인지사고, 생산하고, 실행하는단일한형태의규약
상태머신(State machine)	시스템혹은컴포넌트의행동을유한한상태의집합(finite set of states)와상태의변화(state transitions)으로표현한모델링기법. 상태변화는이벤트(event)에의해발생되고, 차례로다른행동이나이벤트를초래할수있다. 관련용어: 단일상태만을가지는상태머신을유한상태오토마톤(finite state automaton)이라부른다. 상하위개념(hierarchically) 혹은직교개념(orthogonally)의상태를가지고있는상태머신은상태차트(statecharts)라고부른다
상태변화다이어그램, 상태천이다이어그램(State-transition diagram)	상태머신을다이어그램으로표현한것
상태차트(statechart)	상하위개념(hierarchically) 혹은직교개념(orthogonally)의상태를가지고있는상태머신
조정위원회(Steering committee)	프로젝트를관장하는위원회
구조화된분석(Structured Analysis)	상하위개념의데이터흐름다이어그램에기반하여시스템의기능을기술하는접근법. 데이터흐름과지속되는데이터(persistent data)는데이터사진(data dictionary)에정의된다. 컨텍스트다이어그램은(context diagram) 입력되는데이터흐름의소스, 출력되는데이트흐름의목적지를모델링한다.
공급자(Supplier)	제품혹은서비스를고객에게공급하는개인혹은조직
동의어(Synonym)	동일한의미를가지는다른용어
외연(Syntax)	언어에서구조화된표식을구성하는규칙
시스템(System)	1. 일반적으로: 순서를정하고구조화하는원칙 2. 정보학에서: 일관적이고, 범위를정할수있는컴포넌트의집합으로통제된행위(coordinated action)를통해서비스를제공함 요구공학에서는소프트웨어컴포넌트, 기술요소(컴퓨팅하드웨어, 장비, 센서등), 조직요소(개인, 직위, 비즈니스프로세스등)을구성하는시스템에대한요구사항의명세를다룸. Note: 하나의시스템은다른시스템을구성할수있으며, 하나의시스템을구성하는컴포넌트나서비스역시또다른시스템으로간주할수있다.
시스템경계(System boundary)	시스템과해당시스템을둘러싼컨텍스트와의경계. 시스템경계는구현되어야하는시스템을해당시스템의환경으로부터분리한다; 즉, 시스템경계는개발프로세스에의해수정되거나대체되어야하는실제의일정부분을변경되거나수정되지않아야하는나머지실제의환경과분리한다.
시스템컨텍스트(System context)	시스템을둘러싸고있는환경의일부로구현되어야하는시스템과관련된요구사항의정의및이해와밀접한관계가있다.
시스템요구사항(System requirement)	하나의시스템혹은컴포넌트와관련된요구사항
시스템요구사항명세(Systems requirements specification)	시스템과관련된요구사항명세. 요구사항명세(Requirements specification)과동일한의미로사용된다.
도구(Tool in software engineering)	시스템개발, 운영및유지보수를용이하게하는(소프트웨어) 시스템. 요구공학에서, 도구는요구사항관리, 모델링, 문서화및검증을지원한다.
추적성(Traceability of requirements)	추적성이란요구사항에서시작해(1) 해당요구사항의근본(origins)을거슬러탐색하고, (2) 해당요구사항과관련된구현내용을설계와코드에서탐색하고, (3) 해당요구사항자체가의존하고있는요구사항으로연결지어진정도를나타내는척도이다. 요구사항과해당요구사항의근본으로거슬러탐색하는것을전-요구사항명세추적성(Pre-RS traceability)라고한다. 이와바대로요구사항을해다요구사항의구현내용과연결하는것을후-요구사항명세추적성(Post-RS traceability)라고한다. RS는요구사항명세(Requirements specification)을의미한다. 때때로, 요구사항에대한이유로연결되는추적성도그자체로추적성범주에포함되기도한다.
UML	통합된모델링언어(Unified Modeling Language)의약어로, 문제나해결책을모델링하는언어의표준이다.
분명함, 모호하지않음(Unambiguity)	요구사항이사람들마다다른방식으로이해하는일이발생하지않도록명확하게표현된정도를나타내는척도
사용성(Usability)	사용자가시스템을이해하고, 학습하고, 사용하며선호하는정도를나타내는척도. 사용성(혹은사용성의일부)은품질요구사항의하나로언급되기도함.
유스케이스(Use case)	행위자와시스템사이에서수행되었을경우, 부가가치를제공할수있는가능한상호작용을묘사한것. 유스케이스는사용자(혹은다른외부행위자)의관점에서시스템을명세화한다: 모든유즈케이스는해당유즈케이스에개입되어있는행위자에게시스템이제공해야만하는기능들을명세회한다.
유스케이스다이어그램(Use case diagram)	UML에서제공하는다이어그램의한가지로, 행위자와시스템의유즈케이스를모델링한것이다. 행위자와유즈케이스사이의경계는시스템경계를구성한다.
사용자(User)	시스템이제공하는기능을사용하는사람. 최종사용자(end user)라고불리기도한다.
검증(Validation of requirements)	문서로기록된요구사항이이해관계자의필요와일치하는지확인하는프로세스. Note: 특정한소스들은분명함(unambiguity), 총체적(comprehensively) 관같은품질요구사항에대한확인작업을포함시켜넒은의미의요구사항검증을정의하기도하며, 이러한경우검증(validation)은확인(checking)과동일한의미로사용된다.
검증가능성(Verifiability of requirements)	구현된시스템에서요구사항의달성도를평가할수있는정도를나타내는지표. 예를들면, 인수테스트케이스나, 측정지표의설정혹은검열절차정의등이있다.
버전(Version of an entity)	하나의개체가여러가지형태—시간순서에따라나타나며, 시간적으로나중에나타나는개체가이전에있던개체를수정한결과로생성되는경우—로나타나는경우, 형태가다른각개체를버전(version)이라고칭한다.
뷰(View)	인공물의한부분으로, 현재관심이되는부분만을포함하고있다. 뷰는해당인공물의몇몇부분의추상화된개념혹은부분의조합일수있다.
뷰포인트, 시각(Viewporint)	시스템요구사항과관련된특정관점. 일반적인관점이란이해관계자혹은이해관계자집단이가지고있는관점을의미한다(예를들면, 최종사용자관점혹은운영자관점등). 그러나, 보안과관련된뷰포인트(security viewpoint)와같이관심주제에따른뷰포인트도존재한다.
워크스루(Walkthrough)	리뷰의한가지종류로, 인공물의저자가전문가그룹과함께해당인공물에대한체계적인리뷰를진행하다., 전문가가발견한사항들은이후수집및통합된다.

약어리스트(List of Abbreviations)

CCBChange Control Board/ 변경통제위원회

CPRECertified Professional for Requirements Engineering/ 요구공학인증전문가

EREntity-Relationship/ 개체-관계

ERDEntity-Relationship Diagram/ 개체-관계다이어그램

ERMEntity-Relationship Model/ 개체-관계모델

IREBInternational Requirements Engineering Board/ 국제요구공학위원회

RERequirement Engineering/ 요구공학

SRSSoftware Requirements Specification/ 소프트웨어요구사항명세

UMLUnified Modeling Language/ 통합된모델링언어

인수(Acceptance)	인수(Acceptance)
인수테스트(Acceptance Test)	인수테스트(Acceptance Test)
활동다이어그램(Activity diagram)	활동다이어그램(Activity diagram)
정확성(Adequacyof requirement)	정확성(Adequacyof requirement)
어플리케이션도메인(Application Domain)	어플리케이션도메인(Application Domain)
인공물(Artifact)	인공물(Artifact)
속성(Attribute)	속성(Attribute)
베이스라인(Baseline)	베이스라인(Baseline)
행동모델(Behavior model)	행동모델(Behavior model)
버그(Bug)	버그(Bug)
카디날리티(Cardinality)	카디날리티(Cardinality)
변경통제위원회(Change control board)	변경통제위원회(Change control board)
변경요청(Change request)	변경요청(Change request)
변경가능성(Changeabilityof an artifact)	변경가능성(Changeabilityof an artifact)
확인(Checkingrequirements)	확인(Checkingrequirements)
클래스(Class)	클래스(Class)
클래스다이어그램(Class Diagram)	클래스다이어그램(Class Diagram)
클래스모델(Class Model)	클래스모델(Class Model)

 

완결성(Completeness(of requirements)	완결성(Completeness(of requirements)
준수성(Compliance)	준수성(Compliance)
컴포넌트(Component)	컴포넌트(Component)
형상(Configuration)	형상(Configuration)
적합성(Conformityof requirements)	적합성(Conformityof requirements)
일관성(Consistencyof requirements)	일관성(Consistencyof requirements)
제약사항(Constraint)	제약사항(Constraint)
컨텍스트(Context)	컨텍스트(Context)
컨텍스트경계(Context Boundary)	컨텍스트경계(Context Boundary)
컨텍스트다이어그램(Context Diagram)	컨텍스트다이어그램(Context Diagram)
컨텍스트모델(Context model)	컨텍스트모델(Context model)
정확성(Correctness)	정확성(Correctness)
고객(Customer)	고객(Customer)
고객요구사항명세(Customer requirements specification)	고객요구사항명세(Customer requirements specification)
데이터흐름다이어그램(Dataflow diagram)	데이터흐름다이어그램(Dataflow diagram)
결정테이블(Decision table)	결정테이블(Decision table)
결점(Defect)	결점(Defect)
도메인(Domain)	도메인(Domain)
유효성(Effectiveness)	유효성(Effectiveness)
효율성(Efficiency)	효율성(Efficiency)
(요구사항의) 추출(Elicitation(of requirements))	(요구사항의) 추출(Elicitation(of requirements))
최종사용자(End user)	최종사용자(End user)
개체(Entity)	개체(Entity)
개체-관계다이어그램(Entity-relationship diagram)	개체-관계다이어그램(Entity-relationship diagram)
개체-관계모델(Entity-relationship model)	개체-관계모델(Entity-relationship model)
에러(Error)	에러(Error)
실패(Fault)	실패(Fault)
실패내구성(Fault Tolerance)	실패내구성(Fault Tolerance)
기능특성(Feature)	기능특성(Feature)
기능적요구사항(Functional requirements)	기능적요구사항(Functional requirements)
기능성(Functionality)	기능성(Functionality)
용어집(Glossary)	용어집(Glossary)
골(Goal)	골(Goal)
골모델(Goal model)	골모델(Goal model)
동음이의어(Homonyms)	동음이의어(Homonyms)
검열(인스펙션, Inspection)	검열(인스펙션, Inspection)
요구사항의종류(Kind of requirement)	요구사항의종류(Kind of requirement)
언어(Language)	언어(Language)
유지보수성(Maintainability)	유지보수성(Maintainability)
모델(Model)	모델(Model)
모델언어(Model Language)	모델언어(Model Language)
다중도(Multiplicity)	다중도(Multiplicity)
비-기능적요구사항(Non-functional requirement)	비-기능적요구사항(Non-functional requirement)
성능요구사항(Performance requirement)	성능요구사항(Performance requirement)
구문템플릿(Phrase template)	구문템플릿(Phrase template)
이식성(Portability)	이식성(Portability)
요구사항우선순위(Priority of a requirement)C	요구사항우선순위(Priority of a requirement)C
프로세스동사(Process verb)	프로세스동사(Process verb)
프로토타입(Prototype)	프로토타입(Prototype)
품질(Quality)	품질(Quality)
품질요구사항(Quality requirement)	품질요구사항(Quality requirement)
중복(Redundancy)	중복(Redundancy)
릴리스(Release)	릴리스(Release)
신뢰성(Reliability)	신뢰성(Reliability)
요구사항(Requirement)	요구사항(Requirement)
요구사항분석(Requirements analysis)	요구사항분석(Requirements analysis)
요구사항베이스라인(Requirements baseline)	요구사항베이스라인(Requirements baseline)
요구사항발견(Requirements discovery)	요구사항발견(Requirements discovery)
요구사항문서(Requirements document)	요구사항문서(Requirements document)
요구사항추출(Requirements elicitation)	요구사항추출(Requirements elicitation)
요구공학엔지니어(Requirements engineer)	요구공학엔지니어(Requirements engineer)
요구공학(Requirements Engineering)	요구공학(Requirements Engineering)
요구사항관리(Requirements management)	요구사항관리(Requirements management)
요구사항모델(Requirements model)	요구사항모델(Requirements model)
요구사항소스(Requirements sources)	요구사항소스(Requirements sources)
요구사항명세(Requirements specification)	요구사항명세(Requirements specification)
요구사항템플릿(Requirements template)	요구사항템플릿(Requirements template)
리뷰(Review)	리뷰(Review)
리스크(Risk)	리스크(Risk)
안전(Safety)	안전(Safety)
시나리오(Scenario)	시나리오(Scenario)
스코프(scope of a system)	스코프(scope of a system)
보안성(Security)	보안성(Security)
내연(Semantics)	내연(Semantics)
반-정형적(Semi-formal)	반-정형적(Semi-formal)
순서다이어그램(Sequence diagram)	순서다이어그램(Sequence diagram)
소프트웨어요구사항명세(Software requirements specification)	소프트웨어요구사항명세(Software requirements specification)
요구사항소스(Source of a requirement)	요구사항소스(Source of a requirement)
명세(Specification)	명세(Specification)
명세언어(Specification language)	명세언어(Specificationlanguage)
이해관계자(Stakeholder)	이해관계자(Stakeholder)
표준(Standard)	표준(Standard)
상태머신(State machine)	상태머신(State machine)
상태변화다이어그램, 상태천이다이어그램(State-transition diagram)	상태변화다이어그램, 상태천이다이어그램(State-transition diagram)
상태차트(statechart)	상태차트(statechart)
조정위원회(Steering committee)	조정위원회(Steering committee)
구조화된분석(Structured Analysis)	구조화된분석(Structured Analysis)
공급자(Supplier)	공급자(Supplier)
동의어(Synonym)	동의어(Synonym)
외연(Syntax)	외연(Syntax)
시스템(System)	시스템(System)
시스템경계(System boundary)	시스템경계(System boundary)
시스템컨텍스트(System context)	시스템컨텍스트(System context)
시스템요구사항(System requirement)	시스템요구사항(System requirement)
시스템요구사항명세(Systems requirements specification)	시스템요구사항명세(Systems requirements specification)
도구(Tool in software engineering)	도구(Tool in software engineering)
추적성(Traceability of requirements)	추적성(Traceability of requirements)
UML	UML
분명함, 모호하지않음(Unambiguity)	분명함, 모호하지않음(Unambiguity)
사용성(Usability)	사용성(Usability)
유스케이스(Use case)	유스케이스(Use case)
유스케이스다이어그램(Use case diagram)	유스케이스다이어그램(Use case diagram)
사용자(User)	사용자(User)
검증(Validation of requirements)	검증(Validation of requirements)
검증가능성(Verifiability of requirements)	검증가능성(Verifiability of requirements)
버전(Version of an entity)	버전(Version of an entity)
뷰(View)	뷰(View)
뷰포인트, 시각(Viewporint)	뷰포인트, 시각(Viewporint)
워크스루(Walkthrough)	워크스루(Walkthrough)
(Acceptance Test)	인수테스트(Acceptance Test)
활동다이어그램(Activity diagram)	활동다이어그램(Activity diagram)
정확성(Adequacyof requirement)	정확성(Adequacyof requirement)
어플리케이션도메인(Application Domain)	어플리케이션도메인(Application Domain)
인공물(Artifact)	인공물(Artifact)
속성(Attribute)	속성(Attribute)
베이스라인(Baseline)	베이스라인(Baseline)
행동모델(Behavior model)	행동모델(Behavior model)
버그(Bug)	버그(Bug)
카디날리티(Cardinality)	카디날리티(Cardinality)
변경통제위원회(Change control board)	변경통제위원회(Change control board)
변경요청(Change request)	변경요청(Change request)
변경가능성(Changeabilityof an artifact)	변경가능성(Changeabilityofan artifact)
확인(Checkingrequirements)	확인(Checkingrequirements)
클래스(Class)	클래스(Class)
클래스다이어그램(Class Diagram)	클래스다이어그램(Class Diagram)
클래스모델(Class Model)	클래스모델(Class Model)
완결성(Completeness(of requirements)	완결성(Completeness(of requirements)
준수성(Compliance)	준수성(Compliance)
컴포넌트(Component)	컴포넌트(Component)
형상(Configuration)	형상(Configuration)
적합성(Conformityof requirements)	적합성(Conformityof requirements)
일관성(Consistencyof requirements)	일관성(Consistencyof requirements)
제약사항(Constraint)	제약사항(Constraint)
컨텍스트(Context)	컨텍스트(Context)
컨텍스트경계(Context Boundary)	컨텍스트경계(Context Boundary)
컨텍스트다이어그램(Context Diagram)	컨텍스트다이어그램(Context Diagram)
컨텍스트모델(Context model)	컨텍스트모델(Context model)
정확성(Correctness)	정확성(Correctness)
고객(Customer)	고객(Customer)
고객요구사항명세(Customer requirements specification)	고객요구사항명세(Customer requirements specification)
데이터흐름다이어그램(Dataflow diagram)	데이터흐름다이어그램(Dataflow diagram)
결정테이블(Decision table)	결정테이블(Decision table)
결점(Defect)	결점(Defect)
도메인(Domain)	도메인(Domain)
유효성(Effectiveness)	유효성(Effectiveness)
효율성(Efficiency)	효율성(Efficiency)
(요구사항의) 추출(Elicitation(of requirements))	(요구사항의) 추출(Elicitation(of requirements))
최종사용자(End user)	최종사용자(End user)
개체(Entity)	개체(Entity)
개체-관계다이어그램(Entity-relationship diagram)	개체-관계다이어그램(Entity-relationship diagram)
개체-관계모델(Entity-relationship model)	개체-관계모델(Entity-relationship model)
에러(Error)	에러(Error)
실패(Fault)	실패(Fault)
실패내구성(Fault Tolerance)	실패내구성(Fault Tolerance)
기능특성(Feature)	기능특성(Feature)
기능적요구사항(Functional requirements)	기능적요구사항(Functional requirements)
기능성(Functionality)	기능성(Functionality)
용어집(Glossary)	용어집(Glossary)
골(Goal)	골(Goal)
골모델(Goal model)	골모델(Goal model)
동음이의어(Homonyms)	동음이의어(Homonyms)
검열(인스펙션, Inspection)	검열(인스펙션, Inspection)
요구사항의종류(Kind of requirement)	요구사항의종류(Kind of requirement)
언어(Language)	언어(Language)
유지보수성(Maintainability)	유지보수성(Maintainability)
모델(Model)	모델(Model)
모델언어(Model Language)	모델언어(Model Language)
다중도(Multiplicity)	다중도(Multiplicity)
비-기능적요구사항(Non-functional requirement)	비-기능적요구사항(Non-functional requirement)
성능요구사항(Performance requirement)	성능요구사항(Performance requirement)
구문템플릿(Phrase template)	구문템플릿(Phrase template)
이식성(Portability)	이식성(Portability)
요구사항우선순위(Priority of a requirement)C	요구사항우선순위(Priority of a requirement)C
프로세스동사(Process verb)	프로세스동사(Process verb)
프로토타입(Prototype)	프로토타입(Prototype)
품질(Quality)	품질(Quality)
품질요구사항(Quality requirement)	품질요구사항(Quality requirement)
중복(Redundancy)	중복(Redundancy)
릴리스(Release)	릴리스(Release)
신뢰성(Reliability)	신뢰성(Reliability)
요구사항(Requirement)	요구사항(Requirement)
요구사항분석(Requirements analysis)	요구사항분석(Requirements analysis)
요구사항베이스라인(Requirements baseline)	요구사항베이스라인(Requirements baseline)
요구사항발견(Requirements discovery)	요구사항발견(Requirements discovery)
요구사항문서(Requirements document)	요구사항문서(Requirements document)
요구사항추출(Requirements elicitation)	요구사항추출(Requirements elicitation)
요구공학엔지니어(Requirements engineer)	요구공학엔지니어(Requirements engineer)
요구공학(Requirements Engineering)	요구공학(Requirements Engineering)
요구사항관리(Requirements management)	요구사항관리(Requirements management)
요구사항모델(Requirements model)	요구사항모델(Requirements model)
요구사항소스(Requirements sources)	요구사항소스(Requirements sources)
요구사항명세(Requirements specification)	요구사항명세(Requirements specification)
요구사항템플릿(Requirements template)	요구사항템플릿(Requirements template)
리뷰(Review)	리뷰(Review)
리스크(Risk)	리스크(Risk)
안전(Safety)	안전(Safety)
시나리오(Scenario)	시나리오(Scenario)
스코프(scope of a system)	스코프(scope of a system)
보안성(Security)	보안성(Security)
내연(Semantics)	내연(Semantics)
반-정형적(Semi-formal)	반-정형적(Semi-formal)
순서다이어그램(Sequence diagram)	순서다이어그램(Sequence diagram)
소프트웨어요구사항명세(Software requirements specification)	소프트웨어요구사항명세(Software requirements specification)
요구사항소스(Source of a requirement)	요구사항소스(Source of a requirement)
명세(Specification)	명세(Specification)
명세언어(Specification language)	명세언어(Specification language)
이해관계자(Stakeholder)	이해관계자(Stakeholder)
표준(Standard)	표준(Standard)
상태머신(State machine)	상태머신(State machine)
상태변화다이어그램, 상태천이다이어그램(State-transition diagram)	상태변화다이어그램, 상태천이다이어그램(State-transition diagram)
상태차트(statechart)	상태차트(statechart)
조정위원회(Steering committee)	조정위원회(Steering committee)
구조화된분석(Structured Analysis)	구조화된분석(Structured Analysis)
공급자(Supplier)	공급자(Supplier)
동의어(Synonym)	동의어(Synonym)
외연(Syntax)	외연(Syntax)
시스템(System)	시스템(System)
시스템경계(System boundary)	시스템경계(System boundary)
시스템컨텍스트(System context)	시스템컨텍스트(System context)
시스템요구사항(System requirement)	시스템요구사항(System requirement)
시스템요구사항명세(Systems requirements specification)	시스템요구사항명세(Systems requirements specification)
도구(Tool in software engineering)	도구(Tool in software engineering)
추적성(Traceability of requirements)	추적성(Traceability of requirements)
UML	UML
분명함, 모호하지않음(Unambiguity)	분명함, 모호하지않음(Unambiguity)
사용성(Usability)	사용성(Usability)
유스케이스(Use case)	유스케이스(Use case)
유스케이스다이어그램(Use case diagram)	유스케이스다이어그램(Use case diagram)
사용자(User)	사용자(User)
검증(Validation of requirements)	검증(Validation of requirements)
검증가능성(Verifiability of requirements)	검증가능성(Verifiability of requirements)
버전(Version of an entity)	버전(Version of an entity)
뷰(View)	뷰(View)
뷰포인트, 시각(Viewporint)	뷰포인트, 시각(Viewporint)

워크스루(Walkthrough)

워크스루(Walkthrough)