일부 웹 사이트는 응용 프로그램이지만 모든 웹 사이트가 응용 프로그램이 아닙니다 (단지 브로셔보기 사이트 일 수도 있음).'사례'시나리오를 웹 사이트 디자인에 적용 할 수 있습니까?
유용하게 사용할 수있는 브로셔 유형 사이트에 대한 심층적 인 더미 유스 케이스가 있습니까?
기업용 전면 웹 사이트의 경우 예를 들어 실제 데이터베이스 기반 응용 프로그램 (예 : 구매 주문 시스템)의 경우 요소 내에서 느낄 수 있지만 필자는 실명을 겪습니다.
프로 보노 (pro bono) 데이터베이스 구동 응용 프로그램과 동일한 조명으로 "브로셔"사이트를 볼 수있는 리소스가 있습니까?
사용 사례는 시스템 요구 사항을 모델링하는 데 사용할 수 있습니다. 시스템은 입력 및 출력 매핑이있는 구조입니다. 따라서 정적 웹 페이지가있는 경우보기보다는 다른 방법으로 웹 페이지와 상호 작용할 수 없습니다.
의견에서 설명한 것처럼 이해 관계자의 목표를 이해하지 못했다고 생각하는 경우 (해당 단어 문서가 상사가 보낸 내용 ...), 더 많이 묻고 사례를 찾는 것이 좋은 방법입니다 이것 때문에.
주기적으로 배우 (개발해야하는 시스템과 상호 작용하는 시스템 및 역할) 및 사례 (개발 된 시스템이 필요로하는 행위자의 요구)를 발견하십시오. 배우를 찾을 때마다, 그가 가지고있는 다른 요구 사항 (가능한 유스 케이스)을 물을 수 있습니다. 유스 케이스를 발견하면 누가 그것에 참여할 것인지, 누가 관심을 갖고 있는지 질문해야합니다 (누가 다음 배우이고 누가 이해 관계자). 그럼 당신은 범위 경계를 정의하고 우선 순위를 지정할 수 있습니다 ...
나는 당신의 의견에 동의한다. 당신은 당신이 의미하는 것을 사람들에게 보여주고, 상반된 아이디어가있는 긴 이메일보다는 정의 할 수있는 필요성을 창조하도록 고객에게 가르쳐야한다. –
이것은 정말 유용한 스레드입니다. 필자는 UML의 사용을 전적으로지지 했음에도 불구하고 팜플렛 사이트의 유스 케이스와 항상 싸웠습니다 ... UX 기관 출력물 인 & 사이에, 특히 기관들이 UML을 사용하지 않는 경향이있는 경우에 종종 전체 요구 사항 스펙 관계를 보장하려고 애쓰는 느낌을 자주 봅니다.
보기 메뉴 /보기 브로셔 페이지 이외에도 적용되는 몇 가지 유스 케이스가 있습니다. 인쇄 페이지, 검색 사이트 등과 같은 사이트 기능은 특정 브로셔를보기 위해 특정 내용을보기 위해 쿠키를 허용하지만 클래식 브로셔는 많지 않습니다. (모든 것은 UX의 결과물을 다시 말해야 할 필요없이 사용자 여행/페르소나에 잘 맞습니다.)
그러나 웹 사이트 콘텐츠를 만들기 위해 CMS와 같은 시스템을 사용한 후에는 유스 케이스가 적절하게 유용하다고 생각합니다 (일반적으로) 여러 명의 행위자가있을뿐만 아니라 콘텐츠 유형별로 다양한 케이스가 있으므로 중복되지 않고 해당 UX 산출물을 참조하고 갭을 채우기 시작할뿐만 아니라 컨텐츠 전략 유형 산출물 (예 : 워크 플로 & 거버넌스)을 비즈니스 프로세스 및 시스템/사용자 상호 작용을 조사하여 파악할 수 있습니다. 모델링 & 사양이 끝나면이 방법으로 유용한 테스트 매트릭스를 얻을 수 있습니다. 객체를 택 소노 미와 관련시키는 클래스 다이어그램 (Functional Rqmts/Specs 단계에서 함께 묶이는 대행사 제공 물).
그것이 요즘 태클을 시도하는 방법입니다.
"브로셔 시청 사이트"는 단지 2 개의 유스 케이스에만 국한되지 않습니까? "브로셔 목록보기 c.q. 가능한 페이지보기", "브로셔/페이지보기"? 그냥 내 생각 ... – Bazzz
그건 정확히 내가 생각하기 때문에, 누군가가 crm이나 맞춤형 애플리케이션으로 변환해야하는 엑셀 스프레드 시트를 통해 단어로 쓰여진 웹 사이트에 대한 someones 설명을 변환하는 것이 매우 어려운 이유입니다. –
2 가지 유스 케이스를 실물 모형으로 만들어 클라이언트와상의하고 어떤 종류의 피드백을 제공하는지 확인해야 할 수도 있습니다.웹 사이트의 작동 방식에 대한 고객의인지 적 이해가 아닌 사례를 추가하려는 것은 아무 소용이 없다고 생각합니다. 기능 상실로 고통받는 고객은 클라이언트가 이러한 기능을 원한다면 그렇게 나쁘지 않습니다. – Bazzz