사용자 요구 사항 모델링

아티클
06/10/2015

Microsoft Visual Studio Ultimate을 사용하면 사용자가 수행하는 작업과 해당 목표를 달성하기 위해 시스템에서 수행하는 역할 등을 보여 주는 다이어그램을 그려 사용자의 요구를 이해하고, 논의하거나 전달할 수 있습니다. 요구 사항 모델은 이러한 다이어그램의 집합으로, 각 다이어그램은 사용자의 다양한 요구를 각 요소별로 자세히 기술합니다.

비디오 데모는 Modeling the Business Domain을 참조하십시오.

요구 사항 모델을 사용하면 다음과 같은 이점이 있습니다.

시스템의 내부 디자인과 별개로 외부 동작에 집중할 수 있습니다.
자연어를 사용하는 경우보다 모호성을 줄이고 사용자 및 관련자의 요구를 기술할 수 있습니다.
사용자, 개발자 및 테스터가 사용할 수 있는 일관성 있는 용어를 정의할 수 있습니다.
요구 사항의 차이점 및 불일치를 줄일 수 있습니다.
요구 사항 변경을 처리하는 데 필요한 작업을 줄일 수 있습니다.
기능 개발 순서를 계획할 수 있습니다.
테스트와 요구 사항의 관계를 명확히 하여 모델을 시스템 테스트의 기초로 사용할 수 있습니다. 요구 사항이 변경되는 경우 이 관계를 사용하여 테스트를 정확하게 업데이트할 수 있습니다. 즉, 시스템이 새 요구 사항을 충족하도록 합니다.

사용자 또는 담당자와 논의할 때 요구 사항 모델을 사용하고 매번 되풀이될 때마다 이 모델을 다시 사용하면 큰 효과를 볼 수 있습니다. 코드를 작성하기 전에 세부적으로 완료할 필요는 없습니다. 아주 간소하더라도 부분적으로 작동하는 응용 프로그램은 일반적으로 사용자와 요구 사항을 논의할 때 가장 효과적인 기준이 됩니다. 요구 사항 모델은 이러한 논의의 결과를 요약할 수 있는 효과적인 방법입니다. 자세한 내용은 개발 프로세스에서 모델 사용을 참조하십시오.

참고

이 항목 전체에서 "시스템"은 개발 중인 응용 프로그램 또는 시스템을 말합니다.이는 다양한 소프트웨어 및 하드웨어 구성 요소의 컬렉션, 단일 응용 프로그램 또는 더 큰 시스템의 하위 소프트웨어 구성 요소일 수 있습니다.어떤 경우에 해당하든 요구 사항 모델은 사용자 인터페이스 또는 API를 통해 시스템 외부에서 볼 수 있는 동작을 기술합니다.

일반 작업

사용자 요구 사항을 나타내는 다양한 종류의 뷰를 만들 수 있습니다. 각 뷰는 특정한 형식의 정보를 제공합니다. 이러한 뷰를 만드는 경우 서로 다른 뷰로 자주 이동하는 것이 좋습니다. 또한 종류에 관계없이 어떤 뷰에서든 시작할 수 있습니다.

다이어그램 또는 문서	요구 사항 모델에서 기술하는 내용	단원
사용 사례 다이어그램	시스템 사용자 및 시스템 사용자가 시스템에서 수행하는 작업	시스템이 사용되는 방식 기술
개념 클래스 다이어그램	요구 사항을 기술하는 데 사용되는 형식의 용어 및 시스템 인터페이스에서 볼 수 있는 형식	요구 사항을 기술하는 데 사용되는 용어 정의
동작 다이어그램	사용자가 수행하는 동작과 시스템 또는 시스템 요소 사이의 정보 및 워크플로	사용자와 시스템 사이의 워크플로 표시
시퀀스 다이어그램	사용자와 시스템 또는 시스템 요소 사이의 상호 작용 시퀀스. 동작 다이어그램을 대체할 수 있는 뷰입니다.	사용자와 시스템 사이의 상호 작용 표시
추가 문서 또는 작업 항목	성능, 보안, 유용성 및 안정성 기준	서비스 품질 요구 사항 기술
추가 문서 또는 작업 항목	특정 사용 사례에 제한되지 않는 제약 조건 및 규칙	비즈니스 규칙 표시

대부분의 다이어그램 형식은 다른 용도로 사용될 수 있습니다. 다이어그램 형식에 대해 간략히 보려면 소프트웨어 디자인용 모델 개발를 참조하십시오. 다이어그램을 그리는 방법에 대한 기본적인 내용은 UML 모델 및 다이어그램 편집을 참조하십시오.

