Software Architecture: 요구 사항은 어떻게 추출하는가?

 

개요

Software System을 구현할 경우에 돈을 지불하는 고객(Customer)과 혹은 실재 사용하는 사용자(User)와 같은 요구 사항을 정의 하는 이해 관계자(Stakeholder)가 원하는 것(요구사항 Requirement)을 파악하는 것은 쉽지 않다. 이를 잘 설명해 주는 유명한 그림[1]이 있다. 아래 그림에서 실제 Software의 모습은 고객/사용자가 실재로 필요로 하는 것으로 하단 오른쪽에서 3번째 모습이다. 하지만, 이해 관계자가 이해하는 모습도 다르다는 것도 알수 있다. 특히, 상단의 가장 왼쪽 그림은 고객이 요구 사항을 잘 설명하지 못하는 것을 보여 주는 그림이다. 특히 이는 고객이 Software System에 대해서 잘 모르거나, System이 세상에 존재하지 않는 경우도 이에 해당할 수 있다.

 

 

 

 

이와 같은 비유처럼 고객의 요구 사항을 잘 이해하기 위해서 요구 사항 분석(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]로서 요구 사항에 정리해야 하는 항목들을 가지고 있어 이에 따로 요구사항의 모호성을 줄일 수 있다.

 

Function	요구 사항이 수행하는 기능. Use Case의 이름이 될 수 있다.
Description	요구 사항/Use Case에 대한 설명
Inputs	요구 사항의 입력
Source	입력을 주는 소스
Outputs	결과물
Destination	출력물의 수신처
Requires	요구 사항이 가지는 Dependency를 표시
Pre-condition	선행 조건을 설명
Post-condition	후행 조건을 설명
Side effects	부수적인 효과

 

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

 

Number-Title	요구사항/Use Case 이름
Description	설명
Inputs	입력
Processing	동작
Outputs	결과
Pre-condition	선행 조건
Post-condition	후행 조건

 

 

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

 

결론

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

 

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

 

References

[1] The Project Cartoon, http://www.projectcartoon.com/

[2] Len Bass, et. al., "Software Architecture in Practice, Third Edition," Addison Wisely, 2012

[3] Rick Kazman, et. al., "Designing Software Architectures: A Practical Approach," Addison Wisely, May 2016

[4] Writing Requirements, https://www.cs.odu.edu/~tkennedy/cs350/sum15/Public/reqts/index.html

[5] Requirements Engineering — Requirements Specification (Part 3), https://medium.com/omarelgabrys-blog/requirements-engineering-elicitation-analysis-part-5-2dd9cffafae8