SEBok - 시스템 요구사항 (System Requirement) 정리

안녕하세요. 자율주행 안전 전문가를 꿈꾸는 플라잉 준입니다.

 

오늘은 실무에서 시스템 엔지니어링 관련 업무를 하며 도움을 받았던 SEBok (Guide to the system engineering body of knowledge) 의 Part 3: SE and Management / System Definition 의 System Requirements 에 대한 내용을 정리합니다.

 

https://www.sebokwiki.org/wiki/System_Requirements

System Requirements - SEBoK

System Requirements

System requirement (SyR)

• 이해 관계자의 니즈와 요구 사항을 충족시키기 위해 전체 시스템이 충족해야 하는 기능을 설명하는 시스템 레벨의 모든 요구사항
  • 이해 관계자 요구사항의 도출은 Concept Definition 에서 시작되며 인터뷰 및 Mission analysis 를 통해 프로젝트 초기에 개발 됨
  • 이해 관계자 요구사항과 시스템 요구사항 사이의 추적성을 통해 일관성이 달성될 때까지 어느 쪽도 완전한 것으로 간주될 수 없고, 이를 달성하기 위해서는 많은 반복이 필요
• 텍스트, 여러 View point (Logical, Physical 등), 비기능 요구사항 (안전, 보안, 신뢰성 등의 수준) 의 조합으로 표현됨
• 시스템 정의 (System Definition) 중에 자세히 고려됨
  
  • System Definition 은 다음을 포함
    • System Requirements
    • System Architecture
    • Logical Architecture Model Development
    • Physical Architecture Model Development
    • System Design
    • System Analysis

System Engineering 에서 SyR 의 주요 역할

• 시스템 아키텍처 및 설계 활동의 기반
• 시스템 통합 및 검증 활동의 기반
• Validation 및 이해 관계자의 Acceptance 을 위한 참조 역할
• 프로젝트 전반에 걸쳐 상호작용하는 다양한 technical staff (SW Engineer, HW Engineer, Mechanical Engineer, Test Engineer 등) 간의 의사소통 수단을 제공

 

Definition and Purpose of Requirements

Requirement

• 제품 또는 프로세스의 작동, 기능, 디자인 특성, 제약사항을 얘기함
  • Unambiguous, testable or mesurable 해야함
• 요구사항을 표현함에 있어 다음 3가지 분류를 고려 (요구사항과 관련된 여러 혼동을 피하기 위함)
  • Process Role or State : 프로세스에서 요구사항이 수행하는 역할
    • E.g. 시스템 블록에서의 위치 (e.g. 번역됨, 파생됨, 만족됨), 동의 상태 (e.g. 제안됨, 승인됨, 취소됨)
  • Level of Abstratction : 요구사항이 있는 프로세스의 수준
    • E.g. 이해 관계자 요구사항, 시스템 요구사항, 시스템 요소 요구사항
  • Type of Requirement : 요구 사항 자체의 특성
    • E.g. 기능, 성능, 제약 조건 등
• 앞의 3가지 분류에 따라, 단일 요구사항은 특정 상태, 특정 추상화 수준, 특정 유형에 있을 수 있음
  • E.g. 요구사항 A  
    • Process Role or State : 파생됨
    • Level of Abstraction : 시스템 요구사항
    • Type of Requirement : 기능

 

Principles Governing System Requirements

Relationship to Stakeholder Requirements and Logical Architecture (이해관계자 요구사항과 논리적 아키텍처와의 관계)

이해 관계자 요구사항 (Stakeholder requirement)

이해 관계자 요구사항 셋은 Engineering-oriented 언어로 명확화되고 변환됨 → 시스템 요구사항

• 시스템 요구사항 분석의 기초로 필요한 아키텍처 정의, 설계 및 검증 활동을 가능하게 하기 위함

시스템 요구사항 (System requirement)

• 성능 및 기타 품질 측정과 관련된 시스템에 필요한 기능의 식별 및 합성을 기반으로 함
• 후보 솔루션 평가 및 완성된 시스템 검증을 위한 기반을 제공
• 아키텍처 및 설계에 유용한 technical language 로 표현됨
• 이해 관계자 요구사항에서의 변환이 정확하고 추적 가능성이 유지되도록 이해 관계자와의 긴밀한 조정이 필요함
• 측정 가능한 특성을 지정하는 일련의 시스템 기능 및 요구 사항이 생성됨

논리적 아키텍처 (Logical architecture)

