Lecture 06: 요구분석 - 1

경희대학교 김정욱 교수님의 소프트웨어 공학 수업을 기반으로 정리한 글입니다.

소프트웨어 요구(Requirements)란?

요구

• 시스템이 무엇을 해야 하는지, 어떤 특성을 가져야 하는지를 기술한 것
• 어떻게(How)가 아니라 무엇을(What)
• 솔루션이 아니라 문제를

▶ 분석 vs 설계

 

즉, 구축할 것이 뭔지를 나타낸 것이다.

 

요구분석의 목적

• 이해(Understanding): 소프트웨어가 무엇을 위하여 필요한지 정확히 이해
• 전달(Communicating): 이해한 것을 다른 개발자에게 정확히 전달
• 컨트롤(Control): 시스템이 명세에 맞도록 제품 개발을 컨트롤

요구분석

소프트웨어 개발에서의 요구분석

사용자를 직접 만나는 단계로,

의뢰자(사용자)가 현행 시스템의 입출력 화면, 문제점, 산출물, 새로운 요구사항 등을 분석가에게 전달함으로써 대화가 시작된다.

 

요구분석 단계의 목표

• 사용자가 원하는 것을 파악
• 개발할 소프트웨어의 목표를 확립
• 분석 결과를 '요구분석 명세서'로 만들어 내는 것

 

소프트웨어 개발 생명 주기에서의 요구분석

사용자가 잠재적 또는 명시적으로 원하는 요구를 파악한 후, 소프트웨어에 반영할 사용자 요구를 결정하는 것을 의미한다.

 

요구분석을 하는 이유는 '요구분석 명세서'를 작성하기 위함이다.

이때, '요구분석 명세서'는 요구분석 단계에서 생성되는 최종 산출물로, 시스템의 기능이 무엇인지(what)에만 초점을 둔다.

요구분석의 중요성

요구분석의 중요성

1. 의사소통시간 절약

사용자가 원하는 것을 모르는 상태에서 설계, 구현을 하면 시간이 길어질 수 밖에 없는데,

요구분석은 참여자들로 하여금 개발될 소프트웨어 제품을 전체적으로 파악하게 하여 시간을 절약하게 한다.

 

2. 다음 단계의 기초

상세한 요구사항은 다음 단계의 좋은 가이드라인이 된다.

▶ 요구분석의 중요성 - 다음 단계의 기초

요구분석의 어려움

1. 문제 영역에 대한 분석가의 이해 부족

분석가는 IT 분야를 전공한 사람으로, 의뢰를 받은 문제 영역 (ex) 회계 분야, 금융 분야)에 전문성이 없는 경우가 많다.

이럴 경우 ,사용자 요구를 잘못 이해한 채 분석해 필수 요구사항을 빠뜨릴 수 있다.

 

따라서, 문제 영역과 관련된 프로젝트를 개발한 경험이 많은 분석가를 투입해야 한다.

 

2. 사용자와 분석가의 의사소통 문제

소프트웨어 개발에서는 견본(샘플)이 없는 경우가 대부분이므로, 사용자가 분석가에게 요구사항을 설명하기가 어렵다.

때문에 필요한 요구사항은 반영하지 못하고 불필요한 사항만 포함되기도 한다.

 

3. 사용자의 계속되는 요구사항 추가

상황에 따라 새로운 요구사항이 추가될 수 있다.

 

요구사항 변경으로 인한 피해 최소화 방법

• 요구분석 이후 단계인 설계에 들어가기 전에 요구사항 확정
• 이후에는 사용자와 개발자 등 개발 참여자의 동의를 받아 변경
• 애자일 방법론은 계속된 변화를 전제로 만들어지므로, 폭포수 모델보다 변경 사항에 더욱 안정적으로 대응할 수 있음

요구사항 종류

요구사항 분류

1. 기능적 요구사항 (Functional Requirements)

• 사용자가 원하는 기능 (소프트웨어가 제공하는 기능)
• 소프트웨어가 가져야 하는 기능적 속성

2. 비기능적 요구사항 (Non-functional Requirements)

• 소프트웨어가 가져야 하는 성능, 사용의 용이성, 안정성과 같은 행위적 특성
• 운용(신뢰도, 보안성, 제약사항), 성능(응답 시간, 처리량), 융통성 등이 해당 함
• 비기능 요구사항이 중요한 소프트웨어에는 군사 무기, 의료 장비 (오차에 민감) 등이 있음

