Do requisito à user story
O requisito é a condição ou função necessária para um sistema alcançar um determinado objectivo. O objectivo de qualquer sistema, seja software ou um processo de negócio, é atender a um conjunto de requisitos – as necessidades que o sistema deve satisfazer.
Os requisitos podem ser funcionais ou não-funcionais.
Os requisitos funcionais reflectem as necessidades do cliente que devem ser satisfeitas para alcançar os objectivos do negócio.
Os requisitos não-funcionais são os que reflectem as características do sistema ou do ambiente em que está inserido. São requisitos não-funcionais os requisitos de interface, usabilidade, desempenho, operacionais, segurança, legais e manutenção e suporte.
Segundo o IIBA International Institute of Business Analysts, estas são as melhores práticas na definição de requisitos:
- Os requisitos são completos. São fechados e sem azo a depreensões.
- Os requisitos são testáveis. Há que fazer prova de que os requisitos estão implementados.
- Os requisitos são coerentes entre si. Não há conflito ou contradição entre requisitos.
- Os requisitos são independentes do design. Os requisitos indicam o que o sistema faz ou não faz, cabe ao design especificar como é que o software o vai fazer.
- Os requisitos são claros. Têm uma única interpretação.
Os casos de uso capturam e modelam os requisitos funcionais, servindo como contrato entre as partes envolvidas. Portanto, definem uma solução de negócio como resposta à visão do cliente que depois vai ser implementada em termos técnicos.
Um caso de uso descreve uma série de interacções entre o utilizador e o sistema em que o objectivo é indicar como o utilizador usa o sistema e está, portanto, orientado ao utilizador. O caso de uso é constituído por um fluxo principal e fluxos alternativos que podem por sua vez tornar ao fluxo principal. O caso de uso define as interacções detalhadamente reflectindo as regras de negócio da funcionalidade, assim como as opções que o actor pode tomar para a realizar.
Tanto os requisitos como os casos de uso estão mais centrados na especificação de documentos do que na colaboração.
As user stories centram-se no valor que o sistema entrega aos utilizadores. O objectivo não é especificar detalhadamente na fase inicial, é fornecer uma framework em que o detalhe vai sendo adicionado à medida que é necessário. Vai havendo uma conversação à medida que o projecto avança promovendo a colaboração entre as partes.
Cada user story descreve trabalho que traz mais valia para o utilizador. User stories que levam mais do que uma iteração a implementar são os chamados Epics e são decompostos em user stories de uma iteração. Constroi-se, assim, um story map com os epics em sequência e decompostos em peças de trabalho mais pequenas que indica as funcionalidades que satisfazem os objectivos do negócio. A prioridade e a sequência no story map identificam o MVP (Minimum Viable Product ).
Bill Wake criou uma mnemónica para as melhores práticas na definição de user stories:
I Independent Não há dependência entre user stories. Elas não dependem umas das outras.
N Negociable Podem ser sempre alteradas enquanto durar a iteração
V Valuable Tem que trazer valor ao utilizador
E Estimable É possível de estimar (tamanho) caso contrário não é possível planeá-la e mapeá-la em tarefas
S Small Têm de ser pequenas de modo a poderem ser planeadas com um certo nível de certeza
T Testable A sua descrição tem que ter informação suficiente para poder ser testada
Exemplo
Necessidade do cliente: Encontrar todos os analistas especialistas em SOX que existem num raio de 50 km de Bruxelas
Requisitos
O sistema permite pesquisar candidatos por função, especialidade e região geográfica.
A função de um candidato pode ser uma entre analista, responsável técnico, programador e web designer.
A especialidade de um candidato pode ser uma entre SOX, Agile, UX e Microsoft.
A região geográfica de um candidato é a cidade e, opcionalmente, num raio medido em kms da cidade indicada. O raio é de 50 kms por omissão.
Caso de Uso
Fluxo Principal:
1.O actor selecciona a pesquisa de candidatos
2.O sistema apresenta o ecrã de pesquisa de candidatos com a lista de funções, a lista de especialidades, a lista de cidades e o raio 50 km.
3.O actor selecciona a função, a especialidade e a cidade e submete o pedido de pesquisa
4.O sistema apresenta a lista de candidatos
Fluxos alternativos:
1. passo 2 - O actor indica o valor do raio
a. O sistema executa o passo 4
2. .passo 4 - O sistema não encontra candidatos que satisfaçam o critério de pesquisa
a. O sistema devolve a mensagem “Não foram encontrados resultados”
User Story
Título:
Pesquisar candidatos por função, especialidade e região geográfica.
Descrição:
Enquanto utilizador que pesquisa candidatos, quero pesquisar candidatos por especialidade, por forma a fornecer recursos aos clientes.
Critério de Aceitação:
A pesquisa de candidatos permite pesquisar por função.
A pesquisa de candidatos permite pesquisar por especialidade.
A função e a especialidade são seleccionadas a partir de listas.
A pesquisa retorna uma lista de candidatos ou uma mensagem indicando que não há resultados
fonte: CMCrossroads, BATimes
Licença CC BY-SA 4.0
Silvia Pinhão Lopes, 8.1.16
Sem comentários: