SGE

Sistema de Gerenciamento de Estacionamentos

Documento de Elicitao de Requisito

Verso 1.0

Histrico de Revises
Data 27/11/2005 10/02/2012 Autor Karin Komati Karin Komati Verso 1.0 1.01 Modificaes Efetuadas Documento Inicial de Elicitao de Requisitos Alterao para trabalho de BDI do IFES

NDICE
HISTRICO DE REVISES ............................................................................................ 2 1 INTRODUO ................................................................................................................ 4 1.1 PROPSITO DO DOCUMENTO DE REQUISITOS................................................................... 4 1.2 PBLICO ALVO .............................................................................................................. 4 1.3 ESCOPO DO PRODUTO..................................................................................................... 4 1.4 CONVENES, TERMOS E ABREVIAES......................................................................... 5 1.4.1 Identificao dos Requisitos ................................................................................... 5 1.4.2 Prioridade dos Requisitos ...................................................................................... 5 1.5 REFERNCIAS ................................................................................................................ 5 1.6 VISO GERAL DO DOCUMENTO ...................................................................................... 5 2 VISO GERAL DO PRODUTO ..................................................................................... 6 2.1 PERSPECTIVA DO PRODUTO ............................................................................................ 6 2.2 FUNES DO PRODUTO .................................................................................................. 6 2.3 DESCRIO DOS USURIOS ............................................................................................. 6 3 REQUISITOS DO SOFTWARE ..................................................................................... 7 3.1 REQUISITOS FUNCIONAIS ............................................................................................... 7 3.2 REQUISITOS NO-FUNCIONAIS ....................................................................................... 7 3.2.1 Requisitos de Processo ........................................................................................... 7 3.2.2 Requisitos de Produto ............................................................................................ 8 3.2.2.1 Segurana ........................................................................................................... 8 3.2.2.2 Usabilidade ......................................................................................................... 8 3.2.3 Requisitos Externos ................................................................................................ 8 4 MODELAGEM DOS CASOS DE USO........................................................................... 9 4.1 DIAGRAMA DE PACOTES................................................................................................. 9 4.2 ATORES ......................................................................................................................... 9 4.3 DIAGRAMAS ................................................................................................................ 10 4.4 DETALHAMENTO DOS CASOS DE USO ........................................................................... 10 APNDICE A METODOLOGIA DE DESENVOLVIMENTO DO DOCUMENTO 17 APNDICE B REFERNCIAS .................................................................................... 18

Introduo
1.1 Propsito do Documento de Requisitos
Este documento especifica os requisitos do sistema SGE (Sistema de Gerenciamento de Estacionamento), a ser desenvolvido pela turma de Banco de Dados do curso de Sistemas de Informao do IFES no semestre de 2011/2. Este sistema possui a finalidade de prover a automatizao de um parque de estacionamento. Este documento fornece aos desenvolvedores, as informaes necessrias para o projeto do sistema, assim como para a realizao dos testes e homologao do sistema. As informaes aqui descritas formalizam o escopo do sistema e estabelecem uma referncia comum a todos aqueles que participam do desenvolvimento do sistema. Este documento utilizar notao UML para a descrio de suas funcionalidades.

1.2 Pblico Alvo

Este documento no s se destina s pessoas envolvidas no uso e na aquisio do sistema; como tambm na comunicao, de modo preciso, sobre as funes que o sistema tem de fornecer.

1.3 Escopo do Produto

Devido crescente utilizao do automvel como meio de transporte, a centralizao de reas comerciais, aumentou em muito a demanda por uma vaga de estacionamento. No h somente reas fechadas para este fim especfico, reas de estacionamento de shoppings, hospitais, aeroportos, rodovirias e outros locais pblicos decidiram por controlar a entrada e sada de veculos, bem como cobrar pelo uso de seu espao. A cobrana opcional, mas o gerenciamento primordial, pois faz parte da segurana dos locais. Freqentemente, no planejamento de segurana, as empresas ou os empreendimentos subestimam a importncia de um estacionamento, em vez de focaliz-lo como uma das construes e fazendo parte integrante do patrimnio da empresa. As empresas e os empreendedores precisam aprender a ver o estacionamento no como um apndice da empresa, mas sim como uma propriedade de significativa importncia e que requer cuidados especiais, principalmente por causa de seu potencial de levar a empresa a incorrer em custosas aes de responsabilidade legal. Nos EUA, estatsticas de meados de 1.990, do Departamento de Justia revelaram que 10% de todos os raptos ocorreram em estacionamentos chegando a 20% do total de processos de responsabilidade civil. Uma anlise de 731 casos de responsabilidade civil arquivados entre 1.993 e 1.997 refere-se a crimes cometidos em garagens e estacionamentos que geraram aes de responsabilidade civil duas vezes mais freqente do que aqueles cometidos em outros locais de uma propriedade empresarial. De acordo com o Procon-SP, em 2001 foram registradas 24 reclamaes sobre a m prestao desse servio 12 por danos moral ou material causado no veculo e 12 por roubo ou furto. Para minimizar os prejuzos, o consumidor pode valer-se de duas leis municipais, que garantem o ressarcimento em caso de roubo ou furto: a Lei n 10.581, de 22/7/88, que obriga estacionamentos particulares a terem seguro contra roubo, furto, incndio e perda total do veculo, e a Lei n 10.927, de 8/1/91, que obriga shoppings, lojas de departamento e supermercados com mais de 50 vagas a disponibilizarem estacionamento com seguro contra roubo e furto.

