주제

사용자 중심 설계의 의미 페이지 맨 위

사용자 중심 설계를 구성하는 요소가 무엇인지에 대해 명확하게 정해진 것은 없습니다. 그러나 1980년대에 IBM에 근무하는 John Gould와 그의 동료는 가장 일반적으로 인정되고 있는 정의를 포함하는 유용성을 위한 설계[GOU88]라는 접근법을 개발했습니다. 이것은 많은 대화식 시스템, 가장 대표적인 예로는 IBM의 1984 올림픽 메시징 시스템[GOU87]의 실제 경험에서 개발되었습니다. 이 접근법은 아래 설명된 4가지 주요 컴포넌트로 이루어집니다.

사용자 중심 페이지 맨 위

Gould는 사용자가 누구이며 가능한 초기에 이들을 포함시킬지 개발자가 결정하도록 제안합니다. 그는 사용자와 사용자의 작업 및 요구사항에 익숙해지기 위한 많은 방법을 제안합니다.

·    사용자와 대화하십시오.

·    고객 회사를 방문하십시오.

·    사용자가 작업하는 것을 관찰하십시오.

·    사용자가 작업하는 것을 비디오 테이프에 녹화하십시오.

·    작업 조직에 대해 배우십시오.

·    스스로 시도해보십시오.

·    사용자가 작업시 생각을 말하도록 하십시오.

·    설계에 참여하십시오.

·    설계팀에 전문 사용자를 포함시키십시오.

·    타스크 분석을 수행하십시오.

·    조사 및 질문 사항을 확인하십시오.

·    테스트 가능한 목표를 개발하십시오.


RUP에서 워크샵은 여러 중요 단계에 사용되지만, 정확한 그림이 형성되는 경우 Gould가 설명하는 활동 종류로 보완되어야 합니다. (이 다음에 있는 인수 파트는 수행하는 방법과 상당히 다르게 수행하는 것을 사용자가 자주 설명하는 것입니다. 일반적으로 수행된 타스크 및 중요해 보이지 않는 세부사항(예: 작업 배치 또는 문서의 "비밀" 스크랩 존재)은 현재 프로세스의 "공식" 파트가 아니므로 자주 잊혀지거나 생략됩니다.)

설계와 통합페이지 맨 위

유용성 타스크는 개발 초기에 병렬로 수행해야 합니다. 해당 타스크에는 사용자 인터페이스 스케치 및 사용자 가이드 또는 온라인 도움말의 초안 작성이 포함됩니다. 또한 Gould는 유용성에 대한 책임을 하나의 그룹이 맡아야 한다고 강조합니다.   

통합 설계의 중요한 기능은 세부 사용자 인터페이스 설계에 대한 종합적 접근(프레임워크)이 초기 단계에서 개발되고 테스트되는 것입니다. 이는 사용자 중심 설계와 다른 순수 증가 기술 간의 중요한 차이입니다. 이후 단계에서 수행되는 증가 설계가 프레임워크에 항상 적합하며 사용자 인터페이스가 외관, 용어 및 개념상 일관적인지 확인합니다.

RUP에서 사용자 인터페이스에 나타나는 모든 용어 및 개념은 일반 비즈니스에서 및 특정 사용자에게 알려지고 이해되는지 확인하는 데 도메인 모델을 사용하여 해당 프레임워크를 설정할 수 있습니다. (또한 특정 사용자 그룹에만 관련될 도메인 모델의 서브세트도 있습니다. 해당 서브세트가 쉽게 식별되도록 도메인 모델이 구성되어 있는지 확인하는 데 주의해야 합니다.) 사용자 인터페이스 설계 프로세스로서, 많은 도메인 클래스가 사용자 인터페이스 요소로 표시됩니다. 사용자 인터페이스 요소 및 그들 간의 관계는 도메인 모델에서 일관적이어야 하며 설계 중인 시스템의 모든 부분에서 일관적으로 표시되어야 합니다. (이는 사용자를 도울 뿐 아니라 사용자 인터페이스 컴포넌트의 재사용을 향상시킵니다.)

초기 사용자 테스트페이지맨 위로

초기 사용자 테스트는 초기 스토리보딩 및 초기 낮은 충성도 프로토타입의 개발을 의미합니다. 높은 충성도 프로토타입은 프로세서의 후반에 뒤따릅니다.

