Gesto de Projectos de Software - Universidade de Coimbra - Additional... · 2007-06-13 · Gestão...

Gestão de Projectos de Software

Projecto DriveGest

Additional Spec Doc

Versão 1.0 DriveGest_AdditionalSpecDoc_2007-04-14_v1.0.doc

14 de Abril de 2007

DriveGest_AdditionalSpecDoc_2007‐04‐14_v1.0.doc 2

2 Projecto DriveGest

Revisões

Versão Autores Descrição Aprovadores Data

1.0 Pedro Miguel Lourenço

Versão baselined Pedro Matrola (Moderador), Richard Nuno, Jorge Sousa e Miguel Alpendre

2007-04-14



Índice

1. Introdução ............................................................................................... 4

2. Modelo Conceptual de Dados ........................................................................ 5

2.1. Diagrama Entidade-Relacionamento .......................................................... 5

2.2. Descrição das Entidades ......................................................................... 6

2.3. Descrição dos Relacionamentos.............................................................. 13

3. Modelo Físico da Base de Dados................................................................... 16

3.1. Modelo Físico de Dados ........................................................................ 16

3.2. Considerações Adicionais...................................................................... 17

4. Códigos de Erro e Mensagens ...................................................................... 18

4.1. Módulo Aluno .................................................................................... 18

4.2. Módulo Professor................................................................................ 19

4.3. Módulo Administrador.......................................................................... 20

4.4. Módulo Horários ................................................................................. 22

4.5. Módulo Veículos ................................................................................. 22



1. Introdução

O Additional Spec Doc tem por objectivo complementar a especificação do software que se pretende implementar. Essa especificação encontra‐se dividida em dois capítulos principais: 1 – Modelo Conceptual de Dados e 2 – Modelo Físico da Base de Dados.

O primeiro apresenta o modelo conceptual da base de dados e a descrição detalhada das entidades e relacionamentos. Sempre que for necessário será esclarecido o significado dos registos utilizados e que tipo de informação é guardada em cada atributo.

O segundo capítulo apresenta o diagrama físico da base de dados que será utilizada no sistema de gestão. Este diagrama serve sobretudo para elucidar os programadores quanto à estruturação da BD e facilitar a implementação do código e a formulação de queries.


2. Modelo Conceptual de Dados 2.1. Diagrama Entidade‐Relacionamento

são

tem aulada aula

efectua

corresponde a

pode a

disponivel apertence a

é necessario

possui

correspondepossui

necessitam

Instrutor

Veiculo

v_idv_matriculav_marcav_modelov_anov_cilindradav_prox_inspv_prox_revv_dispv_tipo_comb

<pi> IVA8VA15VA15N4N4DDBLVA10

<M><M><M><M>

<M><M><M><M>

Identifier_1 <pi>

Funcionario

Horario

h_idh_anoh_mesh_dia_mesh_dia_semh_hora

<pi> IN4N2N2VA3N2

<M><M><M><M><M><M>

Identifier_1 <pi>

Pessoa

p_idp_nomep_moradap_data_nascp_telefonep_contribuintep_num_identp_loginp_passwordp_mailp_tipo

<pi> IVA30VA50DN9N9N9VA10VA10VA20N1

<M><M><M><M>

<M><M><M>

<M>

Identifier_1 <pi>

Aluno

Pagamento

pg_idpg_montantepg_datapg_tipo_pag

<pi> IN6,2DVA20

<M><M><M>

Identifier_1 <pi>

Hora

hr_idhr_diahr_hora

<pi> IVA3N2

<M><M><M>

Identifier_1 <pi>

Contrato

c_idc_datac_num_aulas

<pi> IDN3

<M><M>

Identifier_1 <pi>

Categoria

ca_idca_desc

<pi> IVA3

<M><M>

Identifier_1 <pi>

Meta

m_idm_estadom_data

<pi> IA1D

<M><M><M>

Identifier_1 <pi>

Tipo_meta

tm_idtm_desc

<pi> IVA20

<M><M>

Identifier_1 <pi>

Precario

pr_idpr_descpr_montante

<pi> IVA20N6,2

<M><M><M>

Identifier_1 <pi>

Adenda

ad_idad_descad_preco

<pi> IVA20N6,2

<M><M><M>

Identifier_1 <pi>




2.2. Descrição das Entidades

Tabela Pessoa

Atributo Tipo Características Descrição

p_id Numérico Chave primária