ex) 비기능적 요구사항 - 개발할 모바일 소프트웨어는 안드로이드/iOS에서 모두 동작

 

※ 제약사항: 개발 소프트웨어가 수행될 환경에 의한 조건

 

※ 기능적 요구사항은 요구분석시 Use case diagram에 반영되고, 비기능적 요구사항은 설계에 반영된다.

 

기능적 요구사항 vs. 비기능적 요구사항

Example 1

▶ 기능적 요구 vs 비기능적 요구

 

Example 2

1. 기능적 요구

• (입력) 항공편, 탑승객, 예약 입력
• (출력) 티켓과 리포트에 어떤 정보가 표시될 것인가
• (컴퓨팅) 요금 계산 방법

2. 비기능적 요구

• 자주 탑승하는 고객을 서비스하기 위하여 시스템을 확장할 수 있도록 설계
• 시스템은 언제나 사용할 수 있어야 하지만, 일주일에 단 2시간만 다운을 허용

3. 요구가 아닌 것

• 항공편을 출발 시간으로 정렬할 때 Merge Sort 알고리즘을 이용 (What이 아니라 How, 즉 설계, 구현 시 필요한 것)

Example 3

▶ 기능적 요구사항 vs 비기능적 요구사항

요구분석의 절차

요구분석 절차

▶ 요구분석 절차

 

※ 요구분석, 설계 등 각 단계는 모두 검증이 필요하다.

(1) 요구사항 도출

요구를 효과적으로 추출하고 분석하는 체계화된 기술들

• 관찰
• 설문 (인터뷰)
• 브레인스토밍
• 프로토타이핑
• 유스케이스 분석

▶ 요구를 효과적으로 추출하고 분석하는 체계화된 기술들 (정리)

1. 관찰

잠재적인 사용자들이 수행하는 일을 관찰한다.

ex) 비디오 촬영을 통해 모바일 게임을 하는 고객이 어떤 부분에 집중하는지 관찰

 

하지만 시간이 많이 소요된다는 단점이 있다.

2. 인터뷰

가능한 많은 당사자와 인터뷰하여야 하고, 미리 잘 계획하여야 많은 정보를 얻을 수 있다.

또한, 관련자 이외의 다른 사람도 인터뷰하여야 한다.

ex) 경쟁 제품의 사용자, 마케팅 담당자 등

 

이 역시, 여유 시간을 할애해야 한다는 단점이 있다.

3. 브레인스토밍

아이디어를 낼 목적으로 여러 명으로부터 정보를 얻기 위한 회의로,

훈련된 요원이 중재하며, 토론보다는 각각의 사람들이 아이디어를 쏟아 놓는 회의이다.

4. 프로토타이핑

프로토타입이란 최종 시스템의 예상 기능 중 일부를 빠르게 구현한 프로그램이다. (가시적인 결과)

모의이기 때문에 다른 시스템과의 상호작용은 불가능하다. (인풋, 아웃풋 개념만 존재)

 

ex) 모의 사용자 인터페이스

5. 유스케이스 (Use case) 분석 (가장 많이 사용)

개발한 소프트웨어를 가지고 사용자가 무엇을 할 수 있는지를 분석하는 체계적인 방법으로,

시스템의 외부 관점에서 시스템이 어떻게 보이는지를 한눈에 보여주는 방법이다.

 

이때, 시스템을 사용할 수 있는 사용자의 부류(actor)를 결정해야 하며,

액터가 시스템을 사용할 필요가 있는 작업을 결정해야 한다. (관계)

 

이때, 액터와 연결되지 않는, 즉 필요없는 Use case는 지워버리면 된다.

 

이렇게 요구사항 도출을 한 후, Use case diagram(사용 사례 다이어그램)을 '(2) 요구사항 분석' 단계에서 그리면 된다.

▶ Use case diagram 예시

 

자연어 vs 유스케이스

1) 자연어

도구나 기술을 따로 익힐 필요가 없다는 장점이 있지만,

표현이 길어지고, 해석이 달라질 수 있고, 검증이 어렵다는 단점이 있다.

 

2) 유스케이스 다이어그램

모호한 표현이 없어 일관되게 모델링 하는 것이 가능하여 개발자 간 원활한 의사소통이 가능하며,

여러 시각으로 볼 수 있고, 사용자 요구사항 검증이 가능하다.

▶  자연어 vs 유스케이스