[SW Architect] 요구 공학

mandu·2025년 6월 9일

SW Architect

[SW Architect]

목록 보기

2/10

1. 요구공학(Requirements Engineering, RE)

소프트웨어 시스템의 목적과 사용 맥락을 정의하고, 문서화하고, 관리하는 구조화된 활동 집합
사용자의 실제 요구와 소프트웨어 기술을 연결하는 다리 역할

1.1 요구공학이 필요한 이유

요구공학에 소요된 비용 비율 vs 프로젝트 초과 비용(% Overrun)
→ 요구공학에 충분히 투자하지 않으면 프로젝트는 예산과 일정 모두에서 큰 손실을 입게 됨.

Why?

요구사항 정리 및 구조화 X → 기능 미흡 → 재작업 비용 증가 → 테스트/검증 지연
오해/커뮤니케이션 오류

→ 반면, 초기 요구 정의에 충분한 비용을 할당하면 전체 프로젝트의 효율성과 성공률이 현저히 향상됨.

2. 요구공학 주요 프로세스

2.1. 요구사항 추출 (Requirements Elicitation)

이해관계자 인터뷰, 워크숍, 브레인스토밍, 역할극 등 다양한 기법 사용
명확하지 않은 문제를 정의하고 요구를 탐색

2.2. 요구사항 분석 (Requirements Analysis)

유스케이스 모델링, 품질 속성 시나리오(QAS), 목표 분석 수행
기능적 / 비기능적 요구사항 분류 및 구조화

Spiral한 요구사항 추출 & 분석 과정

Requirements Discovery (요구사항 발견)
이해관계자(고객, 사용자 등)와의 인터뷰, 회의, 관찰 등을 통해 요구사항을 처음으로 식별하는 단계.
이때 도메인 고유의 제약이나 규칙(도메인 요구사항)도 함께 도출됨
Requirements Classification and Organization (분류 및 조직화)
발견된 요구들을 관련성 있는 그룹으로 묶고, 일관성 있게 구조화.
이 과정을 통해 중복 제거, 명확성 향상, 분석 용이성 확보
Requirements Prioritization and Negotiation (우선순위 결정 및 조정)
요구사항 간의 중요도 또는 실행 순서를 평가하고 이해관계자 간 상충되는 요구사항을 조율하여 합의 도출
Requirements Documentation (요구사항 문서화)
최종적으로 정제된 요구사항들을 명확하고 일관되게 문서화.
이후 단계(분석, 설계 등)를 위한 입력 자료로 활용

2.3. 요구사항 명세 (Requirements Specification)

문서화된 요구사항 → Software Requirements Specification(SRS)
'무엇을'에 중점, '어떻게'는 설계의 몫

2.4. 요구사항 검증 (Requirements Validation)

리뷰, 프로토타입, 테스트케이스 기반 확인
Validation(요구 반영) vs. Verification(정확한 구현)

2.5. 요구사항 관리 (Requirements Management)

변경 요청 추적 및 통제, 요구사항 간 추적성 관리
수직 / 수평 추적성 확보

수직 추적성 (Vertical Traceability)
상위 요구사항에서 하위 요구사항, 설계, 코드, 테스트 등으로 이어지는 관계를 추적하는 개념
e.g. 상위 요구사항 → 세부 요구사항 → 설계 → 코드 → 테스트 사례

수평 추적성 (Horizontal Traceability)
같은 수준의 항목들 간의 관계를 추적하는 개념
e.g. 요구사항 A ↔ 요구사항 B, 또는 기능 A ↔ 기능 B

3. DeepDive: 요구사항 추출

이해관계자와의 상호작용을 통해 시스템의 기능을 파악하고, 이를 점진적으로 구조화하여 명확히 정의해 나가는 반복적인 과정

3.1 요구사항 추출 시 따져봐야 할 것들

요구사항 추출은 단순히 기능을 묻는 것이 아니라, 해결해야 할 문제(problem)와 기회(opportunity)를 명확히 정의하는 것에서 시작된다.

문제 또는 기회를 정의할 때 묻는 질문들:

