정보처리기사 실기 요구사항 분석 완전 정리

---

1. 정의

1-1. 요구사항이란?

요구사항은 사용자가 시스템에 원하는 기능이나 조건이다.

쉽게 말하면 “시스템이 무엇을 해야 하는가”를 정리한 것이다.

예를 들어 게시판 시스템을 만든다고 가정한다.

사용자는 다음과 같은 내용을 원할 수 있다.

• 회원은 게시글을 작성할 수 있어야 한다.
• 회원은 자신의 게시글을 수정할 수 있어야 한다.
• 관리자는 모든 게시글을 삭제할 수 있어야 한다.
• 게시글 목록은 최신순으로 보여야 한다.
• 검색 결과는 3초 안에 표시되어야 한다.
• 비밀번호는 암호화해서 저장해야 한다.

이런 내용이 모두 요구사항이다.

1-2. 요구사항 분석이란?

요구사항 분석은 사용자의 요구사항을 수집하고, 정리하고, 모순이나 빠진 부분을 찾아내는 작업이다.

사용자는 필요한 기능을 항상 정확하게 말하지 못할 수 있다.

예를 들어 사용자가 “쓰기 편한 게시판이 필요하다”고 말할 수 있다.

하지만 “쓰기 편하다”는 표현은 사람마다 다르게 이해할 수 있다.

어떤 사람은 화면이 단순한 것을 편하다고 생각한다.

어떤 사람은 검색 기능이 좋은 것을 편하다고 생각한다.

어떤 사람은 모바일에서도 잘 보이는 것을 편하다고 생각한다.

요구사항 분석은 이런 모호한 표현을 구체적인 기능과 조건으로 바꾸는 작업이다.

1-3. 요구사항 분석을 쉽게 이해하기

요구사항 분석은 개발 전에 “정확히 무엇을 만들 것인가”를 정하는 단계다.

요구사항 분석이 제대로 되지 않으면 개발자는 잘못된 기능을 만들 수 있다.

예를 들어 사용자는 “회원만 글을 작성할 수 있어야 한다”고 생각했는데, 개발자가 비회원도 글을 작성할 수 있게 만들면 문제가 된다.

이런 문제를 막기 위해 요구사항을 정확히 분석해야 한다.

---

2. 필요한 이유

2-1. 잘못된 개발을 막기 위해 필요하다

요구사항은 개발의 출발점이다.

요구사항이 잘못되면 설계도 잘못된다.

설계가 잘못되면 구현도 잘못된다.

구현이 잘못되면 테스트와 배포에서도 문제가 생긴다.

따라서 요구사항 분석은 소프트웨어 개발 전체 품질에 큰 영향을 준다.

2-2. 사용자와 개발자의 이해 차이를 줄이기 위해 필요하다

사용자와 개발자는 같은 말을 다르게 이해할 수 있다.

예를 들어 사용자가 “빠른 검색 기능”을 요구했다고 하자.

사용자는 1초 안에 결과가 나오는 것을 원할 수 있다.

개발자는 5초 정도면 빠르다고 생각할 수 있다.

이런 차이를 줄이려면 요구사항을 구체적으로 정리해야 한다.

예를 들어 “검색 결과는 2초 이내에 표시되어야 한다”처럼 작성해야 한다.

2-3. 기능 누락을 막기 위해 필요하다

요구사항 분석을 하지 않으면 중요한 기능을 빠뜨릴 수 있다.

예를 들어 게시판을 만들 때 글 작성 기능만 생각하고 파일 첨부, 검색, 관리자 삭제, 신고 기능을 빠뜨릴 수 있다.

나중에 빠진 기능을 추가하면 시간과 비용이 더 많이 든다.

2-4. 개발 범위를 명확히 하기 위해 필요하다

개발 범위는 이번 프로젝트에서 어디까지 만들 것인지를 뜻한다.

개발 범위가 명확하지 않으면 개발 중간에 기능이 계속 추가될 수 있다.

이것을 범위 확장 또는 스코프 크리프라고 한다.

스코프 크리프는 프로젝트 범위가 통제 없이 계속 커지는 현상이다.

요구사항 분석은 개발 범위를 명확히 해서 일정과 비용을 관리하는 데 도움을 준다.

