요구사항 유형
IT위키
더 많은 작업
요구사항 유형(Requirement Types)은 요구사항을 누가, 왜, 어느 수준에서 요구하는지에 따라 비즈니스 요구사항·사용자 요구사항·기능 요구사항·비기능 요구사항·전환 요구사항 등으로 나누어 정리하는 분류 체계이다.
위거스와 비티는 요구사항 정보를 다음 열 가지로 나누고, 이들이 서로 어떤 정보의 원천이 되는지를 관계도로 보인다.[1]
| 유형 | 뜻 | 예 |
|---|---|---|
| 비즈니스 요구사항(Business requirement) | 제품을 만들거나 사는 조직의 상위 사업 목표. 왜 이 시스템을 만드는가 | 주문 처리 비용을 1년 안에 20% 줄인다 |
| 비즈니스 규칙(Business rule) | 업무의 어떤 측면을 정하거나 제약하는 정책·지침·표준·법규. 그 자체는 소프트웨어 요구사항이 아니지만 여러 요구사항의 원천이 된다 | 일정 금액 이상 환불은 관리자가 승인한다 |
| 사용자 요구사항(User requirement) | 특정 사용자 계층이 시스템으로 할 수 있어야 하는 목표·작업. 유스케이스나 사용자 스토리로 적는다 | 고객은 주문 상태를 조회할 수 있다 |
| 시스템 요구사항(System requirement) | 여러 하위 시스템(소프트웨어만, 또는 소프트웨어와 하드웨어)으로 이루어진 제품의 최상위 요구사항. 하위 시스템에 할당되며 소프트웨어 몫은 기능 요구사항이 된다 | 단말기는 카드를 읽어 승인 요청을 보낸다 |
| 기능 요구사항(Functional requirement) | 특정 조건에서 시스템이 보여야 하는 동작 → 기능 요구사항 | 주문이 확정되면 확인 메일을 보낸다 |
| 특성(Feature) | 사용자에게 가치를 주는, 논리적으로 묶인 기능 요구사항의 집합 | 주문 추적 기능 |
| 비기능 요구사항(Nonfunctional requirement) | 시스템이 가져야 할 성질이나 지켜야 할 제약 → 비기능 요구사항 | - |
| 품질 속성(Quality attribute) | 비기능 요구사항의 한 종류로, 성능·보안·가용성·사용성 같은 서비스·성능 특성 | 조회 응답은 2초 이내 |
| 외부 인터페이스 요구사항(External interface requirement) | 시스템과 사용자, 다른 소프트웨어, 하드웨어 장치 사이의 연결에 대한 기술 | 결제대행사 API 로 승인 결과를 받는다 |
| 제약사항(Constraint) | 개발자가 제품을 설계·구현할 때 고를 수 있는 선택지에 가해지는 제한 | 전자정부 표준프레임워크와 Java 로 개발한다 |
- 비즈니스 요구사항이 사용자 요구사항의 근거가 되고, 사용자 요구사항을 실현하려고 기능 요구사항이 나온다. 이 흐름이 비전·범위 문서 → 사용자 요구사항 문서 → 소프트웨어 요구사항 명세서(SRS)로 이어진다.
- 비즈니스 규칙은 비즈니스 요구사항, 사용자 요구사항, 기능 요구사항에 두루 영향을 준다. 예를 들어 "환불 승인" 규칙은 승인 화면과 승인 권한 확인이라는 기능을 낳는다.
- 시스템 요구사항은 하위 시스템으로 나뉘면서 소프트웨어가 맡을 기능 요구사항을 만든다.
- 품질 속성과 외부 인터페이스 요구사항도 기능 요구사항의 원천이 된다. 보안이라는 품질 속성은 로그인·권한 확인 기능으로, 외부 시스템과의 연계 요구는 전문 송수신 기능으로 구현된다.
- 제약사항은 기능 요구사항을 낳는 원천이 아니다. 제약사항은 "무엇을 하는가"를 더하지 않고, 이미 정해진 기능을 어떤 언어·플랫폼·표준·도구로 만들지 그 선택 폭을 좁힌다. 제약사항은 SRS 의 비기능 요구사항 부분에 적고 설계·구현 단계에서 지킨다.[1]
프로젝트 관리 지식체계(PMBOK 6판, 5.2 요구사항 수집)는 요구사항 문서에 담을 요구사항을 다음과 같이 나눈다. BABOK 의 분류(비즈니스·이해관계자·솔루션·전환)에 PMBOK 이 프로젝트 요구사항과 품질 요구사항을 더한 모양이다.[3][2]
| 분류 | 내용 |
|---|---|
| 비즈니스 요구사항 | 조직 전체의 상위 요구. 왜 변화를 시작했는가(목표·목적·성과) |
| 이해관계자 요구사항 | 비즈니스 요구를 이루려고 충족해야 할 이해관계자(집단)의 요구. 비즈니스와 솔루션 요구사항을 잇는다 |
| 솔루션 요구사항 | 제품·서비스·결과물이 갖추어야 할 기능과 특성. 기능 요구사항(동작과 다루는 정보)과 비기능 요구사항(신뢰성, 보안, 성능, 안전, 서비스 수준, 지원성, 보존·폐기 등)으로 나뉜다 |
| 전환 및 준비 요구사항 | 현재 상태에서 원하는 미래 상태로 옮겨 가는 동안만 필요한 일시적 역량. 데이터 전환(이전), 교육훈련, 병행 운영 등 |
| 프로젝트 요구사항 | 프로젝트가 충족해야 할 행동·활동·프로세스·조건(마일스톤 일자, 계약 의무, 제약) |
| 품질 요구사항 | 프로젝트 인도물의 완료 여부를 확인하는 조건·기준(시험, 인증, 검증 등) |
데이터 이전과 교육훈련처럼 새 시스템을 쓰기 시작할 때만 필요하고 전환이 끝나면 필요 없어지는 요구사항은 전환 요구사항이다. 시스템이 계속 갖추어야 하는 성능·보안 같은 요구는 비기능 요구사항이고, 사업 목표는 비즈니스 요구사항, 사용자 집단의 요구는 이해관계자 요구사항이다.
| 짝 | 구별 기준 |
|---|---|
| 비즈니스 요구사항 ↔ 비즈니스 규칙 | 요구사항은 이루려는 목표(왜), 규칙은 업무가 지켜야 할 정책·법규(어떻게 해야만 하는가). 규칙은 프로젝트가 끝나도 업무에 남는다 |
| 사용자 요구사항 ↔ 기능 요구사항 | 사용자가 무엇을 하려는가(작업·목표)와 시스템이 어떻게 동작하는가(입력·처리·출력) |
| 품질 속성 ↔ 제약사항 | 품질 속성은 제품이 얼마나 잘 동작해야 하는가(성능, 보안), 제약사항은 개발자의 설계·구현 선택지를 묶는 제한(언어, 플랫폼, 표준). 품질 속성은 기능을 낳을 수 있지만 제약사항은 기능을 낳지 않는다 |
| 비기능 요구사항 ↔ 전환 요구사항 | 비기능은 운영 내내 유지되는 특성, 전환은 이행 기간에만 필요한 일시적 역량 |
| 시스템 요구사항 ↔ 기능 요구사항 | 시스템 요구사항은 하드웨어를 포함한 여러 하위 시스템 수준, 기능 요구사항은 그중 소프트웨어가 맡는 동작 |
- ↑ 1.0 1.1 1.2 Karl Wiegers, Joy Beatty, 『Software Requirements』 3rd ed., Microsoft Press, 2013, 1장 The essential software requirement(표 1-1, 그림 1-1).
- ↑ 2.0 2.1 「Requirements - Infograph」, International Institute of Business Analysis(IIBA), 2021, https://www.iiba.org/contentassets/38e412c7b77d456297d953de5bf5ca61/requirement-types-infograph.pdf, 확인일: 2026-11-04.
- ↑ Project Management Institute, 『A Guide to the Project Management Body of Knowledge (PMBOK Guide)』 6th ed., 2017, 5.2.3.1 요구사항 문서(Requirements Documentation).