요구 사항 문서를 효과적으로 작성하기 – 개요

모든 UX 디자인 프로젝트에서 가장 중요한 부분은 요구 사항 수집 프로세스입니다. 여기에서는 가능한 몇 가지 요구 사항 수집 방법에 대해 간략하게 설명합니다.

좋은 디자인은 모든 비즈니스, 사용자 및 기능 요구 사항을 고려하고 때로는 사용자 의견과 피드백을 기반으로 새로운 기능을 알리고 새로운 요구 사항을 생성하기도 합니다. 빈틈없는 요구 사항 사양에서 작업할 수 없으면 설계의 많은 부분이 가정과 주관에 맡겨집니다. 요구 사항은 프로젝트를 순조롭게 진행하고 설계의 기초를 제공합니다. 견고한 설계는 항상 설계 프로세스의 모든 단계에서 요구 사항과 관련이 있습니다.

프로젝트 요구 사항을 변환하는 방법에는 여러 가지가 있지만 사용 사례, 사용자 스토리 및 시나리오는 이를 캡처하는 데 가장 자주 사용되는 방법입니다. 일부 정교한 프로젝트에는 해당 프로젝트의 모든 결과물에 대한 절대적인 기초를 형성하는 포괄적인 BRD(비즈니스 요구 사항 문서)가 있을 수 있습니다.

나는 이것 각각이 무엇인지, 그리고 각각이 어떤 맥락에서 사용되는지에 대해 조금 더 깊이 들어갈 것입니다 ...

사용 사례란 무엇인가요?

사용 사례는 상호 작용 요구 사항을 도출, 분석 및 모델링할 수 있는 좋은 방법입니다. 또한 인터페이스, 데이터, 프로세스 및 비즈니스 규칙에 대한 관련 요구 사항을 생성하는 데 도움이 됩니다. 사용 사례에서는 사용자가 시스템과 상호 작용하는 방법을 설명하는 기능을 설명합니다. 그것들은 텍스트로 쓰여지고 섹션으로 나뉩니다. 사용 사례는 다음과 같은 형식을 따릅니다.

이름: 사용 사례의 이름

Description: Description of the Use Case

주요 행위자: 이것이 대상이되는 주요 사용자

전제 조건:이 사용 사례를 시작하려면 이미 존재해야 하는 것

방아쇠:이 사용 사례의 시작 부분

기본 흐름: 이상적인 이벤트 흐름

대체 흐름: 발생할 수 있는 다른 가능한 흐름

사후 조건: 수행된 흐름의 결과입니다.

시스템 기능당 하나 이상의 사용 사례가 있을 수 있으며 하나의 사용 사례는 관계를 설정하는 다른 사용 사례를 참조할 수 있습니다. 예를 들어, 관계를 보여주는 사용 사례 다이어그램 또는 순서도를 통해 전체적으로 분석하면 설계 프로세스를 시작하는 데 사용할 수 있는 유효한 요구 사항의 견고한 기반을 제공할 수 있습니다.

이후: Matt Terski마스터 사용 사례 포함 관계

사용자 스토리란 무엇입니까?

Waterfall에서 Agile로 전환하고 있는 많은 개발 팀은 사용자 스토리를 사용하는 것을 좋아합니다. 사용 사례는 고도로 구조화되어 있고 단계를 열거하는 반면, 사용자 스토리는 요구 사항을 명시하여 단계를 설정합니다. 사용자 스토리는 일반적으로 다음과 같이 짧은 문장과 비공식적인 언어로 표현됩니다(예: "교사로서 학생이 액세스하여 작업할 수 있도록 학습 자료를 학교 포털에 업로드하고 싶습니다").

이후: Derek Huether 적격 사용자 스토리란 무엇인가요?

사용자 스토리는 높은 수준의 기능을 수집하고 우선 순위를 지정하는 작업으로 적합합니다. 그들은 본질적으로 골격이며 더 많은 세부 사항이 내장되어 있어야 합니다. 그러나 사용자로부터 이 초기 작업에 대해 배우는 것은 모든 요구 사항을 식별하고 우선 순위를 지정하는 간단한 방법입니다. 그런 다음 이러한 사용자 스토리는 비즈니스 요구 사항 및 사용 사례로 변형됩니다.

시나리오란 무엇입니까?

