Escrevendo documentos de requisitos de forma eficaz - uma visão geral

Em todo projeto de UX Design, a parte mais importante é o processo de coleta de requisitos. Esta é uma visão geral de alguns dos métodos possíveis de coleta de requisitos.

Um bom design levará em consideração todos os requisitos de negócios, usuários e funcionais e às vezes até informará novas funcionalidades e gerará novos requisitos, com base nos comentários e feedback dos usuários. Sem especificações de requisitos estanques para trabalhar, grande parte do design é deixado para suposições e subjetividade. Os requisitos colocam um projeto nos trilhos e fornecem uma base para o design. Um design robusto sempre está vinculado aos seus requisitos em todas as etapas do processo de design.

Embora existam muitas maneiras de traduzir os requisitos do projeto, casos de uso, histórias de usuários e cenários são os métodos usados com mais frequência para capturá-los. Alguns projetos elaborados podem ter um Documento de Requisitos de Negócios (BRD) abrangente, que forma a base absoluta para todas as entregas desse projeto.

Vou me aprofundar um pouco mais no que é cada um deles e em que contexto cada um é usado ...

O que é um caso de uso?

Os casos de uso são uma ótima maneira de obter, analisar e modelar requisitos de interação. Além disso, eles ajudam a gerar requisitos relacionados para interfaces, dados, processos e regras de negócios. Os casos de uso descrevem a funcionalidade que explica como os usuários interagem com um sistema. Eles são escritos como texto e divididos em seções. Os casos de uso seguem um formato como este:

Nome: Nome do caso de uso

Description: Description of the Use Case

Ator Principal: O usuário principal a quem isso se destina

Pré-condição: O que já deve existir para que este caso de uso comece

Gatilho: O que inicia este caso de uso

Fluxo básico: O fluxo ideal de eventos

Fluxo alternativo: Outros fluxos possíveis que podem ocorrer

Condição do post: O resultado do fluxo que foi realizado.

Pode haver um ou vários casos de uso por função do sistema e um caso de uso pode se referir a outro caso de uso que estabelece um relacionamento. Analisá-los como um todo – por exemplo, por meio de um diagrama de caso de uso ou fluxograma que mostra seus relacionamentos fornece uma base sólida de requisitos válidos para iniciar o processo de design.

Depois: Matt Terskidomina o caso de uso inclui relacionamento

O que é uma história de usuário?

Muitas equipes de desenvolvimento que estão mudando do Waterfall para o Agile gostam de usar User Stories. Embora um caso de uso seja altamente estruturado e enumere as etapas, a história do usuário prepara o terreno declarando a necessidade. As histórias de usuários são normalmente redigidas em frases curtas e em uma linguagem informal, como esta: "Como professor, gostaria de fazer upload de materiais de estudo para o portal da escola, para que meu aluno possa acessá-los e trabalhar com eles".

Depois: Derek Huether O que é uma história de usuário qualificado?

As histórias de usuário são ótimas como uma atividade para coletar e priorizar os recursos de alto nível. Eles são de natureza esquelética e precisam de mais detalhes embutidos. No entanto, aprender sobre essa tarefa inicial com o usuário é uma maneira simples de tentar identificar e priorizar todas as suas necessidades. Essas histórias de usuário se transformarão nos requisitos de negócios e casos de uso.

O que é um cenário?

Um cenário é uma descrição narrativa da interação de uma pessoa com um sistema. Normalmente, eles estão vinculados a uma Persona de Usuário que representa um grupo de usuários que exibem padrões comportamentais semelhantes em suas decisões de compra, uso de tecnologia ou produtos, escolhas de estilo de vida, etc. Quando os cenários são criados em torno de um grupo-alvo de usuários, isso ajuda a concentrar os esforços de design nas necessidades do usuário, que são distintas dos requisitos funcionais ou de negócios. Os cenários são semelhantes às histórias de usuários, pois ambos são escritos em uma linguagem informal e não técnica. Os cenários geralmente são mais longos e fornecem informações contextuais adicionais. O nível de detalhe apresentado pelos cenários é comparável aos casos de uso, mas os cenários não têm a estrutura formal que os casos de uso têm. Isso pode dificultar a resolução de um cenário em suas partes relevantes. Ao contrário dos casos de uso, no entanto, os cenários podem ser criados e compreendidos por pessoas que não têm nenhum conhecimento técnico.

After: Eric Schaffer  UI Design Newsletter , HFI

A seguir estão exemplos de todas as três maneiras de descrever as atividades diárias de um gerente de vendas:

Scenario

John quer gerenciar melhor sua equipe de vendas. Para isso, ele precisa ver uma lista de pessoas em sua equipe. Ele deseja pesquisar por nome de vendedor ou localização geográfica ou por cliente. Ele encontra Adam através de sua busca. Ele quer ver os clientes de Adam e seus registros de vendas.

User Story

Como gerente de vendas, gostaria de fazer login e procurar uma lista dos membros da minha equipe. Gostaria de uma opção de pesquisa para pesquisar os membros da minha equipe e os registros de vendas associados a ela.

Use Case

Nome	Sales Person Lookup
Descrição	Este é um caso de uso que descreve a atividade que um gerente de vendas executaria para acessar informações sobre um vendedor específico de sua equipe
Ator Principal	Gerente de Vendas
Precondition	Deve estar conectado com direitos de Gerente
Trigger	O usuário acessou no painel
Basic Flow	User	System
	Usuário acessa a região NE no Mapa dos EUA	Informações dos filtros do sistema na página para NE US
	O usuário acessa uma lista de todos os vendedores	O sistema exibe a lista completa de vendedores
	O usuário seleciona Adam na lista de vendedores	O sistema exibe as informações e o registro de vendas de Adam
Alternate Flow	User	System
	O usuário utiliza um mecanismo de pesquisa usando "Adam" como uma string de pesquisa.	O sistema exibe uma lista de resultados de pesquisa para todos os vendedores cujo nome ou sobrenome contém "Adam"
	O usuário seleciona 'Adam' nos resultados da pesquisa	O sistema exibe as informações e o registro de vendas de Adam
Pós-condição	Quando todas as condições são atendidas, o usuário vê os detalhes do vendedor que ele pesquisou

Todas essas técnicas para escrever requisitos são maneiras de consolidá-los e apresentá-los de maneira eficaz e não ditam nenhuma maneira específica de incluí-los no design. Por exemplo, a lista de pesquisa neste caso de uso pode ser abordada na interface do usuário como um menu suspenso ou uma caixa de listagem ou uma grade que cabe ao designer decidir... Dito isso, os requisitos pedem apenas um conjunto de habilidades que um usuário deve ter para realizar uma tarefa.

Pessoalmente, gosto de usar uma combinação de casos de uso e cenários para meus projetos. Há exceções a isso em que tive que trabalhar com briefings verbais de clientes, que não têm experiência ou tempo e interesse para gerar requisitos elaborados para um projeto. E há situações em que os clientes nem sempre conhecem seus requisitos detalhados. Não é um ótimo começo de projeto para designers, mas ... A melhor maneira de ajudar esses clientes é orientá-los no processo de design, usar o brainstorming para gerar ideias e, em seguida, traduzir essas ideias em requisitos concretos ao longo do caminho!