Modificações no DRO do Hotel

O DRO do Hotel, dentre os estudados, foi o documento que menos continha a maioria das informações solicitadas para preencher os itens do Formato proposto. As requisições a serem desenvolvidas pelo sistema estavam sucintamente descritas. Embora as informações estivessem organizadas, o documento não apresentava seções recomendadas pela técnica TUCCA, portanto o mesmo foi adequado ao padrão de especificação IEEE [1998b] para depois serem aplicadas as Diretrizes propostas.

Ao transformar a apresentação dos Requisitos Funcionais para o Formato proposto, muito dos itens ficaram em branco, mostrando que o DR estava incompleto de dados básicos. Tais ausências de dados demonstraram que os requisitos não tinham todas as informações essenciais para apoiar as próximas etapas do processo de desenvolvimento de software. Sendo assim, os itens não preenchidos foram completados para que o Requisito Funcional apresentasse informações fundamentais.

A seguir são mostrados exemplos de como ficaram os Requisitos Funcionais após a modificação proporcionada pelas Diretrizes.

Exemplo 1:

Figura 6.5 Requisito Funcional 1 do DRO do Hotel.

1. O sistema deve permitir a inclusão, alteração e remoção de hóspedes do hotel, contendo os seguintes atributos: nome, endereço, cidade onde mora, estado, país, telefone, email, documento de identificação (RG ou CPF para brasileiros e passaporte para estrangeiros), data de nascimento e nome dos pais.

Figura 6.6 Requisito Funcional 1 do DRM do Hotel.

De acordo com as Recomendações de Escrita, requisitos múltiplos devem ser evitados. Sendo assim, as três funcionalidades apresentadas na Figura 6.5 (inclusão, alteração e remoção) foram desmembradas e identificadas unicamente. Assim, a Figura 6.6 mostrou apenas o Requisito Funcional de inclusão.

Adequando-se à exigência do item Descrição, que é começar sempre por um verbo principal que expresse a idéia do que o requisito deve fazer, a sua sentença no Requisito Funcional modificado foi descrita. Assim, a partir da descrição anterior, “O sistema deve permitir a inclusão de hóspedes do hotel”, verificou-se que o verbo de ação principal seria ‘inclusão’. A palavra ‘cadastro’, que estava subentendida, foi expressa. Desta forma, gerou-se a sentença ‘Incluir o cadastro de hóspedes’.

Requisito Funcional 1.

Descrição: Incluir o cadastro de hóspedes. Agente Fornecedor/Receptor: Hóspede Agente Executor: Funcionário

Entrada: O cadastro de hóspedes deve conter os seguintes atributos:

Campo Tipo Tamanho Descrição

Nome Alfabético 40 caracteres

Endereço Alfanumérico 50 caracteres

Cidade Alfabético 20 caracteres

Estado Alfabético 2 caracteres Apresentar para

selecionar Estado.

País Alfabético 20 caracteres

Telefone Alfanumérico 10 caracteres Formato:

(xx) xxxx-xxxx.

Email Alfanumérico 30 caracteres

Documento de identificação Alfanumérico RG: 9 caracteres CPF: 11 caracteres Passaporte: 15 caracteres RG ou CPF para brasileiros e passaporte para estrangeiros Data de Nascimento

Alfanumérico 10 caracteres Formato: dd/mm/aaaa Nome dos pais Alfabético 40 caracteres

Processamento: Verificar se o cadastro de hóspedes existe. Em caso afirmativo, o cadastro não deve ser incluído e uma mensagem de aviso deve ser exibida indicando que o hóspede já existe. Senão, incluir o cadastro e exibir uma mensagem de sucesso indicando que a inclusão foi efetuada.

Condição/Restrição: Nenhuma.

Saída: Armazenar dados do hóspede e exibir mensagem de sucesso. Senão, exibir mensagem de aviso.

O Agente Fornecedor/Receptor associado a este requisito foi o hóspede, uma vez que é ele quem informa os dados para a realização da funcionalidade. Já o Agente Executor foi o funcionário, pois é ele quem operacionaliza a execução do requisito.

Os atributos do cadastro de hóspedes foram melhores definidos através da tabela que caracteriza cada informação de entrada. As colunas Tipo, Tamanho e Descrição foram completadas a fim de exemplo, uma vez que no requisito original não havia tal informação.