스토리보드유스 케이스와 함께 사용하여 설계 중인 시스템에 대한 구체적인 사용 시나리오를 작성할 수 있습니다. 설명적, 그림이 있는 설명(설명에 사용자 인터페이스 실물 모형 사용), 스토리보드, 사용자와의 검토회 및 사용자 중심 그룹을 양식으로 취할 수 있으며, 많은 소프트웨어 개발자에게는 친숙하지 않을 수 있는 방법입니다. 그러나 이 방법을 구현하면 적절하지 않은 설계의 전개나 잘못 이해된 요구사항보다 확실히 더욱 비용 효과적입니다.

반복 설계페이지 맨 위

오브젝트 지향 개발은 대화식 프로세스와 같은 의미입니다. 대화식 설계는 세밀한 이해가 요구되며 요구사항을 변경하는 문제점에 아주 적합합니다. 대화식 설계가 사용자 중심 설계의 주요 컴포넌트라는 것은 놀라운 일이 아닙니다. 이는 부분적으로 시간에 따라 사용자 요구를 변경하기 때문만이 아니라, 다양한 요구를 처리할 수 있는 설계 솔루션을 생산하는 것의 고유 복잡도로 인한 것입니다.

사용자 중심 메소드에서는 통합 프레임워크에 반복 설계가 발생함을 참고하십시오. 우리는 "패치워크" 솔루션에 이를 수 있는 협의된 프레임워크 이외의 증가 개발을 의도적으로 막습니다.

사용자 중심 설계 목적 To top of page

사용자 요구 충족 페이지맨 위로

대화식 시스템은 사용자가 성공하도록 사용자 요구를 수용할 수 있는 능력에 의존합니다. 이는 다양한 사용자 커뮤니티의 식별뿐만 아니라 사용자 각각의 기술 범위, 경력 및 선호사항을 인식하는 기능을 의미합니다.

개발자와 관리자가 사용자 요구를 이해한다고 생각하도록 권장되지만, 이는 실제에서는 드문 경우입니다. 종종 사용자가 원하는 타스크 수행 방법보다 해야 하는 수행 방법에 주의를 기울입니다. 대부분의 경우 우선권 문제는 그 자체로도 중요한 문제이지만, 단순한 제어를 훨씬 뛰어넘는 그 이상의 의미입니다. 또한 우선권은 경력, 기량 및 사용 컨텍스트로 판별됩니다. 이런 문제는 설계 프로세스가 대화식 시스템을 위한 인간 중심 설계 프로세스라는 국제 표준[ISO 13407]임을 보증하는 데 있어 아주 중요하게 간주됩니다. 표준 및 관련 문제는 이 페이지의 나중에 있는 일반 항목에 설명되어 있습니다.

사용자 인터페이스 설계 페이지 맨 위

사용자는 해당 사용자 인터페이스에서 시스템을 이해하고 시스템과 대화합니다. 인터페이스에 표시되는 개념, 이미지 및 용어는 사용자의 요구에 적합해야 합니다. 예를 들어, 고객이 본인의 티켓을 구입할 수 있는 시스템은 티켓 판매원이 전문적으로 사용하는 시스템과 매우 다릅니다. 기본적인 차이점은 요구사항 또는 자세한 사용 케이스가 아닌, 시스템이 작동하는 환경 및 사용자의 특성에 있습니다.

또한 사용자 인터페이스는 아래 그림 1에 표시된 것처럼 2차원 이상의 가능한 넓은 범위의 경력, 컴퓨터 및 도메인 경력에 맞게 제공되어야 합니다. 컴퓨터 경력에는 컴퓨터에 대한 일반적인 지식뿐만 아니라 개발 중인 시스템에 대한 경력도 포함됩니다. 컴퓨터 또는 문제점 도메인에 대한 경험이 적은 사용자는 오른쪽 가장자리에 표시된 전문 사용자를 위한 사용자 인터페이스와는 상당히 다른 접근법을 그림의 왼쪽 가장자리 옆에서 요구할 수 있습니다.

첨부 텍스트에 설명된 다이어그램

그림 1: 학습 용이성 대 사용 용이성에 대한 컴퓨터 및 도메인 경력의 효과

미숙한 사용자가 시간 경과 후 전문가가 되는 보류된 결론이 아님을 주의하십시오. 이를 막기 위해 많은 요인이 협업할 수 있습니다(예: 낮은 사용 빈도, 낮은 동기 부여 또는 높은 복잡도). 반대로 일부 시스템에는 뛰어난 전문 사용자가 있을 수 있습니다. 여기서 요인은 훈련, 높은 사용 빈도 또는 높은 동기 부여가 될 수 있습니다(작업 의존). 사용자 인터페이스 설계에 해당하는 이런 문제 및 이에 대한 효과 중 일부가 표 1에 표시되어 있습니다.

 

