[소프트웨어공학] - 5주차 : 요구분석 (2)

요구사항 분석 - 유스케이스 다이어그램

: 유스케이스 다이어그램은 시스템 개발자와 고객 간의 요구를 이해하기 위한 도구로, 전체 기능을 파악하고 대략적인 계획을 수립하는 데 도움을 준다. 사용자의 예외적인 요구사항도 파악할 수 있어, 이를 개발자에게 명확히 전달할 수 있다.

 

: 유스케이스 다이어그램은 시스템이 사용자에게 제공하는 서비스 단위를 중심으로 구성된다. 사용자가 시스템과 어떻게 상호작용하는지를 다이얼로그 형태로 모델링하며, 이를 통해 시스템의 기능을 직관적으로 표현할 수 있다. 설계 과정에서 유용하게 활용되며, 개발자와 고객(또는 이해관계자) 간의 요구사항에 대한 공통된 이해를 형성하는 계약서 역할을 한다.

 

: 유스케이스 다이어그램은 비기능적 요구사항을 도출하는 데는 적합하지 않다. 또한 시스템의 전체적인 흐름을 나타내는 흐름도(flowchart)가 아니며, 시스템이 어떻게 동작하는지를 설명하기보다는, 무엇을 수행하는지를 중심으로 표현한다.

 

 

요구사항 분석 - 유스케이스 다이어그램 - 용어

: '시스템'이란 만들고자 하는 프로그램의 이름이고, 유스케이스를 둘러싼 사각형 틀의 안쪽 상단에 시스템 명칭을 기재한다. '액터'란 시스템의 외부에서 시스템을 사용하는 사람을 뜻한다. 액터는 두 종류가 있는데, 주요 액터는 시스템을 사용하는, 즉 행동을 하는 사람이고, 시스템 액터는 해당 프로그램의 개발 범위에는 속하지 않지만, 해당 프로그램과 서로 연동되는 또다른 시스템인 것이다. '유스케이스'란 시스템의 요구사항으로, 사용자가 시스템을 통해 사용하고 싶은 기능, 즉 사용자가 시스템을 통해 사용하고 싶은 기능이다. 유스케이스로 도출되지 않은 것은 시스템의 개발 범위에 포함할 수 없으므로, 유스케이스 도출 시 시스템 내 필요한 기능을 모두 도출해야 한다.

 

: '관계'는 액터와 유스케이스 간의 의미 있는 관계를 뜻한다. (1) 연관 관계는 실선으로 표시하며, 액터와 유스케이스 사이의 관계를 표현할 때 사용한다. 액터는 정보를 요구하거나 통보받으며, 유스케이스는 정보를 제공한다. (2) 포함 관계는 두 유스케이스 간 의존성을 표시하며, 게시글 작성/게시글 투표를 할 때 로그인이 반드시 수행되어야 하는 것처럼, 하나의 유스케이스를 수행할 때, 포함된 유스케이스가 반드시 수행되는 것을 표현할 때 사용한다. 여러 유스케이스에 나타난 공통적인 이벤트 흐름을 별도의 유스케이스로 표현하여 중복을 방지한다. 예를 들어, 게시글 작성에도 로그인이 필요하고, 댓글 작성에도 로그인이 필요하다면, 로그인 유스케이스를 각각 만들 필요없이 하나의 로그인 유스케이스만 만들고 이를 포함시키면 된다. (3) 확장 관계는 포함 관계 (Include)처럼 여러 유스케이스에 걸쳐 중복적으로 사용되지 않고 특정 조건에서 한 유스케이스로만 확장되는 것을 뜻한다. 즉, 한 유스케이스에서 추가되거나 확장된 기능을 표현한다. (4) 일반화 관계는 액터와 액터 간 혹은 유스케이스와 유스케이스 간의 관계를 표현한다. 특정 유스케이스들이 한 유스케이스의 특수화된 유스케이스라는 것을 의미하는 것이다. 

 

 

요구사항 분석 - 유스케이스 다이어그램 - 작성법

