Autor	Data
Pablo Diego	15/03
Josué Nascimento	15/03
Fabíola Fleury	15/03
Josué Nascimento	16/03
Fabíola Fleury	17/03
Josué Nascimento	19/03
Álax Alves	26/03
Josué Nascimento	27/03
Roger Lenke	28/03

A Elicitação de Requisitos pode ser definida como o processo de compreensão dos requisitos dos stakeholders, e o primeiro estágio para a construção do entendimento sobre o problema que o software deve resolver. É um processo fundamentalmente humano onde são identificados os stakeholders e estabelecidas as relações entre o cliente e o time de desenvolvimento (IEEE, 2004).

De acordo com (Jackson, 1995), uma tecnica de requisitos deve explorar caracteristicas especificas do problema, porem como essas caracteristicas podem e variam de situação para situação é necessario existir um repertorio de metodos de tecnicas para cada situação(Siddiqi, 1997). Para a realização do projeto pan-pan serão utilizadas as tecnicas de elicitação descritas a seguir.

Para a elicitação inicial dos requisitos do projeto, será utilizada a técnica de brainstorm entre os membros da equipe, buscando ideias e soluções para os problemas que iremos solucionar.

Brainstorming é uma técnica de grupo utilizada para criar novas ideias para o projeto e/ou encontrar soluções para um problema específico, além de possibilitar o diagnóstico de problemas em pouco tempo. O Brainstorm é composto de duas fases: a geração de ideias e a busca da solução. Durante a geração de ideias iremos exercitar a criatividade da equipe para o problema proposto, buscando apresentar todas as possibilidades que agregariam valor a nossa solução.

Na busca da solução iremos priorizar as ideias apresentadas na fase anterior, concatenando ideias similares ou que funcionam bem juntas, definindo então as features do sistema que geram mais valor, cabem no escopo e recursos do projeto.

Os resultados do brainstorm realizado pela equipe podem ser encontrados aqui.

A ferramenta 5W1H pode ser definida sendo um documento de forma organizada que identifica as ações e as responsabilidades de quem irá executar, através de um questionamento. A lista de verificação deve ser estruturada de forma que permita rápida identificação dos elementos que serão necessários a implementação do projeto.

Para auxílio na definição do escopo da solução, iremos utilizar uma adaptação do modelo 5W2H, removendo a questão "how much", que ajuda a definir os custos do projeto. Esta decisão foi tomada pelo caráter educacional e acadêmico do projeto, onde os custos de desenvolvimento são mínimos e não condizentes com a realidade de mercado, mas a criação de estimativas pelo o time destes custos é árdua. Partindo desse situação teremos aplicação do 5w1H.

O 5W1H realizado pode ser encontrado aqui.

A Prototipação é uma técnica de elicitação de requisitos comumente utilizadas para levantamento de Requisitos.

Essa técnica consiste em dois tipos Descartável e Evolutiva.

Prototipação Evolutiva: O protótipo é incrementado ao longo do projeto, na medida em que o projeto evolui, o prototipo acompanha a evolução.

Prototipação Descartável: É descartáveis são criados com a função de ilustrar para os usuários e/ou clientes do sistema o que o analista entendeu sobre os requisitos que deverão ser contemplados no produto.

A equipe optou por elaborar um protótipo descartável nesse projeto, para atráves dele possa ser melhor compreendido os requisitos do sistema, a ponto de guiar como será a experiencia do usuário durante a interação com o software e também seja capaz de guiar a equipe quanto a interface para implementação no projeto.

O protótipo pode ser encontrado [aqui][prototipo]

O MoSCoW é uma técnica de classicação e priorização de requisitos na qual atráves de uma tabela é possivel se identificar quais requisitos são prioritários e o por quê. de acordo com IIBA (2011) a priorização dos requisitos garante que os esforços de análise e implementação estejam focados nos requisitos mais críticos,por que partindo da importancia do requisito é possivel se entender sua dificuldade ou risco de implementação. Nessa técnica cada item verificado é atribuído a uma das letras M, S, C ou W, de modo que, a letra M vem da palavra Must(Deve ter), S vem de Should(Deveria ter), C representa Could(Poderia ter) e W que vem de Want(Interessante ter). Os requisitos atribuídos a M são os mais prioritários da aplicação, seguidos pelos atribuídos a S, C e por último, de prioridade muito baixa, os requisitos de W.

Prioridade	Id	Descrição	Comentários	Valor do Negócio
Alta	1	Como um usuário do Pan Pan! gostaria de cadastrar membros para manter registro dos integrantes.	Funcionalidade indispensável, pois os usuários precisam ser capazes de organizar seus registros.	Must Have

