Histórico de Revisão

Data	Versão	Descrição	Autor(es)
24/11/2017	1.0	Versão Inicial	João Paulo e Allan Nobre
24/11/2017	2.0	Introdução	João Paulo e Allan Nobre
24/11/2017	3.0	Tipos de Requisitos, Rastreabilidade, Elicitação	Allan Nobre
24/11/2017	4.0	Labels	João Paulo

1. Introdução
2. Tipos de Requisitos
  2.1. Features
  2.2. Requisitos de Qualidade
3. Rastreabilidade
4. Elicitação de Requisitos
5. Labels das Issues 6. Referências

---

Pressman define engenharia de requisitos como uma forma apropriada para entender de fato o que o cliente deseja, ajuda a analisar essas necessidades e verificar a viabilidade das mesmas. Através da engenharia de requisitos é possível negociar prazos e definir um escopo claro por meio de uma especificação do sistema, tirando todas as possíveis ambiguidades que o projeto poderia vir a ter. Para Pressman a engenharia de requisitos pode ser dividida em sete atividades, são elas: concepção, levantamento, elaboração, negociação, especificação, validação e gestão.

O guia de gerenciamento de projeto PMBOK 5ª edição também define que os projetos devem ter uma fase de elicitação de requisitos, nesta fase é onde as informações do projeto são elicitadas. É nesta fase que é preciso descobrir quais são as necessidades do cliente, o que ele espera de que o sistema forneça. É necessário que tudo seja muito bem documentado, pois é através destes documentos que o projeto se guiará até o seu término. Para que o projeto tenha sucesso é necessário gerenciar os requisitos para que todos possam ser atendidos e as partes interessadas ao final do projeto tenham alcançado o que se esperava.

Os requisitos do projeto foram mapeados para issues do Git, de forma que pudessem ser classificados e identificados através das labels - clique aqui para acessar as labels do projeto -, cada label criada no repositório tem um significado que vai além de que tipo de requisito aquela issue representa, podendo identificar também a criticidade e que tipo de artefato as tasks dela afetarão.

As features do projeto são as próprias funcionalidades do aplicação, sendo estas mapeadas para as issues do Git e são organizadas no KanBan da equipe fornecido pela ferramenta: ZenHub. Toda feature possui a label "feature" que indica que tipo de requisito essa issue representa. Para visualizar a escrita de uma issue basta acessar o KanBan do projeto.

O termo de requisitos de qualidade, também chamado de requisitos não funcionais, por muitas vezes são denotados como sendo atributos do sistema, como por exemplo, atributos de performance ou qualidades específicas. Eles fixam restrições sobre como os requisitos funcionais serão implementados ou devem agir, ou seja, ele descreve como o sistema fará uma determinada ação.

Os requisitos de qualidade representam alguns desafios no decorrer do projeto, pois estes muitas vezes são difíceis de modelar, apresentam ambiguidade, acabam sendo ignorados durante o desenvolvimento porém tem sua função crítica para o desenvolvimento do projeto.

Os requisitos de qualidade representam alguns desafios no decorrer do projeto, pois estes muitas vezes são difíceis de modelar, apresentam ambiguidade , acabam sendo ignorados durante o desenvolvimento porém tem sua função crítica para o desenvolvimento do projeto.

Eles são mapeadas para as issues do Git e são organizadas no KanBan da equipe fornecido pela ferramenta: ZenHub, assim como as features. Todo requisito de qualidade possui a label "technical" que indica que tipo de requisito essa issue representa. Para visualizar a escrita de uma issue basta acessar o KanBan do projeto.

Um aspecto importante do gerenciamento de requisitos é assegurar a rastreabilidade destes. A rastreabilidade de um requisito é a possibilidade de rastreá-los e utilizá-los ao longo de todo ciclo de vida do sistema.

A estratégia de rastreabilidade dos requisitos tem início na Pré Rastreabilidade, onde os requisitos começam a ser visualizados nos mais altos níveis de projeto, prosseguindo para a elicitação destes a nível de Features.

Neste projeto, a rastreabilidade de requisitos manteve-se em alto nível, devido a ideia deste trabalho ter surgido de um trabalho anterior da mesma disciplina, o EmbelezaMais.