낮음

높음

컴퓨터 경력

단순한 질문과 대답, 단순한 양식 채우기, 웹(하이퍼링크로 표시) 또는 메뉴 인터페이스 양식

복잡한 양식 채우기, 웹(하이퍼링크 표시) 또는 메뉴 인터페이스 양식(질문과 대답 또는 단순 양식 채우기가 경력 사용자에게는 매우 부족하게 생각될 수 있음)

도메인 경력

공통 용어 및 개념

도메인 특정 용어 및 개념

교육

학습의 용이성에 주목(일관적, 범용적, 인상적)

사용의 용이성에 주목(직접적, 사용자 정의 가능, 방해 없음)

사용 빈도

용이한 학습 및 기억, 단순 인터페이스 양식

사용 용이성, 사용자 제어가 가능한 다양한 단축키 및 기술

동기 부여

사용할 만한 가치가 있고, 복잡해 보이지 않으며 강력한 경우.

많은 고급 기능 및 사용자 지정이 가능한 기능으로 정교한 경우.


1, 사용자 인터페이스에 영향을 주는 일부 요인

대화식 시스템은 적절한 사용자 경력 및 환경 범위를 제공하도록 설계되거나 또는 설계 영역을 제한하는 단계를 수행해야 합니다. 예를 들면, 훈련을 사용하여 복잡한 시스템의 학습 용이성을 위해 요구사항을 줄일 수 있습니다. 또는 시스템 사용자의 핵심 요구사항을 더 효율적으로 충족시키기 위해 시스템 범위를 축소할 수 있습니다(Alan Cooper가 그의 저서 The Inmates Are Running the Asylum [COO99]에서 제안).

법률 및 표준 페이지 맨 위

사용자 중심 설계의 일부로, 사용자의 기술 및 신체적 특성을 고려해야 합니다. 이런 문제는 현재 점점 더 법률적으로 구체화되고 있습니다.  이는 대부분 장애가 있는 사용자를 위한 조정에 관한 것입니다. 그러나 넓은 범위의 사용자가 시스템에 액세스할 수 있으면 일반적으로 사용자 커뮤니티 전체에 이익이 되는 것처럼 보입니다.

아래 표는 세계 많은 국가의 관련 법률 및 자원을 표시합니다.

설명 웹 사이트

호주

 
장애인 차별 행동 http://www.hreoc.gov.au/disability_rights/dda_guide/dda_guide.htm
장애인 권리 http://www.hreoc.gov.au/disability_rights/index.html

유럽

 
유럽 장애인 포럼 http://www.edf.unicall.be

영국

 
장애인 차별 행동 http://www.hmso.gov.uk/acts/acts1995/1995050.htm
장애인에 대한 새로운 대우 http://www.disability.gov.uk
디지털 액세스 캠페인 http://www.rnib.org.uk/digital/welcome.htm

UN

 
장애인에 대한 동등한 기회 부여에 대한 연합 국가 표준 규칙 http://www.un.org/esa/socdev/enable/dissre00.htm
인터넷의 사회 개발 정보 http://www.unescap.org/esid/psis/disability/index.asp

미국

 
ADA(Americans with Disabilities Act): 미국 법무부 http://www.usdoj.gov/crt/ada/
노동 인력 투자 활동 섹션 508: 미국 법무부 http://www.usdoj.gov/crt/508/508home.html 
미국 액세스 위원회 EITAAC(Electronic and Information Technology Advisory Committee) http://www.access-board.gov 
WWW(World Wide Web) 콘소시엄 웹 이용도 캠페인 http://www.w3.org/wai/ 

기타 자원

 
장애인 관련 인터넷 자원 http://www.disabilityresources.org

 표 2a, 국가 지역 또는 법인의 장애인 관련 법률

법률을 제외하고도, 사용자 중심 설계 및 사용자 인터페이스 설계는 아래에 표시된 바와 같이 점차 표준화의 주제가 되고 있습니다.

설명 웹 사이트/표준

ANSI

www.ansi.org

ANSI

ANSI-HFES

ANSI-NSC