Apesar de no constar das leis municipais, de responsabilidade do prestador de servio a guarda de acessrios e de bens deixados no interior dos carros, assim como o de reparar os danos causados nos veculos, opina Arystbulo Freitas, advogado especialista em Direitos do Consumidor. Este sistema ainda se baseia no processo de que havero funcionrios controlando a entrada e a sada de veculos, bem como a cobrana do valor, se existir. Alm de disponibilizar interfaces para as atividades funcionais do estacionamento, o mesmo poder gerar relatrios de uso administrativo.

1.4 Convenes, Termos e Abreviaes

1.4.1 Identificao dos Requisitos
Os requisitos sero identificados por um identificador nico que segue a seguinte regra:

Requisitos Funcionais possuem o identificador [RFabc]; onde a, b, c so dgitos que variam entre 0 e 9; Requisitos No-Funcionais possuem o identificador [RNFabc]; onde a, b, c so dgitos que variam entre 0 e 9.

1.4.2 Prioridade dos Requisitos

Para estabelecer a prioridade dos requisitos foram adotadas as denominaes essencial, importante e desejvel.

Essencial o requisito sem o qual o sistema no entra em funcionamento. Requisitos essenciais so requisitos imprescindveis, que tm que ser implementados impreterivelmente; Importante o requisito sem o qual o sistema entra em funcionamento, mas de forma no satisfatria. Requisitos importantes devem ser implementados, mas, se no forem, o sistema poder ser implantado e usado mesmo assim; Desejvel o requisito que o sistema funciona de forma satisfatria sem ele. Requisitos desejveis so requisitos que podem ser deixados para verses posteriores do sistema, caso no haja tempo hbil para implement-los na verso que est sendo especificada.

1.5 Referncias
Os documentos referenciados encontram-se no Apndice B.

1.6 Viso Geral do Documento

Esta parte do documento fornece informaes necessrias para a utilizao deste documento, As sees apresentadas especificam a descrio do sistema SGE de forma detalhada e esto organizadas como descrito abaixo.

Seo 1: Introduo: Contm, basicamente, os objetivos do documento e convenes adotadas. Seo 2: Viso Geral do Produto: Apresenta uma perspectiva do produto, alm da descrio dos usurios e das funes do sistema. Seo 3: Requisitos do Software: Apresenta todos os requisitos funcionais e nofuncionais de acordo com o padro descrito no captulo 1.5. Seo 4: Modelagem dos Casos de Uso: Apresenta os casos de uso do sistema e seus detalhamentos.

2 Viso Geral do Produto

2.1 Perspectiva do Produto
O sistema trabalhar da seguinte forma: O controle efetuado com base na placa do veculo Na entrada do parque existir um funcionrio que introduz a placa no sistema, ficando de imediato registrada a data e hora de incio do estacionamento. O sistema deve verificar se a placa existe. Se a placa no for reconhecida pelo sistema, ento o funcionrio dever registrar um novo veculo no sistema, indicando apenas a cor e o modelo do veculo. Na sada, um funcionrio introduz novamente a placa, sendo que o sistema calcula o custo do estacionamento, baseado na tabela de preos que varia de acordo com o tempo. O gestor do parque consulta diariamente uma listagem dos estacionamentos. Em algumas situaes, o gestor poder desempenhar funes de atendimento, no entanto, apenas o gestor poder obter listagens. H dois casos que pedem a interveno do gestor do parque: 1) 2) Se ao dar entrada ou sada do veculo, o sistema trouxer dados que no batem com a informao do carro em questo; Ao dar sada, o sistema no reconhece a placa do veculo.