시나리오는 개인과 시스템의 상호 작용에 대한 내러티브 설명입니다. 이는 일반적으로 구매 결정, 기술 또는 제품 사용, 라이프스타일 선택 등에서 유사한 행동 패턴을 보이는 사용자 그룹을 나타내는 사용자 페르소나와 연결됩니다. 대상 사용자 그룹을 중심으로 시나리오를 작성하면 기능 또는 비즈니스 요구 사항과는 구별되는 사용자의 요구 사항에 디자인 작업을 집중할 수 있습니다. 시나리오는 둘 다 비공식적이고 비기술적인 언어로 작성된다는 점에서 사용자 스토리와 유사합니다. 시나리오는 일반적으로 더 길며 추가 컨텍스트 정보를 제공합니다. 시나리오에 포함된 세부 정보 수준은 사용 사례와 비슷하지만 시나리오에는 사용 사례와 같은 공식 구조가 없습니다. 이로 인해 시나리오를 관련 부분으로 해결하는 것이 번거로울 수 있습니다. 그러나 사용 사례와 달리 시나리오는 기술적 배경이 없는 사람도 작성하고 이해할 수 있습니다.

After: Eric Schaffer  UI Design Newsletter , HFI

다음은 영업 관리자의 일상 활동을 설명하는 세 가지 방법의 예입니다.

Scenario

John은 영업 팀을 더 잘 관리하려고 합니다. 이를 위해 그는 팀의 사람들 목록을 볼 필요가 있습니다. 영업 사원 이름이나 지리적 위치 또는 고객별로 검색하려고 합니다. 그는 수색을 통해 아담을 찾습니다. 그는 Adam의 고객과 판매 기록을 보고 싶어합니다.

User Story

영업 관리자로서 로그인하여 팀원 목록을 조회하고 싶습니다. 내 팀 구성원 및 이와 관련된 판매 기록을 조회할 수 있는 검색 옵션을 원합니다.

Use Case

이름	Sales Person Lookup
설명	이는 영업 관리자가 자신의 팀의 특정 영업 사원에 대한 정보에 액세스하기 위해 수행하는 활동을 설명하는 사용 사례입니다
기본 액터	영업 관리자
Precondition	관리자 권한으로 로그인해야 합니다.
Trigger	사용자가 대시보드에서 액세스했습니다.
Basic Flow	User	System
	사용자가 미국 지도의 NE 지역에 액세스합니다.	NE US 페이지의 시스템 필터 정보
	사용자가 모든 영업 사원 목록에 액세스합니다.	시스템에 전체 영업 사원 목록이 표시됩니다.
	사용자가 영업 사원 목록에서 Adam을 선택합니다.	시스템에 Adam의 정보 및 판매 기록이 표시됩니다.
Alternate Flow	User	System
	사용자는 "Adam"을 검색 문자열로 사용하여 검색 엔진을 사용합니다.	이름 또는 성에 "Adam"이 포함된 모든 영업 사원에 대한 검색 결과 목록이 표시됩니다.
	사용자가 검색 결과에서 'Adam'을 선택합니다.	시스템에 Adam의 정보 및 판매 기록이 표시됩니다.
사후 조건	모든 조건이 충족되면 사용자는 자신이 검색한 영업 사원의 세부 정보를 볼 수 있습니다.

요구 사항 작성을 위한 이러한 모든 기술은 요구 사항을 효과적인 방식으로 통합하고 표시하는 방법이며 설계에 포함하는 특정 방법을 지시하지 않습니다. 예를 들어, 이 사용 사례의 조회 목록은 UI에서 드롭다운 메뉴, 목록 상자 또는 그리드로 처리할 수 있으며, 이는 디자이너가 결정할 수 있습니다. 즉, 요구 사항은 사용자가 작업을 수행하기 위해 갖추어야 하는 일련의 능력만 요구합니다.

개인적으로 저는 디자인에 사용 사례와 시나리오를 조합하여 사용하는 것을 좋아합니다. 이에 대한 예외가 있는데, 프로젝트에 대한 정교한 요구 사항을 생성할 전문 지식이나 시간 및 관심이 없는 고객의 구두 브리핑으로 작업해야 했습니다. 그리고 고객이 자신의 세부 요구 사항을 항상 알지 못하는 상황이 있습니다. 디자이너에게는 훌륭한 프로젝트 시작은 아니지만 ... 이러한 고객을 돕는 가장 좋은 방법은 디자인 프로세스를 안내하고 브레인스토밍을 사용하여 아이디어를 생성한 다음 이러한 아이디어를 구체적인 요구 사항으로 변환하는 것입니다.