Com o objetivo de mostrar a nova forma com que os requisitos deveriam se apresentar, as informações faltantes foram preenchidas, mas o correto seria a confirmação com o cliente do sistema sendo desenvolvido.

No item Processamento foi definido aquilo que o sistema deve processar para incluir o cadastro de hóspede. Esta informação foi incluída com base na experiência e estudos em sistemas de informação. Para este requisito não foi estabelecida nenhuma condição ou restrição que afetasse a sua realização. E a saída retornada por este requisito foi descrita de acordo com aquilo que se espera ao incluir dados, que é a concretização do que foi solicitado (dados armazenados) e uma mensagem para quem realizou a execução do requisito, como forma de esclarecer se houve ou não a inclusão.

Exemplo 2:

Figura 6.7 Requisito Funcional 6 do DRO do Hotel.

6. O sistema deve permitir a reserva de acomodação. Cada reserva possui os seguintes atributos: data e hora de chegada do hóspede, data e hora de saída do hóspede, identificação do hóspede principal (previamente cadastrado), tipo de acomodação desejada, nomes e idades dos acompanhantes, valor da diária, taxa de multa a ser cobrada em caso de desistência de última hora (a menos de 12 horas do início previsto de entrada), os dados do cartão de crédito do hóspede e desconto concedido (opcional). A reserva somente deve ser concretizada se houver vagas suficientes para atendê-la. Caso contrário deverá ser mostrada uma mensagem alertando que não há disponibilidade de acomodações para o período indicado. A remoção de reserva somente é permitida sem maiores encargos até 12 horas antes do início previsto para estadia no hotel. Após esse período, a remoção da reserva deve alertar o funcionário do hotel de que deve ser cobrada a taxa de multa estabelecida durante a reserva.

Figura 6.8 Requisito Funcional 25 do DRM do Hotel. Requisito Funcional 25.

Descrição: Reservar acomodação. Agente Fornecedor/Receptor: Hóspede Agente Executor: Funcionário

Entrada: O cadastro de reserva deve conter as seguintes informações:

Campo Tipo Tamanho Descrição

Data de chegada Alfanumérico 10 caracteres Data de chegada do hóspede. Formato: dd/mm/aaaa.

Hora de chegada Alfanumérico 5 caracteres Hora de chegada do hóspede. Formato: hh:mm.

Data de saída Alfanumérico 10 caracteres Data prevista para saída do hóspede. Formato: dd/mm/aaaa.

Hora de saída Alfanumérico 5 caracteres Hora prevista para saída do hóspede. Formato: hh:mm. Identificação do hóspede Alfanumérico RG: 9 caracteres CPF: 11 caracteres Passaporte: 15 caracteres. RG ou CPF para brasileiros e passaporte para estrangeiros

Tipo de acomodação Alfanumérico 6 caracteres Tipo de acomodação desejada. Oferecer forma de seleção. Nome dos acompanhantes Alfabético 40 caracteres Idade dos acompanhantes Numérico 3 números

Valor da diária Numérico 10 números

Taxa de multa Numérico 10 números Cobrada em caso de desistência de última hora (a menos de 12 horas do início previsto da hora de chegada) Dados do cartão de

crédito

Alfanumérico 30 caracteres Dados do cartão de crédito do hóspede

Desconto concedido Numérico 10 números (Opcional)

Processamento: Verificar a disponibilidade de acomodação no período indicado. Em caso afirmativo, efetuar a reserva de acomodação e exibir uma mensagem de sucesso indicando que a reserva foi efetuada. Senão, a reserva não deve ser efetuada e uma mensagem de alerta deve ser exibida indicando que não há acomodações do tipo solicitadas disponíveis para aquele determinado período.

Condição/Restrição: Se houver acomodações suficientes para atender a reserva. Saída: Armazenar dados da reserva e exibir mensagem de sucesso. Senão, exibir mensagem de alerta.

Figura 6.9 Requisito Funcional 27 do DRM do Hotel.

Como se pode perceber, no Requisito Funcional 6 há mais de uma funcionalidade numa única frase e sob uma única identificação, corrompendo as Recomendações de Escrita no que se refere a requisito múltiplos. Desta forma, o parágrafo corrido e extenso foi desmembrado gerando os Requisitos Funcionais 25 e 27 no DRM do Hotel, ilustrados pelas Figuras 6.8 e 6.9, respectivamente. Percebeu-se que seriam dois requisitos pelo fato de haver duas ações diferentes que o sistema deveria executar, sendo uma a reserva de acomodação e a outra a remoção da reserva. São solicitações diferentes, mas que foram apresentadas juntamente.

