오래된 SW 엔지니어의 평생 공부

개요

 

 

 

이와 같은 비유처럼 고객의 요구 사항을 잘 이해하기 위해서 요구 사항 분석(Requirement Analysis)가 Software Engineering의 주요 부분을 차지하고 있다. Architecture Design에서도 이에 필요한 요구 사항 분석을 이야기 한다.

 

요구 사항 분석(Requirement Analysis)

 

이전 글에서도 살펴보았듯이, Architecture Design에서는 기능 요구 사항(Functional Requirement), 품질 요구 사항(Quality Attribute)와 제약 조건(Constraint)를 요구 사항으로 나눌 수 있다[2]. 여기서는 Functional Requirement에 대해서 자세히 살펴 본다.

 

 

Use Case Diagram

Functional Requirement는 Software System이 제공해야 하는 요구 사항으로 크게는 Use Case Diagram으로 표시 될 수 있다. 아래 그림은 [3]에서 예로 보여주는 Use Case Diagram으로 Software System의 경계(Boundary)와 개별 Use Case를 보여 준다.

Structured Language Specification

일반적인 언어로는 요구 사항을 설명하면, 일반적인 언의의 특징 상 모호성이 증가한다. 그렇기 때문에 이를 줄이기 위해서 Structured Format을 많이 사용한다. 대표적인 예로는 IEEE 830 SRS가 있다. 여기에는 아래와 같은 표[4]로서 요구 사항에 정리해야 하는 항목들을 가지고 있어 이에 따로 요구사항의 모호성을 줄일 수 있다.

상기 내용들이 항상 필요한 것은 아니지만, 위와 같이 기술해야 하는 항목을 요구 사항별로 설명할 수 있다. 다른 형태로는 [5] 아래와 같은 표도 가능하다.

위와 같이 구조화된 양식에 요구 사항을 기술하는 방식으로 자연어(Natural Language)로만 기술하는 것 보다는 모호성을 줄일 수 있는 효과가 있다.

결론

여기서는 기능적 요구 사항에 대해서 분석하였다. 이는 Use Case로 표시 되기도 하고 상세 내용은 Structured Language Specification으로 기술 될 수 있다. 이렇게 하는 이유는 고객 혹은 다른 Stakeholder들이 가지고 있는 요구 사항이 모호하기 때문에 이를 좀 더 명확하게 하기 위한 목적이 있다. 

요구 사항에는 이 뿐 아니라, 품질에 대한 요구 사항(Quality Attribute)들도 중요하다. Quality Attribute들은 Stake Holder들에게서 주어질 수도 있고 Business Goal과 연계될 수도 있다. 이는 Architecture Design을 수행하면서 혹은 추가 혹은 우선 순위가 바뀔 수 있다. 이와 같은 요구 사항들을 가지고 Architecture Design이 수행 될 수 있다는 것은 다른 글로 설명하였다. 

References