No contexto da disciplina aplicaremos essa técnica essencialmente porem não exclusivamente a a priorização das features do projeto, para direcionar a equipe de uma forma mais precisa possível para evitar "achismos" durante a priorização evitando assim priorizar pontos requisitos do projeto de forma equivocada, atrapalhando assim o processo de desenvolvimento e comprometendo a entrega no prazo estabelecido na disciplina.

A priorização realizada com o Moscow pode ser encontrada no Documento de Requisitos do Projeto.

Para entendermos um RichPicture e seu contexto, precisamos primeiro entender o que é rastreabilidade e a sua importância no nicho de Engenharia de Requisitos, assim sendo, temos que rastreabilidade define a capacidade de rastrear um requisito, desde o que motivou sua existência até a funcionalidade que o satisfaz, em outras palavras, permite "voltar no tempo" com um requisito, até a fonte de informação ou stakeholder que propôs sua criação, bem como a forma que deve se comportar - isso já falando de implementação. No final das contas, o que queremos dizer é que um requisito é rastreável se for possível recuperar facilmente todos os artefatos, documentos, motivações, até mesmo conversas que estão relacionadas a ele.

A importância da rastreabilidade está atrelada ao gerenciamento, manutenção e evolução de um projeto. Isso acontece porque o rastro permite que os membros entendam melhor o contexto, as dificuldades, a origem das funcionalidades implementadas e requisitos e também tomem melhores e mais justificadas decisões, assim garantindo uma maior segurança ao próprio projeto.

Junto a Rastreabilidade, temos a Pré-Rastreabilidade, esta irá abranger o contexto que existia antes da implementação da aplicação, que é exatamente o que o RichPicture se propõe a fazer.

Basicamente, RichPictures são representações pictóricas de sistemas ambientais ou sociais. Eles podem ajudar a organizar situações complexas e identificar os problemas subjacentes, incluindo todos os elementos relevantes e os stakeholders de um sistema. É um modelo informal, de simples entendimento e sua intenção é que seja construído colaborativamente com o cliente.

Pode auxiliar em muitíssimos aspectos, dentre eles: identificação de processos de negócio, requisitos dos processos de negócio, envolvidos nos processos de negócio e suas responsabilidades, relacionamentos entre processos e envolvidos, além de facilitar também na identificação de potenciais problemas e conflitos.

A "convenção" adotada para desenhar rege que comecemos com um aspecto em foco, ou seja, no centro de uma página em branco, e acrescentemos posteriormente fatores, processos, aspectos, e outros mais que estejam relacionados a "problemática" inicial.

O RichPicture produzido e suas versões pode ser encontrado aqui.

O NRF é um framework para modelagem de requisitos não-funcionais, sendo que esses são explicitamente representados como metas a serem obtidas. As metas são normalmente representadas por gráficos SIG (Softgoal Interdependency Graph).

Através do modelo é possível identificar relacionamentos e conflitos entre os requisitos que, inicialmente, não eram observados. O modelo permite decompor os requisitos não-funcionais ao nível operacional, para garantir que as necessidades descritas pelos stakeholders estão sendo realmente atendidas, e também como o cumprimento de determinado requisito impacta no outro.

Com o auxilio do NFR na disciplina consiguiremos obter as composições dos requisitos não funcionais do trabalho, com isso tendo uma maior abstração quanto aos seus reais impactos no sistema projetado e como garantir a implementação desses requisitos.

O documento que denota a utilização do NFR Framework pode ser encontrado aqui.

• YOUSUF, M.; ASGER, M. Comparisson of various requirements elicitation techniques. 2015.

• IEEE. Swebok v.3. 2004.

• PONTES, H. L. J; et al. (2005). Melhoria no sistema produtivo de uma fábrica de café: estudo de caso. In Simpósio de Engenharia de Produção, 12, Bauru. Anais... São Paulo: SIMPEP, 2005.

• JACKSON, Michael. “Software Requirements and Specifications” , Addison-Wesley, Reading, Mass., 1995

• SIDDIQI, Jawed. “Requirements Engineering: the emerging wisdow” in Software Requirements Engineering, IEEE-CS Press, Second Edition, 1997, p.p. 36-40.

• IIBA. Um guia para o Corpo de Conhecimento de Análise de Negócios™ (Guia BABOK® ) Versão 2.0. Toronto, Canadá: International Institute of Business Analysis, 2011.

• LISBOA, M. ; Godoy L. Aplicação do Método 5w2h No processo Produtivo do Produto: A Joia

[prototipo]: