Elicitação de requisitos
O gerenciamento de requisitos focará em garantir a qualidade dos requisitos (funcionais e não funcionais). A rastreabilidade vertical dos requisitos será feita em um modelo baseado no framework SAFe, por meio de epicos, features, histórias de usuário e requisitos não funcionais. Utizando este modelo de gerência de requisitos será possível fazer a rastreabilidade dos requisitos, mantê-los atômicos (em nível de história de usuários) e independentes. Features e histórias de usuários serão representadas como issues no Github, onde cada issue possui um conjunto de pessoas assinalados como responsáveis pela issue. Este grupo também irá garantir que a história está correta, priorizada, não ambígua e alocada num tempo razoável de realização, ou seja, que a história esteja de acordo com um checklist simples de qualidade de requisitos.
A rastreabilidade dos requisitos se dará da seguinte forma:
- Cada história de usuário é oriunda de uma única feature;
- Cada feature é oriunda um único épico;
- Cada épico é orundo de um único terma de investimento (no nosso caso, há apenas um tema de investimento).
Isso garante que o "caminho" de um requisito é único.
| Campo | Descrição |
|---|---|
| Cliente | a quem agrega valor? |
| Descrição | sobre o quê é este épico? |
| Valor | qual o valor agregado? |
| Critérios de aceitação | como determinar se este épico foi implementado? |
| Requisitos não funcionais | Listar requisitos não funcionais. |
| Campo | Descrição |
|---|---|
| Nome | Nome |
| Descrição | Explicação curta do contexto e benefício da feature |
| Critérios de aceitação | como determinar se esta feature foi implementada? |
| Requisitos não funcionais | Listar requisitos não funcionais. |
| Campo | Descrição |
|---|---|
| Nome | Nome significativo |
| Eu, como | Papel do usuário |
| Gostaria de | atividade em questão |
| Para que | valor agregado |
| Critérios de aceitação | como determinar se esta feature foi implementada? |
| Requisitos não funcionais | Listar requisitos não funcionais. |
O questionário será aplicado a um conjunto significativo dos usuários. Usuários não-alvo da aplicação não devem participar do questionário, ou suas respostas devem ser filtradas. O questionário terá objetivo principal de entender demandas não atendidas pelos competidores atuais do sistema e entender o ambiente e a frequência que o público alvo se dispõe em relação a utilizar o sistema proposto.
Os formulários serão aplicados, registrados, e analizados pela ferramenta [Google Forms](https://docs.google.com/forms/u/0/)Seŕa elaborado um modelo RichPicture a fim de iniciar a elicitação de requisitos com todos os membros da equipe. Assim, todos os membros da equipe poderão explanar ideias acerca da visão do projeto.
Serão feito protótipos de baixa-fidelidade, em papel para validar hipóteses de como deve ser a interface gráfica da aplicação, bem como os fluxos principais dos usuários.
[1] SAFe 4.0, disponível em "http://v4.scaledagileframework.com/".
[2] Donald G. Firesmith: “Quality Requirements Checklist”, in Journal of Object Technology, vol. 4, no. 9 November-December 2005, pp. 31-38
Como dito no tópico 2.1 deste documento, a técnica para elicitação de requisitos foi o questionário. Com o intuito de saber se os potenciais usuários a utilizar este software, foi elaborado um questionário, no qual os dados serão colocados a seguir, devidamente justificados dentro do contexto deste projeto.
O primeiro, mas nem sempre eficiente, temos a tradicional agenda, seja a de papel, smarthphone ou o que o usuário decida usar. A agenda é um meio que pode ser facilmente esquecido ou perdido. É um dos meios mais conhecidos de se lembrar de se realizar alguma tarefa, contudo nem todo mundo segue a risca o rigor de uma agenda.
Este sistema de gerenciamento, criado pela Google, nada mais que uma agenda online, onde pode ser realizadas anotações de tarefas na forma de um lembrete
É uma ferramenta utilizada normalmente em projetos,mas com um formato diferente do que propomos,o trello usa 3 tabelas para gerenciar o desempenho da equipe no formato do Kanban com o do,to do e doing.
O projeto tem o foco em atender os alunos da UnB (Universidade de Brasília) e tem o objetivo de ajudar o gerenciamento dos estudos dos alunos. E para a elicitação de requisitos do sistema foi primeiro aplicado um questionário geral com uma amostra total de 89 respostas, aplicada entre os dias 24 e 25 de agosto.
O questionário com suas respostas podem ser acessadas ao clicar no link: Questionário PlanUp
De uma maneira geral, os alunos que são os que mais utilizam o MatrículaWeb, estão satisfeitos suas as funcionalidades.
Os alunos de uma forma geral possui uma certa dificuldade de administrar a quantidade de faltas no semestre
Como nem todos os professores dizem a quantidade de faltas os alunos possuem e dentre a faculdade nem todos os alunos não sabem como calcular a quantidade de falta que se pode ter dentro de uma disciplina, muitos sentem dificuldade em saber a razão entre presenças e faltas.
Esse gráfico tem que ser analisado entre os mais relevantes, no caso serão analisados apenas 3 cenários.
- Primeiro com 43,8%, os alunos fazem pequenas anotações em agendas, cadernos e post-it.
- Em segundo com 37,8%, vem os alunos que utilizam seus celulares para registrar sus atividades academicas.
- Em terceiro lugar com 18%, tem os alunos que não fazem registros de suas atividades academicas.
Analisando o seguinte gráfico, percebe-se que os alunos não possuem muito controle sobre suas atividades entregues, notas de provas e o tempo dedicado as disciplinas.
Os alunos desejam saber se os seus estudos estão sendo proveitosos.
A maioria dos alunos que responderam este questionário, deseja um site que os ajude no gerenciamento de tempo de estudo.
A maioria dos alunos não sabe como calcular a nota final em cada matéria.
Com 56,2%, os alunos acreditam que um site pode ajuda-los para lembra-los de determinados trabalhos ou provas.
RichPictures são representações pictóricas de sistemas ambientais ou sociais. Eles podem ajudar na organização situações complexas e identificar questões relevantes elicitação de requisitos junto aos stakeholders do projeto. É um modelo informal, sendo que sua intenção é que seja construído de junto com o cliente ao passo que é possível que ele entenda perfeitamente tudo o que é desenhado. Para o projeto OpenUp foi realizado um model RichPicture para a início da elicitação de requisitos, de modo que a equipe pode explanar algumas ideias para o projeto. Segue abaixo o RichPicture elaborado pela equipe.
