ISO/IEC/IEEE 29148:2018은 요구사항(requirement)을 필요와 그에 따르는 제약·조건을 옮기거나 표현한 진술로 정의하고, 요구사항이 늘 시스템·소프트웨어·서비스 같은 대상에 딸리며 시스템 구조의 여러 수준에 있다고 주석으로 둔다. 이 표준은 요구 공학(requirements engineering)을 구매자와 공급자 사이를 잇는 학제적 기능으로, 대상 시스템·소프트웨어·서비스가 만족할 요구사항을 세우고 유지하는 것으로 정의한다. 요구 공학이 요구사항의 발견, 도출, 개발, 분석, 검증, 확인, 전달, 문서화, 관리를 다룬다는 것도 주석으로 덧붙인다.[1]
ISO/IEC/IEEE 24765 용어집은 요구사항을 계약, 표준, 명세 같은 공식 문서를 만족하려고 시스템, 구성요소, 제품, 서비스가 갖춰야 할 조건이나 능력으로도 정의한다.[2] 요구 공학을 다루는 표준은 ISO/IEC/IEEE 29148이다.
활동
이 용어집은 소프트웨어 요구 공학을 소프트웨어 요구사항의 도출, 분석, 명세, 검증, 관리로 정의하고, 정의·분석·트레이드오프 검토·prototyping을 되풀이하며 시스템 요구사항에서 소프트웨어 요구사항을 끌어낸다는 주석을 둔다.[2]
SWEBOK V4.0a에 따르면 요구사항 개발 활동은 도출, 분석, 명세, 확인(validation)이다. 분석에서는 요구사항 사이의 충돌을 없애고 요구사항이 실현 가능한지 확인하며, 충돌하는 요구사항은 이해관계자들과 협의해 합의된 해결안을 찾는 방식으로 다룰 수 있다. Data-flow 모델링은 모델 기반 요구사항 명세에서 수행할 처리를 명세하는 행위 모델의 하나다.[3]
ISO/IEC/IEEE 29148:2018은 요구 공학의 활동 가운데 넷을 다음처럼 정의한다.[1]
| 활동 | 정의 |
|---|---|
| 요구사항 도출(elicitation) | prototyping, 구조화된 설문 같은 체계적 기법으로 고객과 최종 사용자의 필요를 먼저 찾아 문서로 남기는 일 |
| 요구사항 검증(verification) | 요구사항이 하나씩, 그리고 집합으로 잘 쓰였는지 검토로 확인하는 일 |
| 요구사항 확인(validation) | 요구사항이 하나씩, 그리고 집합으로 이해관계자가 뜻한 올바른 시스템을 정의하는지 확인하는 일 |
| 요구사항 관리(management) | 시스템·제품·서비스의 생명주기 내내 요구사항을 식별, 문서화, 유지, 전달, 추적하는 활동 |
ASPICE 4.1의 SYS.1은 관련 이해관계자를 찾아 그들의 기대와 요청을 얻고(base practice 1, BP1), 그것을 요구사항으로 정리해 영향받는 당사자와 합의하게 한다(BP2). SYS.2와 SWE.1은 기능·비기능 요구사항을 정해 둔 요구사항 특성에 맞춰 찾아 문서로 남기고, 요구사항을 구조화하고 우선순위를 정하며, 상호 의존을 포함해 정확성과 기술적 실현 가능성을 분석하게 한다.[4]
요구사항을 모은 문서는 SRS에서 다룬다.
요구사항 관리
ISO/IEC/IEEE 24765 용어집은 소프트웨어 요구사항 관리를, 시스템 수준에서 모듈·부품 수준까지 요구사항의 식별, 할당, 하향 전개를 인터페이스, 검증, 수정, 상태 감시까지 계획하고 통제하는 과정으로 정의한다.[2]
ASPICE 4.1의 SYS.1은 합의한 이해관계자 요구사항에 대한 변경을 분석해 영향과 위험을 평가하고 변경 통제를 시작하게 한다(BP3). ASPICE 3.1의 SYS.1은 이해관계자 요구사항을 베이스라인으로 정하는 것을 BP의 하나로 두었으나, 4.1의 SYS.1에는 베이스라인 BP가 없고 요구사항 합의와 변경 분석을 둔다.[4][5]
분류
ISO/IEC/IEEE 24765 용어집은 고객 요구사항(customer requirement)을 제품의 관련 이해관계자들의 필요, 기대, 제약, 인터페이스를 도출해 모으고 그 사이의 충돌을 고객이 받아들일 수 있게 푼 결과로 정의한다. 제품 요구사항(product requirement)은 고객 요구사항을 개발자의 말로 다듬어, 암묵적이던 요구사항을 명시적인 파생 요구사항으로 바꾼 것으로 정의한다.[2]
같은 용어집은 기능 요구사항(functional requirement)을 시스템이나 시스템 구성요소가 수행할 기능을 정하는 요구사항으로 정의한다. 비기능 요구사항(nonfunctional requirement)은 시스템이 무엇을 하는지가 아니라 어떻게 개발·유지되고 운용 중에 어떻게 동작하는지를 정하는 요구사항으로 정의하고, 성능 요구사항, 외부 인터페이스 요구사항, 설계 제약을 예로 든다.[2] SWEBOK V4.0a에 따르면 비기능 요구사항 가운데 서비스 품질 제약(quality of service constraint)은 응답 시간, 처리량, 정확도, 신뢰성, 확장성처럼 소프트웨어가 보여야 할 성능 수준을 정한다.[3]
요구사항의 분해
ISO/IEC/IEEE 29148:2018은 파생 요구사항(derived requirement)을, 요구사항을 특정 시스템 구성과 해법으로 모아 정리하면서 끌어낸 요구사항으로 정의한다. 상위 요구사항을 부모, 거기서 나온 요구사항을 자식이라 부른다.[1]
ASPICE 4.1은 요구사항을 수준마다 다른 프로세스로 다룬다.[4]
- SYS.1(Requirements Elicitation): 생명주기 내내 변하는 이해관계자의 필요와 요구사항을 모으고 분석하고 추적해 합의된 요구사항을 세운다.
- SYS.2(System Requirements Analysis): 이해관계자 요구사항과 일관되며 구조화·분석된 시스템 요구사항을 세운다.
- SWE.1(Software Requirements Analysis): 시스템 요구사항 및 시스템 아키텍처와 일관되며 구조화·분석된 소프트웨어 요구사항을 세운다. 하드웨어 요구사항은 HWE.1이 같은 방식으로 세운다.[4]
ASPICE 3.1은 SYS.2와 SWE.1의 목적을 상위 요구사항을 하위 요구사항으로 옮기는 일로 두었다. SWE.1이 옮기는 것은 시스템 요구사항 가운데 소프트웨어에 관한 부분이었다. 4.1은 이를 상위 요구사항과 일관된, 구조화·분석된 요구사항 집합을 세우는 일로 둔다.[4][5]
ASPICE 4.1의 SWE.1과 SYS.2의 BP는 다음과 같다.[4]
| BP | SWE.1 | SYS.2 |
|---|---|---|
| BP1 | 소프트웨어 요구사항 명세 | 시스템 요구사항 명세 |
| BP2 | 요구사항 구조화와 우선순위 지정 | 요구사항 구조화와 우선순위 지정 |
| BP3 | 요구사항 분석 | 요구사항 분석 |
| BP4 | 운용 환경에 대한 영향 분석 | 시스템 컨텍스트에 대한 영향 분석 |
| BP5 | 시스템 요구사항·시스템 아키텍처와의 일관성 확보와 양방향 추적성 수립 | 이해관계자 요구사항과의 일관성 확보와 양방향 추적성 수립 |
| BP6 | 합의한 요구사항과 영향 분석 결과의 전달 | 합의한 요구사항의 전달 |
ASPICE 3.1의 SWE.1과 SYS.2는 BP를 여덟 두었고, 4.1은 여섯을 둔다.[4][5] 검증 기준 BP가 어떻게 바뀌었는지는 아래 검증 기준 절에서 다룬다.
검증 기준
ASPICE 3.1은 요구사항마다 검증 기준을 만들도록 두고, 검증 기준(verification criteria)을 요구사항 검증의 정성적·정량적 척도로 정의했다. ASPICE 4.1은 이 BP를 두지 않고, 요구사항이 갖출 특성의 예로 검증 가능성을 들어 검증 기준이 요구사항 문장 안에 있게 한다.[4][5]
ASPICE 4.1은 요구사항을 모호하지 않고 시험·측정할 수 있으며, 제품이나 프로세스를 받아들이는 데 필요한 특성을 밝힌 진술로 정의한다. SWE.6에서는 통합된 소프트웨어가 기능·비기능 소프트웨어 요구사항을 따르는지 보일 검증 수단을 합격·불합격 기준과 함께 명세하게 한다.[4] ISO/IEC/IEEE 29148:2018은 검증을 명세한 요구사항이 충족됐음을 객관적 증거로 확인하는 일로 정의한다.[1]