무슨 문제를 해결해야 하는가?
→ 문제의 범위 식별 (Problem Boundaries)
문제는 어디에 있는가?
→ 도메인과 맥락 이해 (Context / Problem Domain)
누구의 문제인가?
→ 이해관계자 식별 (Stakeholders)
왜 이 문제를 해결해야 하는가?
→ 이해관계자의 목표 파악 (Goals)
소프트웨어가 어떻게 도움이 될 수 있는가?
→ 시나리오 수집 (Scenarios)
언제까지 해결해야 하는가?
→ 개발 제약 조건 확인 (Schedule 등)
무엇이 해결을 방해할 수 있는가?
→ 실현 가능성, 위험요소 식별 (Feasibility and Risk)

3.2 요구사항 추출 시 현실적인 어려움

요구사항은 명확하지 않고, 다음과 같은 현실적 복잡성이 존재한다:

고객(이해관계자)은 자신이 정확히 무엇을 원하는지 모름
요구를 각자 용어로 설명함
→ 오해 발생
이해관계자 간 요구 충돌이 있음
새로운 이해관계자가 나중에 등장하거나, 환경이 바뀜
→ 요구사항이 지속적으로 변경됨 🤢

Tip: Product Champion(Key Man)을 찾고 팀 내외의 적극적인 지원을 받아라!

Product Champion(Key Man): 특정프로세스 또는 제품이 완전히 개발되고 판매되는 것을 보는 데 과도한 관심(inordinate interest)을 갖는 사람

3.3 요구사항 추출 전략

상황	특징	추천 기법
Fuzzy Problem	양쪽 모두 경험 부족 → 요구가 모호함	워크숍, 브레인스토밍, 스토리보드
Catch Up	고객은 잘 아는데 개발자는 익숙하지 않음	롤플레잉, 인터뷰, 요구사항 리뷰
Selling / Teaching	개발자는 잘 아는데 고객은 모름	유스케이스, 비즈니스 모델링
Mature	양쪽 모두 숙련된 상태	설문지, 프로토타이핑

3.4 요구사항 추출 예시

Volitile한 요구사항과 Stable한 요구사항을 분리해야 한다!! by annotation
→ 추후 변경 사항을 최소화 할 수 있음
SW Architect는 건축에서 용어들을 많이 가져옴
- 하지만! 다른 점은 SW는 비가시성임
- 초반에 Requirment가 많이 안 나오고, GUI가 씌워지면서부터 좀 관심을 가지게 됨
  → 그래서 프로토타이핑이 중요함!!! 혹은 하드코딩이든, 애니메이션이든..

요구사항 추출은 단순한 인터뷰가 아니라, 불명확하고 모순된 의견 속에서 진짜 문제와 목표를 밝혀내는 탐색적 과정이다.

4. DeepDive: 요구사항 분석

4.1 요구사항 유형

기능적 요구사항 (FR, Functional Requirements)

시스템이 무엇을 해야 하는지 정의함
사용자의 입력에 대한 시스템의 행동과 반응
특정 상황에서의 동작 명세
e.g.
- 사용자는 모든 클리닉의 예약 목록을 조회할 수 있어야 한다.
- 시스템은 매일 각 클리닉의 방문 예정 환자 명단을 생성해야 한다.
- 각 직원은 고유한 8자리 직원번호로 식별되어야 한다. (→ 사용자 인증 관련)

비기능적 요구사항 (NFR, Non-functional Requirements)

시스템이 수행하는 단순 기능보다는 전체적인 하드웨어와 소프트웨어 설계의 제약 또는 디자인적인 요소에 관한 요구사항
성능, 보안, 확장성, 사용성, 안정성 등과 관련된 요구사항을 포함하며, 시스템의 품질 속성을 정의하는 데 중요한 역할
Often called Quality Attributes or Quality Requirements
일반적으로 측정이 어렵고, 명확히 정의되기 힘듦 → 하지만 꼭 measure가 가능한 형태로 정의 必
e.g.
- 응답 시간은 2초 이내여야 한다.
- 하루 평균 가동률 99.99% 이상이어야 한다.
종종 "-ility" 형태로 표현됨 (Usability, Reliability, Availability 등)

도메인 요구사항 (Domain Requirements)

시스템이 적용될 특정 도메인의 규칙 및 제약사항
주로 코드 상 if문에 걸리면 다 Domain requirements (domain dependent)
주로 이 요구 사항이 충족이 안 되어서 Product가 실패하는 경우가 많았기 때문에 독립적인 범주로 구분
도메인의 특성을 반영하며, 기능적/비기능적으로 분류 가능
예시:
- 병원 진료 예약 시스템의 법적 보안 요건
- 금융 시스템의 거래 보존 기간 규정

