Documentos de requisitos tradicionais possuem, muitas vezes, centenas de páginas e podem levar muito tempo para ficarem prontos. Os profissionais da indústria que apresentaram métodos ágeis perceberam — ou sofreram com — tais problemas e propuseram uma técnica pragmática para solucioná-los que ficou conhecida pelo nome de Histórias de Usuários. Quando usamos histórias de usuários, atividades de Engenharia de Requisitos ocorrem ao longo de todo o desenvolvimento, em praticamente todos os dias de uma iteração. Consequentemente, troca-se um documento de requisitos com centenas de páginas por conversas frequentes, nas quais o representante dos clientes explica os requisitos para os desenvolvedores da equipe. Assim, histórias de usuários favorecem comunicação verbal, em vez de comunicação escrita.

Considere as seguintes afirmações.

I - Histórias não devem ser abertas para negociação. Uma vez definidas, não se pode usar histórias nas conversas entre clientes e desenvolvedores durante um sprint.

II - Histórias devem ser testáveis, isto é, elas devem ter critérios de aceitação objetivos.

III - Histórias devem ser independentes: dadas duas histórias, deve ser possível implementá-las em qualquer ordem. Para isso, idealmente, não devem existir dependências entre elas.

Quais caracterizam corretamente Histórias de Usuários?