Como a ISO 29148 ajuda no grooming do backlog de solução

Especificar para documentar os requisitos

A modelagem e especificação são descritos como dois processos diferentes, porque enquanto o desenvolvimento do tema modelagem coloca ênfase no desenvolvimento – revelação – dos requisitos e na sua comunicação com as partes interessadas no negócio, o desenvolvimento deste segundo tema coloca ênfase na transmissão da informação para a equipe de desenvolvimento; ainda que ambas as atividades exijam a produção de informação compreensível por todas as partes.

A especificação de requisitos documenta os diferentes tipos de requisitos. Um dos principais objetivos na Engenharia de Requisitos é facilitar o sucesso na comunicação ao longo de todo o desenvolvimento. Aquele que segue as orientações nesse livro afasta-se da infame figura do “preenchedor de templates“. O formato da documentação resultante da especificação de requisitos depende da organização, das necessidades do projeto e do ciclo de vida utilizado.

Por exemplo, as histórias de usuário serão os documentos que descrevem o estoque de requisitos a ser entregue quando se utiliza de uma abordagem Ágil de desenvolvimento; enquanto que se uma abordagem derivada do Processo Unificado é utilizada, então as listas de requisitos cumprem esse papel.

A especificação de requisitos não precisa necessariamente cobrir todo o escopo, mas pode representar a informação disponível em determinado momento no tempo.

Por que especificação?

O [PMI, 2015] fornece uma relação bastante completa com a motivação para especificar requisitos. Ela está transcrita a seguir:

• Estabelece uma linha de base para:
  • Validar as necessidades das partes interessadas;
  • Definir a solução para as necessidades de negócio;
  • A evolução da solução;
• Fornece insumo para:
  • A equipe de projeto (design), os desenvolvedores, analistas de testes e garantia de qualidade;
  • O manual do usuário e outros tipos de documentação sejam eles impressos ou embarcados;
• Fornece detalhamento de suporte para:
  • Acordos contratuais, quando aplicáveis; por exemplo, os requisitos são insumos centrais para a declaração de trabalho (SOW) ou para uma solicitação de proposta (RFP);
  • Auditoria em indústrias reguladas e projetos de alto risco que tem como exigência seus requisitos documentados.
• Viabiliza reutilizar informação por outros times de projeto que necessitam de um entendimento dos requisitos enquanto o projeto está em processo de implementação ou posteriormente.

O PMI também registra, de maneira muito apropriada, que apesar da importância de documentar os requisitos, deve-se manter em mente que a documentação de requisitos é apenas uma de várias técnicas para garantir o consenso entre todas as partes interessadas quanto ao comportamento esperado da solução (como explorado na seção anterior) e que a documentação não deveria substituir a comunicação e a colaboração.

Quando elaborar uma especificação?

Há vários momentos em que se faz necessário elaborar documentos com especificações de requisitos. Dependendo do momento em que se esteja, há diferentes necessidades de informação, cujas respostas devem ser capturadas em especificações de requisitos. O esquema apresentado no Capítulo 06 – As atividades da Engenharia de Requisitos – descreve um processo genérico com três marcos associados e que é útil para discutir a especificação de requisitos conforme esses momentos.

Descrevem-se as especificações relativas aos objetivos de informação que devem ser alcançados até o primeiro marco: A qualificação do domínio do problema, as necessidades de negócio e um escopo em termos de áreas funcionais, organizações afetadas e macro processos afetados; possivelmente uma lista de características para a solução ainda muito geral e pouco específica.

Esta seção aborda ações para atingir os outros objetivos de:

• Qualificar especificamente quais são as tarefas transferidas para o software; e
• Descrever o comportamento que se espera do software no que tange a essas tarefas.

Como elaborar uma especificação?

Nesse sentido, o mínimo do mínimo que se necessita especificar são os requisitos identificados no nível do objetivo do usuário, expressos em sentenças textuais. Mesmo no desenvolvimento usando abordagens Ágeis e que priorizam a colaboração, há necessidade de especificações associadas a esse mínimo. Os adeptos do SCRUM, por exemplo, têm no Product Backlog a especificação de histórias de usuário que compõem escopo inicial para o desenvolvimento.

Essas sentenças textuais devem:

• Expressar um é apenas um requisito por vez;
• Evitar cláusulas condicionais complexas;
• Usar uma terminologia consistente;
• Expressar requisitos com uma sentença com verbo em voz ativa;
• Indicar claramente o que ou quem é responsável pelo requisito;

Para requisitos associados à manutenção de dados cadastrais – os denominados “CRUD” – a prática comum é usar o verbo “manter”. Por exemplo, uma sentença “Manter Produto” (ou “Manter Cadastro de Produto”) é uma sentença que remete ao incluir, consultar, atualizar e excluir um registro de produto.

Elas não devem assumir que o leitor tenha um conhecimento prévio do domínio.

Por exemplo, a sentença na Tabela 8.2 expressa vários requisitos e inclui cláusulas condicionais.

Tabela 8.2: Como não especificar requisitos por sentenças textuais.

Os mesmos requisitos deveriam ser reestruturados conforme a Tabela 8.3.

Tabela 8.3: O resultado da reformulação das sentenças textuais.

A representação das condicionantes que se aplicam em um nível superior, no encadeamento dos processos em que os requisitos se inserem, deve ser feita por meio da modelagem de processos, por exemplo.

O detalhamento dos requisitos identificados nas sentenças textuais pode ser realizado por meio de casos de uso e especificações de regras de negócio ou mesmo outros métodos não documentais como a prototipação. Quanto às especificações de mudança, segue a mesma lógica.

Deve-se ressaltar que alcançar o marco de consolidação do escopo não implica em esgotar a identificação de todos os requisitos, assim como alcançar o marco do detalhamento dos requisitos não implica em esgotar a descrição do passo-a-passo e das regras de negócio que se apliquem a esses requisitos.

Ou seja, ainda que o marco de consolidação do escopo seja alcançado, é possível que ainda haja itens de importância secundária em cinza – escondendo vários requisitos funcionais e não funcionais a descobrir como dentro do escopo (preto) ou fora (branco) em requisitos como “emitir relatórios gerenciais”. Ainda que o projeto tenha ultrapassado o marco citado, novas especificações indicando quais requisitos funcionais farão parte do escopo serão elaboradas como histórias do usuário ou elementos em uma lista de requisitos mais refinada.

Não se descarta a hipótese de elaborar especificações de requisitos após o projeto, implementação, testes, etc. que, obviamente, não as puderam utilizar. Certamente, não se recomenda essa prática. Coloca-se como uma possibilidade com um intuito de minimizar danos, porque ao menos se retém a informação numa perspectiva de requisitos e desde que haja a intenção de promover sua atualização conforme o produto evolui.