Campo obrigatório

Identificador unívoco de uma pessoa.

p_nome String Campo obrigatório

Máximo: 30 caracteres

Nome de uma pessoa.

p_morada String Campo obrigatório


Morada de uma pessoa.

p_data_nasc Data Campo obrigatório Data de nascimento da pessoa.

p_telefone Numérico Número de 9 dígitos Contacto telefónico de uma pessoa.

p_contribuinte Numérico Mínimo: 8 carateres


Número de contribuinte de uma pessoa.

p_login String Campo obrigatório

Mínimo: 6 carateres


Login para autenticação no sistema.

P_password String Campo obrigatório

Mínimo: 6 carateres


Password para autenticação no sistema.

p_num_ident Numérico Campo obrigatório

String de 9 dígitos

Número de identificação pessoal de um aluno.

p_mail String Máximo: 20 caracteres

E-mail da pessoa.

p_tipo Numérico Campo obrigatório Consiste numa flag que identifica o tipo de pessoa a que nos estamos a



Valores possíveis:

1 - Aluno, 2- Instrutor, 3 - Funcionário

referir.

A tabela ‘Pessoa’ tem três entidades‐filho que herdam os seus atributos. Essas três tabelas: ‘Aluno’, ‘Instrutor’ e ‘Funcionario’ representam os diversos tipos de pessoas que podem ser representadas na base de dados. Nenhuma dessas tabelas possui atributos específicos.

Tabela Contrato


c_id Numérico Chave primária

Campo obrigatório

Identificador unívoco de um contrato efectuado entre um aluno e a escola de condução.

c_data Data Campo obrigatório Data do contrato.

c_num_aulas Numérico Máximo: 2 dígitos Número de aulas de condução efectuadas por um aluno dentro de um determinado contrato. Este atributo é calculado.

Tabela Adenda


ad_id Numérico Chave primária

Campo obrigatório

Identificador unívoco de uma adenda correspondente a um determinado contrato.

ad_desc String Campo obrigatório


Descrição do produto ou serviço requisitado à escola de condução.

ad_preco Numérico Campo obrigatório

Número de 6 dígitos com 2 para precisão

Valores possíveis:

Indica o montante a pagar por um determinado produto ou serviço.



0,01 a 9999,99

ad_data Data Campo obrigatório Data do pedido.

Tabela Pagamento


pg_id Numérico Chave primária

Campo obrigatório

Identificador unívoco de um pagamento efectuado para uma determinada adenda do contrato.

pg_montante Numérico Campo obrigatório

Número de 6 dígitos com 2 para precisão

Valores: 0,01 a 9999,99

Indica o montante pago.

pg_data Data Campo obrigatório Data do pagamento.

pg_tipo_pag String Valores possíveis:

‘dinheiro’, ‘cheque’, ‘cartao’ ou ‘transferencia’.

Forma de pagamento utilizada

Tabela Categoria


ca_id Numérico Chave primária

Campo obrigatório

Identificador unívoco de uma categoria de veículo.

ca_desc String Campo obrigatório

Valores possíveis:

‘A’,’B’,’C’, ‘D’, ‘E’, ‘B+E’, ‘C+E’ e ‘D+E’.

Descrição da categoria em questão.



Tabela Veiculo


v_id Numérico Campo obrigatório Identificador unívoco de um veículo. É um atributo do tipo inteiro.

v_matricula String Campo obrigatório

String de 8 caracteres

Matrícula de um veículo.

v_marca String Campo obrigatório


Marca do veículo.

v_modelo String Campo obrigatório


Modelo do veículo.

v_ano Numérico Número de 4 dígitos Ano do veículo.

v_cilindrada Numérico Número de 4 dígitos Cilindrada do veículo.

v_prox_insp Data Campo obrigatório Data da próxima inspecção do veículo.

v_prox_rev Data Campo obrigatório Data da próxima revisão do veículo.

v_disp Boolean Campo obrigatório

Valores possíveis:

true - disponível, false - indisponível

Apresenta a disponibilidade do veículo.

v_tipo_comb String Campo obrigatório


Valores possíveis:

gasóleo, gasolina, gás, eléctrico, hidrogénio, híbrido.

Tipo de combustível utilizado pelo veículo.

Tabela Hora




hr_id Numérico Chave primária

Campo obrigatório

Identificador unívoco de uma hora.

hr_dia String Campo obrigatório


Valores possíveis:

