Observação
Introdução
A técnica de observação consiste em observar as pessoas enquanto elas usam ou interagem com algo, sem interferir. O objetivo é entender como elas fazem as coisas no dia a dia, para identificar suas necessidades e dificuldades. Isso ajuda a obter informações mais reais e detalhadas sobre o que é necessário em um software ou sistema. Utilizamos esta técnica com o objetivo de coletar todos os requisitos presentes nas tabelas, abaixo, tanto os funcionais como os não-funcionais.
Metodologia
Um dos integrantes do grupo realizará a observação de um usuário utilizando o aplicativo Caesb Autoatendimento, seguindo um roteiro previamente elaborado pela equipe. Durante a observação, o observador não irá interferir nas ações do usuário, permitindo que ele interaja de forma natural com o aplicativo. A partir dessa interação, serão coletados os requisitos funcionais e não funcionais com base no comportamento do usuário.
Requisitos
Os requisitos levantados durante a análise de documentos, identificados com 'OBS' + número do requisito, e com a seguinte legenda de categoria:
-
RF: Requisitos Funcionais - Descrevem o comportamento ou a funcionalidade que o software deve ter para atender às necessidades do usuário.
-
RNF: Requisitos Não-Funcionais - Descrevem os atributos que o software deve ter, como desempenho, segurança e usabilidade, mas não descrevem o comportamento do software em si.
Tabela 01: Requisitos
Rastreabilidade | Descrição | Categoria |
---|---|---|
OBS01 | O aplicativo deve permitir que o usuário escolha o imóvel desejado. | RF |
OBS02 | O aplicativo deve permitir que o usuário selecione o ano ou mês da segunda via da conta. | RF |
OBS03 | O aplicativo deve permitir que o usuário escolha visualizar a segunda via de contas pendentes. | RF |
OBS04 | O aplicativo deve reconhecer automaticamente os imóveis associados ao cliente da Caesb. | RF |
OBS05 | O aplicativo deve considerar o número de pessoas no imóvel para calcular a média do consumo. | RF |
OBS06 | O aplicativo deve permitir que o usuário visualize as regiões em que haverá falta de água. | RF |
OBS07 | O aplicativo deve permitir que o usuário informe o vazamento em uma rua. | RF |
OBS08 | O aplicativo não deve permitir que o usuário escolha rua, bairro e cidade para informar o vazamento em uma rua. | RF |
OBS09 | O aplicativo deve permitir filtrar os atendimentos em andamento ou finalizados. | RF |
OBS10 | O aplicativo deve permitir filtrar os atendimentos por ano ou mês. | RF |
OBS11 | O aplicativo deve permitir que o usuário busque um atendimento pelo protocolo. | RF |
OBS12 | O aplicativo deve permitir que o usuário simule o faturamento pelo aplicativo. | RF |
OBS13 | O aplicativo deve permitir que o usuário altere o vencimento da conta. | RF |
OBS14 | O aplicativo deve permitir que o usuário altere a titularidade da conta. | RF |
OBS15 | O aplicativo deve possuir 2 abas separadas, uma para serviços e outra para consultas. | RF |
OBS16 | O aplicativo deve ser compatível com as plataformas Android e iPhone. | RNF |
OBS17 | O aplicativo deve se adaptar a diferentes tamanhos de tela. | RNF |
OBS18 | O aplicativo deve ser acessível para pessoas com deficiência visual. | RNF |
OBS19 | O aplicativo deve permitir que o usuário realize tarefas principais em no máximo 3 cliques. | RNF |
Bibliografia
1. VASQUEZ, Carlos Eduardo; SIMÕES, Guilherme Siqueira. Engenharia de requisitos: software orientado ao negócio. 1. ed. São Paulo: Pearson, 2016. 328 p. ISBN 9788574527901. Disponível em: https://aprender3.unb.br/pluginfile.php/2972448/mod_resource/content/4/Elicitacao%20de%20Req%202.pdf. Acesso em: 22 de Nov. 2024
Histórico de versão
Versão | Data | Descrição | Autor(es) | Revisor(es) |
---|---|---|---|---|
1.0 | 22/11/2024 | Adicionando introdução e requisitos | Leandro de Almeida e Joao Victor Marques | Letícia Resende |
1.1 | 22/11/2024 | Padronizando a tabela | Leandro de Almeida | Joao Victor Marques |