É notório como o Formato proposto reestrutura a apresentação do Requisito Funcional, facilitando a sua compreensão através de uma aparência mais discreta.

Quanto à Figura 6.8, cuja funcionalidade principal identificada foi “reservar acomodação”, os itens do Formato foram compostos da seguinte maneira: o Agente Fornecedor/Receptor foi designado ao hóspede, pois é ele quem solicita a reserva informando os dados e o funcionário foi atribuído ao Agente Receptor, pois ele é a interface que manuseia o sistema; os dados da Entrada foram preenchidos com informações adequadas ao seu tipo; já o Processamento, explica em detalhes a atividade que o sistema deve desempenhar para reservar a acomodação. Como no item Condição/Restrição foi estabelecido que deve haver

Requisito Funcional 27.

Descrição: Cancelar reserva de acomodação. Agente Fornecedor/Receptor: Hóspede Agente Executor: Funcionário

Entrada:

Campo Tipo Tamanho Descrição

Identificação do hóspede Alfanumérico RG: 9 caracteres CPF: 11 caracteres Passaporte: 15 caracteres. RG ou CPF para brasileiros e passaporte para estrangeiros

Processamento: Verificar se o pedido de cancelamento da reserva de acomodação foi feito até 12 horas antes do início previsto para a estadia no hotel. Em caso afirmativo, remover o cadastro de reserva de acomodação sem maiores encargos e exibir uma mensagem de sucesso indicando que o cancelamento foi efetuado. Senão, exibir uma mensagem de alerta indicando que uma taxa de multa, estabelecida durante a reserva, deve ser cobrada.

Condição/Restrição: Nenhuma.

acomodações suficientes para efetuar a reserva, isso se traduziu para o item Processamento que o sistema deveria verificar a disponibilidade de acomodação. E conforme o Formato, a ação positiva (Em caso afirmativo) e negativa (Senão) foram descritas. A parte do requisito original que diz “A reserva somente deve ser concretizada se houver vagas suficientes para atendê-la” foi colocada no item Condição/Restrição, pois ao verificar o termo “se” observou- se que realmente se tratava de algo a ser respeitado; na Saída, foi estabelecida resposta de quando a reserva era concretizada e quando não era possível realizá-la.

O segundo requisito gerado, ilustrado pela Figura 6.9, foi identificado ao ler o seguinte trecho do Requisito Funcional 6 mostrada na Figura 6.7: “A remoção de reserva somente é permitida sem maiores encargos até 12 horas antes do início previsto para estadia no hotel. Após esse período, a remoção da reserva deve alertar o funcionário do hotel de que deve ser cobrada a taxa de multa estabelecida durante a reserva”. Foi percebida que a forma apresentada por esta sentença apenas explica a remoção de reserva, o que indiretamente solicita a sua realização. Assim, foi definida para a Descrição a frase “Cancelar reserva de acomodação”. Por ser mais usual o termo ‘cancelar’ para este caso, este foi escolhido ao invés de ‘remover’.

Os itens do Requisito Funcional 27 foram formatados da seguinte maneira: os Agentes foram estabelecidos como no Requisito Funcional 25; a Entrada foi percebida ao analisar a entrada do Requisito Funcional 25, cujo campo principal que melhor identifica cada reserva é o campo ‘identificação do hóspede’, sendo este escolhido para cancelar reserva de acomodação; no item Processamento, as ações positiva (Em caso afirmativo) e negativa (Senão) foram descritas, uma vez que ação anterior (verificar se o pedido de cancelamento da reserva de acomodação foi feita até 12 horas antes do início previsto para a estadia no hotel) tem essa possibilidade; não houve nenhuma condição/restrição que implicasse a realização do requisito; para o item Saída foram definidas mensagens para que o usuário do sistema saiba o que aconteceu ao solicitar o cancelamento da reserva.

Os exemplos apresentados mostram a forma com que os Requisitos Funcionais foram sendo identificados e transformados para o Formato proposto. Conforme as sentenças originais iam sendo reformuladas, as Recomendações de Escrita foram sendo observadas. Após a conclusão do DRM do Hotel, o Checklist Pré-Inspeção foi aplicado.