논리적 아키텍처는 시스템 경계와 기능을 정의함

• 논리적 아키텍처를 생성하며 더 자세한 시스템 요구사항을 도출할 수 있음
• 프로세스의 출발점은 
  
  • 이해 관계자 요구사항에서 기능 요구 사항을 식별하고 이를 사용하여 아키텍처 정의를 시작하기 위함
  • 높은 수준의 기능 아키텍처에서 시작하여 시스템 요구사항을 구조화하기 위한 기초로 사용하기 위함
• 프로세스가 시작되면 이해 관계자 요구사항, 시스템 요구 사항 및 논리적 아키텍처가 모두 완전하고 서로 일관성이 있으며 시스템 수명 주기 모델의 적절한 지점에서 함께 평가되는 것이 중요함

 

Traceability and the Assignment of System Requirements during Architecture and Design (아키텍처 및 설계 중 추적성 및 시스템 요구사항 할당)

요구사항 추적성

• 이해 관계자 요구사항에서 시스템 계층의 모든 수준의 요소 및 요구사항에 이르기까의 추적하는 기능을 제공
• 제안된 엔지니어링 개선 또는 변경 요청에 의해 영향 분석을 수행할 때 입력으로 변경 범위에 대한 이해를 제공하는데 사용

 

아키텍처 정의 및 설계 단계에서 시스템 계층의 더 낮은 수준으로 요구사항을 할당하는 것은 여러 방법을 사용할 수 있음

 

Assignment Type for a System Requirement	Description
Direct Assignment	상위 수준에 시스템 요구 사항은 하위 수준의 시스템 또는 시스템 요소에 직접 할당됨 (e.g. 제품의 눈에 보이는 부분을 칠하는데 사용되는 색상)
Indirect Assignment (Simply Decomposed)	상위 수준의 시스템 요구 사항은 여러 하위 시스템 또는 시스템 요소에 분포되어 할당됨 분배된 요구사항 들에서의 특정 수치의 합 = 충분한 margin 또는 tolerance (허용 오차) 가 있는 상위 수준에 요구사항 요구사항 분배에 대해 복잡한 계산의 합은 충분한 margin 또는 tolerance 를 가지고 있는 상위 수준에 요구사항과 동일함 (e.g. 질량 요구사항, 전력 분배, 신뢰성 할당 등) 하위 요구사항에 할당되는 "Assignment budget" 은 유지보수 되야 함 Assignment budget 은 문서화되고 configuration 이 관리되야 함
Indirect Assignment (Modeled and Decomposed)	상위 수준에 시스템 요구 사항은 분석 또는 수학적 모델링 기술을 사용하여 여러 시스템 또는 시스템 요소에 분포되어 할당됨 설계 매개변수는 충분한 Margin 을 가지고 하위 시스템 또는 시스템 요소에 할당됨 (e.g. 레이더 감지 요구사항의 경우, 출력 전력, 빔 크기, 주파수 등에 대한 하위 수준 매개변수가 적절한 하드웨어 및 소프트웨어 요소에 할당) 이러한 분석 및 모델은 문서화되고 Configuration 이 관리되야 함
Derived Requirement (from Design)	시스템 요구사항이 이해 관계자 요구사항이 아닌 설계 팀의 결정 결과로 개발됨 (e.g. Commercial-Off-The-Shelf (COTS) 품목, 기존 시스템 사용, 공통 구성 요소 및 유사한 설계 결정 사용) 이러한 파생된 시스템 요구 사항은 이해 관계자 요구사항으로 직접 추적되지 않을 수 있음 이러한 파생된 시스템 요구 사항은 이해 관계자 요구사항 또는 제약 조건과 충돌하지 않아야 함

 

Classification of System Requirements

요구사항 정의 방법과 적용되는 아키텍처 및 설계 방법에 따라 시스템 요구 사항은 여러 형태로 분류가 가능함

 