Em ambos os casos, o gestor do parque ter autonomia de alterar quaisquer dados do sistema, porm o sistema ter que criar um log destas situaes.

2.2 Funes do Produto

Visando aproveitar as necessidades identificadas, o sistema apresenta as seguintes funcionalidades:

Gerenciamento de usurios; Acesso restrito a algumas partes do sistema. Gerao de relatrios administrativos; Registro de entrada e sada de veculos, com eventual cobrana se houver;

2.3 Descrio dos usurios

Os usurios do sistema esto descritos a seguir.

Gestor do parque pessoa responsvel pela administrao do estacionamento. Funcionrio pessoa responsvel por registrar as entradas e sadas do parque.

3 Requisitos do Software
3.1 Requisitos Funcionais
Neste tpico abordaremos as funcionalidades a serem oferecidas pelo SGE. Estas funcionalidades so os requisitos funcionais do mesmo. A tabela 1 abaixo lista os servios a serem oferecidos pelo sistema na sua verso inicial. Os identificadores dos requisitos seguem as convenes citadas na Seo 1.4.
Funo [RF01] Login Descrio Dar acesso a usurios aos sistemas. Permite adicionar um novo veculo ao sistema. Permite a edio dos dados de um veculo j cadastrado no sistema. Casos de Uso Relacionados [CDU001] [CDU002] [CDU003]

[RF02] Criar novo veculo [RF03] Alterar Veculos

[RF04] Log do sistema de Ser a gravao de todas as aes gesto do gestor com data/hora, de forma automtica, de forma indireta pelo sistema. [RF05] Registrar entrada [RF06] Registrar sada [RF07] Gerar Relatrios [RF08] Sair Entrada de estacionamento veculo no

[CDU005]

[CDU006] [CDU007] [CDU004] [CDU008]

Sada de veculo no estacionamento Permite ao gestor gerar relatrios do sistema Sai do sistema.

Tabela 1 - Descrio dos Requisitos Funcionais do Sistema

3.2 Requisitos No-Funcionais

Os requisitos que descrevem os aspectos no-funcionais do sistema so apresentados a seguir e foram divididos nas categorias de processo, de produto e externos:

3.2.1 Requisitos de Processo

Os requisitos de processo esto relacionados ao processo de desenvolvimento do sistema.
Identificao [RNF01] Linguagem Programao [RNF02] Modelagem de Descrio O sistema ser desenvolvido utilizando as linguagem de programao Object Pascal. Na fase de anlise, o sistema dever ser modelado em MER (Modelo de Entidades e Relacionamentos).
Tabela 2 - Requisitos de Processo

Casos de Uso Relacionados [CDU001..CDU029]

[CDU001..CDU029]

3.2.2 Requisitos de Produto

Os requisitos de produto esto relacionados s caractersticas desejadas que o sistema deve ter.

3.2.2.1 Segurana
Identificao [RNF03] Confidencialidade Descrio Os usurios cadastrados no sistema devero possuir um login e senha de acesso ao sistema para que assim possam ter acesso s funcionalidades do mesmo. Dever haver um log de sistema para todas as operaes do gestor, exceto a de gerao de relatrios. Os dados armazenados e consultados devero estar corretos em relao aos dados fornecidos ao sistema.
Tabela 3 - Requisitos de Segurana

Casos de Uso Relacionados [CDU008]

[RNF04] Log de sistema

[RNF05] Integridade

[CDU002]

3.2.2.2 Usabilidade
Identificao [RNF06] Mensagens de Erro [RNF07] Interface Sistema do Descrio As mensagens de erro do sistema devero estar em portugus. A interface do sistema dever ser a mesma acordada entre equipe de desenvolvimento e cliente.
Tabela 4 - Requisitos de Usabilidade

Casos de Uso Relacionados [CDU001..CDU029] [CDU001..CDU026; CDU029]

3.2.3 Requisitos Externos

Os requisitos externos so derivados do ambiente no qual o sistema est sendo desenvolvido.
Identificao [RNF08] Tempo Desenvolvimento de Descrio O tempo com o desenvolvimento do sistema no poder a 2 semanas ou at a data de entrega das pautas definido em calendrio da FAVI.
Tabela 5 - Requisitos Externos

Casos de Uso Relacionados [CDU001..CDU029]

4 Modelagem dos Casos de Uso

