Instruções para Especificação de Requisitos - ejplatform/ej-meta GitHub Wiki

Instruções para Especificação de Requisitos de Software

O presente documento foi redigido com o objetivo definir procedimentos que permitam facilitar a definição de requisitos de software para o contexto do projeto ejplatform-cpa.

Principais referências incluem Scaled Agile Framework - SAFe (de Dean Leffingwell), Management 3.0 (de Jurgen Appelo) e User Story Mapping (de Jeff Patton).

As definições deste presente documento foram simplificadas e características julgadas dispensáveis foram omitidas com o objetivo de estabelecer de forma enxuta as instruções.

Afirmações do Contexto

Os procedimentos foram definidos para apoiar no contexto do projeto ejplatform-cpa para a primeira release, que possui as seguintes características:

  1. Não há um Product Owner definido que se responsabilizará pela definição dos requisitos em nível de time;
  2. Os requisitos serão definidos apenas para satisfazer as exigências formais do contexto, estes não previstos para ser aplicáveis ao projeto;
  3. Os requisitos serão utilizados para validar o(s) produto(s) de software desenvolvidos.

Desta forma, as definições de requisitos devem:

  1. Ser de fácil compreensão;
  2. Ser de fácil confecção;
  3. Contemplar de forma realística o(s) produto(s) da primeira release;
  4. Contemplar checklists para validações do(s) produto(s) da primeira release.

Ademais, é interessante para a equipe do projeto alinhar-se às características do contexto de forma a simplificar as tarefas ao longo do desenvolvimento do projeto. Com isto, tais instruções foram idealizadas para ser aplicáveis ao projeto.

Instrução A - Camadas

Definir requisitos de software é uma tarefa que deve levar em consideração a quem se destina tais definições.

Por exemplo, definir requisitos para a equipe de desenvolvimento de software exige um detalhamento técnico para permitir a entrega esperada do produto, enquanto que definir requisitos para envolvidos do projeto responsáveis pela tomada de decisões de negócio exige uma abordagem que mitigue riscos e catalise as oportunidades do negócio.

Com isto, dividir a definição de requisitos em camadas de abstração é uma boa prática que facilita o gerenciamento de requisitos.

Camada de Time

Camada operacional do projeto que objetiva garantir que as definições de requisitos satisfaçam os critérios mínimos para desenvolvimento e que também satisfaça as necessidades e interesses dos clientes do produto.

Os principais papéis desta camada são:

  • Time de Desenvolvimento: Responsável por colaborar na definição dos requisitos de time, desenvolver, testar e entregar soluções de software. No contexto atual do projeto, há pelo menos dois times de desenvolvimento (Frontend e Backend);
  • Product Owner: Responsável pela interface entre as necessidades do cliente e as definições dos requisitos para o time de desenvolvimento. Este deve definir e priorizar os requisitos e validar as soluções entregues pelo time de desenvolvimento ao longo de suas iterações. No contexto atual do projeto não há product owners;
  • Scrum Master: Responsável pela consistência operacional do time de desenvolvimento e do product owner. No contexto atual do projeto, há informalmente um scrum master (Prof. Fábio).

Os principais artefatos de requisitos desta camada são:

  • Histórias de Usuário (US): Descrições atômicas de uma determinada funcionalidade esperada pelo atual ou futuro usuário do sistema. São definidas através de título, cartão e critérios de aceitação;
  • Histórias Técnicas (TS): Descrições atômicas de requisitos que devem ser satisfeitas de forma a garantir o desenvolvimento de uma ou mais US. São definidas através de título, descrição e critérios de aceitação;
  • Metas de Iteração (IG): Lista simplificada de metas técnicas e de negócio que são esperadas para a iteração de forma a satisfazer os objetivos de entrega.

Camada de Programa

Camada operacional do projeto que objetiva garantir a entrega contínua de soluções de software. As definições de requisitos desta camada estabelecem as missões de negócio e as funcionalidades esperadas do produto de software.

Os principais papéis desta camada são:

  • DevOps: Responsável pelo gerenciamento e melhoria da(s) pipeline(s) de entrega. No contexto atual do projeto, há informalmente pelo menos dois DevOps (Jonathan e Luan);
  • Product Management: Responsável por identificar as necessidades do cliente, priorizar funcionalidades e definir as metas de projeto e produto. No contexto atual do projeto, há pelo menos três PMs (Prof. Fábio, Henrique e Ricardo).

