Como trato os aspectos do aplicativo com relação a recursos e histórias de usuários?

Ao elaborar uma lista de pendências, tenho vários requisitos que se aplicam a muitas histórias de usuários, ou seja, aspectos do aplicativo, como tratamento de erros e feedback. Como os incluo (sem usar uma diretiva #include em cada história de usuário)? Devo tratar a apresentação de erros como um recurso e ter histórias de usuários para esse recurso como "o sistema captura uma exceção e mostra informações ao usuário"?

Lidar com o feedback do usuário é fundamental para a experiência do usuário, mas também se aplica a diferentes partes do aplicativo de maneiras diferentes.

Veja os dois exemplos a seguir:

Uma história pode se concentrar em uma interação direta do usuário na qual ocorre um erro fatal. Uma caixa de diálogo modal é usada para informar o usuário sobre o erro e notificar que a recuperação é impossível. A história para isso seria: "Como usuário, quero ser informado sobre uma entrada inválida de algum formulário de dados para que eu possa voltar e corrigir esse erro imediatamente" . Esta história de usuário implica que este é um erro fatal de bloqueio que o usuário precisa corrigir imediatamente.

Em uma segunda história, o usuário esquece de inserir dados obrigatórios em um formulário. A história seria: "Como usuário, quero que os campos ausentes de uma entrada sejam destacados para que eu saiba quais são os campos obrigatórios".

Essa notificação sutil é muito diferente e não pode ser combinada com a primeira história em uma história geral de manipulação de erros. No entanto, ambos podem surgir de exceções internas.

Lembre-se de que é importante transmitir o "quê" de uma história, por exemplo, o cenário de erro que deve ser tratado em uma situação específica. O como do erro (ou seja, uma exceção está sendo lançada em algum lugar) é quase irrelevante para o proprietário do produto, pois não possui valor comercial. Do ponto de vista técnico, ter uma arquitetura sólida é algo que eu esperaria do meu produto de qualquer forma.

No final, você ganhará flexibilidade e extensibilidade concentrando-se no valor comercial e terá histórias de usuários pequenas e bem separadas .

Acredito que a solução é uma boa separação de preocupações. Coisas como manipulação de erros, registro em log, feedback e outras devem ser tratadas globalmente com apenas um pedaço de código. Somente requisitos diferentes desse comportamento global devem ser observados como parte das histórias de usuários ou na discussão sobre a implementação da referida história de usuário.

Portanto, do lado do gerenciamento de projetos, deve haver uma história do usuário, que diga "Como usuário, quero ver o erro dessa maneira, que me permita denunciá-lo ao administrador". ou algo assim. E essa história de usuário deve ser aplicada como regra global a todos os casos de uso.

Uma ideia (retirada do SCRUM): as coisas que precisam ser verificadas para cada história de usuário são incluídas na chamada "definição de pronto" .

Normalmente, "definição de concluído" inclui coisas técnicas, como:

• todos os testes são verdes
• código está razoavelmente limpo
• código não causa regressões

Mas também pode incluir coisas visíveis ao usuário:

• nenhuma operação do usuário leva mais de um segundo, ou
• todos os controles da GUI podem ser usados ​​apenas com o teclado

A equipe deve verificar a "definição de concluído" para cada história de usuário antes de declarar que está concluída.

Uma opção seria incluir o tratamento de erros apropriado nessa "definição de concluído". No entanto, como as outras respostas apontam, os exemplos que você cita (tratamento de erros e feedback) provavelmente não são realmente bons exemplos de requisitos que se aplicam "em qualquer lugar":

O tratamento e feedback adequados de erros geralmente dependem do contexto, portanto, ele precisa ser definido separadamente para os locais onde é necessário. Portanto, nesse caso, pode ser melhor formular o tratamento de erros como histórias de usuários separadas, conforme explicado pela resposta da malte.