Types of System Requirement	Description
Functional Requirement	운영중에 수행할 시스템 기능 (function) 또는 작업 (task) 을 정성적으로 설명한 것
Performance Requirements	기능이나 작업이 어느 정도 / 얼마나 잘 수행되어야 하는지 또는 기능 또는 작업이 수행되는 조건 (e.g. rates, velocities) 을 정략적으로 정의한 것 시스템 성능의 정략적 요구사항이며 개별적으로 검증할 수 있음 단일 기능, 기능 요구사항, 작업과 관련한 하나 이상의 성능 요구사항이 있을 수 있음
Usability Requirements	시스템 사용의 품질을 정의한 것 (e.g. 측정가능한 효과성, 효율성, 만족도 기준)
Interface Requirements	시스템이 외부 시스템과 상호 작용하거나 물질, 에너지, 정보를 교환하는 방법 (외부 인터페이스) 또는 인간 요소를 포함한 시스템 내의 시스템 요소가 서로 상호 작용하는 방법 (내부 인터페이스) 를 정의한 것 상호 작용 또는 교환을 지원하는 외부 시스템 또는 내부 시스템 요소와의 물리적 연결 (물리적 인터페이스) 이 포함됨
Operational Requirements	시스템이 작동하거나 지속되는데 필요한 작동 조건 또는 속성을 정의한 것 인적 요소, 가용성, 유지 관리 가능성, 신뢰성, 안전성, 보안이 포함됨
Modes and/or States Requirements	동작 중인 시스템의 다양한 작동 모드와 모드 전이를 일으키는 이벤트를 정의한 것
Adaptability Requirements	시스템 수명 주기 동안 잠재적인 확장 (extenstion), 성장 (growth), 확장성 (scalability) 를 정의한 것
Physical Constraints	시스템을 구성하는 시스템 요소에 적용할 수 있는 무게, 부피 및 치수에 대한 제약을 정의한 것
Design Constrints	특정 바운더리와 한계를 부과하여 솔루션 설계자가 사용 할 수 있는 옵션의 한계를 정의한 것 (e.g. 시스템은 레거시 또는 제공된 시스템 요소를 통합해야 함 or 특정 데이터는 온라인 저장소에서 유지되야 함)
Environmental Conditions	다양한 작동 모드에서 시스템이 직면할 환경 조건을 정의한 것 자연환경 (e.g. 바람, 비 온도, 동물군, 염분, 먼지, 방사선 등) 유도 및 자체 유도 환경 영향 (e.g. 움직임, 충격, 소음, 전자기, 열 등) 사회적 환경에 대한 위협 (e.g. 법적, 정치적, 경제적, 사회적, 비즈니스 등)
Logistical Requirements	시스템의 지속적인 활용에 필요한 물류 조건을 정의 (e.g. 유지 (시설 제공, 수준 지원, 인력 지원, 예비 부품, 교육, 기술 문서 등), 포장, 취급, 선적, 운송 등)
Policies and Regulations	시스템의 운영 또는 성능에 영향을 미칠 수 있는 관련있는 조직 정책, 규제 요구 사항을 정의 (e.g. 노동 정책, 규제 기관에 대한 보고서, 건강, 안전 기준 등)
Cost and Schedule Constraints	시스템의 모형 비용, 첫 번째 모형의 예상 배송 날짜 등을 정의 한 것

 

Requirements Management

요구사항 관리

• 시스템 요구사항 및 시스템 요소 요구사항을 시스템의 다른 표현, 분석, 산출물과 정렬하기(align) 위해 수행됨
  • 요구 사항에 대한 이해 제공, 약속 획득, 변경 관리, 요구 사항 간의 양방향 추적성 유지, 시스템 정의의 나머지 부분, 프로젝트 리소스 및 일정과의 정렬이 포함
    
    
• 요구사항 관리 인프라를 구축하는데 사용할 수 있는 도구들이 많이 있음
  • 프로젝트 또는 기업의 프로세스와 요구사항 관리 프로세스가 일치하는 것이 좋음
    
    
• 요구사항 관리는 베이스라인 관리 및 제어를 위한 형상관리와 밀접하게 관련됨
  • 요구사항 정의, 문서화, 승인하는 활동이 형상관리 (베이스라인 관리 및 제어)에 포함되어야 함
  • 베이스라인을 통해 프로젝트는 이해관계자 요구사항 or 내부 요구사항에 의한 변경과 관련된 영향 (기술, 비용, 일정) 을 분석하고 정리할 수 있음

 

Process Approach

Purpose and Principle of the Approach

시스템 요구사항 분석 프로세스 목적

• 이해 관계자, 사용자 관점의 서비스 및 시스템의 속성을 제품의 기술적 관점으로 변환
• 공급자의 관점에서 이해 관계자의 요구사항을 충족시키기 위해 보유해야 하는 성능 및 비성능 특성을 지정하는 측정 가능한 시스템 요구사항을 생성하는 것
• 이해 관계자의 요구사항을 만족하는 시스템의 표현을 구축
  • 해당 내용에는 제약 조건이 허용하는 한 특정 구현을 의미하지 않음

