6. Requirment Engineering

요구사항 분석이란?

요구사항(Requirments)이란 아래의 두 가지를 합친 것을 의미한다.

소프트웨어 시스템은 무엇(What)을 제공하는가?
소프트웨어 시스템의 제약 사항은 무엇인가?

요구사항 분석은 매우 중요한 작업이다. 시스템은 요구사항을 기반으로 만들기 때문에, 요구상항보다 보다 더 나을 수 없다. 또한, 부적절한 요구사항이나 요구사항의 잘못된 이해는 프로젝트를 실패하게 하는 주요 원인이다.

따라서 우리는 요구사항을 가장 잘 만들어야 한다.

요구사항 정의가 힘든 이유

정말 여러가지 이유가 있다. 아래 나열한 것 이외에도 많을 것이다.

요구사항이라는 것 자체가 복합적이다.
요구하는 사람도 본인이 원하는 것을 모른다.
이해당사자들은 본인들의 용어로 설명하고, 그들의 지식을 기반으로 설명한다. 물론 개발자는 잘 모르는 내용들이다.
요구사항은 계속해서 변화한다.
여러 이해당사자 사이에 이해관계가 충돌할 수 있다.

바람직한 요구사항의 요소

부족해서도 안되고(Missing)
넘쳐서도 안된다(Superfluous)

정말 핵심적인 기능들에 대해서만 요구하는 것이 좋다. 예를 들어 체육관 출입시스템을 만든다고 했을 때, 고객과 개인 트레이너를 연결하는 기능은 핵심적이라고 할 수 있다. 그러나 이러한 구조를 linked list 형태로 제작해 달라는 요구는 어떤가? 상황에 따라 달라질 수 있겠지만, 반드시 들어가야만 하는 내용인가?

위의 조건 외에도 요구사항을 올바르게 전달하기 위해서는 다음의 요소들을 생각해야한다.

Unambiguous - 누구에게나 동일하게 해석되어야 한다.
Correct - 요구자가 정말로 원하는 것이어야 한다.
Complete - 부족함이 없이 모든 사항을 포함해야 한다.
Consistent - 요구사항끼리 충돌이 없어야 한다.
Feasible - 소프트웨어로 구현 가능해야 한다.
Traceable - 이후 작업에서 요구사항이 어떻게 다루어지는지 추적가능해야한다.

Requirment Engineering

이처럼 요구사항을 얻기 위해서는 많은 것을 고려해야 한다. 그렇기에 보다 체계적으로, 공학적으로 접근하기 위하여 Requirment Engineering(RE)이 등장하였다.

Untitled

RE에서는 요구사항을 유형에 따라 구분한다.

사용자 유형에 따른 구분

User requirments

→ 고객용 요구사항이다. 자연어로 서술하며, 기술적인 부분들이 많이 제거되어있다.
System requirments

→ 개발자용 요구사항이다. 기능적, 비 기능적 요구사항들이 자세하게 적혀있다.

기능에 따른 구분

기능적 요구사항(Functional requirments)

→ Input, Output 유무가 중요하다. 소프트웨어 시스템 내부 기능과 관련된다.
비기능적 요구사항(Non-Functional requirments)

→ 기능적 요구사항을 제외한 모든 요구사항들이다. 품질, 제약, 외부 조건에 관한 요구사항들을 포함한다(ex: 속도, 규모, 사용성, 안정성, 이식성 등)

요구사항 추출(Requirment Elicitation)

올바른 요구사항이 무엇인지 알았으니, 이제는 누구에게서 어떻게 요구사항을 얻을 것인지 알아보자.

요구사항을 얻을 수 있는 대상

고객
도메인 전문가(해당 분야의 지식 전문가)
이해관계자
소프트웨어 사용자(고객과 소프트웨어 사용자는 다를 수 있다)
리버스 엔지니어링

요구사항을 추출하는 방법

워크숍

→ 모든 이해 관계자가 모여서 집중적으로 요구사항을 정리하는 회의. 단기간에 요구사항 추출 과정을 마칠 수 있다.
설문조사

→ 깊이있는 요구사항 파악이 가능하며 대규모 인원의 의견을 취합할 수 있다. 그러나 질문의 전문성 문제와, 질문 수정 불가라는 단점이 있다.
문헌조사

→ 보고서, 차트같은 자료를 보면서 요구사항의 배경을 이해하는 것이다. 도메인 지식은 높아지지만, 너무 많은 내용에 요구사항과 동떨어지는 기능을 만들 수도 있다.
브레인스토밍
프로토타입 제작

→ 도메인에 관한 이해, 용이한 피드백, 알지 못했던 요구사항들, 시뮬레이션 가능성 등의 이점이 있지만, 시간과 돈이 많이 소요된다.

Use Case Diagram

요구사항을 추출했으니 이제는 어떤 모델을 사용하여 표시할 지 생각해보자. 사실 방법론에 따라서 사용하는 모델이 다르다. 구조적 방법론에서는 DFD를, 객체지향 방법론에서는 UML을 사용한다. 이에 관한 내용은 다음에 다룰 것이며, 우선은 UML의 한 종류인 Use Case Diagram에 대해 알아보자.

시스템의 사용자는 시스템을 어떻게 바라보고 있는가? 소프트웨어와 사용자간의 상호작용을 시각적으로 나타낸것이 Use Case Diagram이다.

Untitled

UCD는 구조가 단순하여 알아보기 쉽다는 특징이 있다. 그러나 해당 모델 자체로는 디테일한 부분을 표시할 수 없으므로, Use Case 명세서를 통해 세부 내용을 보충한다.

UCD의 구성

Untitled

System Scope(사각형)

→ 소프트웨어 시스템의 범위
Actor(사람모양)

→ 시스템 바깥에서 시스템과 소통하는 존재. 꼭 사람일 필요는 없다.
Use Case(타원)

→ 시스템의 한 기능
Line

→ 구성 요소간의 관계를 의미한다. 화살표는 누가 상호작용을 시작하는지를 나타낸다.

UCD에서의 관계 표현

Actor-Usecase 사이의 관계 이외에도 Usecase끼리의 관계가 존재한다.

Include relationship

은행에서 개인 확인 이후에 입출금이 가능한 것 처럼, 종속성이 있는 관계를 나타낸다. 점선 화살표로 표현.
Extend relatoinship

기존에서 확장한 관계를 나타낸다. 부모, 자식 모두 접근하여 사용이 가능하다. 점선 화살표로 표현.
Use case generalization

상속과 같은 개념이다. 실선 화살표로 표현.