’seg’, ‘ter’, ‘qua’, ‘qui’, ‘sex’ e ‘sab’

Representa um dia da semana.

hr_hora Numérico Campo obrigatório

Número de 2 dígitos.

Indica uma hora que em que alunos ou instrutores podem estar disponíveis para marcação de aula.

Tabela Horário


h_id Numérico Chave primária

Campo obrigatório

Identificador unívoco de uma marcação de aula.

h_ano Numérico Campo obrigatório

Representa o ano em que a aula decorre.

h_mes Numérico Campo obrigatório


Valores: 1 a 12.

Representa um mês do ano.

h_dia_mes Numérico Campo obrigatório


Valores: 1 a 31.

Representa um dia do mês.

h_dia_sem String Campo obrigatório


Representa um dia da semana.



Valores possíveis:

’seg’, ‘ter’, ‘qua’, ‘qui’, ‘sex’ e ‘sab’

h_hora Numérico Campo obrigatório


Representa uma hora do dia. Qualquer hora do dia poderá ser representada, sendo que terá lógica restringir à gama 8h-19h.

Tabela Meta


m_id Numérico Chave primária

Campo obrigatório

Identificador unívoco de uma meta dentro de um contracto.

m_data Data Campo obrigatório Data do registo da meta.

m_estado Caracter Campo obrigatório

Valores possíveis:

‘E’ – Em espera

‘P’ – Passou

‘C’ – Chumbou

Define o estado da meta.

Tabela Tipo_meta


tm_id Numérico Chave primária

Campo obrigatório

Identificador unívoco de um tipo de meta.

tm_desc String Campo obrigatório


Descrição da meta.

Tabela Precario




pr_id Numérico Chave primária

Campo obrigatório

Identificador unívoco de um preço.

pr_desc String Campo obrigatório


Valores possíveis:

‘pack cat. A’, ‘pack cat. B’, (…), ‘aula extra’, ‘exame codigo’, ‘exame conducao’.

Produto que se está a comprar.

pr_montante Numérico Campo obrigatório

Número de 6 dígitos com 2 para precisão.

Valores: 0,01 a 9999,99

Preço do produto ou serviço.



2.3. Descrição dos Relacionamentos

Tabela de Relacionamentos

Tabela 1 Tabela 2 Cardinalidade Descrição

Pessoa Aluno - Relação de herança.

O aluno é um dos três tipos de pessoas existentes na BD.

Pessoa Funcionario -

Relação de herança.

Um funcionário é um dos três tipos de pessoas existentes na BD.

Pessoa Instrutor -

Relação de herança.

Um instrutor é um dos três tipos de pessoas existentes na BD.

Aluno Contrato One-to-Many

Um aluno pode efectuar vários contratos para tirar diferentes licenças de condução.

Um contrato corresponde a um e um só aluno.

A relação é mandatory nos dois sentidos visto que não existe nenhum aluno na escola que não tenha efectuado um contrato e não existe contrato sem haver aluno.

Aluno Hora Many-to-Many

Um aluno está disponível a várias horas.

Numa determinada hora, vários alunos podem estar disponíveis.

A relação não é mandatory em nenhum dos sentidos visto que os alunos não são obrigados a terem definidas as suas disponibilidades e para determinada hora não é obrigatório que exista algum aluno disponível.

Aluno Horario One-to-Many

Um aluno marca aulas de condução em diversos horários.

Em cada horário só pode existir um aluno a ter aula com um determinado instrutor, a uma determinada hora, no mesmo veículo.

A relação é mandatory no sentido Horario -> Aluno visto que não é possível marcar uma aula de condução se não



existirem alunos.

Instrutor Hora Many-to-Many

Um instrutor está disponível a várias horas.

Numa determinada hora, vários instrutores podem estar disponíveis.

A relação não é mandatory em nenhum dos sentidos visto que os instrutores não são obrigados a terem definidas as suas disponibilidades e para determinada hora não é obrigatório que exista um instrutor disponível.

Instrutor Horario One-to-Many

Um instrutor dá aulas de condução em diversos horários.

Em cada horário só existe um instrutor a dar uma aula, numa determinada hora, num determinado veículo.

A relação é mandatory no sentido Horario -> Instrutor visto que não é possível efectuar uma aula de condução se não existir um instrutor disponível.

Horario Veiculo Many-to-Many

Um veículo é utilizado em diversos horários.