Activities of the Process

1. 예상 서비스 및 운영 시나리오, 조건, 운영 모드 및 제약의 완전성을 확인하기 위해 이해 관계자의 요구사항 분석
2. 시스템 요구사항과 해당 근거 정의
3. 제안된 분류를 사용하여 시스템 요구사항 분류 (Process Role or State, Level of Abstraction, Type of Requirement)
4. 파생된 요구 사항 (아키텍처 및 설계에서 가져온) 을 시스템 요구사항 베이스라인에 통합
5. 이해 관계자의 요구사항과 시스템 요구 사항간의 추적성 연결 (Upward traceability)
6. 시스템 계층 구조의 인전합 레벨의 요구 사항간의 양방향 추적성 연결 (Bi-directional traceability)
7. 각 시스템 요구 사항의 품질 및 완전성 검증 (Verification), 시스템 요구 사항 셋의 일관성 검증 (Verification)
8. 이해 관계자 요구사항 셋에 대해 각 시스템 요구사항의 내용 및 관련성  검증 (Validation)
9. 시스템 요구사항에 의해 생성될 수 있는 잠재적 위험 (or threat, hazard) 식별
10. 시스템 요구사항 및 관련된 잠재적 위험을 종합, 기록, 관리
11. 요구 사항이 승인되면 형상관리 규칙에 맞춰 다른 시스템 정의 요소와 함께 베이스라인 설정

 

Checking Correctness of System Requirements

시스템 요구사항이 적절한지 평가하기 위해 확인해야 함

• 아래 "Presentation and Quality of Requirements" 의 Table 3 & 4 의 특성을 기반으로 Peer review 기법을 이용하여 확인
• 아래 "Methods and Modeling Techniques" 에서 설명된 요구 사항 도출 및 근거 캡처 방법을 사용하요 추가 확인 가능

 

Methods and Modeling Techniques

Requirements Elicitation and Prototyping

요구사항 도출에는 사용자 참여가 필요하며 이해 관계자 참여 및 동의를 얻는데 효과적일 수 있음

요구사항 도출에 사용할 수 있는 기법은 아래와 같음

1. Quality Function Deployment (QFD)
2. Prototyping
   1. 사용자 인터페이스, 기능, 운영 요구사항을 직관적으로 식별하는데 도움을 줌 (사용자와 개발자가 프로토타입을 보며 대화하며 명확히 요구사항을 정할 수 있음)
3. 인터뷰
4. 포커스 그룹
5. 델파이 테크닉

 

Capturing Requirements Rationale

요구사항에 대한 근거 파악 : 이해 관계자 요구사항을 시스템 요구사항으로 변환하는 강력하고 효율적인 기술

• 요구사항 근거는 요구사항이 존재하는 이유, 가정, 관련 설계 연구의 결과, 관련 지원 정보에 대한 설명을 의미함
• 추가 요구사항 분석 및 분해를 지원
• 몇 가지 추가 장점
  • 전체 요구사항의 개수 감소
    • 중복된 요구사항을 제거하는데 도움이 되며 전체 요구사항을 감소시키게 되면 프로젝트 비용 및 리스크가 감소하게 됨
  • 잘못된 가정의 조기 발견
  • 설계
  • 이해 관계자와의 커뮤니케이션 향상

 

Modeling Techiques

요구사항이 상세하거나 개선되어야 하는경우, 이해 관계자 요구사항 및 미션 분석이 고려되지 않은 경우 사용할 수 있는 모델링 기술

• State-charts models
• Scenarios modeling
• Simulations, prototyping
• Quality Function Deployment
• System Modeling Language (SysML)
  • Sequence diagrams, activity diagram, use cases, state machine diagrams, requirement diagrms
• Functional FlowBlock Diagram for operational scenarios

 

Presentation and Quality of Requirements

일반적으로 요구사항은 자연어 형태로 제공됨

• 요구사항 작성하기 위한 가이드라인 존재
  • 요구 사항 설명의 구문
  • 단어 선택 (제외, 개념 표현 등)
  • 특성 (구체적, 측정 가능, 달성 가능, 실행 가능, 테스트 가능 등)

 

개별 요구 사항 및 요구 사항 집에는 몇 가지 특성이 존재함

