-
Notifications
You must be signed in to change notification settings - Fork 13
Politicas de Verificação e Validação
Data | Versão | Descrição | Autor(es) |
---|---|---|---|
22/05/2018 | 1.0 | Criação da verificação do documento de especificação de casos de uso | Bruno Dantas, Diego Resende, João Vitor, Lucas Gomes, Martha Dantas, Paulo Lopes |
23/05/2018 | 1.1 | Criação da verificação do documento de RichPicture | Martha Dantas, Victor Gomide |
28/05/2018 | 1.2 | Adição da ata de reunião | Paulo Lopes |
Dada a extensão dos artefatos criados, faz-se necessária a criação de uma política de verificação e validação dos requisitos levantados.
Para a construção da verificação, o grupo decidiu realizar a inspeção, que é uma estratégia que detalha os requisitos em forma de lista. Essa é a melhor maneira discutida pela equipe, pois já estamos modelando requisitos para um sistema implementado. É interessante ressaltar que além das verificações feitas pela equipe, os professores responsáveis também realizam inspeções em nossos documentos, visando sempre encontrar falhas e possíveis melhorias.
As etapas percorridas na Verificação por Inspeção foram inspiradas no processo "Fagan Inspection":
- Planejamento: Foi organizado no Trello (Ferramenta de gerenciamento de projetos) as atividades a ser realizadas pelos integrantes do grupo durante o processo de verificação;
- Preparação para a inspeção: Nessa etapa, foi decidido a divisão dos artefatos entre cada integrante do grupo, onde ficaram responsáveis pela revisão e análise dos artefatos;
- Inspeção: Cada membro realizou a inspeção, onde se encontrou possíveis erros que foram discutidos pelos integrantes do grupo, para então decidir o que realmente precisa ser arrumado;
- Correção: É feita a correção de todos os erros que foram encontrados e que o grupo decidiu que precisavam ser arrumados;
Como um exemplo de verificação, utilizamos o documento de especificação de casos de uso. Esse documento foi analisado por um integrante do grupo que montou uma checklist de todos os principais critérios que o artefato deveria possuir. Após feito o checklist, foi discutido entre os outros integrantes do grupo para confirmar os possíveis erros e então solucioná-los no documento.
No documento tido como exemplo foi possível identificar os possíveis erros:
- Falta de todas as pré-condições nas regras de negócio.
- Falta de regras de negócio em todas as especificações.
- Falta de casos de uso para todos os requisitos.
No checklist é mostrado o status do problema, contendo a sua resolução como a sua rastreabilidade.
O RichPicture têm como princípio a liberdade em sua criação então não há um modelo a se seguir. Entretanto existem algumas boas práticas que devem ser observadas na criação desse documento para que ele cumpra com seu objetivo de maneira satisfatória. Usamos como base para a verificação, através de um checklist, os feedbacks de especialistas e o artigo Using RichPicture in Information System Teaching. Feita a verificação, foi discutido entre integrantes se a mesma estava condizente . Foi identificado o seguinte erro no documento:
- Nem todos os atores externos estão representandos.
O processo de validação necessariamente precisa estar em contato com o cliente. Porém, na matéria de Engenharia de requisitos, não é desenvolvida uma aplicação mas sim estudada uma aplicação já existente - o que não se faz necessário o contato com o cliente - torna-se inviável o processo de validação no momento para a matéria.
Engenharia de Requisitos 2018/1 - Grupo 7 iFood