ANSI 및 Human Factors and Ergonomics Society는 많은 공동 표준을 출판했습니다. 또한 ANSI에는 누적된 스트레스 장애의 방지 및 제어와 관련된 ANSI-NSC Z365가 있습니다(반복적인 과로 상해 또는 RSI(repetitive strain injury)로도 알려짐).

ANSI는 인간과 컴퓨터 간의 대화를 정보 인프라스트럭처 표준 패널(IISP)의 일부로 간주하는 표준의 초안을 작성합니다.

ISO

www.iso.ch
ISO 9241 대규모 표준 시리즈는 주로 워크스테이션의 인간 공학과 관련되어 있지만, 유용성에 대한 가이드도 포함되어 있습니다(파트 11). 또한 ANSI-HFES 200에 대한 기초가 개발 중입니다.
ISO 10075: 1991 정신 노동 로드에 관련된 인간 공학적 원리
ISO 17041-1: 1995 텍스트 편집에 필요한 커서 제어
ISO 11581 아이콘 및 포인터를 다루는 개발 시리즈.
ISO 13407: 1999 대화식 시스템의 인간 중심 설계 프로세스 표준.

 표 2b, ANSI 및 ISO 사용자 인터페이스 및 사용자 중심 설계 표준

RUP의 사용자 중심 설계 페이지 맨 위

사용자 요구에 적합한 시스템 개발에는 상당한 요구분석 작업이 필요합니다. 사용자 중심 설계에서 해당 작업은 일반 사용자를 중심으로 이뤄집니다. 나중에 요구사항 규칙에서 액터로 자세하게 설명합니다.

그러나 사용자 중심 설계에서 실제로 강조되는 점은 위에서 언급한 결과물에 설명된 역할을 완수할 실제 사람들의 요구사항을 이해한다는 것입니다. 특히 소프트웨어 시스템을 설계하는 것이 편리한 사람에게 가상 인간을 설계하지 않아야 합니다. 일반 사용자를 설명하는 결과물은 사용자와 실질적으로 직접 연락한 후에 작성해야 합니다. 사용자 중심 설계에서 이 직접 연락은 가끔 컨텍스트 조회로 불리는 프로세스의 일부입니다. Hugh Beyer and Karen Holtzblatt의 저서 컨텍스트 설계, [BEY98]는 컨텍스트 조회 전제에 대해 다음과 같이 설명합니다.

"...고객이 작업하는 곳에 가서 고객이 작업하는 것을 관찰하고 작업에 대해 고객과 얘기하십시오."

(일부 구체적인 예는 사용자 중심에 이미 나열되어 있습니다.) 이 방법은 시스템 요구사항뿐만 아니라 사용자 자신, 사용자의 타스크 및 환경을 더 잘 이해하는 데 사용됩니다. 이들은 각각의 해당 속성이 있으며, 결합되어 사용 컨텍스트로 불립니다. 자세한 내용은 아래에 설명된 사용자 중심 설계에 대한 ISO 표준에 있습니다.

사용 컨텍스트 페이지 맨 위

ISO 대화식 시스템의 인간 중심 설계 프로세스 [ISO13407]는 사용 컨텍스트를 이해하고 지정하여 설계의 첫 단계를 식별합니다. 다음과 같은 속성이 제공됩니다.

컨텍스트 속성

타스크

시스템 사용 목적, 성능 지속 기간 및 빈도, 상태 및 보안 고려사항, 활동 할당, 인간과 기술 자원간의 작동 단계. 제품 또는 시스템이 제공하는 기능 또는 함수 항목에 타스크를 단독으로 기술해서는 안됩니다.

사용자(각각 다른 유형 또는 역할의 경우)

지식, 기술, 경력, 교육, 훈련, 신체적 특성, 습관, 우선권, 재능.

환경

하드웨어, 소프트웨어, 자료; 신체적 사회적 환경, 관련 표준, 기술 환경, 주위 환경, 법적 환경, 사회적 문화적 환경


표 3: 사용자 중심 설계에 대한 ISO 표준의 사용 컨텍스트

이는 사용자 컨텍스트를 두 개의 구성 파트(사용자 유형 및 역할)로 나눈 후 네 개의 모든 컨텍스트 간의 관계를 생각하는 데 유용합니다.

첨부 텍스트에 설명된 다이어그램

그림 2: 컨텍스트 간의 관계

그림 2는 환경에 있는 사용자가 수행하는 역할에서 수행되는 모든 타스크를 표시합니다. 이 컨텍스트는 표 4에 표시되어 있는 RUP 결과물에 해당합니다.

ISO 13407 컨텍스트 RUP 결과물