개별 요구사항의 특성에 대한 목록과 설명

Characteristic	Description
Necessary	요구사항은 필수 기능, 특성, 제약 조건, 품질 요소를 정의해야 함 해당 특성을 가지는 요구사항이 포함되지 않으면 전체 요구사항의 결함이 존재할 수 있음
Appropriate	요구사항의 구체적인 의도와 디테일 수준은 추상화 레벨에 적합해야 함 아키텍처 / 설계에 대한 불필요한 제약을 피하여 가능한 한 구현 독립성을 보장하는것이 포함
Unambiguous	요구사항은 한 가지 방식으로만 해석될 수 있도록 명시되야 함
Complete	요구사항은 해당 요구사항을 이해하기 위해 다른 추가 정보를 필요로 하지 않고 해당 요구사항만으로 필요한 기능, 특성, 제약, 품질 요소를 충분히 설명해야 함
Singular	요구사항은 단일 기능, 특성, 제약 조건, 품질 요소를 명시해야 함
Feasible	요구사항은 특정 제약 (e.g. 비용, 일정, 기술, 법률, 규제) 관련하여 수용 가능한 수준의 위험(Risk) 내에서 구현되야 함
Verifiable	요구사항은 요구사항이 작성된 수준에서 고객의 관점으로 요구사항을 구현한 것이 검증 될 수 있도록 구조화되고 표현되야 함
Correct	요구사항은 변환된 고객 요구사항을 정확하게 표현해야 함
Conforming	요구사항은 요구사항 작성에 대한 승인된 표준 템플릿 및 스타일을 준수해야 함

참고사항

• 최근 요구사항의 추적성은 특성이 아닌 요구사항 작성시 추가적으로 작성해야 하는 하나의 속성으로 간주됨
• 요구사항의 추적성은 상위 요구사항 (e.g. 이해관계자 요구사항, 고객 요구사항 등) 과의 연결도 필요하고 하위 요구사항 (e.g. SW 요구사항, 시스템 엘리먼트 요구사항 등) 과의 연결도 필요함

 

요구사항 집합의 특성 (Characteristics of a Set of Requirements)

 

Characteristic	Description
Complete	요구사항 집합은 엔티티의 요구사항을 충족하는데 필요한 기능, 특성, 제약 조건, 품질 요소를 충분히 설명해야 함 다른 정보 제외
Consistent	요구사항 집합은 다른 요구사항과 겹치거나 충돌하지 않은 개별 요구사항으로 구성되어 있어야 함 요구사항 집합은 단위 및 측정 시스템이 Homogeneous 해야 함 요구사항 집합 내에서 사용되는 언어는 일관성이 있어야 함 집합 전체에서 단어가 동일한 것을 의미해야 함
Feasible	요구사항 집합은 특정 제약 (e.g. 비용, 일정, 기술, 법률, 규제) 관련하여 수용 가능한 위험 (Risk) 내에서 구현되야 함
Comprehensible	요구사항 집합은 엔티티가 기대하는 것과 엔티티가 속한 시스템과의 관계가 명확하도록 작성되어야 함
Able to be validated	요구사항 집합은 특정 제약 (e.g. 비용, 일정, 기술, 법률, 규제) 내에서 엔티티의 요구사항을 달성할 것임을 증명할 수 있어야 함

 

Requirements in Tables

시스템 또는 시스템의 엘리먼트의 요소 (parameter) 를 지정할 때 요구사항은 테이블 형태로 작성할 수 있음

테이블은 아래의 규칙이 적용되어야 함

• 고유한 제목과 테이블 번호로 각 테이블을 식별
• 표 제목에 "요구사항" 이 포함되어야 함
• 바로 앞의 텍스트에서 표의 목적을 식별하고 문맥과 단위를 포함하여 표를 읽고 사용하는 방법에 대한 설명을 포함해야 함
• 독립 종속 변수 상황의 경우, 정보 사용을 가장 잘 수용하는 방식으로 테이블을 구성
• 각 셀에는 최대 단일 요구 사항이 포함되어야 함

 

Requirements in Flow Charts

플로우 차트에는 그래픽 형식의 요구사항이 작성 됨

• 시스템에 통합되어야 하는 논리, 운영 요구사항, 프로세스, 절차 요구사항, 일련의 상호 관련된 단계에 의해 그래픽으로 가장 잘 정의되는 기타 상황이 포함될 수 있음

플로우 차트에는 아래의 규칙이 적용되어야 함

