Modificações no DRO do PG

Para que os Requisitos Funcionais do DRO do PG se apresentassem no Formato de especificação de Requisitos Funcionais proposto, diversos ajustes tiveram de ser realizados. A adequação a este Formato foi a principal modificação realizada, pois a apresentação dos Requisitos Funcionais teve de ser reformulada.

Para facilitar a explicação das mudanças que ocorreram nos requisitos após o uso do Formato proposto alguns exemplos serão dados. Para cada exemplo, primeiro será mostrado como o Requisito Funcional estava apresentado no DRO e depois como o mesmo Requisito Funcional ficou após a sua transformação com o uso do Formato.

A identificação do Requisito Funcional no DRO pode não corresponder com a identificação do mesmo requisito no DRM, pois ao tentar transformar determinados requisitos usando as Diretrizes propostas verificou-se que os mesmos não eram Requisitos Funcionais, sendo eles desconsiderados.

Exemplo 1:

Figura 6.1 Requisito Funcional 13 do DRO do PG. Requisito Funcional 13

• Descrição: o painel de status deve representar o estado de ocupação das vagas não reservada. Deve exibir ‘vagas’ se houver uma vaga não reservada disponível naquele momento. Deve exibir ‘lotado’, se não há nenhuma vaga não reservada disponível naquele momento.

Figura 6.2 Requisito Funcional 8 do DRM do PG.

Como pode ser visto, o requisito da Figura 6.1 apresenta-se apenas com o item Descrição. Ao usar o Formato, percebeu-se que determinados itens ficariam sem serem preenchidos, pois o requisito original não deixa claro qual a informação de entrada necessária para a sua realização e nem o que o sistema deve fazer para permitir que o painel de status mostre o estado de ocupação das vagas não reservadas. Sendo assim, algumas informações foram acrescentadas e outras colocadas no item adequado.

É visível que o Formato proposto detalha o Requisito Funcional de forma a incluir informações essenciais que melhoram o seu entendimento. Cada item foi especificado da seguinte forma: a Descrição foi alterada para começar por um verbo que indique ‘o quê’ o requisito deve fazer. Conforme é recomendado no formato, uma descrição sem detalhes é oferecida por tal item, de forma que fique mais clara a funcionalidade requerida. Foi aproveitada parte essencial da descrição original. Os itens Agente Fornecedor/Receptor e Agente Executor foram completados após a compreensão da interação que ocorre no sistema, pois não estavam explícitos. O item Entrada foi preenchido com a informação que diz qual a entrada recebida para que o requisito possa ser concluído. Nesse caso, por ser sistema embutido, percebe-se que apenas quando o painel de status receber um sinal de mudança de estado é que o requisito será executado. Uma tabela que especifica os dados de entrada é usada. O Processamento iniciou-se por um verbo e detalha os passos necessários para a execução do requisito. Como é o painel de status quem mostra a mensagem se há vagas ou

Requisito Funcional 8.

Descrição: Mostrar o estado atual de ocupação das vagas não reservadas. Agente Fornecedor/Receptor: Painel de status

Agente Executor: Sistema Entrada:

Campo Tipo Tamanho Descrição

Sinal de que houve mudança de estado “há vagas” para “lotado”, ou “lotado” para “há vagas”

Numérico 1 inteiro 0 = estado “há vagas” para “lotado”

1 = estado “lotado” para “há vagas”

Processamento: Enviar uma notificação para o painel de status para que este exiba determinada mensagem se houver uma vaga não reservada disponível naquele momento ou se não há nenhuma vaga não reservada disponível naquele momento. Condição/Restrição: Nenhuma.

não, é para ele que o sistema deve notificar a mudança de estado. Para este requisito não houve alguma condição ou restrição que delimitava a sua realização. E no item Saída foi colocada parte da informação contida na descrição do requisito original, pois seria a resposta dada pelo requisito.

Exemplo 2:

Figura 6.3 Requisito Funcional 14 do DRO do PG.

Figura 6.4 Requisito Funcional 9 do DRM do PG.

O requisito funcional 14, mostrado na Figura 6.3, é descrito com mais detalhes através dos termos Descrição, Entrada, Processamento e Saída, embora no mesmo documento que o Requisito Funcional 13 do Exemplo 1, apresentado pela Figura 6.1. Ainda assim, modificações foram feitas de acordo com as orientações definidas no Formato para especificação de Requisitos Funcionais.