환경

사용자

역할

타스크


 표 4, ISO 사용자 중심 설계 표준 컨텍스트 및 해당 RUP 결과물

해당 컨텍스트 각각은 적절한 사용자 인터페이스 설계에 상당한 영향을 줄 수 있습니다. 결과적으로 가능한 많은 변경을 직면하게 됩니다. 소규모 시스템의 경우에도 두 가지 환경(예: 사무실 및 고객 사이트), 세 가지 사용자 유형(예: 판매 초보자, 판매 전문가 및 관리) 및 여섯 가지 역할(예: 전화 판매 협조, 외부 영업 담당자 등)이 있습니다. . 따라서 실제 조합 세트는 일반적으로 더 작지만 각 타스크마다 36개까지의 변경이 가능합니다.

타스크를 개별적으로 명확하게 설명해야 하나, 단독 설명은 일부 변경에 적합하지 않을 수 있습니다. 한 가지 방법은 사용자 및 환경 컨텍스트를 역할 설명의 요인으로 포함시키는 것입니다. 이는 Constantine and Lockwood [CON99]가 채택한 솔루션입니다. 여기서는 역할, 사용자 및 환경의 주요 변경 각각에 대해 별도의 "사용자 역할"을 제공한 후 하나의 단어가 아닌 설명적인 문구로 사용자 역할의 이름을 지정합니다. 예를 들어, "고객" 역할을 "임시 고객", "웹 고객", "정규 고객" 및 "고급 고객" 사용자 역할과 비교하십시오.

각 사용자 역할 설명에는 역할 자신과 해당 사용자(역할 소유자로 참조됨) 및 환경에 대한 세부사항이 있습니다. 이 방법은 사용자 역할에 해당하는 액터를 선택하여 RUP와 함께 채택할 수 있습니다.

시나리오, 유스 케이스 및 필수 유스 케이스 페이지 맨 위

시나리오, 유스 케이스 및 필수 유스 케이스라는 용어에는 많은 중복이 있으며 다른 설계 방법에서 약간 다른 의미로 사용됩니다. 예를 들어, RUP "시나리오"에서는 유스 케이스 인스턴스, 즉 기본 및 대체 플로우의 특정 "경로"만을 의미합니다. 그러나 사용자 중심 및 사용자 인터페이스 설계 메소드는 시나리오를 단순한 이벤트 플로우가 아닌 대체로 더 자세한 세부사항이 있는 사용 내용으로 설명하는 것이 일반적입니다. 이러한 추가 정보는 이후 설계 단계와 연관이 없는 반면, 사용자, 타스크 및 환경에 대한 이해 부분을 형성합니다. 따라서 시나리오는 비즈니스 모델링 규칙(../../workguid/wg_stbd.htm -- This hyperlink in not present in this generated website스토리보딩../../workguid/wg_rlpl.htm -- This hyperlink in not present in this generated website역할 재생)에서 광범위하게 사용될 수 있으나, 초점은 요구사항 규칙의 유스 케이스로 이동합니다.

그림 3에서는 이러한 중복의 특징을 표시합니다. 맨 위의 배율은 함께 변경되는 경향의 다른 많은 요인을 통합합니다. 예를 들어, 목적이 요구사항에 가까워질수록 구조는 보통 더욱 형식적이 됩니다. 필수 유스 케이스는 일반 유스 케이스의 오른쪽에 나타나는데, 이는 사용자 역할이 이것을 좀더 특정하게 하며(이전 섹션 참조) 이것이 더욱 형식적인 구조를 갖기 때문입니다.

첨부 텍스트에 설명된 다이어그램

그림 3: 사용자 중심 설계에서 시나리오 및 유스 케이스 간에 겹쳐지는 개념

시스템 유스 케이스와 필수 유스 케이스의 차이점은 예에 잘 설명되어 있습니다. 표 5는 [CON99] 사용을 위한 Constantine and Lockwood 소프트웨어의 유스 케이스를 표시합니다.

사용자 조치 시스템 응답
카드 삽입 자기 띠 읽기
PIN 요청
PIN 입력 PIN 확인
트랜잭션 옵션 메뉴 표시
키 누르기 계정 메뉴 표시
키 누르기 총계로 프롬프트
총계 입력 총계 표시
키 누르기 카드 리턴
현금 선택 현금 인출
현금 선택  

표 5: ATM에서 현금을 인출하는 일반 유스 케이스

