Como escrever um documento de requisitos de negócios de forma ágil

Os clientes querem o que pagam. As empresas querem clientes satisfeitos. Este mantra simples se encaixa em todos os elementos do mundo dos negócios.

A partir de uma perspectiva de TI, as organizações esperam que o software que compram funcione da maneira prometida pela empresa que o vendeu. E a empresa espera que seu produto dê como resultado um cliente satisfeito.

Uma organização de TI deve ter documentação clara e completa que resuma, em termos comerciais, o que deve entregar a um cliente. A equipe pode atender a essa demanda com um documento de requisitos comerciais.

Avaliaremos a seguir o papel de um documento de requisitos comerciais (BRD, por sua sigla em Inglês), como as equipes ágeis e não-ágeis convertem os requisitos em código de trabalho e como determinar se o equipamento cumpriu com os requisitos comerciais.

Como um BRD define expectativas

Um BRD descreve o propósito comercial de um projeto. Ele define como produzir o produto, inclusive seu objetivo, como funciona e o uso previsto pelo cliente. Com um BRD a empresa pode avaliar os possíveis fatores de custo e restrições e uma linha de tempo ou cronograma para o projeto de software. Um BRD representa um contrato básico entre o cliente e o fornecedor; descreve as expectativas e resultados do projeto. Além disso, estabelece os padrões para o sucesso do projeto.

Antes que qualquer organização de TI crie um aplicativo para clientes ou partes interessadas no negócio, você deve entender como criar um BRD detalhado, especialmente para o uso de equipes ágeis.

Como requisitos funcionais e comerciais se diferenciam

Embora os termos sejam frequentemente usados de forma intercambiável, os requisitos comerciais não são os mesmos que os requisitos funcionais de um projeto. Os requisitos comerciais descrevem os produtos finais de que os clientes precisam, mas não como alcançá-los.

Os requisitos funcionais cobrem como atender às expectativas do cliente com um produto de software. Você pode ter documentação de requisitos de software separadamente para projetos de desenvolvimento ou uma seção de requisitos funcionais no BRD. Estes requisitos funcionais detalham como deve operar um sistema para cumprir com os requisitos comerciais.

Como usar BRD no desenvolvimento ágil

Na metodologia ágil, o proprietário do produto ou o representante do cliente geralmente define as características do produto. As características são consideradas uma épica no ágil, e essas epopéias abrangem tudo o que foi definido no BRD. O gerente de projeto ágil trabalha com o dono do produto para traduzir o BRD em uma série de epopeias que definem o produto. Esses dois então traduzem as características em histórias de usuários. Aqui, os desenvolvedores cumprem os requisitos funcionais para atender os requisitos comerciais.

Uma história de usuário descreve brevemente algo de valor para um usuário ou cliente alvo. A seguir mostramos um exemplo do formato de história do usuário:

"Como < tipo de usuário / função>, eu <quero/desejo>, então <algum motivo/benefício>".

A história do usuário também inclui critérios de aceitação, que descrevem o que a função deve realizar e como os desenvolvedores podem determinar se a história do usuário teve êxito ou fracassou.

Muitos grupos de desenvolvimento desmembram ainda mais as histórias de usuário em tarefas e/ou sub-tarefas que se concentram em diferentes componentes do sistema. Por exemplo, as tarefas cobrem o trabalho na interface de usuário, o back-end ou a base de dados que a equipe de desenvolvimento precisa terminar para completar a história.

https://cdn.ttgtmedia.com/rms/onlineimages/software_quality-how_epics_become_agile_team_tasks-f_desktop.png

Como gerenciar as mudanças no BRD

Muitas equipes não-ágeis utilizam um processo de gestão de configuração bem definido para fazer um monitoramento dos requisitos de um projeto. Este processo utiliza ferramentas de gestão de requisitos automatizadas para fazer uma referência cruzada de cada requisito que os desenvolvedores utilizam para criar uma matriz de rastreabilidade. Essa matriz ajuda a confirmar que a equipe de desenvolvimento atendeu a cada requisito e que o desenvolvimento cria apenas artefatos vinculados aos requisitos. A gestão de documentos e requisitos é da responsabilidade de um painel de controle de configuração.

No ágil, a equipe mantém a relação entre a função de produto de nível superior e tarefas de desenvolvimento de nível inferior através de uma relação pai / filho. O gerente de projeto ágil e o proprietário do produto vinculam todas as histórias dos usuários a sua história principal e todas as tarefas e subtarefas são conectadas a sua história de usuário principal. Esta relação e fluxo inerentes permitem ao gerente de projeto ágil rastrear facilmente seu progresso. A configuração também permite ao proprietário do produto administrar ou reorganizar o trabalho em função das prioridades iniciais ou alteradas.

Como reagir a mudanças nos requisitos comerciais

Os clientes podem fazer solicitações de alteração (RFC, por sua sigla em inglês) e os fornecedores podem redigir e aprovar os requisitos comerciais revisados. Porém, os RFC podem significar custos extras e prazos mais longos para as equipes de desenvolvimento. Ademais, a gestão destas alterações é diferente no desenvolvimento ágil e não-ágil.

Os equipamentos de cascata e outros estilos de desenvolvimento muitas vezes controlam ativamente mudanças possíveis nos documentos de requisitos comerciais através do painel de controle de alterações. Este organismo aprova antecipadamente as alterações solicitadas e, por vezes, também confirma que as alterações aprovadas foram realizadas de acordo com as especificações dos clientes.

As mudanças em ágil tomam forma seja como epopéias adicionais ou histórias de usuários adicionais de acordo com o escopo da RFC. Não existe um painel de controle nas equipes ágeis, e o proprietário do produto, que trabalha em conjunto com a equipe de desenvolvimento, cumpre essa função. Na medida em que o cliente ou as partes interessadas no desenvolvimento estejam de acordo com as mudanças de funções, a equipe ágil escreve novas histórias de usuário que o proprietário do produto deve priorizar no trabalho pendente para os desenvolvedores. Posteriormente, a equipe de desenvolvimento deve revisar essas histórias nas sessões de preparação dos trabalhos pendentes e criar as tarefas necessárias. A matriz de rastreabilidade do BRD é inerente à relação pai/filho entre epopéias e histórias.

Como medir o cumprimento dos requisitos comerciais

As equipes ágeis medem o sucesso em cada nível do processo de desenvolvimento.

No nível de lançamento, o proprietário do produto continuamente faz concessões no escopo, prazo, orçamento e qualidade à medida em que chega um fluxo de informação economicamente importante para o desenvolvimento do produto. Em última instância, as equipes ágeis podem medir o sucesso neste nível através da entrega a tempo das características do produto que o proprietário do produto se comprometeu a entregar.

Para chegar a essa entrega, a equipe ágil deve realizar as tarefas, completar as histórias de usuário e testar a aceitação de cada função. A nível de tarefa, os testes individuais no código verificam se atende o limiar necessário para comprometer-se. A nível de história de usuário, os membros da equipe utilizam critérios de aceitação para determinar se satisfazem aspectos específicos da função. Quando os desenvolvedores completam todas as histórias de usuários com sucesso, a equipe pode realizar testes de aceitação dos usuários na função ou na épica.