Elicitação de requisitos de monetização
Histórico de revisão
Data | Responsável | Versão | Mudança realizada |
---|---|---|---|
31/03/2018 | José Aquiles | 1.0 | Primeira versão do plano de elicitação feitas a partir de uma introspecção de José Aquiles |
25/05/2018 | Eduardo e Geovanne | 2.0 | Atualização do moscow, mostrar os requisitos elicitados na técnica de introspecção |
Storytelling¶
Introspecção¶
Como pode se observar no storytelling há três tipos publico alvo que o spotify vai tratar:
Pessoas que estão dispostas a pagar para mais benefícios: este publico simplesmente tem dinheiro de sobra ou se gostariam de pagar uma assinatura para ter um serviço de qualidade.
Universitários: muitos deles tem que trabalhar para poder pagar a universidade e quase não sobra dinheiro para ele mesmo.Visto que é possível comprovar se a pessoa é universitária ou não e pela maioria serem jovens são possiveis clientes.Então para atrair este tipo de cliente podemos cobrar menos em cima da mensalidade.
Pessoas que não estão dispostas a pagar para mais benefícios ou não podem: eles irão utilizar uma versão com menos recursos e para gerar lucro a empresa e encorajar a comprarem a versão com mais recursos eles irão ver propagandas.
- Modelo free com limitações de funcionalidades.
- Compra do modelo Premium com mais benefícios
- Planos Premium alternativos(família, tradicional e estudante).
- Propaganda de divulgação de artistas, empresas ou eventos.
MoSCoW¶
Explicação de como foi avaliado os requisitos em: must, should, could, would.
- Must: O que acontece se esse requisito não for atendido? ”Se a resposta for cancelar o projeto então deve se usar o must, não é possível entregar na data prevista sem isso, Inseguro sem isso.
- Should: Importante, mas não vital, pode ser doloroso deixar de fora, mas a solução ainda é viável.
- Could: Os requisitos rotulados como Could são desejáveis, mas não necessários, e podem melhorar a experiência do usuário ou a satisfação do cliente por um pequeno custo de desenvolvimento. Estes serão tipicamente incluídos se o tempo e os recursos permitirem..
- Would: Requisitos rotulados como Would terão que ser acordados pelas partes interessadas como os itens menos críticos e de menor retorno, ou não são apropriados naquele momento. Como resultado, os requisitos não serão planejados no cronograma do próximo timebox de entrega. Os requisitos não serão eliminados ou reconsiderados para inclusão em um timebox posterior..
Requisitos | Must(deve ter) | Should(deveria ter) | Could(poderia ter) | Would(seria legal ter) |
---|---|---|---|---|
Modelo free com limitações de funcionalidades | X | |||
Compra do modelo Premium com mais benefícios | X | |||
Planos Premium alternativos(família, tradicional e estudante). | X | |||
Propaganda de divulgação de artistas, empresas ou eventos. | X |