4.2 FR vs NFR

구분	Functional Requirements (기능적 요구사항)	Non-functional Requirements (비기능적 요구사항)
정의	내/외부 자극에 대한 시스템의 동작(Behavior)을 기술	시스템이 구현되었을 때 기대되는 수준(level)을 기술
검증 방법	PASS 또는 FAIL로 구현 여부를 명확히 판단 가능	품질 속성별로 정량적 기준(range)을 명시하고 만족 여부를 측정
적용 범위	특정 기능 단위에 국한됨	시스템 전체에 적용됨
책임 주체	개발자(Developer)가 구현 담당	설계자(Architect)가 구현 책임
변경 영향	기능 변경은 일부 컴포넌트에 국한된 영향	변경 시 시스템 전체 구조(architecture)에 영향 가능
시스템 성공 판단	기능 구현은 1차 목표이나, 시스템의 성패를 결정짓지 않음 비슷한 시스템들끼리는 FR이 거의 비슷하기 때문	보통 시장에서 성공을 결정짓는 요소는 NFR 구현된 비기능 요구 수준에 따라 시스템 성공/실패가 결정됨

초기 결정된 NFR이 개발하다보니 FR로 들어갈 수도 있다.
즉, FR과 NFR이 서로 다른 Track으로 완전히 구분되진 않는다.

4.3 비기능 요구사항의 상세 유형 (Ian Sommerville 분류)

Product Requirements: 성능, 신뢰성 등 제품 자체의 속성
- e.g. 실행 속도, 신뢰성 등
Organizational Requirements: 조직의 정책/규정에 따른 요구
- e.g. 개발 프로세스 표준, 구현 방식에 대한 요구사항 등
External Requirements: 법률, 표준, 외부 시스템과의 상호운용성 등
- e.g. 시스템 간 호환성 요구사항, 법적 요구사항 등

4.4 (Old) FR 분석 기법: Structured analysis

Divide and Conquer approach → 한번에 전체를 설계하고 모듈 별로 구현
각 모듈 단위별로 완성시키는 데에 시간이 오래 걸리고 추후 integration 단계에서 굉장히 번거로움

Data Flow Diagram (DFD)
State Transition Diagram (STD)
Entity-Relation Diagram (ERD)

4.5 (State-Of-The-Art) FR 분석 기법: Use Case analysis

독립적인 Use Case 단위로 기능별 릴리즈 및 피드백 가능 → Incrementally development

Use Case Model (UC)

Use Case Model 정의

시스템이 수행하는 일련의 동작 시퀀스를 정의하며,
이 동작은 행위자(Actor)에게 가시적인 가치 있는 결과를 제공함

A use case defines a sequence of actions
performed by a system
that yields an observable result of value
to an actor.

독립성을 강조! action들의 선후관계를 고려하지 않는다.

Actor
시스템 외부에 있는 존재로, 시스템과 상호작용하는 사용자 또는 다른 시스템

한 명의 사용자가 여러 역할(Actor)을 수행할 수도 있음
Active Actor: Invoker (Actor → Use Case)
Passive Actor: Reciver (Actor ← Use Case)
Association Navigability == interaction invocatation의 방향
어떤 시스템을 Actor로 식별한다는 것은 그 시스템이 프로젝트 외부에 존재하는 객체, 즉 Out-of-Scope임을 의미함
반대로, 개발 범위에 포함된다면 이는 System 내부 요소로 간주되며 Actor가 아님

Use Case Model 예시

Diagram → Outline → Detail 순으로 작성!

Detail

<Use Case Name>
1. Brief Description
2. Basic Flow of Events
3. Alternative Flows of Events)
4. Special Requirements
5. Preconditions / Postconditions
6. Extension Points
7. Relationships*
8. Use-Case Diagrams
9. Other Diagrams/Enclosures

e.g.

💳 Use Case: 현금 인출하기 (Withdraw Cash)

Brief Description
사용자가 ATM을 통해 본인의 계좌에서 지정된 금액을 현금으로 인출하는 기능이다.

Basic Flow of Events

