Atividades e Técnicas de Engenharia de Requisitos (ER)¶

Introdução¶

As atividades e técnicas de Engenharia de Requisitos desempenham uma função essencial no desenvolvimento e na construção de um Software que busca atender as necessiades de seus Stakeholders.

Desta forma, temos as seguintes atividades de ER:

• Elicitação e Descoberta
• Análise e Consenso
• Declaração
• Verificação e Validação
• Representação
• Organização e Atualização

No que diz respeito as técnicas de engenharia de requisitos definidas na primeira missão na página Introdução à Engenharia de Requisitos para o planejamento inicial, mantivemos uma estrutura similar ao que previamente havíamos estabelecido, alterando somente alguns métodos que faziam mais sentido para o desenvolvimento dos artefatos nesse momento.

Dessa forma, para a definição do Backlog inicial, utilizamos a metodologia (SAFE) a partir de um conjunto de técnicas das atividades da Engenharia de Requisitos para definir os Épicos, Capacidades, Funcionalidades e Histórias de Usuário.

A seguir a tabela abaixo identifica as atividades e técnicas utilizadas para definição do Backlog inicial:

Elicitação e Descoberta - Storyboard e Brainstorming¶

Regularmente sendo tida como um dos primeiros passos no processo de Engenharia de Requisitos, a partir dela podemos identificar uma fonte de informação (Documento, Stakeholders, etc..), visando escolher a técnica mais apropriada para aquele contexto. Além disso, apartir dessa técnica, podemos descobrir e extrair algo que previamente não era conhecido.

Inicialmente para Elicitação e Descoberta, utilizamos um Storyboard, pensamos em utilizar essa técnica ao invés de qualquer outra, pois nos ajudaria a visualizar quem são os nossos clientes e a quem é destinado o nosso produto.

Portanto, para isso definimos em reunião três personas envolvidas no nosso projeto, descrevendo o que elas fazem e esperam do Crystaleum. Sendo elas:

Posteriormente, cada um dos membros identificou ideias que queria executar no projeto. A partir disso, foi realizado uma dinâmica de StoryBoard iterativo, de forma que todos os membros puderam colaborar com novas ideias para o jogo. A seguir, exemplo de um dos produtos gerados através da técnica escolhida. As demais podem ser encontradas no Miro do projeto.

Além disso, nessa fase da Elicitação e Descoberta, atráves da reunião do grupo também foi utilizado um Brainstorming de ideias. A técnica foi escolhia por se apoiar muito na criativade e na imaginação, tendo como objetivo que cada membro gerasse o máximo possível de ideias e agrupassem-nas. Desta maneira, identificamos sua importância para encontrar possíveis problemas e soluções para o projeto, assim como também identificar os requisitos funcionais e não funcionais.

Segue o Brainstorming de ideias que pensamos sobre possíveis problemas:

Análise e Consenso - Feedback¶

É uma forma de identificar possíveis conflitos ou incongruências entre os requisitos, a partir de uma análise desses requisitos em suas formas "brutas". Por meio do consenso, podemos estabelecer um concilio entre possíveis fontes de informações divergentes e estabelecer uma compreensão mútua sobre os requisitos.

O Feedback é uma importante técnica de Análise e Consenso, a qual possibilita que o cliente ou mesmo a equipe, identificar como o projeto está progredindo, e se está caminhando corretamente. Assim, através dos Feedbacks recebidos em sala de aula e em reuniões presenciais com a Equipe do Super-R, ajustamos os requisitos funcionais e não funcionais que não se alinhavam as solicitações realizadas. Por meio do Miro - Moonwalkers, é possível ver a diferença de como definimos inicialmente na fase de elicitação e descoberta, e, após na atividade de análise e consenso.

Declaração - Temas, Épicos e Histórias de Usário¶

É uma atividade que visa evitar possíveis retrabalhos no projeto, documentando os requisitos de forma com que possam ser utilizados conforme o desenvolvimento e andamento do processo.

Utilizamos os Temas, Épicos e Histórias de Usuário como forma de documentar o nosso Backlog, pois além de se alinhar a metodologia utilizada, por meio da granularidade, conseguimos ir dissecando pouco a pouco cada um dos itens. Definimos também um problema principal nessa etapa e uma possível solução.

Representação - Prototipação rápida¶

Podendo representar os requisitos tanto de forma informal, quanto semiformal e formal, a representação é um atividade que busca apresentar os requisitos por meio de visualização do produto ou por um modelo.

Como forma de representação, foi utilizado desde o início do projeto, a prototipação rápida, utilizando um papel visando demonstrar como o jogo funcionará. Assim, essae protótipo permite que possamos demonstrar de uma forma mais visual aquilo que imaginamos em nossa mente quando pensamos em nosso produto. Desta forma, escolhemos essa técnica, pois ela auxilia tanto na validação quanto na facilitação da comunicação do Crystaleum.

Verificação e Validação - Feedback¶

A partir o livro Engenharia de Requisitos da Sheila Reinehr, temos a seguinte citação que "De acordo com a norma internacional ISO/IEC/IEEE 12207 (ISO/IEC/IEEE, 2017, p. 10–11)":

• Validação seria “a confirmação, por meio do fornecimento de evidência objetiva, que o requisito foi atendido para um uso ou aplicação pretendidos específicos”.

• Enquanto a verificação é “confirmação, por meio do fornecimento de evidência objetiva, que os requisitos especificados foram atendidos”"

Desta forma, temos que a Validação seria uma forma de estabelecer que os requisitos definem uma solução adequada ao projeto, enquanto a Verificação estabeleceria que os requisitos foram realizados de forma que atenda ao objetivo.

O Feedback foi utilizado de forma externa, por meio de um grupo que avaliou nosso Backlog utilizando outras técnicas de Verificação e Validação. O documento está no seguinte acesso: Documento- Insurgentes. Utilizamos esse feedback como forma de orientação para ajustar incongruências no Backlog.

Organização e Atualização - Priorização¶

Conforme o próprio nome da atividade já indica, trata-se de estar constantemente organizando e atualizando de forma adequada um conjunto de requisitos, mantendo eles no seu estado mais atual de forma estruturada, refinada e priorizada.

Inicialmente, utilizamos um gráfico de Priorização com um relação entre importância e viabilidade. Estabelecemos gráficos para as capacidades, funcionalidades e história dos usuários. Essa priorização foi realizada inicialmente com uma parcela do grupo, no entanto, após refletirmos e avaliarmos em uma outra reunião, percebemos que poderia haver uma forma melhor de estimarmos os valores de nossas histórias.

Anteriormente haviamos definido importância e a viabilidade como métrica para definirmos o valor das histórias, no entanto, achamos melhor adicionar também uma categoria de complexidade, pois já estavamos abstraindo isso na questão da viabilidade, o que dificultava estabelecer a localização de cada história no gráfico, e por conta disso, decidimos mudar nossa priorização para uma tabela de valores de 1 a 3 para Valor de Negócio e Viabilidade e 3 à 1 para a complexidade. Estabelecemos um cálculo de (Total=Va*Vi/Co) e tomamos as histórias com maiores resultados para o MVP 1.

Referências Bibliográficas¶

1. REINEHR, Sheila. Engenharia de requisitos. Grupo A, 2020.

2. Requirements Engineering: A Roadmap, Nuseibeh, Bashar & Easterbrook, Steve

3. Software Requirements Engineering: An Overview, Jitnah, Daniel & Steele, Phillip

Histórico de Versão¶