Por estar no contexto do wireframe (próxima seção), é mais conciso. Você pode simplesmente fazer referência ao nome do campo, em vez de declarar detalhadamente tudo sobre o campo. Você pode manter os detalhes no comprimento do campo, obrigatório etc.

Fluxo de Trabalho
Isso deve incluir uma imagem das telas envolvidas (você fará isso na IHC e no protótipo das telas;
riqueza de detalhes é fundamental). Os estados de erro (incluindo as telas de mensagem de erros) e
as alterações de visualização com base na função devem ser documentados. Aqui, uma imagem vale
mais que mil palavras, pois os detalhes do fluxo através do recurso podem ser bastante complexos,
e é difícil explicar os detalhes na próxima seção (aqui, visão é tudo, me desculpem os sinestésicos e
auditivos).

Segue uma lista de alguns para você usar na construção de sua aplicação. Eles ajudarão a explicar o
sistema através de fluxos e vão apoiar no desenvolvimento. Suas versões demo vão permitir que
você utilize pelo tempo desse desafio, tranquilamente, portanto, não “durma no ponto”. São todos
amigáveis e não precisam de curso para usar. Use e abuse:

Detalhamento dos Requisitos
Esses são os detalhes do recurso. Documente todas as telas e todos os campos, rótulos, validações,
mensagens e ações. Esta é essencialmente a especificação funcional dos detalhes da(s) tela(s)
envolvida(s). Por estar no contexto do wireframe (próxima seção), é mais conciso. Você pode
simplesmente fazer referência ao nome do campo, em vez de declarar detalhadamente tudo sobre
o campo. Você pode manter os detalhes no comprimento do campo, obrigatório etc.

Casos de Uso
No início de um projeto, você precisa de vários dias para elicitar e, por que não, prever os requisitos
de alto nível e entender o escopo, nesse caso, é o que você acha que o sistema deve fazer.

Seu objetivo é ter uma ideia do que é o projeto, não documentar em detalhes a operacionalidade do
sistema.

A documentação pode vir mais tarde, se você realmente precisar dela. Para seu modelo de
requisitos inicial, minha experiência é que você precisa de alguma forma de:

Modelo de uso: permite que você explore como os usuários trabalharão com seu
sistema. Pode ser uma coleção de casos de uso essenciais ou uma coleção de histórias
de usuário;

Modelo de domínio inicial: identifica os tipos de entidade de negócios fundamentais e os
relacionamentos entre eles. Os modelos de domínio podem ser descritos como uma
coleção de cartões, um diagrama de classe macro, ou até mesmo um modelo de dados
geral. Este modelo de domínio conterá apenas informações suficientes: as principais
entidades do domínio, seus principais atributos e os relacionamentos entre essas
entidades. Seu modelo não precisa ser completo, ele só precisa cobrir informações
suficientes para que você se sinta confortável com os conceitos de domínio primário.
(coloquei literatura de referência na sessão de Material Complementar e deve ser
mandatoriamente lida, por gentileza);

Modelo de interface do usuário: para projetos intensivos de interface de usuário, você
deve considerar o desenvolvimento de alguns esboços de tela, ou até mesmo um
protótipo de interface de usuário. (conforme coloquei no tópico Wireframe desse
material).

Mas afinal, que nível de detalhes você realmente precisa?

Minha experiência é que você precisa de artefatos de requisitos que sejam bons o suficiente para lhe
dar esse entendimento e nada mais, portanto, pense simples, porém direto.

Veja esse exemplo de um caso de uso geral:

Nome do caso de uso geral (macro): Inscrever-se numa Disciplina
Curso Básico de Ação (trata-se de um caso de uso normal):

Aluno digita seu nome e número de aluno;

O sistema verifica se o aluno está qualificado para se inscrever no curso. Se não for
elegível, o aluno será informado e o caso de uso será encerrado;

O sistema exibe uma lista de disciplinas do curso disponíveis (naquele mês);

O aluno escolhe uma disciplina ou decide não se inscrever;

O sistema valida se o aluno está qualificado para se inscrever naquela disciplina (pode
haver disciplinas anteriores como pré-requisito). Se não for elegível, o aluno é
convidado a escolher outra disciplina;

O sistema valida se a disciplina se encaixa na trilha de aprendizagem do aluno;

O sistema calcula e exibe as taxas para que o aluno pague por aquela disciplina;

O aluno verifica o custo e indica que deseja se inscrever ou não;

O sistema inscreve o aluno na disciplina e cobra por ela;

O sistema imprime o comprovante de inscrição na disciplina quando o departamento de
contas a receber der baixa no crédito.

A descrição acima contém informações suficientes para você entender o que o caso de uso escrito
faz e, na verdade, pode conter informações demais para este ponto do ciclo de vida, já que apenas o
nome do caso de uso pode ser suficiente para que o time de desenvolvimento ou outra parte
interessada entenda os fundamentos do que se pede.

Porém, podemos detalhar isso, num caso de uso mais aprofundado, a que chamaremos de caso de
uso expandido.