사용자가 카드를 ATM에 삽입하면, 시스템은 PIN 입력 화면을 출력한다.

사용자가 PIN을 입력하면, 시스템은 입력된 PIN의 유효성을 확인한다. (AF1)

사용자가 올바른 PIN을 입력하면, 시스템은 기능 선택 메뉴를 출력한다.

사용자가 '현금 인출' 메뉴를 선택하면, 시스템은 출금 금액 입력 화면을 출력한다.

사용자가 출금 금액을 입력하고 확인 버튼을 누르면, 시스템은 계좌 잔액을 확인한다. (AF2)

사용자의 잔액이 충분하면, 시스템은 지정된 금액의 현금을 인출한다. (AF3)

시스템은 영수증 출력 여부를 묻는 화면을 출력한다.

사용자가 응답하면, 시스템은 해당 요청을 처리한 후 카드를 반환한다.

본 유스케이스를 종료한다.

Alternative Flows of Events
Condition(조건), Start(분기점), Actions(행동), Resume(복귀 지점)이 필요함

AF1. PIN 입력 오류 (3회 초과)

Start: Basic Flow 2

Actions: 시스템은 "PIN이 3회 연속 틀렸습니다. 카드를 회수합니다."라는 메시지를 출력한 뒤, 카드를 회수한다.

Resume: 본 유스케이스를 종료한다.

AF2. 입력된 출금 금액이 계좌 잔액을 초과함

Start: Basic Flow 5

Actions: 시스템은 "잔액이 부족합니다. 다른 금액을 입력하세요."라는 메시지를 출력한다.

Resume: Basic Flow 4로 되돌아간다.

AF3. 현금 투입구 장애 발생

Start: Basic Flow 6

Actions: 시스템은 "현금 인출이 불가합니다. 거래를 취소합니다."라는 메시지를 출력한다.

Resume: 본 유스케이스를 종료한다.

Special Requirements

출금은 10,000원 단위로만 가능

각 출금 거래는 최대 1,000,000원까지 제한

시스템 응답시간은 5초 이내

Preconditions

사용자가 유효한 ATM 카드와 PIN을 보유하고 있어야 함

Postconditions

출금이 성공하면 계좌 잔액이 차감되고 거래 로그가 저장됨

사용자의 카드가 반환됨

Extension Points

OTP 인증 절차 (일정 금액 이상 출금 시)

Relationships

Include: PIN 검증

Extend: OTP 인증, 거래 이력 저장

Use-Case Diagram
[사용자] ---> (현금 인출)
                  ^
                  |
            <<include>> (PIN 검증)
                  |
            <<extend>> (OTP 인증)

Basic Flow of Events에서 "~~하면 Step 2로 돌아간다"도 가능함
보통 CRUD는 하나의 Use case 시나리오로 잡음
어떤 도구(e.g. DB)를 사용했는지와 같은 매우 구체적인 HOW는 적지 않되, 어떤 작업을 어떻게 하는지 정도는 적어줘야 한다

Use case 분석 시 주의해야할 점

Functional Decomposition 증상을 피하라!

Order-relationship among use cases
Very small use cases
Too many use cases
Uses cases with no result of value
Names with low-level operations
- “Operation” + “object”
- “Function” + “data”
- Example: “Insert Card”
Difficulty on understanding the overall mode

유스케이스는 행위자와 시스템 간의 상호작용을 통해 가치 있는 결과가 생성되는 일련의 흐름을 표현

4.6 (State-Of-The-Art) NFR 분석 기법: Architectural trade-off analysis

시스템의 품질을 정량적으로 측정하거나 테스트할 수 있는 특성(Attribute)들을 시나리오 형식으로 작성한 것으로, Quality Attribute는 Non-Functional Requirements와 같은 의미
trade-off analysis라고 불리는 이유는 품질 속성들이 서로 충돌하거나 경쟁 관계에 있기 때문에,
소프트웨어 아키텍트가 트레이드오프(절충)를 고민하면서 의사결정해야 하기 때문

Quality Attribute Scenario(QAS)

특성 유형 정리

매우 많은 Requirements taxonomy가 있지만,
결국 모든 Requirements를 빠짐없이 식별하고자 만든 것
서로 다른 taxonomy 체계가 왜 다른 지에 집착할 필요는 없음
→ ISO 25010 분류 체계 사용하자
Ref: https://www.iso25000.co
이 특성들은 시스템이 이해관계자의 요구를 얼마나 잘 만족시키는지를 판단하는 기준이 됨

