[SE] 요구 분석

[SE] 요구 분석

2022. 7. 19. 15:11ㆍMajor`/소프트웨어 공학

소프트웨어 프로젝트에서 계획이후 가장 먼저 할 일은 "소프트웨어 시스템이 가져야할 기능/성능을 분석하고 요구사항을 정리"하는 것이다

요구 분석

요구 분석이란 "사용자의 여러가지 요구에 대해서 이해하는 단계"라고 생각하면 된다

요구 분석은 간단해보이지만 소프트웨어 개발의 성패에 굉장히 큰 영향을 미치는 단계이다

요구 분석단계에서 사용자의 스토리를 제대로 이해하지 못하고 설계및 구현에 들어가게 되면 반드시 스토리와 맞지 않는 부분이 도출될 것이고 그러면 설계및 구현에서 오류에 대한 fix를 해야하는데 그 경우 오류 처리에 대한 cost가 굉장히 많이 들어가게 된다

그리고 요구 분석 단계에서는 작업에 대한 "How"가 아니라 "What"에 초점을 두어서 작업해야 한다

1. 요구에 대한 정의

요구란 시스템에 대한 "고객의 요청을 확정"한 것이다

한마디로 어떤 업무가 있고, 어떤 문제가 있고, 어떤 기능을 어떤 조건으로 제공해야 하는지를 잘 정리한 것이라고 할 수 있다

제약 사항

요구 분석 단계에서 파악해야 하는 또 다른 사항은 "제약"이다

"특정 프로그래밍 언어로 개발해주세요"
"DB는 무조건 PostgreSQL을 사용해주시고 MySQL은 절대 사용하지 말아주세요"
....

이렇게 고객의 요구사항에 "제약"이 존재한다면 소프트웨어 시스템의 해결책을 제한한다고 볼 수 있다

이러한 "제약"은 정치적/사업적인 고려에 의해서 도출되는 부분들이다

요구 분류

소프트웨어에 대한 "요구"는 크게 2가지로 나뉘게 된다 (기능 요구 & 비기능 요구)

과거의 소프트웨어는 사용자로부터 기능적 요구를 찾아내고 정확하게 기술하는 것에 초점을 맞추었다

하지만 요즘에는 소프트웨어가 보편화되면서 "신뢰성/안전성"에 대한 비기능적 요구가 늘어남에 따라 비기능 요구를 명확하게 정의하는 것이 시스템의 신뢰성 향상을 위하여 중요하다고 생각된다

(1) 기능 요구

기능 요구란 "시스템이 정확하게 무엇을 할 것인가"를 표현한다

항공권 예약 시스템
- 예약하기 위해서 시스템이 필요한 정보는 무엇?
- 어떤 업무 처리 기능이 필요?

한마디로 기능 요구는 "시스템이 외형적으로 나타내는 기능/동작"을 의미한다

현금 인출기의 기능 요구
- 잔금 조회, 계좌 이체, 현금 서비스, ...
현금 인출기의 기능 '외적' 요구
- 성능, 효율, 반응 시간, 제약 조건, ...

그리고 기능 요구는 외부 요소들간의 Interaction이라고 볼 수 있다

※ 기능 요구의 종류

IEEE 표준 830에서는 기능 요구로 다음 사항이 포함되어야 한다고 제시한다

입력의 검증
정확한 작업 순서
비정상적 상태(오버플로우, 네트워크 오류, ...)에 대한 응답 및 복구
매개변수의 유효성
입출력 관계

분류	질문	사례 (ATM)
기능	- 시스템이 무엇(What)을 하는가 - 시스템이 언제(When) 그 일을 하는가 - 시스템이 운영될 떄 여러가지 다른 모드가 있는가 - 언제 어떻게 시스템이 변경되거나 확장되는가	- 현금이나 수표를 인출/조회/입금/송금 - 24시간 - 준비 중, 유지보수 중 - 지폐나 수표가 바뀔 때
자료	- 입/출력이 무엇이며 어떤 형태를 가지는가 - 얼마나 자주 자료를 받고 내보내는가 - 자료가 얼마나 정확해야 하는가 - 시스템에 유입되는 자료의 양 - 데이터는 일정 기간 동안 보관되어야 하는가	- 현금 카드/현금/수표 - 매일 수천건 - 100% 정확 - 200byte × 수천건 - 20년
입출력	- 다른 시스템에서 유입/배출되는 입력은 무엇인가 - 데이터의 특정 형태가 있는가 - 자료 전달에 사용되는 특정 미디어가 있는가	- 계좌 정보 - 문자와 숫자 - 없음
사용자	- 누가 시스템을 사용할 것인가 - 사용자가 여러 그룹인가 - 각 사용자 그룹의 컴퓨터 사용 경험은? - 각 사용자 그룹에 따라 필요한 교육은?	- 은행 고객 3그룹(고객, 은행원, AS엔지니어) - 초보 - 행원 교육

(2) 비기능 요구

비기능 요구는 "시스템이 제공하는 기능에 직접 관련되지 않은 요구"를 의미한다

즉, 시스템에 대한 사용자의 요구를 충족시키기 위해서 "파생적"으로 필요한 요구라고 볼 수 있다

성능, 보안, 품질, 안전, ...

이러한 비기능 요구는 요구분석 이후에 설계 단계에서 언어/플랫폼/구현의 선택을 다르게 할 수 있다

※ 비기능 요구의 종류

외부 인터페이스
메모리 제약
성능 요구
사용자의 특성과 가정
설치 환경의 적합성

분류	질문	사례(ATM)
성능	- 시스템의 속도, 반응시간, 처리율 - 시스템에 의해서 처리되는 자료의 크기	- 10초, 10건/시간 - 200MB/일
품질	- 신뢰성, 가용성, 유지 보수성 등 품질 특성에 대한 요구 - 시스템이 결함을 찾아내고 격리시켜야 하나 - 시스템 가동되는 평균 시간 - 시스템의 작업이 중단된 후 다시 복구될 때까지 허용되는 시간 - 얼마나 쉽게 위치나 플랫폼을 변동할 수 있는가	- 결함 발견 즉시 가동 중지 및 격리 - 99%의 가동률 - 복구 허용 시간 = 1시간 - 플랫폼 변경시 작업일 1 이내 완성
안전	- 계좌 도용 인출 방지책은? - 화재/홍수/도난 등의 재난을 대비한 방지책은?	- IC칩 사용 - 불연재, 화재경보기, 도난 방지기
보안	- 자료와 시스템에 대한 접근이 통제되어야 하는가? - 사용자들 사이에 타인의 데이터 또는 프로그램 접근 방지 방법은? - 시스템의 백업 기간 및 책임자는 누구인가? - 물리적 보안 대책은 무엇인가?	- 시스템 접근 권한 부여 - 담당자 지정제 - 카드키 및 지문인식
사용성	- 사용자 인터페이스 방법은? - 메뉴의 언어는? - 사용자 오류를 최소화 하는 방안은?	- 터치스크린 - 한글 및 영문 - 음성 안내

요구 대상에 의한 분류

요구는 또 요구하는 대상에 따라 요구의 종류를 나눌 수 있다

(1) 비즈니스 요구

소프트웨어 적용 업무 사례로부터 획득하는 요구사항

잔액 조회
계좌 이체

(2) 아키텍처 및 설계 요구

비즈니스 요구보다는 더 상세한 요구사항으로 구현에 필요한 전체적인 설계와 관련된 요구 사항

▶ 고객이 인터넷 뱅킹에 로그인하고 자동이체를 사용하는 방법을 설명

고객은 등록된 자동이체 대시 보드를 볼 수 있다
청구 세부 정보를 추가/수정/삭제할 수 있다
고객은 CMS를 구성하고 다양한 이체 작업에 대한 문자 알림을 전 휴대폰으로 보낼 수 있다. 또한 과거 지급된 자동이체의 목록을 볼 수 있다

(3) 시스템 및 통합 요구

개발자가 코딩하는데 필요한 아주 상세한 요구사항이다

유틸리티 제공자 이름
관계/고객 번호
자동 결제 - YES/NO
전체 청구서 지급 - YES/NO
자동 지급 한도 - 청구 금액이 지정된 금액을 초과하는 경우 지급하지 않는다

2. 요구 추출

개발하려고 하는 시스템에 대한 사용자의 기대/요구를 추출해낸다

요구에 대한 정보 출처 파악
요구에 대한 정보 취합
요구와 제한 사항 정리

(1) 요구에 대한 정보 출처 파악

일단 요구 추출은 가장 먼저 사용자에게 누가 시스템과 관련되어 있는지 또한 시스템의 범위가 어디까지인지 물어보고 정보 출처를 결정하는 것으로 시작된다

어떤 데이터가 어디서 어디로 전달되는지...
어떤 과정을 거쳐서 데이터가 변경되는지...

(2) 요구에 대한 정보 취합

그리고 소프트웨어 응용 분야에 대한 정보를 모으는 일이 필요하다

비즈니스 목표, 현재 업무 상황, 정책, 법령과 표준, ...

결국 요구를 추출하는 방법은 굉장히 여러가지이고 각 방법마다 요구의 범위와 효율이 다르다

고객의 발표
문헌, 양식 조사
인터뷰
설문
브레인스토밍 회의
관찰과 작업 분석
프로토타이핑
...

3. 요구 분석 및 정의

1단계에서 찾아낸 기대/요구를 소프트웨어 관계자와 합의할 수 있는 형태로 정의한다

도출된 요구 후보들은 명확하고 완전한지, 모호하지 않은지, 모순이 있는지 분석하고 결정하여 "최종 요구로 확정"한다

(1) 요구 품질

요구를 분석할때는 요구사항이 다음과 같은 성질을 가지고 있는지 분석하여야 한다

성질	설명
원자적 (Atomic)	요구 사항이 복합된 목적이 아니라 단일 목적을 가지는 성질
완전성 (Complete)	요구 사항 안에 정의된 것이 정보의 모든 것을 포함한 것
비모호성 (Unambiguous) & 통일성 (Consistent)	명확하지 않은 것을 기술하거나 같은 내용을 다르게 언급하지 않는 성질
추적성 (Traceable)	요구 사항을 쉽게 추적할 수 있도록 고유번호를 매김
우선순위화 (Prioritize)	요구 사항의 중요도를 파악할 수 있는 성질
테스트 가능성 (Testable)	요구 사항이 검증 가능하도록 기술되어 있는 성질

(2) 도메인 분석

"도메인"이란 요구의 배경을 의미한다

소프트웨어를 구축할 때는 어떤 문제가 있고 그 문제를 해결하기 위해서 무엇이 요구되는지 알아야 한다

도메인을 분석하는 이유는 대표적으로 "설계 모델링에 필요한 여러 개념과 비즈니스 규칙을 파악"하기 위해서이다

▶ 도메인 개념 찾기

도메인 개념이란 {도메인 목적, 구조, 객체, 프로세스, 사람, 규칙, ..}과 같은 것들이다

프로세스 초기에는 정확한 개념을 세우기 위해서 "용어를 정확하게 정의"하는 것이 굉장히 중요하다

제품이 출시된 이후에 변경하려면 굉장한 노력과 시간이 들기 때문에

▶ 도메인 사전 작성

도메인 사전이란 "시스템과 관련된 도메인 개념을 조직화"한 것이다

사전을 꾸미기 위해서는 요구/인터뷰/매뉴얼/... 등의 모든 정보를 모아야 한다

▶ 비즈니스 규칙 정리

비즈니스 규칙이란 업무에서 지키기로 정한 규정이다

운영 가이드라인, 규정, 절차, 표준의 집합

※ Example) 의료 정보 시스템 도메인 분석

1. 도메인 개념 파악

- 예약

- 접수

- 진료와 검사

- 입원

- 퇴원

2. 도메인 사전 작성

명칭	타입	설명
예약	프로세스	- 환자가 의료 서비스를 받는 일정 - 예약 담당 직원에 의해 처리
예약	객체	- 환제엑 의료 서비스를 제공하기 위하여 약속된 날짜/시간
예약 담당 직원	역할	- 환자를 위해 예약
의료 서비스	객체	- 의료진이 환자에게 제고아는 의학적 서비스의 총칭 : 진료/처방/조제/검사
의료 서비스	기능	의료진이 환자에게 의학적 서비스를 제공하는 행위
예약	프로세스	- 의료 서비스를 제공하기 이전에 이루어진다 - 프로세스는 새로 오는 환자 또는 기존 환자의 개인 정보와 보험 정보를 수집한다 - 이 과정에서 병원 진료 카드가 발급된다 - 예약 담당 직원이 수행
예약 담당 직원	역할	- 예약을 실시

3. 비즈니스 규칙

ID	정의	타입	소스
001	환자는 질병으로부터 고통받는 사람이며 의사나 응급실, 다른 의료기관에서 진료를 의뢰받는다	사실	도메인 사전
002	19세 이하의 환자는 보호자나 응급 센터와 동행하여야 한다	제약	병원 정책
003	예약할때는 환자에 대한 다음 정보가 보관되어야 한다 {ID ; 데이터} → 004-01 : 이름 → 004-02 : 주소 → 004-03 : 전화번호1 → 004-04 : 전화번호2 → 004-05 : 주민등록번호 → 004-06 : 의료카드ID	제약	도메인 전문가와의 인터뷰
005	접수 직원은 환자의 개인 정보를 입력/수정하고 필요에 따라 의료카드를 발행	사실	도메인 사전
006	의료비 청구가 30일 이내에 수납되지 않으면 연체료를 물린다	유추	병원 정책

(3) 시나리오 기반 분석

소프트웨어를 개발하는 현장에는 개발자/사용자/고객/... 등 다양한 사람들이 참여하여 다양한 용어및 개념을 전달해서 요구를 도출한다

여기서 개발자와 일반 사용자간에는 용어에 따른 커뮤니케이션 이슈가 발생할 수 있다

>> 이러한 문제의 원인은 서로 다른 전문 영역의 용어에 대한 이해와 해석에 있다

이러한 장벽을 해소할 수 있는 방법은 "시나리오 기반"이다

보통 시나리오를 쓸 때는 5W1H로 표현하면 효과적이다

5W : When, Where, Who, What, Why
1H : How

그리고 시나리오를 작성할 때는 대표적으로 문장으로 작성하지만 이외에도 {스토리보드, 만화, 음성, 동영상, ..}등의 형식으로도 작성할 수 있다

4. 유스케이스

앞서 설명한 "도메인"의 개념은 시스템을 모델링하기 위한 개념적 프레임워크를 제공한다

도메인 분석 자체는 모델을 만드는게 아닌, 모델링을 위한 개념이라고 이해하면 된다

>> 여기서 도메인 분석 ↔ 모델링 사이에 연결되는 작업이 "유스케이스를 찾아내는 일"이라고 한다

유스케이스 모델링은 시스템의 동작을 모형화하는 것이다

유스케이스는 다음 4가지 요소가 결합된 것으로 각 요소의 의미와 관계를 잘 이해해야 한다

액터
시스템 범위
유스케이스
관계

(1) 유스케이스 다이어그램

유스케이스 다이어그램은 시스템의 기능을 나타내기 위해서 사용자의 요구를 추출하고 분석하는데 사용하는 그림이다

주로 외부에서 보는 시스템의 동작에 초점을 맞춰서 그린다

유스케이스 다이어그램은 크게 유스케이스/액터로 구성된다

유스케이스 : 액터에게 보이는 시스템의 기능
액터 : 시스템과 상호작용하는 것

※ 액터

액터는 위의 사진에서 사람 모형을 나타내고 시스템 외부에 존재하는 요소이다

따라서 액터는 시스템의 여러가지 기능을 외부에서 접근하는 객체라고 볼 수 있다

유스케이스 모델링의 첫 단계는 바로 "액터를 찾는 일"이다

※ 유스케이스

유스케이스란 시스템이 실행하는 일련의 동작으로 특정 액터에게 관찰 가능한 실행 결과를 제공한다

타원으로 표시되는 유스케이스는 "시스템의 단위 기능"을 의미한다

(2) 유스케이스 명세

유스케이스는 결국 대상 시스템이 제공해야 하는 서비스를 시간이 경과되는 순서로 정렬하여 기술한 것이다.

시나리오가 시작될 때 외부 시스템이나 사용자가 기대하는 것
시나리오에서 일어나는 사건에 대한 기본 흐름
문제가 발생되는 비정상적인 사건에 대한 대안 흐름
동시에 병행으로 일어나는 다른 활동에 대한 정보
시나리오가 종료되었을 때 시스템의 상태에 대한 정보

시스템 제목	수강 신청 시스템
유스케이스 이름	수강 신청
액터	학생
시작 조건	학생이 재학 중이고 로그인 되어 있어야 한다
기본 흐름	1. 학생이 수강신청을 선택 2. 시스템이 일정표 양식을 디스플레이 3. 시스템이 강좌 목록에서 수강 가능한 강의 리스트를 검색 4. 학생이 강의 리스트에서 꼭 수강하려는 4개의 강좌와 2개의 대인 강좌를 선택한다. 선택이 완료되면 제출버튼을 누른다 5. 선택된 각 강좌가 일정표에 추가된다 6. 시스템이 일정표를 저장한ㄷ
대안 흐름	3A 1. 시스템이 강조 목록을 접근할 수 없다면 일정한 횟수로 반복 시도하고 그래도 불가능하면 오류 메시지를 디스플레이한다 2. 학생이 오류 메시지를 인식하고 유스케이스를 마친다
종료 조건	수강 신청된 강좌가 스케줄로 저장된다

(3) 유스케이스간의 관계

일반적으로 이벤트 흐름의 일부를 "분리 추출"해서 따로 설명해주면 기본 이벤트 흐름의 가독성을 높이고 유스케이스 모델의 구조를 개선시킬 수 있다

▶ 대안 흐름

기존 유스케이스에서 이벤트의 흐름이 약간 변형되거나 선택 또는 예외인 경우 대안 흐름으로 분리한다

▶ 포함 관계

다른 유스케이스에서 재사용할 수 있도록 캡슐화하려는 경우 포함 관계로 명시한다

포함관계는 다음 2가지 경우에 사용한다

유스케이스의 기본 목적을 이해하는 데 꼭 필요하지 않은 이벤트 묶음을 분리할 때
2개 이상의 유스케이스에 공통적인 요소를 분리할 때

▶ 확장 관계

기존 유스케이스에서 묵시적으로 포함된 이벤트로써, 기존 유스케이스의 기존 이벤트 흐름이 특정 조건에 만족되었을 때 분리 확장된 것이다

확장 관계를 사용하는 목적은 다음과 같다

유스케이스의 일부가 선택적으로 수행되는 동작임을 나타낸다. 확장 관계를 이용하여 선택적 동작을 필수 동작과 분리할 때 사용
서브플로우가 어떤 조건이 만족되었을 때만 실행됨을 표시할 때 사용
기본 유스케이스의 확장 포인트에 하나 또는 여러 개의 동작 세그먼트가 삽입될 수 있음을 보여줄 때 사용한다. 삽입되는 동작 세그먼트의 순서는 기본 유스케이스 실행 중 액터와의 상호 작용에 따라 달라진다

5. 요구 명세

앞서 분석한 요구사항을 "모두 빠짐없이 명확하게 작성"하는 것을 명세라고 한다

합의한 정의가 고객과 사용자가 만족할만한 정의인지 확인하고 필요에 따라 수정한다

명세한 문서를 SRS(Software Requirement Specification)이라고 하고 IEEE 830은 SRS가 기술해야 하는 내용과 형식을 표준으로 권고하고 있다

SRS에는 대상 시스템이 어떻게(How) 수행되어야 하는지가 아닌, 무엇(What)을 수행할 것인가에 대해서 기술한다

시스템이 이루어야 할 목표를 기술하는 것이지, 목표를 달성하기 위한 해결 방법은 기술하지 않는다

목차	소항목
1. 소개	1.1 SRS의 목적 1.2 제품의 범위 1.3 정의/동의어/약어 1.4 참조문서 1.5 개요
2. 일반적인 기술사항	2.1 제품의 개관 2.2 제품의 성능 2.3 사용자 특성 2.4 제약사항 2.5 가정 및 의존성
3. 상세한 요구사항	3.1 외부 인터페이스 3.2 기능요구 3.3 성능요구 3.4 논리 DB 요구 3.5 설계 제약사항 3.6 소프트웨어 시스템 속성 3.7 상세요구 사양의 구성
부록
색인

6. 요구 검증

사용자 요구가 요구사항 명세서에 올바르게 기술되었는지 검토하는 활동을 요구 검증이라고 한다

여기서 문제를 발견하지 못하고 추후에 구현 중에 결함을 발견하게 된다면 수정 비용이 꽤 많이 들게 된다

SRS에 기술한 요구를 검증할 때 체크하는 내용은 다음과 같다

요구사항이 사용자나 고객의 목적을 완전하게 포함하고 있는가?
요구사항 명세가 문서 표준을 따르고, 설계 단계의 기초로 적합한가?
요구사항 명세의 내부에 기술된 내용과 일치하고 완벽한가?
기술된 요구사항이 참여자의 기대와 일치하는가?

검증 사항	설명
이해용이성 (Comprehensibility)	요구 명세서를 읽을 때 요구의 의미를 잘 이해할 수 있는가?
중복 (Redundancy)	필요없이 중복된 부분이 없는가?
완전성 (Completeness)	빠진 요구가 없는지, 요구를 기술하는데 빠진 정보가 없는가?
일관성 (Consistency)	요구사항이 서로 모순되지 않는가?
모호성 (Ambiguity)	요구분석의 내용이 모호함 없이 모든 참여자들에 의해 명확하게 이해될 수 있는가?
검증 가능성 (Verifiable)	요구분석 명세서에 기술된 내용이 사용자의 요구를 만족하는가? 개발된 시스템이 요구사항 분석 내용과 일치하는지를 검증할 수 있는가?
추적 가능성 (Traceable)	시스템 요구사항과 시스템 설계문서 및 구현과 매핑되어 추적할 수 있는가?

저작자표시 변경금지

Coding