2-5. 실제 개발에서 해결하는 문제

• 사용자 요구를 잘못 이해하는 문제
• 필요한 기능을 빠뜨리는 문제
• 불필요한 기능을 만드는 문제
• 개발 중간에 요구사항이 계속 바뀌는 문제
• 기능 요구사항과 비기능 요구사항을 혼동하는 문제
• 요구사항이 모호해서 테스트 기준을 세우기 어려운 문제
• 사용자와 개발자 사이에 책임 범위가 불명확해지는 문제

---

3. 핵심 개념

3-1. 기능 요구사항

기능 요구사항은 시스템이 반드시 수행해야 하는 기능이다.

쉽게 말하면 “시스템이 해야 하는 일”이다.

게시판 시스템의 기능 요구사항 예시는 다음과 같다.

• 회원은 로그인할 수 있어야 한다.
• 회원은 게시글을 작성할 수 있어야 한다.
• 회원은 자신의 게시글을 수정할 수 있어야 한다.
• 관리자는 모든 게시글을 삭제할 수 있어야 한다.
• 사용자는 게시글을 검색할 수 있어야 한다.

기능 요구사항은 실제 기능 구현과 직접 연결된다.

3-2. 비기능 요구사항

비기능 요구사항은 기능은 아니지만 시스템이 만족해야 하는 조건이다.

쉽게 말하면 “시스템이 어떤 품질 수준을 가져야 하는가”를 정리한 것이다.

비기능 요구사항의 예시는 다음과 같다.

• 검색 결과는 3초 이내에 표시되어야 한다.
• 비밀번호는 암호화해서 저장해야 한다.
• 시스템은 하루 24시간 운영되어야 한다.
• 모바일 화면에서도 사용할 수 있어야 한다.
• 동시에 1,000명이 접속해도 정상 동작해야 한다.

비기능 요구사항은 성능, 보안, 안정성, 사용성, 접근성, 확장성 같은 품질과 관련된다.

3-3. 요구사항 도출

요구사항 도출은 사용자나 이해관계자로부터 요구사항을 찾아내는 작업이다.

이해관계자는 시스템과 관련된 사람이나 조직이다.

예를 들어 쇼핑몰 시스템의 이해관계자는 다음과 같다.

• 일반 사용자
• 관리자
• 판매자
• 배송 담당자
• 결제 담당자
• 개발자
• 운영자

요구사항 도출 방법에는 인터뷰, 설문, 워크숍, 브레인스토밍, 문서 분석, 관찰 등이 있다.

3-4. 요구사항 분석

요구사항 분석은 도출된 요구사항을 정리하고 검토하는 작업이다.

중복된 요구사항을 합친다.

서로 충돌하는 요구사항을 찾는다.

빠진 요구사항을 보완한다.

모호한 요구사항을 구체적으로 바꾼다.

우선순위를 정한다.

3-5. 요구사항 명세

요구사항 명세는 분석한 요구사항을 문서로 정리하는 작업이다.

이 문서를 요구사항 명세서라고 한다.

요구사항 명세서는 사용자, 개발자, 테스터가 모두 기준으로 삼는 문서다.

요구사항 명세서에는 기능 요구사항, 비기능 요구사항, 제약사항, 인터페이스 요구사항 등이 포함될 수 있다.

3-6. 요구사항 확인

요구사항 확인은 정리된 요구사항이 사용자의 의도와 맞는지 확인하는 작업이다.

사용자가 원하는 내용과 문서화된 요구사항이 일치하는지 검토한다.

요구사항 확인을 제대로 하지 않으면 개발 완료 후 “원한 기능이 아니다”라는 문제가 생길 수 있다.

3-7. 요구사항 검증

요구사항 검증은 요구사항이 올바른지 검사하는 작업이다.

요구사항이 명확한지, 완전한지, 일관성이 있는지, 실현 가능한지 확인한다.

검증은 요구사항의 품질을 확인하는 과정이다.

3-8. 요구사항 우선순위

요구사항 우선순위는 어떤 요구사항을 먼저 구현할지 정하는 기준이다.

모든 기능을 한 번에 만들 수 없을 때 중요하다.