이 예에서는 사용자 인터페이스를 표시하는 두 개의 열 사이에 있는 수직 선과 함께 액터와 시스템 간의 이벤트 순서를 자세히 설명합니다. Constantine and Lockwood에서는 필수 유스 케이스에 이 스타일을 권장하지만 이 특정 유스 케이스가 필수는 아닙니다. 그 이유는 대화의 자세한 구문에 기반하기 때문입니다. 즉, 대화가 발생하는 방법입니다. 필수 유스 케이스는 대화 내용에 초점을 둡니다(의미론). 표 6은 필수 대화 버전입니다.

사용자 의사 시스템 책임
본인 식별 ID 확인
선택사항 제공
선택 현금 인출
현금 선택  

표 6: ATM에서 현금을 인출하기 위한 필수 유스 케이스

유스 케이스는 현금을 가져오는 대화의 요소를 캡처합니다. 중요한 변경을 반영하도록 사용자 조치 및 시스템 응답 표제가 사용자 의사 및 시스템 책임으로 바뀌었습니다. 사용자 목적과 의도에 맞는 인터페이스 설계 센터는 종종 일반적 유스 케이스에 숨겨집니다. 필수 유스 케이스는 특히 다음 경우에 유용합니다.

  • 소수의 설계 제한조건(예: 은행 카드 사용에 내포된 설계 제한조건이 거짓)이 있는 경우
  • 다른 식별 수단(예: 일부 보안 인터넷 액세스)을 사용하도록 시스템이 강화된 경우
  • 제한조건이 부족한 프로젝트에서 재사용이 가능하도록 설계 제한조건 없이 유스 케이스를 작성하려 는 경우

그러나 필수 유스 케이스에는 약점이 있습니다. 완벽하게 직접 나아가는 유스 케이스(예: 표 5에 있는 유스 케이스)는 해당 요소 제거시 상당한 검토를 요합니다. 예를 들어, 카드 입력이 고객 또는 계정을 식별합니까? Constantine and Lockwood는 이를 고객 식별시 해석하도록 선택했지만 대부분의 기존 ATM에서는 나중에 합니다. 이는 최신 기술(예: 망막 스캐닝 및 지문 식별)의 견지에서 보면 신중한 결정이었거나 또는 간과한 것일 수 있습니다. 여기서 중요한 것은 두 개 이상의 계정이 있는 고객이 작성해야 하는 추가 선택입니다.

필수 유스 케이스가 갖는 또 다른 어려움은 필수 유스 케이스의 추상 특성으로 인해 일반 사용자 및 스테이크홀더와의 검토에 적합하지 않다는 것입니다. 이 문제점의 일부는 필수 유스 케이스를 사용자 조치를 표시하는 구체적인 양식으로 다시 변환해야 한다는 점에 기인합니다. 이는 구체적인 용어로 상호작용을 설명하는 시나리오를 작성하여 설계 모델을 사용할 수 있게 되면 완료될 수 있습니다(내부 오브젝트 협업이 아닌, 사용자와 시스템의 상호작용과 관계가 있지만 유스 케이스 구현 개념과 유사).

요약하면, 다음의 경우에는 필수 유스 케이스 구성이 적합하지 않을 수 있습니다.

  • 사용자 인터페이스 기술이 의도적으로 높게 제한되는 경우(예: 시스템이 은행 카드를 승인해야 함)
  • 사용자가 더 추상적인 유스 케이스를 이해하는 데 필요한 시간을 예상 이익이 능가한 경우

RUP의 필수 유스 케이스 페이지 맨 위

RUP가 명시적으로 필수 유스 케이스를 참조하지 않지만, 활동: 사용자 인터페이스 설계에서 필수 유스 케이스가 시작점으로 사용되고 유용성 요구사항을 통해 개발되고 확대되어 가이드라인: 스토리보드에 설명된 대로 스토리보드를 작성합니다.   

이는 의미론(상호작용의 수단)만 남도록 모든 설계 또는 현재 구현 세부사항을 제거하게 됩니다. 그러면 다양한 설계 대체가 조사되고 구문 세부사항(상호작용 발생 방법)이 필수 유스 케이스에 구현의 한 유형으로 추가됩니다. (각 대체 설계는 사실상 동일한 필수 유스 케이스의 구현입니다.)

스토리보드를 활동: 사용자 인터페이스 프로토타입에 대한 입력으로 사용하여 사용자 인터페이스 프로토타입을 개발할 수 있습니다.



Rational Unified Process   2003.06.15