QAS 작성 방법

Response Measure 같은 경우 측정 가능하고 검증 가능하게 적어야 함
- 일반 가정집 환경, 정상적으로 인지하여 << 이런 문장 xx
- 테스터들이 이 QAS를 보고 테스트한다고 생각
Availability, Performance 속성을 적을 때 사용 가능한 지표
- P99 latency
- 전체 시간을 윈도우 단위로 쪼갠 뒤, 전체 시간 및 윈도우 내에서 가용성 체크

e.g.

QAS 1: 모빌리티 예약 시스템을 사용하는 일반 사용자, 기업 고객, 관리자 등이
실시간 운영 환경(정상 또는 일부 장애 포함)에서 시스템에 접속을 시도할 때,
UI, 서버 애플리케이션, DB, 인증 시스템 등 전체 구성요소는 요청을
정상 처리하여 예약 기능을 응답해야 하며, 시스템은 연간 기준으로
99.9% 이상의 가용성을 유지해야 하며, UI 상 응답 시간은 3초 이내이다.

품질 속성 도출 기법
QAW(Quality Attribute Workshop), 혹은 약식으로 Mini-QAW를 진행한다.

QAW: 아키텍처 설계 이전 단계에서 품질 속성 요구사항을 조기에 식별하고,
이해관계자의 의견을 바탕으로 정량적 시나리오로 정제하여
설계의 기준점으로 삼는 워크숍 방식의 기법
보통 Raw QAS → QAS → QA Tree 순으로 작성

5. DeepDive: 요구사항 명세

elicitation, analysis 한 거 다 정리해서 하나의 문서로
Software Requirements Specification(SRS) 작성
SRS는 시스템 개발자에게 공식적으로 전달되는 요구사항 문서
설계 문서가 아님! → 무엇(What)을 해야 하는지를 설명하며, 어떻게(How) 할지는 다루지 않음
즉, Desgins에 대한 내용이 담기면 안 됨

5.1 SRS의 목적

목적	설명
의사소통 수단	시스템과 도메인을 이해관계자와 공유하기 위한 도구
계약적 역할	법적 구속력이 있을 수 있음 (고객과 개발자 간 약속)
검증/테스트 기준	납품된 시스템이 요구사항을 만족하는지 검토 가능
변경 관리 기준	변경 요청 시 기준이 되는 베이스라인 역할

5.2 SRS의 주요 구성 요소

Requirement analysis에서 했던 내용 모두 합치면 됨

기능(Functionality)
- 소프트웨어가 무엇을 해야 하는지 명시
외부 인터페이스(External Interfaces)
- 사용자, 하드웨어, 다른 소프트웨어와의 상호작용 방식
- 외부 시스템에 대한 전제 조건도 포함
성능 요구사항(Required Performance)
- 응답 속도, 가용성, 회복 시간 등 속도나 안정성 관련
품질 속성(Quality Attributes)
- 이식성, 정확성, 유지보수성, 보안성 등 비기능 요구사항
설계 제약사항(Design Constraints)
- 적용 표준, 구현 언어, 데이터베이스 정책, 자원 제한, 운영 환경 등

5.3 SRS 작성 방법

집단 특성에 맞게 SRS 작성 방법을 정하면 됨

Natural languages
Structured specifications
Form-based specifications
Tabular specifications

6. DeepDive: 요구사항 검증

우리가 정의한 요구사항이 고객이 실제로 원하는 것인지를 확인하는 것
즉, "우리가 올바른 소프트웨어를 만들고 있는가?"를 검증(Validation)

6.1 검증 항목

항목	설명
유효성(Validity)	시스템이 고객의 니즈를 잘 반영한 기능을 제공하는가?
정확성(Correctness)	이 요구사항들이 진짜 목표를 달성하는 데 적절한가?
일관성(Consistency)	서로 충돌하는 요구사항은 없는가?
완전성(Completeness)	고객이 요구한 모든 기능이 포함되어 있는가?
실현 가능성(Feasibility)	예산과 기술로 구현 가능한가?
검증 가능성(Verifiability)	테스트나 리뷰를 통해 확인할 수 있는가?