4.1 Diagrama de Pacotes
O sistema foi divido em dois pacotes, uma chamada de Gesto do estacionamento, apenas com as interfaces que o gestor pode efetuar, e outro denominado de Entrada e sada do estacionamento, que se compe apenas destas duas interfaces.

Figura 1 Diagrama de pacotes

4.2 Atores
So os mesmo usurios j descritos anteriormente.

Gestor do parque pessoa responsvel pela administrao do estacionamento. Funcionrio o atendente que lida diretamente com o cliente, isto , pessoa responsvel por registrar as entradas e sadas do parque.

Figura 2 - Hierarquia de Atores do Sistema

4.3 Diagramas

Figura 3 - Casos de Uso do Sistema

4.4 Detalhamento dos Casos de Uso

O detalhamento dos casos de uso do sistema encontra-se.

[CDU01]
1

Login

Descrio Sumria:
a autenticao do usurio, que restringe determinados usurios cada mdulo do sistema.

2 3 4 5

Atores
Gestor e Funcionrio.

Prioridade Essencial Importante Desejvel Entradas e pr-condies

Nenhuma.

Prioridade:

Sadas e ps-condies
Usurio autenticado.

Fluxo de Eventos
1. apresentado ao Usurio um formulrio com os campos Login e Senha; 2. O usurio informa o seu login e sua senha e clica em continuar; 3. O sistema verifica se existe algum usurio com a senha e o login fornecido; 4. O usurio autenticado no sistema e o sistema aberto; 5. Se for login do gestor: Include (Log de Sistema de Gesto). 6. O caso de uso termina.

Fluxo Bsico

Fluxos Alternativos Login Incorreto

Este fluxo ocorre quando o login que o usurio informou est invlido ou no preenchido. Uma mensagem de erro exibida para o usurio e pedido que o mesmo tente autenticarse novamente. O caso de uso termina.

Senha Incorreta
Este fluxo ocorre quando a senha que o usurio informou est invlida ou no preenchida. Uma mensagem de erro exibida para o usurio e pedido que o mesmo tente autenticarse novamente. O caso de uso termina.

Usurio no cadastrado
Este fluxo ocorre quando o sistema no consegue autenticar o usurio devido sua ausncia no seu cadastro interno. Uma mensagem de erro exibida para o usurio e pedido que o mesmo tente autenticar-se novamente ou solicite seu cadastramento no sistema. O caso de uso termina.

[CDU02]
1 2 3 4 5 6

Criar Novo Veculo

Descrio Sumria
Descreve o processo que permite inserir um novo veculo no sistema.

Atores
Gestor.

Prioridade Essencial Importante Desejvel Entradas e pr-condies

Usurio autenticado no sistema.

Prioridade:

Sadas e ps-condies
Insero de um novo veculo ao sistema.

Fluxo de Eventos

Fluxo Bsico
1. O usurio preenche um formulrio com os campos placa, cor e modelo do veculo; 2. O sistema valida os dados.

3. O sistema atualiza a base de dados; 4. Include (Log de Sistema de Gesto). 5. O caso de uso termina.

Fluxos Alternativos Cancelamento

At o passo 3, o processo pode a qualquer momento ser cancelado e o registro no inserido no sistema.

Placa j existente
A validao dos dados deve verificar se a placa j existe no sistema. No podese ter placas repetidas, logo, uma mensagem de erro explicativa deve ser exibida e o registro no inserido no sistema.

Placa invlida
A validao dos dados deve verificar se a placa est na formatao correta, isto , carros nacionais possuem placa no formato [LLLDDD], onde L letra e D digito. Caso esteja em formato diferente, uma mensagem de erro explicativa deve ser exibida e o registro no inserido no sistema.

Modelo ou cor inexistente

Tanto modelo quanto cor devem ser informados, no devem ser aceitos valores vazios. Caso ocorra, uma mensagem de erro explicativa deve ser exibida e o registro no inserido no sistema.

[CDU03]
1 2 3 4 5 6

Alterar Veculos

Descrio Sumria
Permite alterar os dados de um veculo no sistema.

Atores
Gestor.

Prioridade Essencial Importante Desejvel Entradas e pr-condies

Usurio autenticado no sistema.

Prioridade:

Sadas e ps-condies
Atualizao dos dados do sistema.

Fluxo de Eventos

Fluxo Bsico
1. O sistema exibe uma lista de veculos; 2. O usurio pode selecionar qualquer um dos veculos; interessante que nesta interface o usurio tenha alguma facilidade de pesquisa do veculo atravs de seus dados; 3. o sistema exibe um formulrio com os dados do veculo escolhido; 4. O usurio modifica os dados desejados, menos a placa