As funcionalidades de pesquisa, cadastro de Empresas/Serviços e Agendamentos, chamaram a atenção da equipe no tange possibilidade de reutilização dessas funcionalidades. Essa curiosidade levou-nos a pesquisar softwares que utilizassem desses artifícios e findamos em implementá-las no framework baseados tanto no projeto anterior, como nos softwares: Uber, TriVago e Airbnb.

Após um estudo inicial de viabilidade, o próximo estágio do processo de engenharia de requisitos é a elicitação requisitos. Nessa atividade, os engenheiros de software trabalham com clientes e usuários finais do sistema para obter informações sobre o domínio da aplicação, os serviços que o sistema deve oferecer, o desempenho do sistema, restrições de hardware e assim por diante (SOMMERVILLE, 2011).

A elicitação de requisitos e análise de requisitos podem ser vistas como um processo iterativo, com feedback contínuo de cada atividade para outras atividades. O ciclo do processo começa com a descoberta de requisitos e termina com sua documentação (SOMMERVILLE, 2011).

Nesse contexto, a elicitação de requisitos aconteceu em um bate-papo entre os membros da equipe sobre quais funcionalidades seriam reaproveitadas do software anterior e quais seriam mais aproveitadas por outros softwares.

Desta discussão, as issues foram criadas e marcadas com a label de "feature", de modo que fosse capaz dividí-las entre a equipe e separá-las por iterações para que fossem devidamente implementadas.

Assume-se que parte da rastreabilidade é perdida nesse processo, contudo, este é o preço que se paga pelo curto período de tempo para a implementação da aplicação, que tenta reutilizar o máximo possível das funcionalidades já feitas no trabalho anterior, herdando, de certa forma, a rastreabilidade de alguns requisitos já elicitados anteriormente.

Como dito anteriormente para um maior controle de requisitos e para facilitar o monitoramento dos tipos de atividades realizadas, são utilizadas labels nas issues criadas para o desenvolvimento do projeto.Ao total foram criadas 7 tipos diferentes de labels.

Os mesmos e uma pequena explicação da função que cada um desempenha será aparesentada a seguir:

• Critical:

  As issues marcadas com essa label são consideradas fundamentais para o desenvolvimento do projeto, tendo uma maior importância e foco por parte da equipe.

• Feature:

  Como dito anteriormente, as issues marcadas com essa label são issues relacionadas ao desenvolvimento de um requisito do projeto.

• Help Wanted:

  As issues marcadas com essa label necessitam de uma atenção dos outros membros, pois o membro responsável por solucioná-la esta enfrentando problemas com ela.

• Improvement:

  Issues de improvement são issues consideradas fundamentais para evoluir algo feito no projeto.

• Spike:

  Issues marcadas com Spike são issues relacionadas há um estudo a cerca de um assunto necessário para a equipe de desenvolvimento.

• Technical:

  Issues marcadas com essa label costumam ser relacionadas a dividas técnicas do projeto ou a configuração de uma ferramenta ou algo necessário para a equipe de desenvolvimento.

• Wiki:

  A label Wiki representa issues relacionadas a modificações de artefatos ou informações presentes na Wiki do repositório do projeto.São issues relacionada aos artefatos gerados durante o projeto.

PRESSMAN, R. S. Engenharia de software, Uma abordagem profissional. 7ª ed. Rio de Janeiro: McGraw-Hill, 2011

PMI. Um guia do conhecimento em gerenciamento de projetos. Guia PMBOK 5a. ed. - EUA: Project Management Institute, 2013.

http://docente.ifrn.edu.br/joaoqueiroz/disciplinas/ihc-interacao-humano-computador/aulas/aula-5 <Acessado em 27/08/2017>

http://www.scaledagileframework.com/ <Acessado em 28/08/2017>

MAYHEW, Deborah J. Principales and Guidelines in Software User Interface Design. Englewood Cliffs (New Jersey), PTR Prentice Hall. 1992.

SOMMERVILLE, I., Engenharia de Software, 9ª Edição. São Paulo: Pearson Prentice Hall, 2011.