SW를 개발하기 위한 요구사항을 추출, 분석, 명세, 검증하며, 개발된 요구사항의 변경 및 추적을 관리하는 공학적 접근 방법
V-Model 좌측 최상위 단계. 결함 수정 비용이 단계별로 폭증하기 때문에 가장 중요한 단계 중 하나.
요구사항이란
현실 세계의 문제를 해결하기 위하여 고객에 의해 요구되거나 표준 등을 만족하기 위해 제품이 가져야 하는 서비스 또는 제약사항
요구사항 분류
| 분류 | 정의 |
|---|---|
| 고객 요구사항 | 고객이 개발 대상 제품에 대해 원하는 기대사항 (Needs) |
| 제품 요구사항 | 고객 요구사항을 만족하기 위해 제품이 수행해야 하는 개발 관점의 구체적 요구사항 |
| 기능적 요구사항 | 제품이 목표를 달성하기 위해 사용자에게 제공해야 하는 행위적(기능적) 속성 |
| 비기능적 요구사항 | 제품의 기능이 성능, 안전성, 사용성 등의 품질 기준을 만족시키기 위해 가져야 하는 속성 |
로봇 청소기 예시
- 고객 요구사항: 스스로 움직이며 청소해야 한다.
- 기능적 요구사항: 주변을 감지해야 한다. 속도를 계산해야 한다. 계획된 경로를 움직여야 한다.
- 비기능적 요구사항: 주변의 사물을 100ms 이내에 감지해야 한다.
자동차 협업체계 요구사항 계층
OEM·Tier-1·Tier-2 협업에서 요구사항은 Why → What → Behavior 계층으로 분해되어 하위 프로젝트로 전파된다.
[Why] 비즈니스 요구사항, 이해관계자 요구사항
↓
[What] 시스템 개발 프로젝트 — Vehicle 시스템 요구사항
↓
파워트레인 개발 프로젝트 — 시스템 요구사항 [Behavior: Why, How]
↓
EMS 개발 프로젝트 — 엔진제어 시스템 요구사항
↓
ECU / 센서 / 액추에이터 개발 프로젝트
↓
SW / HW 개발 프로젝트 — 컴포넌트 요구사항→ 상위 계층의 [고객 요구사항]이 하위 계층으로 전개되면서 점차 [제품 요구사항]으로 구체화되며, 각 레벨에서 양방향 추적성이 유지되어야 한다. ISO 26262의 Safety Goal → FSR → TSR → SWSR/HWSR 전개와 구조적으로 동일.
기능/비기능 요구사항 세부 분류
- Functional(What the system must do?): Behavior, Interface, Control, Accuracy
- Non-Functional (How well does the system do?):
- Quality: Reliability, Maintainability, Serviceability, Usability, Reusability, Security, Adaptability
- Performance: Response Time, Workload, Capacity
- Limitation: External (Standard & Legal, Cultural & Political), Internal (Company Vision, Product Goal, Resources)
요구사항의 중요성
프로젝트 실패 원인
| 원인 | 비중 |
|---|---|
| Poor requirements definition | 50% |
| Poor scope definition | 17% |
| Inadequate risk management | 15% |
| Communication problems | 14% |
| Lack of qualified resources | 3% |
| Other | 1% |
단계별 결함 수정 비용
요구분석(1배) → 설계(2~6배) → 구현(10배) → 통합테스트(15~40배) → 시스템테스트(40~1000배) → 현장운영(30~70배)
Bad vs Good 명세 예시
| Bad (모호) | Good (정량) |
|---|---|
| The system must refresh the data reasonably quickly | within 0.5 seconds |
| resist concurrent usage by many users | by 1000 users |
| should not allow external users to access | will only allow employees to access |
요구공학 4+1 프로세스
| 단계 | 활동 |
|---|---|
| 도출 | 이해관계자 식별, 요구사항 도출 |
| 분석 | 기능/비기능 분석 (엔지니어 관점), 우선순위 결정, 타당성 평가 |
| 명세 | 명세 방법 선정, 기능 요구사항 명세 (양식/지침/체크리스트) |
| 검증 | 검증 기준 준비, 검증 수행 (리뷰) |
| 관리 | 변경·추적 관리 (전체 단계 지원) |
A-SPICE의 SWE.1 Software Requirements Analysis Process
The purpose of the Software Requirements Analysis Process is to transform the software related parts of the system requirements into a set of software requirements.
A-SPICE SWE.1의 8개 Base Practices:
| BP | 활동 |
|---|---|
| BP 1 | Specify software requirements (명세) |
| BP 2 | Structure software requirements (우선순위) |
| BP 3 | Analyze software requirements (분석) |
| BP 4 | Analyze the impact on the operating environment |
| BP 5 | Develop verification criteria (검증 기준) |
| BP 6 | Establish bidirectional traceability (양방향 추적성) |
| BP 7 | Ensure consistency (일관성) |
| BP 8 | Communicate agreed software requirements (소통) |
요구사항 도출: 이해관계자
| 유형 | 예시 |
|---|---|
| Global | Economic, Market, Technology, Legal & Politics, Social & Cultural |
| Competition | Competitor, Potential Customer |
| Operation | User & Customer, Pedestrians, Other Vehicles |
요구사항 분석 방법
| 방법 | 설명 | 도구 |
|---|---|---|
| 구조적 분석 | 프로세스를 도출하고, 도출된 프로세스 간 데이터 흐름을 중심으로 정의 | System Context Diagram, Data Flow Diagram |
| 객체지향 분석 | 사용자 중심의 시나리오 분석을 중심으로 정의 | Use Case Diagram |
| 운용 관점 분석 | 운용 상태/모드를 고려 | State Machine Diagram |
| 개발 대상 관점 분석 | 외부 시스템과의 인터페이스 + 입출력 데이터 (IPO 관점) | – |
요구사항 명세 방법
Formal한 정도에 따라 3단계.
| 분류 | 설명 | 예시 |
|---|---|---|
| Informal Notation | 자연어, 조직 내부 다이어그램 | EARS |
| Semiformal Notation | UML 등 모델링 언어. Informal 대비 커뮤니케이션 오류 감소 | Use-Case, DFD, Sequence, Class Diagram 등 |
| Formal Notation | 수학적 기호로 정형 표현. 시스템도 이해 가능한 가장 정형화된 표기법 | LTL |
EARS 명세 기법
Easy Approach to Requirements Syntax
[<when?> <under what conditions?>] the <system> must/must not
provide <whom> the ability to <process> <thing to be processed> <process detail>예시: 운전자가 브레이크를 누르지 않았고, 차량이 안전 거리 이내로 진입하면, 크루즈 시스템 SW는 속도를 감속해야 한다.
Semiformal — 관점별 다이어그램
| 관점 | 다이어그램 |
|---|---|
| 기능적 | Use-Case, DFD, Process Diagram (세부: Sequence, Activity, Flow Chart) |
| 구조적 | Class, Component, Deployment, ER-Diagram |
| 동적 | Sequence, State-Transition, Flow Chart |
Formal — LTL 예시
차량이 안전 거리 이내, 크루즈 모드, 운전자가 브레이크를 누르지 않았을 때 감속:
G(distance<=safedistance && ACCController==cruise && brakepedal!=Pressed)
-> !(accelerationSignal)IEEE 830 SW 요구사항 명세서 구성
- Introduction
- Overall Description
- External Interface Requirements
- Systems Features
- Other Nonfunctional Requirements
- Other Requirements
- Appendices
ISO 26262 안전 요구사항의 전개
HARA에서 시작해 단계별로 구체화되며, 마지막에 SW와 HW 영역으로 나뉜다.
예시:
- TSR: 모터 제어 시스템은 모터의 short circuit이 발생되었을 때 100ms 내에 고장을 감지해야 한다.
- SWSR: 모터 제어 시스템 SW는 Motor의 고장을 감지하기 위해 20ms 주기로 모니터링 해야 한다.
SW 안전 요구사항의 5가지 유형
| 유형 | 내용 |
|---|---|
| Fault Detection | SW 또는 컴포넌트에서 발생할 수 있는 결함을 검출하기 위해 필요한 요구사항 |
| Failure Alarm | 고장 발생 시 사용자에게 정확히 알려주는데 필요한 요구사항 |
| Safe State Transition | 고장 시 위험을 회피하기 위해 사전 정의된 안전 상태로 전환하도록 하는 요구사항 |
| Degraded Mode Operation | 즉각적인 안전 상태 전환이 불가능한 경우 제한된 기능 동작을 수행하도록 하는 요구사항 |
| Fault Tolerant Time | SW 결함에 대해 허용되는 시간 관련 요구사항 |
→ 도출 방법: HAZOP 등 위험원 분석 기법으로 기능/인터페이스 측면 위험원의 완화 대책 도출, 이 중 SW로 처리될 항목을 SWSR로 식별.
요구사항 검증
좋은 SW 요구사항의 특징 (ISO/IEC/IEEE 29148)
| 특성 | 의미 |
|---|---|
| Completeness (완전성) | 필요한 모든 정보 포함 |
| Feasible (실현 가능성) | 제한된 자원 내 구현 가능 |
| Unambiguous (명확성) | 의미 모호하지 않음 |
| Traceable (추적 가능성) | 상하위 관련 문서들과 연결됨 |
요구사항 검토 체크리스트
| 항목 | 질문 |
|---|---|
| Correct | 이해관계자 니즈가 정확히 반영되었는가? |
| Unambiguous | 단일한 의미로 해석되는가? |
| Elementary | 하나의 요구사항이 하나의 개체로 간결·명료한가? |
| Complete | 기능, 성능, 외부 인터페이스 등을 빠짐없이 포함하는가? |
| Consistent | 요구사항들 간에 충돌하는 것은 없는가? |
| Verifiable | 검증(테스트/검토/분석) 가능한 수준인가? |
| Feasible | 기술적으로 구현 가능한가? |
| Modifiable | 기존 구조와 양식을 유지하면서 쉽고 일관성 있게 변경 가능한가? |