5. O sistema valida as informaes. 6. O sistema atualiza a base de dados; 7. Include (Log de Sistema de Gesto). 8. O caso de uso termina.

Fluxos Alternativos Cancelamento

At o passo 4, o processo pode a qualquer momento ser cancelado e o registro no inserido no sistema.

Modelo ou cor inexistente

Tanto modelo quanto cor devem ser informados, no devem ser aceitos valores vazios. Caso ocorra, uma mensagem de erro explicativa deve ser exibida e o registro no inserido no sistema.

[CDU04]
1

Log do sistema de gesto

Descrio Sumria
De acordo com algumas aes do gestor, o sistema automaticamente cadastra o que foi feito, permitindo o rastreamento das operaes posteriormente.

2 3 4 5 6

Atores
Sistema.

Prioridade Essencial Importante Desejvel Entradas e pr-condies

Gestor autenticado no sistema.

Prioridade:

Sadas e ps-condies
Nova entrada no log do sistema.

Fluxo de Eventos

Fluxo Bsico
1. Ser inserido uma entrada no log de operaes contendo as seguients informaes: login, data e hora atual e texto descrevendo qual foi a operao realizada, dados anteriores operao (se houver) e dados posteriores (se houver). 2. Base de dados atualizada; 3. O caso de uso termina.

Fluxos Alternativos Erro na insero de registro no log

Caso haja algum problema: falta de espao ou problemas de hw ou de rede, e o log no pode ser gravado, a operao do gestor que deu origem ao log tambm no poder ser efetivada na base de dados.

[CDU05]
1 2 3 4 5 6

Registrar Entrada

Descrio Sumria
Permite o registro de entrada de um veculo ao estacionamento.

Atores
Funcionrio e gestor.

Prioridade Essencial Importante Desejvel Entradas e pr-condies

Usurio autenticado no sistema e h vaga no estacionamento.

Prioridade:

Sadas e ps-condies
Veculo no estacionamento.

Fluxo de Eventos

Fluxo Bsico
1. O funcionrio introduz a placa do veculo. 2. Se esta placa no existir, ento <Extension Point>: Novo Veculo; 3. Valida-se o formato da placa; 4. Se a placa j existir e os dados conferem, ento registrada a data e hora de entrada do veculo. 5. O sistema deve diminuir em um, as vagas disponveis inicialmente. 6. O caso de uso termina.

Fluxos Alternativos Placa invlida

A validao dos dados deve verificar se a placa est na formatao correta, isto , carros nacionais possuem placa no formato [LLLDDD], onde L letra e D digito. Caso esteja em formato diferente, uma mensagem de erro explicativa deve ser exibida e o registro no inserido no sistema.

Se os dados do sistema no conferirem com o veculo

Caso haja este problema, o atendente dever efetuar a entrada do veculo e comunicar ao gestor. O gestor que decidir se ir atualizar os dados do veculo.

[CDU06]
1 2 3

Registrar Sada

Descrio Sumria
Permite o registro de sada de um veculo ao estacionamento.

Atores
Funcionrio e gestor.

Prioridade

Prioridade: 4 5 6
1 2 3 4 5 6 7

Essencial

Importante

Desejvel

Entradas e pr-condies
Usurio autenticado no sistema.

Sadas e ps-condies
O veculo saiu do estacionamento e h mais uma vaga disponvel.

Fluxo de Eventos
O funcionrio introduz a placa do veculo. Valida-se o formato da placa; Se a placa j existir e os dados conferem, ento registrada a data e hora de sada do veculo. O sistema computa o valor, dado a data;hora de entrada e sada e de acordo com a tabela de preos por tempo de uso. O valor do caixa deve ser incrementado deste valor de pagamento computado; O sistema deve aumentar em um, as vagas disponveis inicialmente. O caso de uso termina.

Fluxos Alternativos Placa invlida

A validao dos dados deve verificar se a placa est na formatao correta, isto , carros nacionais possuem placa no formato [LLLDDD], onde L letra e D digito. Caso esteja em formato diferente, uma mensagem de erro explicativa deve ser exibida e o registro no inserido no sistema.

Se os dados do sistema no conferirem com o veculo

Caso haja este problema, o atendente dever chamar o gestor, e este dever efetuar uma vistoria do carro. Ele ter autonomia para decidir o que fazer.

