기술사 학습노트 | imt-log

기술사 학습노트 › 소프트웨어공학 › 요구공학

SW Engineering · 한장정리

[기술사토픽] 요구공학 완벽 정리 - 한장정리

요구사항 유형(기능/비기능), 도출·분석·명세·검증 4단계 프로세스, 요구사항 관리와 추적성 기법까지 기술사 빈출 주제를 완벽 정리합니다.

요구공학요구사항분석SRS유스케이스요구사항추적정보관리기술사

Ⅰ.소프트웨어 품질의 출발점, 요구공학의 개요

개념: 요구공학(Requirements Engineering)이란 이해관계자의 요구를 체계적으로 수집·분석·명세·검증하여 소프트웨어가 해결해야 할 문제를 정확히 정의하는 공학적 활동입니다.

중요성: 요구사항 오류는 개발 초기 수정 비용 대비 유지보수 단계에서 100배 이상의 비용이 발생합니다. 소프트웨어 프로젝트 실패의 가장 큰 원인이 불명확한 요구사항입니다.

가. 요구사항 유형 분류

유형	개념	예시
기능적 요구사항 (Functional)	시스템이 무엇을 해야 하는가에 관한 요구사항. 시스템의 기능과 동작 정의.	"사용자는 아이디와 비밀번호로 로그인할 수 있어야 한다"
비기능적 요구사항 (Non-Functional)	시스템이 얼마나 잘 해야 하는가에 관한 품질 속성.	"로그인 응답 시간은 2초 이내여야 한다" "99.9% 가용성 보장"
도메인 요구사항 (Domain)	특정 도메인의 관례·법규·표준에서 유래한 요구사항.	"의료 시스템은 HIPAA 규정을 준수해야 한다"

나. 비기능적 요구사항 세부 분류 (품질 속성)

속성	설명	측정 지표
성능(Performance)	응답 속도·처리량	응답시간, TPS
가용성(Availability)	서비스 지속 운영	업타임 %, MTTR, MTBF
보안(Security)	인가·인증·무결성	취약점 수, 침해 시간
유지보수성(Maintainability)	변경 용이성	결함 수정 시간
이식성(Portability)	다른 환경 이전 능력	플랫폼 지원 수
확장성(Scalability)	부하 증가 대응	최대 동시 사용자 수

Ⅱ.요구공학 4단계 프로세스

① 요구사항 도출	인터뷰·설문·워크샵·프로토타이핑·유스케이스·JAD로 요구 수집
↓
② 요구사항 분석	충돌·중복·모호성 제거. 우선순위 부여(MoSCoW). 실현 가능성 검토
↓
③ 요구사항 명세	SRS(소프트웨어 요구사항 명세서) 작성. IEEE 830 표준 준수
↓
④ 요구사항 검증	요구사항 리뷰·인스펙션·프로토타이핑으로 완전성·일관성·추적성 확인

시험 포인트

요구공학 4단계: 도·분·명·검 (도출→분석→명세→검증) 암기!
SRS 품질 기준(IEEE): 완전성·일관성·추적성·수정가능성·검증가능성

Ⅲ.요구사항 도출 기법 & 관리

가. 주요 도출 기법 비교

기법	방법	장점	단점
인터뷰	이해관계자와 1:1 또는 그룹 대화	심층 정보 수집	시간 많이 소요
유스케이스	사용자-시스템 상호작용 시나리오	기능 요구 시각화	비기능 요구 표현 한계
프로토타이핑	시제품으로 피드백 수집	요구 구체화·확인	완성품 오인 위험
JAD 워크샵	이해관계자 합동 세션	빠른 합의·충돌 해결	진행자 전문성 필요
설문조사	다수 사용자 의견 수집	광범위 수집 가능	심층 분석 어려움

나. 요구사항 우선순위 — MoSCoW 기법

분류	의미	처리 방침
Must Have	반드시 있어야 하는 핵심 요구사항	이번 릴리스에 필수 구현
Should Have	중요하지만 없어도 시스템 동작 가능	가능하면 이번 릴리스에 포함
Could Have	있으면 좋은 선택적 기능	여력이 있으면 구현
Won't Have	이번 릴리스에 포함하지 않음	향후 버전으로 이연

Ⅳ.결론 및 전문가 의견

결론

요구공학은 소프트웨어 품질의 근원적 출발점입니다.
향후 AI 기반 자동 요구사항 추출, 자연어 처리(NLP) 요구사항 분석, 모델 기반 요구공학(MBSE)으로 발전하며 복잡한 시스템 개발의 핵심 역량이 되고 있습니다.

"요구사항이 잘못되면 완벽하게 잘못된 시스템을 만든다. 올바른 것을 만들기 전에 무엇이 올바른지를 먼저 알아야 한다."

블로그: 기술사 학습노트 · imt-log.tistory.com

← 소프트웨어공학 목록