Requisito Funcional 14

• Descrição: todo motorista com um ingresso mensal deverá inserir o ingresso no leitor de ingresso. Se este for válido, o portão abrirá. Um ingresso reservado válido sempre permitirá entrada.

• Entrada: motorista insere ingresso mensal.

• Processamento: o número de ingresso será analisado pelo sistema para determinar se a data de sua compra foi há 30 dias ou menos antes da data atual. Em caso afirmativo, o portão abrirá.

• Saídas: o portão é aberto.

Requisito Funcional 9

Descrição: Permitir a entrada de motoristas com ingresso mensal se este for válido. Agente Fornecedor/Receptor: Motorista

Agente Executor: Motorista Entrada:

Campo Tipo Tamanho Descrição

Número do ingresso mensal

Numérico 8 inteiros

Processamento: Analisar o número de ingresso para verificar se a data da sua compra foi há 30 dias ou menos da data atual. Em caso afirmativo, o ingresso é válido, então o portão deve ser aberto. Senão, nada acontece.

Condição/Restrição: Se o ingresso mensal for válido. Saída: Abrir portão. Senão, nada acontece.

Ao ler a Descrição do requisito original pode-se notar a dificuldade de compreendê-la devido às informações misturadas, ou seja, dados de entrada e sua explicação, condições e afirmações. Não está claro qual a finalidade do requisito. Para compor o item Descrição do requisito modificado de forma simples, direta e começando por verbo, teve que se ler e entender o que estava sendo solicitado por aquele requisito original. Verificou-se que o objetivo principal do requisito era permitir que motoristas com ingresso mensal entrassem no estacionamento se o ingresso fosse válido. Assim, a funcionalidade foi resumidamente explícita numa única frase. A parte em que diz “todo motorista com um ingresso mensal deverá inserir o ingresso no leitor de ingresso” foi desconsiderado na nova Descrição, pois trata-se de uma explicação de como o motorista deve agir. A sentença “Se este for válido, o portão abrirá” também foi retirada da Descrição, pois expressa uma condição e processamento. E a última sentença “Um ingresso reservado válido sempre permitirá entrada”, expressando uma afirmação, foi então reformulada para começar por um verbo e exprimir o que realmente o requisito deve fazer.

Para a realização dessa funcionalidade, identificou-se que o motorista era quem interagia com o sistema ao inserir o número do ingresso, sendo ele o Agente Fornecedor/Receptor e Agente Executor, pois além de informar o número do ingresso também operava diretamente com o sistema. A informação de entrada, ao invés de se apresentar em forma de sentença, foi especificada pela tabela que caracteriza cada dado de entrada necessário para a conclusão do requisito. No item Processamento foi descrito o que o sistema deve fazer para permitir a realização do requisito, ou seja, daquilo que foi mencionado na Descrição. Também foram mostradas tanto as ações positivas quanto negativas após a verificação da data da compra do ingresso. Como a ação negativa não estava definida no requisito original, foi colocada apenas a sentença ‘Senão, nada acontece’, pois assim não modificaria as funções definidas para o sistema. Caso fosse exibida uma mensagem ao motorista indicando que o ingresso é inválido, o documento deveria informar que o leitor de ingresso apresentava um visor e isso não foi mencionado em lugar algum. Apenas para conformar com o formato proposto e explicar de forma mais didática é que tal ação negativa foi descrita, mas o correto seria verificar com o cliente do sistema sendo desenvolvido. Para o item Condição/Restrição, a presença do termo ‘se’ na Descrição facilitou a sua identificação. E para o item Saída foi descrita a resposta esperada com a realização do requisito.

Terminada a transformação nos Requisitos Funcionais, o DR foi analisado para verificar a sua adequação às Recomendações de Escrita. Diversos termos inconsistentes foram eliminados.

E para finalizar, o Checklist Pré-Inspeção foi checado no documento, o que possibilita uma verificação rápida de determinadas informações.

Aplicando-se as Diretrizes propostas no DRM do PG pôde-se perceber que diversos defeitos foram sendo percebidos antes mesmo da aplicação de algum tipo de inspeção ser iniciado. Isso porque as Diretrizes são compostas de itens que permitem que as sentenças usadas para especificar um requisito sejam descritas de forma mais completa, objetiva e padronizada.