우선순위가 높은 기능부터 개발하면 핵심 기능을 먼저 완성할 수 있다.

예를 들어 게시판에서는 글 작성, 글 조회, 로그인 기능이 댓글 신고 기능보다 우선순위가 높을 수 있다.

3-9. 제약사항

제약사항은 개발할 때 반드시 지켜야 하는 제한 조건이다.

예를 들면 다음이 제약사항이 될 수 있다.

• DBMS는 MySQL을 사용해야 한다.
• 개발 언어는 Java를 사용해야 한다.
• 기존 회원 데이터를 그대로 이전해야 한다.
• 반드시 사내 서버에서 운영해야 한다.
• 모바일 웹을 지원해야 한다.

제약사항은 설계와 구현 방식에 영향을 준다.

---

4. 주변 기초 개념

4-1. 이해관계자

이해관계자는 시스템 개발에 영향을 주거나 영향을 받는 사람 또는 조직이다.

사용자만 이해관계자가 아니다.

운영자, 관리자, 개발자, 고객사, 보안 담당자도 이해관계자가 될 수 있다.

4-2. 사용자

사용자는 시스템을 실제로 사용하는 사람이다.

예를 들어 게시판 시스템에서는 글을 작성하고 읽는 사람이 사용자다.

4-3. 고객

고객은 시스템 개발을 의뢰하거나 비용을 지불하는 사람 또는 조직이다.

사용자와 고객이 항상 같지는 않다.

예를 들어 회사가 직원용 시스템을 개발하면 회사는 고객이고 직원은 사용자다.

4-4. 업무 규칙

업무 규칙은 업무를 처리할 때 지켜야 하는 규칙이다.

예를 들어 “관리자만 게시글을 강제 삭제할 수 있다”는 업무 규칙이다.

업무 규칙은 요구사항으로 정리될 수 있다.

4-5. 요구사항 명세서

요구사항 명세서는 요구사항을 문서로 정리한 것이다.

개발자, 사용자, 테스터가 공통 기준으로 사용한다.

4-6. 유스케이스

유스케이스는 사용자가 시스템을 이용해 수행하는 기능이나 시나리오다.

예를 들어 “회원이 게시글을 작성한다”는 유스케이스다.

유스케이스는 요구사항을 사용자 관점에서 정리할 때 사용한다.

4-7. 액터

액터는 유스케이스에서 시스템과 상호작용하는 외부 대상이다.

예를 들어 회원, 관리자, 외부 결제 시스템이 액터가 될 수 있다.

4-8. 시나리오

시나리오는 사용자가 시스템을 사용하는 구체적인 흐름이다.

예를 들어 로그인 시나리오는 아이디 입력, 비밀번호 입력, 로그인 버튼 클릭, 인증 결과 확인 순서로 구성될 수 있다.

4-9. 요구사항 추적성

요구사항 추적성은 요구사항이 설계, 구현, 테스트와 어떻게 연결되는지 확인할 수 있는 성질이다.

예를 들어 “회원은 글을 작성할 수 있다”는 요구사항은 글 작성 화면, 글 저장 API, 글 작성 테스트 케이스와 연결되어야 한다.

4-10. 모호성

모호성은 의미가 분명하지 않은 상태다.

예를 들어 “빠르게 처리해야 한다”는 모호한 요구사항이다.

“3초 이내에 처리해야 한다”는 명확한 요구사항이다.

4-11. 일관성

일관성은 요구사항끼리 서로 충돌하지 않는 성질이다.

예를 들어 “비회원은 글을 작성할 수 없다”와 “모든 사용자는 글을 작성할 수 있다”는 서로 충돌한다.

4-12. 완전성

완전성은 필요한 요구사항이 빠짐없이 포함된 성질이다.

로그인 기능을 정의하면서 로그인 실패 처리, 비밀번호 오류 처리, 계정 잠금 정책을 빠뜨리면 완전성이 부족하다.

4-13. 검토

검토는 작성된 문서나 결과물을 확인하고 문제를 찾는 작업이다.

요구사항 명세서는 개발 전에 반드시 검토해야 한다.

---

5. 실제 흐름

5-1. 요구사항 분석 전체 흐름