Num horário podem ser necessários vários veículos. Esta relação prevê, de entre outras coisas, as aulas de condução de motociclos. Neste tipo de aula é necessário um motociclo para o aluno e um automóvel para o instrutor.

A relação é mandatory no sentido Horario -> Veiculo visto que não é possível efectuar uma aula de condução se não existir um veiculo disponível.

Veiculo Categoria Many-to-Many

Existem vários veículos com a mesma categoria.

Uma categoria pode incluir um ou dois veículos. É o caso da categoria B+E que inclui um automóvel e um atrelado.

A relação é mandatory no sentido Veiculo -> Categoria visto que um veículo tem que pertencer obrigatoriamente a uma categoria.

Categoria Contrato One-to-Many

Num determinado contrato, a licença de condução que se pretende tirar refere-se a uma única categoria de veículos.

Vários contratos podem referir-se à mesma categoria.

A relação é mandatory no sentido Contrato -> Categoria visto que para existir um contrato é necessário que ele se



refira a uma categoria.

Contrato Adeda One-to-Many

Podem existir diversas adendas dentro de um contrato.

Uma adenda refere-se a um e um só contrato.

A relação é mandatory no sentido Adenda -> Contrato visto que só existem adendas se estiver estabelecido um contrato.

Adenda Pagamento One-to-Many

Podem existir diversos pagamentos dentro de uma adenda.

Um pagamento refere-se a uma e uma só adenda.

A relação é mandatory no sentido Pagamento -> Adenda visto que só existem pagamentos se estiver estabelecida uma adenda.

Contrato Meta One-to-Many

Um contrato possui várias metas.

Uma meta corresponde a um único contrato.

A relação é mandatory no sentido Meta -> Contrato visto que só existem metas se estiver estabelecido um contrato.

Meta Tipo_meta Many-to-One

Uma meta corresponde a um único tipo de meta.

Várias metas podem corresponder ao mesmo tipo de meta.

A relação é mandatory no sentido Meta -> Tipo_meta visto que só existe uma meta se estiver estabelecido o tipo de meta correspondente.


3. Modelo Físico da Base de Dados 3.1. Modelo Físico de Dados

FK_ALUNO_SAO_PESSOAFK_INSTRUTO_SAO2_PESSOA

FK_FUNCIONA_SAO3_PESSOA

FK_HORARIO_TEM_AULA_ALUNOFK_HORARIO_RELATIONS_INSTRUTO

FK_CONTRATO_EFECTUA_ALUNO

FK_CONTRATO_RELATIONS_CATEGORI

FK_RELATION_RELATIONS_HORA

FK_RELATION_RELATIONS_ALUNO

FK_RELATION_RELATIONS_INSTRUTO

FK_RELATION_RELATIONS_HORA

FK_RELATION_RELATIONS_CATEGORI

FK_RELATION_RELATIONS_VEICULO

FK_RELATION_RELATIONS_VEICULOFK_RELATION_RELATIONS_HORARIO

FK_META_RELATIONS_CONTRATO

FK_META_RELATIONS_TIPO_MET

FK_ADENDA_RELATIONS_CONTRATO

FK_PAGAMENT_RELATIONS_ADENDA

Instrutor

p_id integer <pk,fk>

Veiculo

v_idv_matriculav_marcav_modelov_anov_cilindradav_prox_inspv_prox_revv_dispv_tipo_comb

integervarchar(8)varchar(15)varchar(15)numeric(4)numeric(4)datedatesmallintvarchar(10)

<pk>

Funcionario


Horario

h_idp_idAlu_p_idh_anoh_mesh_dia_mesh_dia_semh_hora

integerintegerintegernumeric(4)numeric(2)numeric(2)varchar(3)numeric(2)

<pk><fk2><fk1>

Pessoa

p_idp_nomep_moradap_data_nascp_telefonep_contribuintep_num_identp_loginp_passwordp_mailp_tipo

integervarchar(30)varchar(50)datenumeric(9)numeric(9)numeric(9)varchar(10)varchar(10)varchar(20)numeric(1)

<pk>

Aluno


Pagamento

pg_idad_idpg_montantepg_datapg_tipo_pag

integerintegernumeric(6,2)datevarchar(20)

<pk><fk>

Hora

hr_idhr_diahr_hora

integervarchar(3)numeric(2)

<pk>

Contrato

c_idca_idp_idc_datac_num_aulas

integerintegerintegerdatenumeric(3)

<pk><fk2><fk1>