Placa inexistente
Caso haja este problema, o atendente dever chamar o gestor, e este dever efetuar uma vistoria do carro. Ele ter autonomia para decidir o que fazer.

[CDU07]
1 2 3 4 5

Gerar Relatrios

Descrio Sumria
Descreve o processo que permite ao gestor do estacionamento gerar relatrios

Atores
Gestor.

Prioridade Essencial Importante Desejvel Entradas e pr-condies

Estar autenticado pelo sistema.

Prioridade:

Sadas e ps-condies

Relatrio gerado.

Fluxo de Eventos

Fluxo Bsico
1. O gestor ir escolher as tabelas do sistema. 2. Opcionalmente, ir escrever quais so as condies de filtro; 3. Opcionalmente, ir escolher quais so as colunas de agrupamento 4. Opcionalmente, ir escrever quais so as condies de filtro de grupo; 5. Opcionalmente, ir escolher quais colunas sero mostradas; 6. Opcionalmente, ir escolher qual a ordem dos dados; 7. O relatrio gerado; 8. O caso de uso termina.

Fluxos Alternativos Relatrio com erro.

Os relatrios dependem muito do que o usurio ir escrever, logo, as mensagens de erro do SGBD sero apenas mostradas de forma verbatim ao usurio.

[CDU08]
1 2 3 4 5 6

Sair

Descrio Sumria
Sai do sistema.

Atores
Funcionrio e gestor.

Prioridade
Essencial Importante

Prioridade:

Desejvel

Entradas e pr-condies
Usurio deve estar autenticado no sistema.

Sadas e ps-condies
Sada do sistema.

Fluxo de Eventos

Fluxo Bsico
1. O usurio clica no boto de sair para sair da rea restrita do sistema. 2. O sistema fecha. 3. Se for login do gestor: Include (Log de Sistema de Gesto). 4. O caso de uso termina.

APNDICE A METODOLOGIA DE DESENVOLVIMENTO DO DOCUMENTO

A estrutura deste documento seguiu o padro IEEE/ANSI 830-1998 e o resultado de um processo que foi confeccionado atravs dos seguintes passos: 1) 2) 3) 4) 5) 6) 7) 8) 9) Identificao do Problema a ser pesquisado Estudo de viabilidade de desenvolvimento do projeto Coleta de Informaes Levantamento dos usurios mais significativos Definio do escopo do produto Identificao dos requisitos funcionais, no funcionais e organizacionais. Desenvolvimento do diagrama de casos de uso Detalhamento dos casos de uso Escolha de modelos de documentao A primeira atividade foi a identificao de um problema a ser focado e a anlise de viabilidade de desenvolvimento de uma soluo para o mesmo. Aps a concluso que o desenvolvimento de um software que solucionasse o problema era vivel, partimos para a definio do escopo do produto em sua verso inicial. No desenvolvimento do escopo, selecionamos as idias que resolvessem as principais necessidades dos usurrios. No houve coleta de informaes atravs de entrevistas e sim apenas atravs de observao de um sistema pr-existente. A partir dos requisitos funcionais e dos usurios identificados, elaboramos um diagrama de casos de uso que ilustra as funcionalidades do sistema e como estas esto relacionadas com cada um dos usurios do sistema. Feito isto, detalhamos os casos de uso exibindo o fluxo de eventos executados pelos usurios para realizar a funcionalidade desejada, o que acontece se o fluxo for desviado por algum motivo e como estes casos de uso esto relacionados com os requisitos funcionais e no funcionais do sistema.

APNDICE B REFERNCIAS
Esta subseo do documento apresenta as referncias aos documentos utilizados na elaborao deste.

Norma IEEE/ANSI 830-1998 (US Depatment of Defense). IEEE Recommended Pratice for Software Requirements Specifications, IEEE Computer Society Press. KOTONYA, Gerald and SOMMERVILLE, Ian. Requirements Engineering. Ed Wiley. SOMMERVILLE, Ian. Engenharia de Software. 6 edio. Aulas da Disciplina de Especificao de Requisitos e Validao de Sistemas (IF716). Disponveis em http://www.cin.ufpe.br/~if716. ltimo acesso: 02/06/2004. Aulas da Disciplina de Projeto de Banco de Dados (IF692). Disponveis em http://www.cin.ufpe.br/~if692. ltimo acesso: 15/06/2004. Aulas da Disciplina de Engenharia de Software e Sistemas (IF682). Disponveis em http://www.cin.ufpe.br/~if682. ltimo acesso: 08/06/2004.