시스템이 사용되는 방식 기술

시스템 사용자 및 시스템 용도를 기술하려면 사용 사례 다이어그램을 만듭니다. 사용 사례 다이어그램은 시스템 사용 목적 및 이러한 목적을 달성하기 위해 수행하는 절차를 나타냅니다.

예를 들어 온라인 식사 판매 시스템은 고객이 메뉴에서 품목을 선택할 수 있고 공급 식당에서 메뉴를 업데이트할 수 있도록 해야 합니다. 다음과 같이 사용 사례 다이어그램에 이 내용을 요약할 수 있습니다.

Customer와 Restaurant에 대한 사용 사례

사용 사례가 어떻게 구성되는지 하위 사례를 표시할 수도 있습니다. 예를 들어 식사를 주문하는 것은 구매의 한 부분이며 지불과 배달을 포함합니다.

시스템은 지불에만 참여하고 배송에는 참여하지 않음

또한 개발 중인 시스템의 범위에 포함되는 사용 사례를 표시할 수 있습니다. 예를 들어 그림에 나온 시스템은 Deliver Meal 사용 사례에 참여하지 않습니다. 이는 개발 작업의 컨텍스트를 설정하는 데 유용합니다. 사용 사례 다이어그램에서는 하위 시스템 컨테이너를 사용하여 시스템 또는 시스템 구성 요소를 나타낼 수 있습니다.

팀에서 후속 릴리스에 포함할 내용에 대해 논의할 때도 유용합니다. 예를 들어 시스템 초기 릴리스에서 시스템이 개입하지 않고 식당과 고객 사이에 Pay for Meal이 직접 조정되도록 할지 여부를 논의할 수 있습니다. 이런 경우에는 초기 릴리스의 Dinner Now System 영역 외부로 Pay for Meal을 옮길 수 있습니다.

사용 사례 다이어그램은 해당 사례에 대한 요약만 제공합니다. 자세한 설명을 제공하려면 다이어그램의 사용 사례를 별도의 문서 및 다른 다이어그램으로 연결하는 링크를 만들어야 합니다. 이 작업을 수행하는 방법을 보려면 방법: 문서 및 다이어그램에 사용 사례 연결을 참조하십시오.

사용 사례 다이어그램을 그리면 팀에서 다음과 같이 할 수 있습니다.

상세한 구현 내용에 신경 쓰지 않고 사용자가 시스템으로 수행할 작업에만 집중할 수 있습니다.
현재 시스템 또는 특정 릴리스의 시스템에 포함할 범위를 논의할 수 있습니다.

다음 항목에서는 자세한 내용을 설명합니다.

내용	Read
사용 사례를 만드는 방법에 대한 자세한 내용	UML 사용 사례 다이어그램: 지침
사용 사례 다이어그램의 요소	UML 사용 사례 다이어그램: 참조
사용 사례에서 코드를 개발하는 방법	소프트웨어 시스템의 아키텍처 모델링

요구 사항을 기술하는 데 사용되는 용어 정의

UML 클래스 다이어그램을 사용하면 다음과 같은 용도로 사용되는 비즈니스 개념의 일관성 있는 용어 모음을 개발할 수 있습니다.

시스템이 동작하는 비즈니스를 논의하는 사용자에게 유용합니다.
예를 들어 사용 사례, 비즈니스 규칙 및 사용자 스토리 설명에서 사용자의 요구를 기술하는 데 유용합니다.
시스템 API에서 또는 사용자 인터페이스를 통해 교환되는 정보의 유형을 나타내는 데 유용합니다.
시스템 또는 수용 테스트 설명을 기술하는 데 유용합니다.

이 용도로 사용되는 UML 클래스 다이어그램의 콘텐츠를 개념 클래스 다이어그램이라고 합니다. 도메인 모델 또는 분석 클래스 모델이라고도 합니다.

개념 클래스 다이어그램에서는 시스템의 내부 디자인 정보는 전혀 표시하지 않고 요구 사항 설명에 필요한 클래스만 나타냅니다. 즉, 이 다이어그램에는 시스템의 내부 디자인에 대한 정보가 나타나지 않습니다. 일반적으로 개념 클래스에는 작업 또는 인터페이스를 나타내지 않습니다.

예를 들어 Dinner Now 시스템에 대해 다음과 같은 개념 클래스를 그릴 수 있습니다.

Menu, Order, Menu Item, Order Item 클래스