Categoria

ca_idca_desc

integervarchar(3)

<pk>

Meta

m_idc_idtm_idm_estadom_data

integerintegerintegerchar(1)date

<pk><fk1><fk2>

Tipo_meta

tm_idtm_desc

integervarchar(20)

<pk>

Precario

pr_idpr_descpr_montante

integervarchar(20)numeric(6,2)

<pk>

Adenda

ad_idc_idad_descad_preco

integerintegervarchar(20)numeric(6,2)

<pk><fk>

pode a

hr_idp_id

integerinteger

<pk,fk1><pk,fk2>

disponivel a

p_idhr_id

integerinteger

<pk,fk1><pk,fk2>

pertence a

ca_idv_id

integerinteger

<pk,fk1><pk,fk2>

é necessario

v_idh_id

integerinteger

<pk,fk1><pk,fk2>




3.2. Considerações Adicionais

Quanto ao modelo físico da base de dados não há elementos importantes a acrescentar. Tudo o que é necessário saber está indicado na descrição do modelo conceptual. Destaque apenas para o surgimento de novas tabelas de ligação devido às relações N para M. Estas tabelas são:

disponivel a – ligação entre Instrutor e Hora. (Instrutor ‘disponivel a’ determinada Hora)

pode a ‐ ligação entre Aluno e Hora. (Aluno ‘pode’ ter aula a determinada Hora)

e necessario – ligação entre Veiculo e Horario. (Veiculo ‘e necessario’ num determinado Horario)

pertence a – ligação entre Categoria e Veiculo. (Veiculo ‘pertence a’ uma Categoria)



4. Códigos de Erro e Mensagens

Nas tabelas seguintes são apresentados os códigos de erro e mensagens correspondentes a cada um deles. Estas mensagens surgem ao utilizador caso sejam introduzidos valores inválidos nos formulários ou exista uma tentativa de aceder a secções do programa para as quais não há permissão. Estão também previstas outras mensagens de aviso ou de confirmação.

Cada módulo do nosso trabalho terá uma tabela de mensagens. Os principais módulos existentes correspondem aos diferentes tipos de permissão de acesso. Assim sendo, teremos módulo Aluno, módulo Professor e módulo Administrador. Para completar, teremos o módulo Horários e o módulo Veículos.

4.1. Módulo Aluno

Código Circunstância Mensagem

A1 Global – tentativa de acesso a páginas para as quais não tem permissão

Não tem permissão para aceder a esta página.

A2 Edição de dados de acesso – campo login – falta de preenchimento

Campo login em branco.

A3 Edição de dados de acesso – campo password – falta de preenchimento

Campo password em branco.

A4 Edição de dados de acesso – campo confirme password – falta de preenchimento

Campo confirme password em branco.

A5 Edição de dados de acesso – campo password e confirmação de password com dados diferentes

As passwords não coincidem.

A6 Edição de dados de acesso – campo login possui menos de 6 caracteres

O login tem de ter pelo menos 6 caracteres.

A7 Edição de dados de acesso – campo password possui menos de 6 caracteres

A password tem de ter pelo menos 6 caracteres.

A8 Edição de dados de acesso – campo login com um login já existente na bd

O login escolhido já existe. Tente outro por favor.



4.2. Módulo Professor


B1 Global – tentativa de acesso a páginas para as quais não tem permissão


B2 Edição de perfil – campo nome – falta de preenchimento

Campo nome em branco.

B3 Edição de perfil – campo login – falta de preenchimento


B4 Edição de perfil – campo password – falta de preenchimento


B5 Edição de perfil – campo confirmação de password – falta de preenchimento

Campo confirmação de password em branco.

B6 Edição de perfil – campo data de nascimento – falta de preenchimento

Campo data de nascimento em branco.

B7 Edição de perfil – campo password e confirmação de password com dados diferentes


B8 Edição de perfil – campo login possui menos de 6 caracteres


B9 Edição de perfil – campo password possui menos de 6 caracteres


B10 Edição de perfil – campo data de nascimento – data muito recente

Data de nascimento inválida - mínimo 18 anos.

B11 Edição de perfil – campo nº contribuinte tem menos que oito dígitos

Nº de contribuinte tem de ter pelo menos 8 dígitos.

B12 Edição de perfil – campo telefone tem menos de 9 dígitos

Telefone tem que ter 9 dígitos.

B13 Edição de perfil – campo nº contribuinte apresenta caracteres não numéricos