• 고유한 제목과 그림 번호로 각 순서도를 식별
• 순서도 제목에 "요구사항" 이 포함되어야 함
• 순서도에는 요구 사항을 나타내는 고유한 기호를 명확하게 표시하고 설명해야 함

 

Requirements in Drawings

도면은 요구사항을 정의하는 그래픽 수단을 제공

• 도면에 정의된 요구사항 유형은 도면 유형에 따라 다름

다음의 경우, 도면을 사용하여 요구사항을 정의

• 공간 요구사항
• 인터페이스 요구사항
• 레이아웃 요구사항 등

 

Artifacts

해당 프로세스를 거치면서 생성되는 프로세스는 다음과 같음

• 시스템 요구사항 문서
• 시스템 요구사항 정당화 문서 (근거 문서, 추적성 목적)
• 시스템 요구사항 데이터 베이스 (추적성, 분석, 근거, 결정, 속성 등을 포함)
• 시스템 외부 인터페이스 요구사항 문서
  • 시스템 컨텍스트의 외부 요소와의 인터페이스를 설명

 

Practical Considerations about System Requirements

시스템 요구사항을 정의하는데 있어 주요한 함정

 

Pitfall	Description
이해관계자 요구사항의 불충분한 분석	이해 관계자 요구사항을 전달받은 수신자가 충분한 분석을 수행하지 않은 경우, 시스템 요구사항으로 변환하는데 있어 어려움 존재
운영 시나리오와 동작 모드의 불충분한 분석	The operational modes and operational scenarios are not sufficiently analyzed or defined by the person in charge of writing the system requirements. Those elements allow the structuring of the system and its use early in the engineering process and help the designer to remember functions and interfaces.
불완전한 시스템 요구사항 집합	시스템 요구사항이 불완전한 경우, 설계가 원하는 품질 수준을 만족하지 못할 수 도 있고 시스템 검증이 미뤄질 수 있는 리스크가 존재함
검증 방법의 부족	각 시스템 요구사항에 대한 검증 방법 및 이벤트가 지연될 수 있음 각 시스템 요구사항에 대한 검증 접근 방식의 식별은 종종 요구 사항 자체의 정확성과 필요성을 파악하는데 도움을 줌
추적성 누락	상위 요구사항과의 부적절한 연결 또는 연결 누락을 의미함 추적성이 잘못 연결된 경우, 변경 관리 (Change Request) 프로세스에 대한

 

아래 테이블에서 설명하는 입증된 사례는 프로젝트 위험과 비용을 줄이고 고객 만족도를 높이며 성공적인 시스템 개발을 생산하는 것으로 반복적으로 나타났음

Practice	Description
Involve Stakeholders	시스템 요구사항 개발 프로세스 초기에 관련 이해관계자들이 참여
Presence of Rationale	각 시스템 요구사항에 대한 근거를 정리
Always Complete before Starting	시스템 요구사항 정의를 시작하기 전에 이해관계자 요구사항이 가능한 한 완전한지 확인
Peer Reviews	해당 주제 전문가와 함께 시스템 요구사항에 대한 동료 검토를 구성
Modeling Techniques	위 섹션에 표시된 대로 모델링 기술을 사용
Requirement Management Tool	특히 더 복잡한 프로젝트의 경우 요구사항 관리 도구 사용을 고려. 해당 툴에는 요구사항 간의 연결을 추적하는 기능이 있어야 함 해당 툴은 프로젝트 수명 주기 전반에 걸쳐 시스템 요구사항의 체계적인 관리를 촉진하고 지원하기 위함
Measures for Requirement Engineering	요구사항 엔지니어링에 대한 일반적인 측정을 사용 상세 내용은 Systems Engineering Leading Indicators Guide 참조 요구사항 엔지니어링에는 프로세스 및 제품 (판단측정의) 척도 (기준)을 사용해야 함 위험관리 요구사항 엔지니어링을 잘 하려면, 요구사항에 대한 정보 (위험, 목표, 문제)에 따라 둘 이상의 (판단측정의) 척도 (기준) 을 사용해야 할 수도 있음 유용한 (판단측정의) 척도 (기준) 은 다음과 같음 요구사항 변동성 요구사항 동향 요구사항 검증 진행 상황 (계획 vs 실제) 요구사항 검증 진행률 (계획 vs 실제) 계획에 따라 TBD 및 TBR 폐쇄 피어 리뷰 결함