요구사항 분석은 보통 다음 순서로 진행된다.

1. 이해관계자를 식별한다.
2. 요구사항을 도출한다.
3. 요구사항을 분류한다.
4. 요구사항을 분석한다.
5. 요구사항의 우선순위를 정한다.
6. 요구사항을 명세한다.
7. 요구사항을 확인한다.
8. 요구사항을 검증한다.

5-2. 1단계: 이해관계자 식별

먼저 시스템과 관련된 사람이나 조직을 찾는다.

게시판 시스템에서는 다음이 이해관계자가 될 수 있다.

• 일반 회원
• 관리자
• 운영자
• 개발자
• 보안 담당자

이해관계자를 빠뜨리면 중요한 요구사항을 놓칠 수 있다.

5-3. 2단계: 요구사항 도출

이해관계자로부터 요구사항을 수집한다.

요구사항 도출 방법에는 다음이 있다.

• 인터뷰
• 설문
• 워크숍
• 브레인스토밍
• 문서 분석
• 업무 관찰
• 프로토타입 확인

5-4. 3단계: 요구사항 분류

수집한 요구사항을 종류별로 나눈다.

대표적으로 기능 요구사항과 비기능 요구사항으로 구분한다.

• 기능 요구사항: 로그인, 게시글 작성, 검색
• 비기능 요구사항: 응답 속도, 보안, 안정성, 접근성

5-5. 4단계: 요구사항 분석

도출된 요구사항을 정리하고 문제를 찾는다.

다음 내용을 확인한다.

• 중복된 요구사항이 있는가
• 서로 충돌하는 요구사항이 있는가
• 모호한 표현이 있는가
• 빠진 기능이 있는가
• 실제로 구현 가능한가

5-6. 5단계: 우선순위 결정

모든 요구사항을 한 번에 구현하기 어려울 수 있다.

그래서 먼저 구현할 요구사항을 정한다.

핵심 업무에 필요한 기능은 우선순위가 높다.

부가 기능은 우선순위가 낮을 수 있다.

5-7. 6단계: 요구사항 명세

분석한 요구사항을 문서로 정리한다.

문서에는 요구사항 번호, 요구사항 이름, 설명, 유형, 우선순위, 검증 기준을 포함할 수 있다.

5-8. 7단계: 요구사항 확인

작성된 요구사항이 사용자의 의도와 맞는지 확인한다.

사용자나 고객과 함께 요구사항 명세서를 검토한다.

5-9. 8단계: 요구사항 검증

요구사항이 명확하고, 완전하고, 일관성 있고, 테스트 가능한지 확인한다.

검증이 끝나면 요구사항은 설계와 구현의 기준이 된다.

---

6. 예시

6-1. 게시판 시스템 요구사항 예시

시스템명: 게시판 시스템

기능 요구사항
1. 회원은 로그인할 수 있어야 한다.
2. 회원은 게시글을 작성할 수 있어야 한다.
3. 회원은 자신의 게시글을 수정할 수 있어야 한다.
4. 관리자는 모든 게시글을 삭제할 수 있어야 한다.
5. 사용자는 제목으로 게시글을 검색할 수 있어야 한다.

비기능 요구사항
1. 게시글 검색 결과는 3초 이내에 표시되어야 한다.
2. 비밀번호는 암호화해서 저장해야 한다.
3. 모바일 화면에서도 게시글을 읽을 수 있어야 한다.
4. 시스템은 하루 24시간 운영되어야 한다.

제약사항
1. DBMS는 MySQL을 사용한다.
2. 기존 회원 데이터는 유지해야 한다.
3. 관리자 권한은 기존 권한 체계를 따른다.

6-2. 요구사항 명세서 형식 예시

요구사항 ID	구분	요구사항명	설명	우선순위	검증 기준
REQ-001	기능	로그인	회원은 아이디와 비밀번호로 로그인할 수 있어야 한다.	상	정상 계정으로 로그인 성공
REQ-002	기능	게시글 작성	로그인한 회원은 게시글을 작성할 수 있어야 한다.	상	글 작성 후 목록에 표시
REQ-003	비기능	검색 성능	게시글 검색 결과는 3초 이내에 표시되어야 한다.	중	검색 응답 시간 3초 이내
REQ-004	비기능	비밀번호 보안	비밀번호는 암호화해서 저장해야 한다.	상	DB에 평문 비밀번호 저장 금지