6.2 검증 항목

방법	설명
요구사항 리뷰	수작업으로 요구사항 문서를 체계적으로 분석
프로토타이핑	실행 가능한 시스템 모델을 통해 요구사항을 테스트
테스트 케이스 생성	요구사항에 대한 테스트 항목을 만들어 검증 가능성 확인

6.3 Validation vs Verification (검증 vs 확인)

구분	Validation (검증)	Verification (확인)
의미	소프트웨어가 사용자의 실제 요구를 충족하는가?	소프트웨어가 명세서(SRS)를 충족하는가?
질문	- 우리가 올바른 소프트웨어를 만들고 있는가? - 설계/구현/납품된 시스템이 사용자 기대에 부합하는가?	- 우리가 소프트웨어를 올바르게 만들고 있는가? - 문제 정의가 정확하고 이해관계자의 요구를 모두 반영했는가?

7. DeepDive: 요구사항 관리

소프트웨어 개발 및 요구공학(RE) 과정 중에 발생하는 요구사항 변경을 체계적으로 처리하는 활동
요구사항은 항상 불완전하거나 모순적일 수 있으며,
개발 중에도 비즈니스 변화나 시스템 이해의 향상에 따라 새로운 요구가 계속 생김

7.1 변경 관리의 핵심 개념: 추적성(Traceability)

처음 Needs부터 만들어진 산출물을 계속 이어서 trace 하는 것
출처(Source) ↔ 요구사항(Requirements) ↔ 설계(Design) ↔ 코드(Code)

Horizontal Traceability Link & Vertical Traceability Link
이 Link로 Change Impact를 산출할 수 있고, 고객의 Change Request를 Reject 할 수도 있음

7.2 요구사항 추적의 어려움

개발자들한테 코딩 말고 다른 거 하라고 하면 당연히 저항이 있음

항목	설명
비용 문제	자동화 도구 부족, 완전한 추적성 구현은 비용과 시간이 많이 듦
지연된 보상	추적성 작업자는 즉각적인 혜택을 보지 못함 (개발자는 작성, V\&V 팀은 활용)
규모와 다양성	문서, 도구, 책임이 다양하고 통합된 분류 체계가 부족
현실적 한계	실제로는 베이스라인 요구사항 중심으로 제한적 추적이 이뤄짐

mandu

만두는 목말라

이전 포스트

[SW Architect] Associate Architect 과정 학습 내용

다음 포스트

[SW Architect] 요구 공학

[SW Architect]

1. 요구공학(Requirements Engineering, RE)

1.1 요구공학이 필요한 이유

2. 요구공학 주요 프로세스

2.1. 요구사항 추출 (Requirements Elicitation)

2.2. 요구사항 분석 (Requirements Analysis)

Spiral한 요구사항 추출 & 분석 과정

2.3. 요구사항 명세 (Requirements Specification)

2.4. 요구사항 검증 (Requirements Validation)

2.5. 요구사항 관리 (Requirements Management)

3. DeepDive: 요구사항 추출

3.1 요구사항 추출 시 따져봐야 할 것들

3.2 요구사항 추출 시 현실적인 어려움

3.3 요구사항 추출 전략

3.4 요구사항 추출 예시

4. DeepDive: 요구사항 분석

4.1 요구사항 유형

4.2 FR vs NFR

4.3 비기능 요구사항의 상세 유형 (Ian Sommerville 분류)

4.4 (Old) FR 분석 기법: Structured analysis

4.5 (State-Of-The-Art) FR 분석 기법: Use Case analysis

Detail

e.g.

4.6 (State-Of-The-Art) NFR 분석 기법: Architectural trade-off analysis

e.g.

5. DeepDive: 요구사항 명세

5.1 SRS의 목적

5.2 SRS의 주요 구성 요소

5.3 SRS 작성 방법

6. DeepDive: 요구사항 검증

6.1 검증 항목

6.2 검증 항목

6.3 Validation vs Verification (검증 vs 확인)

7. DeepDive: 요구사항 관리

7.1 변경 관리의 핵심 개념: 추적성(Traceability)

7.2 요구사항 추적의 어려움

[SW Architect] Associate Architect 과정 학습 내용

[SW Architect] Software Development Life Cycle(SDLC)

0개의 댓글