O nº contribuinte só pode ter caracteres numéricos.

B14 Edição de perfil – campo telefone apresenta caracteres não numéricos

O telefone só pode ter caracteres numéricos.



B15 Edição de perfil – campo e-mail apresenta um e-mail incoerente

O e-mail é inválido.

4.3. Módulo Administrador


C1 Global – tentativa de acesso a páginas para as quais não tem permissão


C2 Global – Proximidade de uma inspecção num dos veículos

A inspecção do veículo x é já no próximo dia y!

C3 Global – Proximidade de uma revisão num dos veículos

A revisão do veículo x é já no próximo dia y!

C4 Edição de perfil – campo nome – falta de preenchimento


C5 Edição de perfil – campo login – falta de preenchimento


C6 Edição de perfil – campo password – falta de preenchimento


C7 Edição de perfil – campo confirmação de password – falta de preenchimento

Campo confirmação de password em branco.

C8 Edição de perfil – campo password e confirmação de password com dados diferentes


C9 Edição de perfil – campo login possui menos de 6 caracteres


C10 Edição de perfil – campo password possui menos de 6 caracteres


C11 Edição de perfil – campo nº contribuinte tem menos que oito dígitos


C12 Edição de perfil – campo telefone tem menos de 9 dígitos


C13 Edição de perfil – campo nº contribuinte apresenta caracteres não numéricos




C14 Edição de perfil – campo telefone apresenta caracteres não numéricos


C15 Inserção de utilizadores – campo nome – falta de preenchimento


C16 Inserção de utilizadores – campo login – falta de preenchimento


C17 Inserção de utilizadores – campo data de nascimento – falta de preenchimento

Campo data de nascimento de em branco.

C18 Inserção de utilizadores – campo login possui menos de 6 caracteres


C19 Inserção de utilizadores – campo data de nascimento – data muito recente

Data de nascimento inválida - mínino 18 anos.

C20 Inserção de utilizadores – campo nº contribuinte tem menos que oito dígitos


C21 Inserção de utilizadores – campo telefone tem menos de 9 dígitos


C22 Inserção de utilizadores – campo nº contribuinte apresenta caracteres não numéricos


C23 Inserção de utilizadores – campo telefone apresenta caracteres não numéricos


C24 Inserção de utilizadores – campo e-mail apresenta um e-mail incoerente

O e-mail é inválido.

C25 Inserção de utilizadores – campo permissão – não efectuou nenhuma selecção na drop-down box

Não efectuou nenhuma selecção para a permissão

C26 Edição alunos – dados contabilísticos – campos pagar – sem preenchimento

O campo pagamento está em branco

C27 Edição alunos – dados contabilísticos – campos pagar – com caracteres não numéricos

O valor inserido é inválido

C28 Edição alunos – dados contabilísticos – campos pagar – valor em excesso

O valor introduzido é superior ao valor total necessário para efectuar o pagamento

C29 Edição alunos – dados contabilísticos – O campo mais aulas está em branco



campo mais aulas – sem preenchimento

C30 Edição alunos – dados contabilísticos – campo mais aulas – com carateres não numéricos

O valor inserido no campo mais aulas é inválido

4.4. Módulo Horários


D1 Inserir nova aula – submissão do formulário sem existir selecção de aluno e/ou professor.

Não seleccionou nenhum aluno e/ou professor

4.5. Módulo Veículos


E1 Global – tentativa de acesso a páginas para as quais não tem permissão


E2 Inserir novo veículo – campo marca – falta de preenchimento

Campo marca sem preenchimento

E3 Inserir novo veículo – campo modelo – falta de preenchimento

Campo modelo sem preenchimento

E4 Inserir novo veículo – campo data de aquisição – falta de preenchimento

Campo data de aquisição sem preenchimento

E5 Inserir novo veículo – campo data próxima inspecção – falta de preenchimento

Campo data próxima inspecção sem preenchimento

E6 Inserir novo veículo – campo ano de aquisição – ano superior ao ano actual.

Data de aquisição inválida

E7 Inserir novo veículo – campo data próxima inspecção – data inferior à data actual

Data da próxima inspecção inválida

Gesto de Projectos de Software - Universidade de Coimbra - Additional... · 2007-06-13 · Gestão...

Documents

Transcript of Gesto de Projectos de Software - Universidade de Coimbra - Additional... · 2007-06-13 · Gestão...