---

7. 코드 또는 설정 설명

7-1. 예시 문서 설명

위 예시는 실제 코드가 아니라 요구사항 명세 예시다.

요구사항 분석 단계에서는 코드를 작성하지 않는다.

개발 전에 무엇을 만들어야 하는지 문서로 정리한다.

7-2. 기능 요구사항 설명

회원은 로그인할 수 있어야 한다.

이 문장은 기능 요구사항이다.

시스템이 제공해야 하는 실제 기능이기 때문이다.

회원은 게시글을 작성할 수 있어야 한다.

이 문장도 기능 요구사항이다.

게시글 작성은 사용자가 시스템에서 수행하는 기능이다.

7-3. 비기능 요구사항 설명

게시글 검색 결과는 3초 이내에 표시되어야 한다.

이 문장은 비기능 요구사항이다.

검색 기능 자체가 아니라 검색 성능 조건을 말하기 때문이다.

비밀번호는 암호화해서 저장해야 한다.

이 문장도 비기능 요구사항이다.

보안 조건에 해당하기 때문이다.

7-4. 제약사항 설명

DBMS는 MySQL을 사용한다.

이 문장은 제약사항이다.

개발자가 자유롭게 DBMS를 선택할 수 없고 MySQL을 사용해야 한다는 제한 조건이기 때문이다.

7-5. 요구사항 ID 설명

REQ-001

REQ는 Requirement의 줄임말이다.

Requirement는 요구사항을 뜻한다.

REQ-001은 첫 번째 요구사항이라는 의미로 사용할 수 있다.

요구사항 ID를 붙이면 요구사항을 추적하기 쉽다.

---

8. 주의점

8-1. 기능 요구사항과 비기능 요구사항을 구분해야 한다

기능 요구사항은 시스템이 해야 하는 기능이다.

비기능 요구사항은 시스템이 만족해야 하는 품질 조건이다.

구분	의미	예시
기능 요구사항	시스템이 제공해야 하는 기능	회원은 게시글을 작성할 수 있다.
비기능 요구사항	시스템이 만족해야 하는 조건	게시글 검색 결과는 3초 이내에 표시되어야 한다.

8-2. 모호한 표현을 쓰면 안 된다

요구사항은 명확해야 한다.

“빠르게 처리한다”는 모호하다.

“3초 이내에 처리한다”는 명확하다.

“사용하기 쉽게 만든다”도 모호하다.

“모바일 화면에서 글 작성 버튼은 화면 하단에 고정한다”처럼 구체적으로 작성해야 한다.

8-3. 요구사항끼리 충돌하면 안 된다

요구사항끼리 서로 반대되는 내용이 있으면 안 된다.

예를 들어 다음 두 요구사항은 충돌한다.

• 비회원은 게시글을 작성할 수 없다.
• 모든 사용자는 게시글을 작성할 수 있다.

이런 경우 사용자와 다시 확인해서 하나로 정리해야 한다.

8-4. 테스트할 수 없는 요구사항은 좋지 않다

요구사항은 나중에 테스트할 수 있어야 한다.

“시스템은 안정적이어야 한다”는 테스트하기 어렵다.

“시스템은 하루 24시간 중 99.9% 이상 정상 운영되어야 한다”는 테스트 기준을 만들 수 있다.

8-5. 사용자 말만 그대로 적으면 안 된다

사용자의 말은 모호할 수 있다.

요구사항 분석자는 사용자의 말을 그대로 받아 적는 것이 아니라 구체적인 요구사항으로 정리해야 한다.

예를 들어 “관리하기 쉽게 해주세요”라는 말은 다음처럼 구체화해야 한다.

• 관리자는 회원을 검색할 수 있어야 한다.
• 관리자는 회원 상태를 변경할 수 있어야 한다.
• 관리자는 게시글을 일괄 삭제할 수 있어야 한다.

8-6. 요구사항 변경을 관리해야 한다

개발 중 요구사항은 바뀔 수 있다.

