ISO/IEC/IEEE 29148은 시스템과 소프트웨어 제품 및 서비스의 생명주기 전반에서 수행되는 요구사항 공학에 관한 국제 표준이다. 공식 명칭은 Systems and software engineering — Life cycle processes — Requirements engineering이다. 요구사항을 발견하고 도출하는 활동뿐 아니라 요구사항의 분석, 명세, 검증, 타당성 확인, 추적, 변경 관리와 관련 정보 항목의 내용까지 다룬다.
이 표준은 특정 개발 방법론이나 문서 작성 도구를 규정하는 방법론 표준이 아니다. ISO/IEC/IEEE 15288의 시스템 생명주기 프로세스와 ISO/IEC/IEEE 12207의 소프트웨어 생명주기 프로세스에 포함된 요구사항 관련 활동을 구체화하고, 요구사항 명세에 포함되어야 할 정보와 요구사항 품질 기준을 제공한다.
| 항목 | 내용 |
|---|---|
| 표준 번호 | ISO/IEC/IEEE 29148 |
| 공식 명칭 | Systems and software engineering — Life cycle processes — Requirements engineering |
| 현행 발행본 | ISO/IEC/IEEE 29148:2018, 제2판 |
| 발행 시기 | 2018년 11월 |
| 담당 위원회 | ISO/IEC JTC 1/SC 7, IEEE Computer Society Systems and Software Engineering Standards Committee |
| 규범 참조 | ISO/IEC/IEEE 15288:2015, ISO/IEC/IEEE 12207:2017 |
| 적용 대상 | 인공 시스템, 소프트웨어 집약 시스템, 소프트웨어·하드웨어 제품 및 관련 서비스 |
| 개정 상태 | 2026년 8월 기준 제3판 초안인 ISO/IEC/IEEE DIS 29148이 개발 중이다 |
목적과 적용 범위
ISO/IEC/IEEE 29148은 다음 사항을 다룬다.
- 시스템과 소프트웨어 제품 및 서비스의 요구사항을 산출하는 공학 프로세스
- ISO/IEC/IEEE 15288 및 ISO/IEC/IEEE 12207의 요구사항 관련 프로세스 적용 지침
- 요구사항 공학 프로세스에서 생성되는 정보 항목
- 각 정보 항목에 요구되는 내용
- 요구사항 및 관련 정보 항목의 구성과 표현에 관한 지침
- 개별 요구사항과 요구사항 집합의 품질 특성
- 요구사항 추적성, 변경 관리 및 측정
표준은 프로젝트의 범위, 제품 유형, 개발 방법론, 규모 또는 복잡도와 관계없이 적용할 수 있도록 구성되어 있다. 요구사항 공학 활동만을 독립적으로 개선하는 데 사용할 수도 있고, 15288 또는 12207에 따른 전체 생명주기 프로세스의 일부로 사용할 수도 있다.
역사
ISO/IEC/IEEE 29148은 기존에 분리되어 있던 시스템 요구사항, 소프트웨어 요구사항, 운용 개념 관련 IEEE 표준을 통합하면서 형성되었다.
| 연도 | 표준 또는 사건 | 내용 |
|---|---|---|
| 1998 | IEEE 830-1998 | 소프트웨어 요구사항 명세서의 내용과 품질을 다룬 권고 실무 |
| 1998 | IEEE 1233-1998 | 시스템 요구사항 명세서의 개발 지침 |
| 1998 | IEEE 1362-1998 | 운용 개념 문서의 형식과 내용에 관한 지침 |
| 2011 | ISO/IEC/IEEE 29148:2011 | 위 세 IEEE 표준을 대체하고 시스템·소프트웨어 요구사항 공학을 하나의 국제 표준으로 통합한 제1판 |
| 2018 | ISO/IEC/IEEE 29148:2018 | ISO/IEC/IEEE 15288:2015 및 12207:2017과 구조와 내용을 조화시키기 위해 기술적으로 개정한 제2판 |
| 2024 | 정기 검토 | 제2판이 확인되어 현행 발행본으로 유지됨 |
| 2026 | ISO/IEC/IEEE DIS 29148 | 제3판 국제표준안이 개발 단계에 진입함 |
2011년판은 IEEE 830의 소프트웨어 요구사항 명세, IEEE 1233의 시스템 요구사항 명세, IEEE 1362의 운용 개념을 더 넓은 요구사항 공학 체계 안에 통합했다. 2018년판은 이러한 범위를 유지하면서 생명주기 프로세스 표준과의 정합성을 높이고 정보 항목의 구조를 재정비했다.
핵심 개념
요구사항
표준에서 요구사항은 필요와 그에 수반되는 제약조건 및 적용 조건을 번역하거나 표현한 문장으로 정의된다. 요구사항은 시스템, 소프트웨어, 서비스 또는 그 밖의 관심 대상에 대해 작성되며, 시스템 구조의 여러 추상화 수준에 존재할 수 있다.
요구사항은 단순한 희망 사항이나 기능 목록과 구별된다. 이해관계자의 필요가 분석과 합의를 거쳐 특정 대상이 충족해야 하는 조건으로 변환되어야 하며, 그 변환 관계를 추적할 수 있어야 한다.
요구사항 공학
요구사항 공학은 획득자와 공급자의 영역을 매개하여 관심 대상 시스템, 소프트웨어 또는 서비스가 충족해야 할 요구사항을 수립하고 유지하는 학제적 기능이다. 표준이 다루는 활동에는 다음이 포함된다.
- 필요와 요구사항의 발견 및 도출
- 분석과 정제
- 요구사항 작성과 명세
- 검증과 타당성 확인
- 의사소통과 합의
- 문서화와 정보 관리
- 추적성과 변경 관리
주요 용어
| 용어 | 의미 |
|---|---|
| 이해관계자 | 시스템 또는 시스템이 제공해야 할 특성에 권리, 이해관계, 청구권 또는 관심을 가진 개인이나 조직 |
| 관심 대상 시스템 | 특정 생명주기와 공학 활동의 대상으로 삼는 시스템 |
| 도출 요구사항 | 상위 요구사항, 분석, 절충 연구 또는 설계 결정으로부터 추론된 요구사항 |
| 정보 항목 | 사람의 사용을 위해 생성·저장·전달되는, 별도로 식별 가능한 정보의 집합 |
| 베이스라인 | 특정 시점에 공식 승인되어 고정된 구성 항목의 버전 |
| 요구사항 추적성 | 요구사항의 상향 도출 경로와 하향 할당 또는 전개 경로를 식별하고 기록하는 성질 |
| 요구사항 추적성 행렬 | 요구사항을 상위 필요·요구사항 및 하위 구현·검증 항목과 연결하는 구조화된 정보 항목 |
요구사항 검증과 타당성 확인
ISO/IEC/IEEE 29148은 요구사항에 대한 검증과 타당성 확인을 구분한다.
| 구분 | 핵심 질문 | 대상 |
|---|---|---|
| 요구사항 검증 | 요구사항이 올바른 형식과 품질 특성을 갖추었는가 | 개별 요구사항과 요구사항 집합 |
| 요구사항 타당성 확인 | 요구사항이 이해관계자가 의도한 올바른 시스템을 정의하는가 | 요구사항과 이해관계자 필요의 관계 |
| 시스템 검증 | 구현된 시스템이 명세된 요구사항을 충족하는가 | 구현·통합된 시스템 |
| 시스템 타당성 확인 | 구현된 시스템이 실제 사용 목적과 운용 환경에서 필요를 충족하는가 | 운용 맥락의 시스템 |
요구사항 문장이 명확하고 측정 가능하더라도 원래의 필요를 잘못 표현할 수 있다. 반대로 이해관계자의 의도를 반영하더라도 모호하거나 검증할 수 없는 형태로 작성될 수 있다. 표준은 두 문제를 별도의 활동으로 취급한다.
표준의 구성
2018년판은 요구사항의 개념, 프로세스, 정보 항목과 명세서 내용을 구분하여 구성한다.
| 절 | 주제 | 주요 내용 |
|---|---|---|
| 1–3 | 범위·참조·용어 | 적용 범위, 규범 참조, 정의와 약어 |
| 4 | 적합성 | 전체 적합성, 프로세스 적합성, 정보 항목 내용 적합성, 테일러링된 적합성 |
| 5 | 개념 | 요구사항 기초, 필요의 요구사항 변환, 품질 특성, 언어 기준, 속성, 반복·재귀 적용 |
| 6 | 프로세스 | 비즈니스·임무 분석, 이해관계자 필요와 요구사항 정의, 시스템·소프트웨어 요구사항 정의, 요구사항 관리 |
| 7 | 정보 항목 | 프로세스에서 생성·유지해야 하는 요구사항 관련 정보 항목 |
| 8 | 정보 항목 지침 | BRS, StRS, SyRS, SRS의 예시 개요 |
| 9 | 정보 항목 내용 | 각 요구사항 명세서에 포함되는 세부 내용 |
| 부속서 A | 시스템 운용 개념 | 규범적 부속서 |
| 부속서 B | 운용 개념서 | 참고적 부속서 |
| 부속서 C | 테일러링 정책 | 규범적 부속서 |
필요에서 요구사항으로의 변환
요구사항 공학은 필요를 단순히 받아 적는 작업이 아니라, 서로 다른 추상화 수준의 요구사항으로 변환하고 그 관계를 유지하는 과정이다.
flowchart TD
A[비즈니스 또는 임무의 문제·기회] --> B[비즈니스 요구사항 BRS]
B --> C[이해관계자 필요와 요구사항 StRS]
C --> D[시스템 요구사항 SyRS]
D --> E[소프트웨어·시스템 요소 요구사항 SRS 등]
E --> F[아키텍처·설계·구현]
C <--> |양방향 추적성| D
D <--> |양방향 추적성| E
F -. 검증 결과와 변경 영향 .-> E
E -. 분석 결과와 도출 근거 .-> D
이 구조는 고정된 단방향 단계가 아니다. 표준은 요구사항 프로세스가 생명주기 동안 반복적으로 적용되고, 시스템·하위 시스템·시스템 요소의 여러 수준에서 재귀적으로 적용된다고 설명한다. 아키텍처 분석, 절충 연구, 검증 계획 또는 위험 분석의 결과가 상위 요구사항의 수정으로 이어질 수 있다.
요구사항 공학 프로세스
비즈니스 또는 임무 분석
비즈니스 또는 임무 분석은 해결하려는 문제, 활용하려는 기회, 달성해야 할 임무와 조직적 목적을 정의한다. 주요 이해관계자, 성공 기준, 비즈니스 환경, 운용 개념, 제약조건과 잠재적 해결 방향을 식별하며 이후 요구사항 활동의 범위를 설정한다.
이 프로세스의 결과는 특정 제품의 상세 기능보다 상위 수준의 목적과 조건을 표현한다. 관련 정보는 비즈니스 요구사항 명세서에 구조화할 수 있다.
이해관계자 필요와 요구사항 정의
이 프로세스는 시스템의 전체 생명주기에 관계하는 이해관계자를 식별하고, 그들의 필요·기대·제약조건을 도출하고 분석한다. 사용자뿐 아니라 획득자, 운영자, 유지보수자, 공급자, 규제기관, 안전·보안 담당자와 폐기 단계의 관계자도 이해관계자가 될 수 있다.
도출된 내용은 충돌 여부, 우선순위, 기술적 실현 가능성, 운용 환경과 생명주기 개념을 고려해 통합된다. 그 결과는 시스템이 이해관계자에게 제공해야 할 능력과 조건을 나타내며, 시스템 요구사항 정의의 입력이 된다.
시스템 및 소프트웨어 요구사항 정의
시스템 요구사항 정의는 이해관계자 필요와 요구사항을 시스템 관점의 기술적 요구사항으로 변환한다. 기능, 성능, 사용성, 인터페이스, 운용 모드, 보안, 물리적·환경적 조건, 법규, 유지지원과 검증 조건 등이 포함될 수 있다.
소프트웨어가 관심 대상이거나 시스템 요소로 할당된 경우 같은 원리가 소프트웨어 요구사항에 적용된다. 요구사항은 아키텍처와 설계를 불필요하게 제한하지 않는 수준에서 무엇을 달성해야 하는지를 표현하되, 상위 설계 결정에서 필연적으로 발생한 제약조건은 명시적으로 관리한다.
다른 기술 프로세스의 요구사항 활동
요구사항 공학은 요구사항 정의 절에서 끝나지 않는다. 표준은 아키텍처 정의, 검증, 타당성 확인과 같은 다른 기술 프로세스에서도 요구사항 관련 활동을 수행하도록 다룬다.
- 아키텍처 대안이 요구사항을 충족하는지 분석한다.
- 요구사항마다 충족 여부를 입증할 방법과 성공 기준을 정한다.
- 검증 결과를 요구사항과 연결한다.
- 운용 시나리오와 이해관계자 필요를 기준으로 요구사항 집합의 타당성을 확인한다.
- 분석 또는 시험에서 발견된 결함을 요구사항 변경 절차로 환류한다.
요구사항 관리
요구사항 관리는 요구사항을 식별하고, 기록하고, 유지하고, 전달하고, 추적하고, 상태를 관리하는 활동이다. 변경 제안은 관련 요구사항, 아키텍처, 구현, 검증 항목, 비용, 일정과 위험에 미치는 영향을 분석한 뒤 승인된 절차에 따라 반영한다.
표준은 요구사항 관리에 변경 관리와 요구사항 측정을 포함한다. 요구사항 수, 상태, 결함, 변경, 추적성 또는 검증 준비도와 같은 측정치는 조직이 정한 목적과 정보 요구에 맞추어 정의된다.
요구사항의 품질 특성
개별 요구사항
2018년판은 잘 형성된 개별 요구사항의 특성을 다음과 같이 제시한다.
| 특성 | 의미 |
|---|---|
| 필요함 | 상위 필요나 요구사항을 충족하는 데 필수적이며, 제거하면 충족되지 않는 결손이 발생한다 |
| 적절함 | 대상의 추상화 수준과 책임 범위에 맞는 내용과 상세도를 가지며 불필요한 구현 제약을 피한다 |
| 모호하지 않음 | 의도한 독자들이 하나의 의미로 해석할 수 있다 |
| 완전함 | 필요한 능력, 특성, 제약조건, 적용 조건 또는 품질 요소를 이해하는 데 필요한 정보를 포함한다 |
| 단일함 | 하나의 능력, 특성, 제약조건 또는 품질 요소를 표현한다 |
| 실현 가능함 | 비용, 일정, 기술, 법규와 위험 등의 제약 안에서 구현할 수 있다 |
| 검증 가능함 | 충족 여부를 객관적 증거로 판단할 수 있도록 작성되어 있다 |
| 정확함 | 변환의 근거가 된 필요, 상위 요구사항 또는 출처를 정확히 표현한다 |
| 규약에 부합함 | 승인된 요구사항 패턴, 템플릿과 작성 규칙을 따른다 |
이 특성들은 문장 표면의 품질만을 뜻하지 않는다. 필요성, 정확성, 적절성과 실현 가능성은 요구사항의 출처, 분석 근거, 시스템 수준과 제약조건을 함께 검토해야 판단할 수 있다.
요구사항 집합
개별 요구사항이 양호해도 전체 집합이 서로 충돌하거나 필요한 영역을 누락할 수 있다. 2018년판은 요구사항 집합에 다음 특성을 요구한다.
| 특성 | 의미 |
|---|---|
| 완전함 | 해당 수준에서 필요한 능력, 특성, 제약조건과 품질 요소를 충분히 포함한다 |
| 일관됨 | 요구사항이 서로 충돌하거나 불필요하게 중복되지 않고, 용어와 단위 체계가 일관된다 |
| 실현 가능함 | 집합 전체를 제약조건과 허용 가능한 위험 안에서 실현할 수 있다 |
| 이해 가능함 | 대상이 무엇을 충족해야 하는지와 상위 시스템과의 관계가 명확하다 |
| 타당성 확인 가능함 | 집합을 충족하면 원래의 필요와 상위 목적이 달성되는지 확인할 수 있다 |
INCOSE의 후속 작성 지침은 ISO/IEC/IEEE 29148의 개념을 확장해 더 세분된 규칙과 품질 특성 간 대응 관계를 제시한다. 이 지침의 분류는 실무 보조 자료이며 ISO 표준 조항 자체와 동일한 목록으로 취급하지 않는다.
요구사항 언어
표준은 검증 가능성과 해석 일관성을 떨어뜨리는 표현을 피하도록 안내한다.
| 문제가 되는 표현 | 예 | 문제 |
|---|---|---|
| 최상급 | 최고, 최적, 가장 빠른 | 비교 집단과 판정 기준이 불명확하다 |
| 주관적 형용사 | 사용하기 쉬운, 효율적인, 충분한 | 관찰자에 따라 판단이 달라진다 |
| 모호한 대명사 | 이것, 해당 항목, 그것 | 지시 대상이 불분명할 수 있다 |
| 불확정 수량 | 여러, 일부, 거의 항상, 약 | 범위와 허용 오차가 정의되지 않는다 |
| 열린 목록 | 등을 포함하되 이에 한정되지 않음 | 요구 범위가 닫히지 않는다 |
| 회피 조항 | 가능한 경우, 적절한 때, 필요시 | 적용 조건과 책임이 불명확하다 |
| 불완전한 참조 | 관련 표준을 준수한다 | 표준의 판, 조항과 적용 범위가 식별되지 않는다 |
| 복합 논리 | A 및/또는 B | 가능한 조합과 의무가 모호하다 |
수량에는 단위, 범위 또는 허용 오차를 명시하고, 시간 의존성에는 시작 조건과 완료 조건을 정의하며, 논리 조건은 프로젝트에서 합의한 표현 규칙에 따라 작성한다. 요구사항의 이유와 설계 근거는 요구사항 문장에 혼합하기보다 속성이나 관련 정보 항목으로 관리할 수 있다.
요구사항 속성
요구사항 문장만으로는 출처, 상태, 중요도와 검증 계획을 모두 표현하기 어렵다. 표준은 요구사항 리포지토리에서 요구사항과 관련 속성을 함께 관리하도록 안내한다.
대표적인 속성은 다음과 같다. 조직은 프로젝트와 적합성 범위에 따라 속성 체계를 테일러링할 수 있다.
| 속성 | 용도 |
|---|---|
| 고유 식별자 | 요구사항을 문서·도구·버전 사이에서 식별한다 |
| 출처 또는 상위 항목 | 필요, 규정, 계약, 상위 요구사항과의 관계를 기록한다 |
| 근거 | 요구사항이 필요한 이유, 수치의 출처, 분석 또는 절충 결과를 기록한다 |
| 소유자 | 작성·승인·유지 책임을 식별한다 |
| 분류 | 기능, 성능, 인터페이스, 보안, 안전, 제약조건 등의 유형을 구분한다 |
| 우선순위 | 구현 또는 의사결정 순서를 지원한다 |
| 중요도 | 실패 영향 또는 임무·안전·보안상 중요성을 나타낸다 |
| 상태와 버전 | 제안, 분석 중, 승인, 변경, 폐기 등의 생명주기 상태를 기록한다 |
| 검증 방법과 성공 기준 | 시험, 분석, 검사, 시연 등 입증 방법과 합격 조건을 연결한다 |
| 위험 | 실현 가능성, 기술 성숙도, 비용·일정 영향과 관련된 위험을 기록한다 |
| 추적 링크 | 상위 필요, 하위 요구사항, 설계, 구현 및 검증 증거를 연결한다 |
추적성과 베이스라인
추적성은 요구사항이 어디에서 유래했고 어디로 전개되었는지를 양방향으로 설명한다.
- 상향 추적성은 요구사항을 이해관계자 필요, 상위 요구사항, 규정, 계약 또는 분석 근거와 연결한다.
- 하향 추적성은 요구사항을 하위 요구사항, 아키텍처 요소, 설계, 구현 항목과 검증 증거에 연결한다.
- 수평 추적성은 같은 수준의 인터페이스, 제약조건, 위험, 의사결정 또는 관련 요구사항 사이의 관계를 표현할 수 있다.
승인된 요구사항 집합은 베이스라인으로 지정할 수 있다. 이후의 변경은 변경 이유, 승인자, 영향 범위와 관련 추적 링크를 함께 갱신해야 한다. 추적성 행렬은 이러한 관계를 표현하는 한 가지 형식이며, 데이터베이스나 모델 기반 리포지토리의 링크 구조로도 구현할 수 있다.
요구사항 정보 항목
ISO/IEC/IEEE 29148은 요구사항 공학에서 사용되는 주요 명세 정보 항목의 예시 구조와 내용을 제공한다.
| 정보 항목 | 약어 | 주요 관점과 내용 |
|---|---|---|
| 비즈니스 요구사항 명세서 | BRS | 비즈니스 또는 임무의 목적, 범위, 환경, 목표, 운영 정책·제약, 상위 운용 개념과 프로젝트 제약 |
| 이해관계자 요구사항 명세서 | StRS | 이해관계자, 사용 맥락, 운용 환경, 사용자 요구, 운용 모드·상태, 품질 기대, 운용 시나리오와 제약 |
| 시스템 요구사항 명세서 | SyRS | 시스템 기능, 사용성, 성능, 외부 인터페이스, 운용, 모드·상태, 물리·환경 조건, 보안, 정보 관리, 규정, 유지지원과 검증 |
| 소프트웨어 요구사항 명세서 | SRS | 제품 관점, 기능, 사용자 특성, 외부 인터페이스, 성능, 사용성, 데이터, 설계 제약, 표준 준수, 소프트웨어 품질 특성, 검증과 지원 정보 |
| 시스템 운용 개념 | OpsCon | 특정 시스템 또는 관련 시스템 집합이 운용 환경에서 어떻게 사용되는지를 사용자와 운영자 관점에서 표현 |
| 운용 개념서 | ConOps | 조직 또는 기업이 인적·기술적 자원을 사용해 운용 목적을 달성하려는 상위 수준의 가정과 의도를 표현 |
표준의 명세서 개요는 정보 내용의 예시 구조이다. 모든 프로젝트가 각 항목을 별도의 파일로 작성해야 한다는 뜻은 아니다. 여러 정보 항목을 하나의 리포지토리나 모델에서 관리하거나, 하나의 문서에 여러 관점을 결합할 수 있다. 적합성은 선택한 범위에서 요구되는 프로세스와 정보 내용이 충족되는지를 기준으로 판단한다.
ConOps와 OpsCon
ISO/IEC/IEEE 29148은 흔히 혼용되는 두 개념을 구분한다.
| 개념 | 중심 대상 | 관점 |
|---|---|---|
| Concept of Operations | 조직 또는 기업의 운용 | 조직이 인력과 기술 자원을 이용해 어떤 결과를 달성하려는지에 대한 넓은 그림 |
| Operational Concept | 특정 시스템 또는 관련 시스템 집합 | 사용자와 운영자가 시스템을 운용 환경에서 어떻게 사용할지에 대한 구체적인 그림 |
2018년판에서 시스템 운용 개념은 규범적 부속서 A에서 다루고, 운용 개념서는 참고적 부속서 B에서 다룬다.
적합성과 테일러링
표준은 적합성을 하나의 단일 주장으로만 정의하지 않는다.
- 전체 적합성은 표준에서 요구하는 적용 범위의 프로세스와 정보 항목 관련 규정을 함께 충족하는 주장이다.
- 프로세스 적합성은 요구사항 공학 프로세스의 목적, 결과, 활동과 과업에 대한 적합성을 다룬다.
- 정보 항목 내용 적합성은 생성된 요구사항 정보 항목이 표준에서 요구하는 내용을 포함하는지를 다룬다.
- 테일러링된 적합성은 프로젝트 또는 조직의 상황에 맞추어 프로세스와 정보 항목을 선택·조정한 범위를 명시하고 그 범위에 대해 적합성을 주장한다.
테일러링은 규모가 작은 프로젝트에서 모든 산출물을 기계적으로 유지하는 것을 피하거나, 규제 산업에서 더 엄격한 정보와 승인 절차를 추가하는 데 사용할 수 있다. 테일러링 정책과 적용 범위는 문서화되어야 하며, 제외하거나 변경한 항목이 적합성 주장에 어떤 영향을 주는지 식별할 수 있어야 한다.
생명주기와 개발 방법론의 관계
ISO/IEC/IEEE 29148은 요구사항 공학을 폭포수 개발의 초기 단계로 한정하지 않는다. 표준은 요구사항 프로세스의 반복적·재귀적 적용을 명시하며, 방법론과 프로젝트 규모에 관계없이 사용할 수 있도록 설계되어 있다.
또한 표준에서 사용하는 문서와 정보 항목은 종이 문서나 단일 파일에 한정되지 않는다. 요구사항 데이터베이스, 모델, 표, 다이어그램과 전자 문서가 함께 요구사항 정보를 구성할 수 있다. 따라서 특정 도구나 문서 이름보다 다음 사항이 중요하다.
- 요구사항과 관련 정보가 고유하게 식별되는가
- 상위 필요와 하위 구현·검증 항목이 추적되는가
- 변경과 승인 상태가 관리되는가
- 필요한 정보 내용과 품질 특성이 유지되는가
- 검증 및 타당성 확인에 필요한 객관적 증거를 생성할 수 있는가
관련 표준과 지침
| 표준 또는 지침 | 관계 |
|---|---|
| ISO/IEC/IEEE 15288 | 인공 시스템의 생명주기 프로세스 프레임워크를 제공하며, 29148은 그중 요구사항 관련 프로세스의 적용을 구체화한다 |
| ISO/IEC/IEEE 12207 | 소프트웨어 생명주기 프로세스 프레임워크를 제공하며, 소프트웨어 요구사항 활동과 29148을 연계한다 |
| ISO/IEC/IEEE 15289 | 생명주기 정보 항목의 목적과 내용 체계를 제공하며, 29148의 요구사항 정보 항목과 연계된다 |
| ISO/IEC/IEEE 24765 | 시스템 및 소프트웨어 공학의 공통 용어를 제공한다 |
| INCOSE Guide to Writing Requirements | 요구사항 문장과 집합의 품질 특성을 실무 규칙으로 상세화한 보조 지침이다 |
| SEBoK | 시스템 공학 지식체계에서 이해관계자 필요, 시스템 요구사항, 속성, 추적성과 관련 실무 개념을 정리한다 |
범위에 관한 주의
ISO/IEC/IEEE 29148은 종종 소프트웨어 요구사항 명세서 템플릿으로만 이해되지만, 표준의 범위는 SRS보다 넓다. 비즈니스와 임무 분석부터 이해관계자 요구사항, 시스템 요구사항, 소프트웨어 요구사항, 아키텍처·검증·타당성 확인 활동과 생명주기 변경 관리까지 포함한다.
반대로 이 표준은 특정 도메인의 안전성, 보안, 품질 또는 규제 요구사항을 대신하지 않는다. 의료기기, 자동차, 항공우주, 원자력과 같은 분야에서는 도메인별 표준과 법규가 추가 요구사항의 출처가 되며, ISO/IEC/IEEE 29148은 그러한 요구사항을 일관되게 정의하고 관리하는 공통 요구사항 공학 체계로 사용된다.
참고 자료
- ISO/IEC/IEEE (2018), ISO/IEC/IEEE 29148:2018, Systems and software engineering — Life cycle processes — Requirements engineering, 2nd edition, ISO·IEC·IEEE.
- International Organization for Standardization (2026), ISO/IEC/IEEE 29148:2018 — Requirements engineering, ISO Standards Catalogue.
- International Organization for Standardization (2026), ISO/IEC/IEEE DIS 29148, Systems and software engineering — Life cycle processes — Requirements engineering, Draft International Standard, edition 3.
- Institute of Electrical and Electronics Engineers (2011), ISO/IEC/IEEE 29148:2011, Systems and software engineering — Life cycle processes — Requirements engineering, IEEE Standards Association.
- Institute of Electrical and Electronics Engineers (1998), IEEE 830-1998, Recommended Practice for Software Requirements Specifications, IEEE Standards Association.
- Institute of Electrical and Electronics Engineers (1998), IEEE 1233-1998, Guide for Developing System Requirements Specifications, IEEE Standards Association.
- Institute of Electrical and Electronics Engineers (1998), IEEE 1362-1998, Guide for Information Technology — System Definition — Concept of Operations Document, IEEE Standards Association.
- ISO/IEC/IEEE (2015), ISO/IEC/IEEE 15288:2015, Systems and software engineering — System life cycle processes, ISO·IEC·IEEE.
- ISO/IEC/IEEE (2017), ISO/IEC/IEEE 12207:2017, Systems and software engineering — Software life cycle processes, ISO·IEC·IEEE.
- ISO/IEC/IEEE (2019), ISO/IEC/IEEE 15289:2019, Systems and software engineering — Content of life-cycle information items, ISO·IEC·IEEE.
- INCOSE Requirements Working Group (2023), Guide to Writing Requirements, Version 4 — Summary Sheet, International Council on Systems Engineering.
- SEBoK Editorial Board, System Requirements Definition 및 Stakeholder Needs Definition, Guide to the Systems Engineering Body of Knowledge.