: (1) 구성요소 정의로, 유스케이스 다이어그램을 이루는 시스템, 액터, 유스케이스를 정의한다. (2) 관계 정의로, 액터와 액터 사이의 관계 정의 (일반화관계), 액터와 유스케이스 사이의 관계 정의 (연관관계), 유스케이스와 유스케이스 사이의 관계 정의 (포함관계, 확장관계)를 한다. (3) 유스케이스 구조화로, 두 개 이상의 유스케이스 간 공통된 서비스를 추출해 일반화 (일반화 관계)한다. 

 

: 액터를 찾기 위한 질문은, 누가 정보를 제공하고, 사용하고, 삭제하는가? 누가 또는 어떤 조직에서 개발될 시스템을 사용할 것인가? 누가 요구사항에 대해 관심을 가지고, 시스템이 만든 결과에 관심이 있는가? 개발될 시스템과 상호작용하는 하드웨어나 소프트웨어 시스템은 무엇인가? 등이 있다. 유스케이스를 찾기 위한 질문에는 액터가 원하는 시스템 제공 기능은 무엇인가? 액터는 시스템에 어떤 정보를 생성, 수정, 조회, 삭제하고 싶어 하는가? 시스템이 어떤 기능을 제공하면 액터의 일상 작업이 편리해지는가? 모든 요구사항들을 만족할 수 있도록 유스케이스가 식별되었는가? 등이 있다.

 

 

요구사항 분석 - 유스케이스 다이어그램 - 예시

 

 

요구사항 분석 - 유스케이스 다이어그램 - 점검사항

: 유스케이스 간에는 연관 관계를 정의할 수 없으며, 잘못된 유스케이스가 없는지 점검한다. 즉, 유스케이스는 시스템을 사용하는 입장에서 작성되어야 하며, DB 관리, 웹서버 관리 등은 관리자에게 필요한 기능이다. 유스케이스는 시스템 자체의 기능적으로 필요한 것들만 작성한다.

 

 

요구사항 분석 - 요구사항 문서화

: 요구분석 명세서(SRS)를 작성하며, 이는 분석한 요구사항을 모두 빠짐없이 작성한 문서이다. SRS를 작성할 때에는 사용자가 쉽게 읽고 이해할 수 있도록, 개발자가 설계와 코딩에 효과적으로 사용할 수 있도록, 테스트 기준으로 사용할 수 있도록, 다시 말해 품질과 제약사항 등 비기능 요구사항을 등을 정량적으로 명확히 작성해야 한다. 

 

 

요구사항 분석 - 요구사항 검증

: 요구분석 명세서가 정확하고 안전하게 서술되었는지 검토하는 활동으로, 사용자의 요구사항이 완전하게 서술되었는지 검증한다. 또한, 요구분석 명세서가 설계 단계에 사용하기에 적합한지 확인한다. 검증하는 요소로는 (1) 완전성으로, 사용자의 모든 요구 사항이 누락되지 않고 완전하게 반영되고 있는가? (2) 일관성으로, 요구 사항이 서로 간에 모순되거나 충돌되는 점은 없는가, 산출물 또는 요구 사항의 내용이 일관성을 유지하고 있는가? (3) 명확성으로, 서술된 명세서의 내용이 애매모호하지 않고 모든 참여자가 명확히 이해할 수 있는가? (4) 기능성으로, 서술된 명세서가 “어떻게(How)”보다 “무엇을”에 관점을 두고 서술했는가? (5) 검증 가능성으로, 서술된 명세서의 내용이 사용자의 요구를 만족하는가? 혹은 개발된 소프트웨어가 사용자가 요구하는 내용과 일치하는지를 검증할 수 있는가? (6) 추적 가능성으로, 사용자 요구 분석 명세서와 설계 사양서를 추적할 수 있는가? (7) 변경 용이성으로, 요구 분석 명세서의 내용을 변경하고자 할 때 쉽게 찾아 변경할 수 있도록 작 성되었는가? 등이 있다.