하지만 변경을 아무 기준 없이 받아들이면 일정과 비용이 크게 늘어난다.

요구사항 변경이 발생하면 변경 사유, 영향 범위, 일정 변경 여부를 검토해야 한다.

8-7. 현행 시스템 분석과 요구사항 분석을 구분해야 한다

현행 시스템 분석은 현재 시스템의 상태를 파악하는 작업이다.

요구사항 분석은 새 시스템에 필요한 기능과 조건을 정리하는 작업이다.

현행 시스템 분석 결과는 요구사항 분석의 기초 자료가 될 수 있다.

---

9. 요약

요구사항은 사용자가 시스템에 원하는 기능이나 조건이다.

요구사항 분석은 사용자의 요구를 수집하고, 정리하고, 검토해서 명확한 개발 기준으로 만드는 작업이다.

요구사항은 기능 요구사항과 비기능 요구사항으로 나눌 수 있다.

기능 요구사항은 시스템이 제공해야 하는 기능이다.

비기능 요구사항은 성능, 보안, 안정성, 사용성 같은 품질 조건이다.

요구사항 분석 흐름은 이해관계자 식별, 요구사항 도출, 분류, 분석, 우선순위 결정, 명세, 확인, 검증 순서로 이해하면 된다.

요구사항은 명확하고, 완전하고, 일관성 있고, 검증 가능해야 한다.

정보처리기사 실기에서는 기능 요구사항과 비기능 요구사항의 차이, 요구사항 도출 방법, 요구사항 명세와 검증 개념을 반드시 구분해야 한다.

---

10. 핵심 용어 정리

요구사항 = 사용자가 시스템에 원하는 기능이나 조건

요구사항 분석 = 요구사항을 수집, 정리, 검토하여 명확한 개발 기준으로 만드는 작업

기능 요구사항 = 시스템이 반드시 제공해야 하는 기능

비기능 요구사항 = 성능, 보안, 안정성처럼 시스템이 만족해야 하는 품질 조건

요구사항 도출 = 이해관계자로부터 요구사항을 찾아내는 작업

요구사항 명세 = 분석한 요구사항을 문서로 정리하는 작업

요구사항 명세서 = 요구사항을 정리한 공식 문서

요구사항 확인 = 요구사항이 사용자의 의도와 맞는지 확인하는 작업

요구사항 검증 = 요구사항이 명확하고 올바른지 검사하는 작업

이해관계자 = 시스템 개발에 영향을 주거나 영향을 받는 사람 또는 조직

사용자 = 시스템을 실제로 사용하는 사람

고객 = 시스템 개발을 의뢰하거나 비용을 지불하는 사람 또는 조직

업무 규칙 = 업무를 처리할 때 지켜야 하는 규칙

유스케이스 = 사용자가 시스템을 이용해 수행하는 기능이나 시나리오

액터 = 시스템과 상호작용하는 외부 대상

시나리오 = 사용자가 시스템을 사용하는 구체적인 흐름

요구사항 추적성 = 요구사항이 설계, 구현, 테스트와 어떻게 연결되는지 확인할 수 있는 성질

모호성 = 의미가 분명하지 않은 상태

일관성 = 요구사항끼리 서로 충돌하지 않는 성질

완전성 = 필요한 요구사항이 빠짐없이 포함된 성질

제약사항 = 개발할 때 반드시 지켜야 하는 제한 조건

우선순위 = 어떤 요구사항을 먼저 구현할지 정하는 기준

스코프 크리프 = 프로젝트 범위가 통제 없이 계속 커지는 현상

인터뷰 = 이해관계자에게 직접 질문해 요구사항을 수집하는 방법

설문 = 여러 사람에게 질문지를 배포해 요구사항을 수집하는 방법

워크숍 = 여러 이해관계자가 함께 모여 요구사항을 논의하는 방법

브레인스토밍 = 자유롭게 의견을 내면서 아이디어를 도출하는 방법

문서 분석 = 기존 문서나 자료를 검토해 요구사항을 찾는 방법

업무 관찰 = 실제 업무 수행 과정을 보고 요구사항을 찾는 방법

프로토타입 = 본격 개발 전에 요구사항 확인을 위해 만드는 임시 버전