Os principais artefatos de requisitos desta camada são:

  • Features (FT): Descrições de serviços que satisfazem as necessidades dos stakeholders. São definidas através de título, hipótese e critérios de aceitação;
  • Objetivos de Entrega (PI): Lista simplificada de metas técnicas e de negócio que são esperadas para a entrega do produto.

Camada de Portfolio

Camada organizacional do projeto que objetiva garantir a entrega de valor de negócio. As definições de requisitos desta camada estabelecem as características do negócio e os produtos esperados do projeto.

Os principais papéis desta camada são:

  • Lean Portfolio Management: Responsável pelas estratégias para tomadas de decisão organizacional e pelo gerenciamento contábil do projeto. No contexto atual do projeto, há possivelmente três LPMs (Prof. Fábio, Henrique e Ricardo);
  • Epic Owner: Responsável pela coordenação do segmento do projeto responsável pelo desenvolvimento da épica. No contexto atual do projeto, há um epic owner (Prof. Fábio).

Os principais artefatos de requisitos desta camada são:

  • Épicas (EP): Descrições de produtos ou iniciativas de desenvolvimento. São definidas através de título, hipótese e case;
  • Temas Estratégicos (ST): Lista de definições e constatações estratégicas do contexto de negócio que são avaliadas para tomadas de decisão organizacional.

Instrução B - Rastreabilidade

Ser capaz de rastrear a origem e as interações dos diferentes requisitos é uma característica essencial de engenharia de requisitos.

Por exemplo, dada uma US, qualquer envolvido do projeto pode:

  • Identificar qual FT ela pertence (Rastreabilidade Vertical);
  • Identificar quais US ou TS ela depende ou cria dependência (Rastreabilidade Horizontal);
  • Identificar quais metas (IG/PI) estão associadas a ela (Rastreabilidade Cruzada)

Com isto, estabelecer príncipios e técnicas de mapeamento de requisitos é uma boa prática que facilita o gerenciamento de requisitos.

Rastreabilidade Vertical

Rastreabilidade vertical é a capacidade de identificar quais os requisitos associados da camada superior e quais os requisitos associados da camada inferior para todos os requisitos definidos no projeto.

Há diferentes técnicas para garantir a rastreabilidade vertical de requisitos. A seguir são listadas três possíveis técnicas para o contexto do ejplatform-cpa:

Técnica de Identidade (Bottom-Up)

A identidade dos requisitos da camada mais alta são herdadas para a definição da identidade dos requisitos da camada mais baixa.

Por exemplo:

  • EP1 descreve a primeira EP do projeto;
  • EP1FT1 descreve a primeira FT da primeira EP do projeto;
  • EP1FT1US1 descreve a primeira US da primeira FT da primeira EP do projeto.

Técnica do Sumário (Top-Down)

Cada requisito da camada mais alta possui uma listagem de todos os requisitos da camada mais baixa associada a ele.

Por exemplo:

  • Cada FT possuirá em sua documentação a lista de todas as US associadas a ele;
  • Cada EP possuirá em sua documentação a lista de todas as EP associadas a ele.

Técnica da Matriz de Rastreabilidade (Centered)

Há um documento central que mapeia as interações dos requisitos e que deve ser referenciado em todos os requisitos identificados.

Por exemplo:

  • A tabela US x FT define a matriz de rastreabilidade entre US e FT;
  • Para cada US e FT definida na matriz de rastreabilidade deve existir um link ou referência para o documento de rastreabilidade.

Rastreabilidade Horizontal/Cruzada

Rastreabilidade horizontal é a capacidade de identificar quais os requisitos associados de mesma camada para todos os requisitos definidos no projeto.

Rastreabilidade cruzada é a capacidade de identificar quais os requisitos associados de contextos distintos para todos os requisitos definidos no projeto.

Há diferentes técnicas para garantir a rastreabilidade horizontal/cruzada de requisitos. A seguir são listadas duas possíveis técnicas para o contexto do ejplatform-cpa:

Técnica do Grafo

Na definição de cada requisito deve existir as arestas de associação horizontal.

Por exemplo:

  • Na definição da US deve existir um tópico de Depende de onde haverá referências de outras US/TS na qual ela possui dependência direta;
  • Na definição do IG deve existir um tópico de Aplicada para onde haverá referências de todas as US/TS na qual ela é aplicável.

Técnica da Matriz de Rastreabilidade

Há um documento central que mapeia as interações dos requisitos e que deve ser referenciado em todos os requisitos identificados.

Por exemplo:

  • A tabela US x US define a matriz de dependência entre US e US;
  • Para cada US definida na matriz de rastreabilidade deve existir um link ou referência para o documento de rastreabilidade.