개념 클래스 다이어그램에서는 요구 사항 모델 전체에서 사용하는 용어 모음을 제공합니다. 예를 들어 Order a Meal 사용 사례에 대한 자세한 설명에서 다음과 같이 작성할 수 있습니다.

고객은 Order를 만들기 위해 Menu를 선택한 다음, Menu에서 Menu Items를 선택하여 Order에서 Order Items를 만듭니다.

설명에 사용된 용어가 모델에서 클래스 이름이 되는 것에 주목하십시오. 이 다이어그램은 클래스 관계에서 모호성을 제거합니다. 예를 들면 각 Order가 하나의 Menu에만 연결된다는 것을 명확하게 보여 줍니다.

사용자의 요구 사항을 잘못 이해하는 경우 그 원인을 추적해 보면 대부분 단어의 의미를 잘못 이해했기 때문입니다. 예를 들어 대부분의 식당에서는 Menu와 Order라는 용어의 의미를 동일하게 이해하지만 Order 항목과 Menu 항목 간의 차이점은 분명하지 않습니다. 비즈니스 관련자와 요구 사항에 대해 논의하는 경우 이러한 차이점을 언급해야 합니다. 클래스 다이어그램은 용어 및 용어 관계를 명확하게 나타내는 데 유용한 도구입니다.

개념 클래스 모델은 시스템의 비즈니스 논리를 기술하는 데 사용할 수 있는 기본 용어 모음을 만들 수 있습니다. 그러나 시스템을 구현할 때는 성능, 배포, 유연성 및 기타 요인 등의 문제를 고려해야 하므로 소프트웨어의 클래스가 개념 모델보다 일반적으로 더 복잡합니다. 따라서 한 시스템에서 서로 다른 개념 클래스가 여러 개 구현되는 경우가 종종 있습니다.

예를 들어 XML, SQL, HTML, C# 등을 사용하여 시스템의 각 구성 요소 및 해당 요소 간의 여러 인터페이스에 Orders를 나타낼 수 있습니다. 또한 Order와 Menu 간 연결은 C# 코드 내의 참조, 데이터베이스의 관계 또는 XML의 상호 참조 ID와 같은 다양한 방법으로 나타낼 수 있습니다. 그러나 이렇게 서로 다른 특성에도 불구하고 개념 모델은 소프트웨어의 모든 부분에 동일하게 적용되는 중요한 정보를 제공합니다. 이 예제의 클래스 다이어그램을 보면 모든 구현에서 각 Order에 Menu가 하나만 연결된다는 것을 알 수 있습니다.

요구 사항 클래스 다이어그램을 그리면 팀에서 다음과 같이 할 수 있습니다.

사용자의 요구를 논의할 때 사용되는 기본 용어를 정의하고 표준화할 수 있습니다.
이러한 용어의 관계를 명확하게 나타낼 수 있습니다.

다음 항목에서는 자세한 내용을 설명합니다.

내용	Read
요구 사항 클래스를 찾는 데 대한 자세한 내용	UML 클래스 다이어그램: 지침
개념 클래스 다이어그램의 요소	UML 클래스 다이어그램: 참조
개념 클래스에서 코드를 개발하는 방법	소프트웨어 시스템의 아키텍처 모델링

개념 클래스 다이어그램에서는 탐색 가능성을 나타내기 위해 연결에 화살표를 배치하는 것이 대개 유용하지 않습니다. 이는 개념 클래스 다이어그램이 구현을 나타내지 않기 때문입니다. 연결은 실제 개체 간의 관계를 나타냅니다. Sample: UML Domain Modeling features에 있는 Visual Studio Extension은 비방향 화살표를 기본값으로 만듭니다.

비즈니스 규칙 표시

비즈니스 규칙은 특정 사용 사례와 연결되지 않고 시스템 전체에서 관찰되어야 하는 요구 사항입니다.

대부분의 비즈니스 규칙은 개념 클래스 간 관계에 대한 제약 조건입니다. 이러한 정적 비즈니스 규칙을 개념 클래스 다이어그램의 관련 클래스와 연결된 주석으로 작성할 수 있습니다. 예를 들면 다음과 같습니다.

Order 클래스에 연결된 주석의 규칙

동적 비즈니스 규칙은 허용 가능한 이벤트 시퀀스를 제한합니다. 예를 들어 시스템에서 다른 작업을 수행하기 전에 사용자가 로그인해야 한다는 것을 나타내기 위해 시퀀스 또는 동작 다이어그램을 사용합니다.

그러나 대부분의 동적 규칙은 정적 규칙으로 바꾸면 훨씬 효과적이고 일반적인 방식으로 지정할 수 있습니다. 예를 들어 '로그인됨'이라는 부울 특성을 개념 클래스 모델의 클래스에 추가합니다. 그런 다음 이 특성을 사용 사례의 로그 사후 조건으로 추가하고, 다른 사용 사례 대부분의 사전 조건으로 추가합니다. 이렇게 하면 이벤트 시퀀스의 가능한 모든 조합을 정의하지 않아도 됩니다. 또한 모델에 새 사용 사례를 추가해야 하는 경우에도 더 유동적입니다.

여기에서는 요구 사항을 정의하는 방법에 대해서만 선택하며, 이는 프로그램 코드에서 요구 사항을 구현하는 방법과는 별개입니다.

다음 항목에서는 자세한 내용을 설명합니다.

내용	Read
정적 비즈니스 규칙을 찾고 기록하는 데 대한 자세한 내용	UML 클래스 다이어그램: 지침
개념 클래스 다이어그램의 요소	UML 클래스 다이어그램: 참조
비즈니스 규칙을 따르는 코드를 개발하는 방법	소프트웨어 시스템의 아키텍처 모델링

서비스 품질 요구 사항 기술

서비스 품질 요구 사항은 몇 가지 범주로 구성됩니다. 이러한 범주는 다음과 같습니다.

성능
보안
유용성
안정성
견고성

특정 사용 사례를 기술할 때 이러한 요구 사항 중 일부를 포함할 수 있습니다. 다른 요구 사항은 사용 사례에 제한되지 않으며 별도의 문서에서 가장 효과적으로 작성됩니다. 가능한 경우 요구 사항 모델에 정의된 용어를 따르면 유용합니다. 다음 예에서 요구 사항에 사용된 주요 단어는 앞에 나온 그림에서 행위자, 사용 사례 및 클래스의 제목임을 참고하십시오.

Customer가 Ordering a Meal을 수행하는 동안 Restaurant에서 Menu Item을 삭제하면 해당 Menu Item을 참조하는 모든 Order Item이 빨간색으로 표시됩니다.

다음 항목에서는 자세한 내용을 설명합니다.

내용	Read
서비스 품질 요구 사항을 기록하는 데 대한 자세한 내용	Guidelines for Defining Quality of Service Requirements
추가 문서를 사용 사례에 연결	방법: 문서 및 다이어그램에 사용 사례 연결
서비스 품질 요구 사항을 따르는 코드를 개발하는 방법	소프트웨어 시스템의 아키텍처 모델링

사용자와 시스템 사이의 워크플로 표시

동작 다이어그램을 사용하면 각 사용 사례 사이의 워크플로를 나타낼 수 있습니다. 대부분의 경우 시스템 내부와 외부에서 사용자가 수행할 주요 작업을 보여 주는 동작 다이어그램을 그려 요구 사항 모델을 시작하면 유용합니다.

예를 들면 다음과 같습니다.

동작 세 개와 루프 하나가 포함된 작업입니다.

같은 정보를 서로 다른 뷰로 나타내려는 경우 사용 사례 다이어그램과 동작 다이어그램을 그릴 수 있습니다. 사용 사례 다이어그램은 큰 동작 내에 더 작은 동작이 중첩되는 것을 보여 줄 때 효과가 있지만 워크플로를 나타내지 않습니다. 예를 들면 다음과 같습니다.

이전 동작에 대한 사용 사례

또한 소프트웨어 내의 알고리즘을 자세히 나타낼 때도 동작 다이어그램을 사용할 수 있지만 이 다이어그램을 비즈니스 프로세스에 사용할 경우에는 시스템 외부에서 볼 수 있는 동작에 초점을 맞춥니다.

다음 항목에서는 자세한 내용을 설명합니다.

내용	Read
비즈니스 워크플로를 정의하는 방법에 대한 자세한 내용	UML 동작 다이어그램: 지침
동작 다이어그램의 요소	UML 동작 다이어그램: 참조
동작 다이어그램에서 코드를 개발하는 방법	소프트웨어 시스템의 아키텍처 모델링

사용자와 시스템 사이의 상호 작용 표시

시퀀스 다이어그램을 사용하면 시스템과 외부 행위자 간 또는 각 시스템 구성 요소 간의 메시지 교환을 나타낼 수 있습니다. 이렇게 하면 사용 사례에서 상호 작용 시퀀스를 명확히 나타내는 단계 뷰를 제공할 수 있습니다. 시퀀스 다이어그램은 사용 사례에 상호 작용 대상이 여러 개 있는 경우와 시스템에 API가 있는 경우 특히 유용합니다.

예를 들면 다음과 같습니다.

시스템과 행위자가 포함된 시퀀스 다이어그램

시퀀스 다이어그램은 생성 중인 시스템으로 들어 오는 메시지를 쉽게 볼 수 있다는 장점이 있습니다. 단일 시스템 수명선을 각 시스템 구성 요소에 대한 개별 수명선으로 바꾼 다음, 들어오는 각 메시지에 대한 응답으로 구성 요소 사이의 상호 작용을 표시하여 시스템을 디자인할 수 있습니다.

다음 항목에서는 자세한 내용을 설명합니다.

내용	Read
상호 작용을 정의하는 방법에 대한 자세한 내용	UML 시퀀스 다이어그램: 지침
시퀀스 다이어그램의 요소	UML 시퀀스 다이어그램: 참조
시퀀스 다이어그램에서 코드를 개발하는 방법	소프트웨어 시스템의 아키텍처 모델링

모델을 사용하여 불일치 줄이기

일반적으로 모델을 만들면 사용자의 요구 사항에서 불일치 및 모호성 문제가 상당히 줄어듭니다. 각 관련자마다 시스템이 동작하는 비즈니스 환경을 서로 다르게 이해하는 경우도 종종 있습니다. 따라서 클라이언트 간의 이러한 차이를 해결하는 것이 첫 번째 과제입니다.

모델을 만드는 동안 자연스럽게 비즈니스 도메인에 대한 질문이 많이 생긴다는 것을 알게 될 것입니다. 이를 사용자에게 미리 질문하면 프로젝트의 이후 단계에서 변경 필요성이 줄어듭니다. 다음은 먼저 자신에게 질문한 후 대답이 명확하지 않을 경우 비즈니스 관련자에게 물어볼 수 있는 몇 가지 특정 질문입니다.

요구 사항 모델의 각 클래스에 대해 "이 클래스의 인스턴스를 만드는 사용 사례는 무엇입니까?"라는 질문을 생각해 봅니다. 예를 들어 온라인 식사 주문 서비스의 경우 "Restaurant Menu 클래스의 인스턴스를 만드는 사용 사례는 무엇입니까?"라고 질문할 수 있습니다. 이는 새 식당의 서비스 등록 및 메뉴 제공 방식에 대한 논의로 이어질 수 있습니다. 무엇이 특성 및 연결을 만들거나 변경하는지에 대해서도 비슷한 질문을 할 수 있습니다.
요구 사항 모델의 각 사용 사례에 대해 클래스 다이어그램에서 제공하는 용어로 각 사용 사례의 결과 또는 사후 조건을 기술해 보십시오. 사용 사례가 발생하기 전후에 클래스 인스턴스를 스케치하여 해당 사용 사례의 결과를 나타내면 유용한 경우가 종종 있습니다. 예를 들어 사용 사례 사후 조건에 "메뉴 항목이 고객 주문에 추가됩니다"라는 내용이 있으면 Order 및 Menu Item 클래스의 인스턴스를 스케치합니다. 새 링크 또는 새 개체와 같은 사용 사례 결과를 다른 색 또는 새 그림으로 표시하십시오. 이는 모델에 필요한 정보가 무엇인지에 대한 논의로 이어질 수 있습니다. 요구 사항 클래스는 구현과 직접적인 관련은 없지만 시스템에서 저장하고 전송해야 할 정보를 기술합니다.
특성 및 연결에 대한 제약 조건, 특히 둘 이상의 특성 또는 연결을 포함하는 제약 조건에 대해 질문합니다.
시퀀스 또는 동작 다이어그램을 그리고 사용 사례의 유효한 시퀀스와 잘못된 시퀀스에 대해 질문합니다.

각 다이어그램에서 제공하는 뷰의 관계를 조사하면 사용자가 다루는 주요 개념을 쉽게 이해할 수 있으며 사용자가 시스템에서 무엇을 필요로 하는지 스스로 이해하도록 도움을 줄 수 있습니다. 또한 관련자가 가장 의문을 갖고 있는 요구 사항에 대해서도 더 잘 이해하게 됩니다. 사용자가 기능을 시험해 볼 수 있도록 프로젝트 초기 단계에서 간소화된 형태로나마 이러한 기능을 개발할 것을 계획할 수 있습니다.