G2 - Atividade Prática 4

Prévia do material em texto

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE GOIÁS 
DEPARTAMENTO DE COMPUTAÇÃO 
 
João Vitor Ferreira de Melo 
Vinícius Biasi Nascimento 
Wemerson Moura Viana 
Willgnner Ferreira Santos 
 
G2 – Atividade Prática 4 
 
 
 
 
 
 
 
André Luiz Alves 
 
 
 
 
 
 
 
 
 
 
GOIÂNIA, 
2021 
João Vitor Ferreira de Melo 
Vinícius Biasi Nascimento 
Wemerson Moura Viana 
Willgnner Ferreira Santos 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
G2 – Atividade Prática 4 
 
Relatório apresentado como requisito parcial para 
obtenção de aprovação na disciplina Validação e Testes 
de Sistemas no Curso de Engenharia da Computação, na 
Pontifícia Universidade Católica de Goiás. 
André Luiz Alves 
 
 
 
 
 
 
 
 
GOIÂNIA, 
2021 
Revisões 
A primeira versão deste documento é criada após a sua aprovação e é vinculada a uma 
baseline do software. Esta versão, portanto, não pode ser modificada. As modificações que se 
fizerem necessárias após a criação da baseline farão parte de uma versão seguinte que será 
vinculada a uma outra baseline. Este procedimento pode se repetir sucessivamente. As 
modificações introduzidas em cada versão devem ser registradas seguindo o modelo do quadro 
abaixo. Desta forma, será possível perceber as diferenças entre as diversas versões geradas. 
Data Descrição Autor 
17/11/2021 Criação do documento João, Vinícius, Wemerson e Willgnner. 
Sumário 
1. INTRODUÇÃO ................................................................................................................................................ 5 
1.1. OBJETIVOS ...................................................................................................................................................... 5 
1.2. PÚBLICO-ALVO ................................................................................................................................................. 5 
1.3. ORGANIZAÇÃO DO DOCUMENTO .......................................................................................................................... 5 
2. CASOS DE USO .............................................................................................................................................. 5 
2.1. ATORES .......................................................................................................................................................... 5 
2.2. LISTA DE CASOS DE USO ...................................................................................................................................... 5 
3. REQUISITOS E RESTRIÇÕES FUNCIONAIS (RFUN) ........................................................................................... 6 
4. REQUISITOS E RESTRIÇÕES NÃO FUNCIONAIS ............................................................................................... 8 
4.1. REQUISITOS E RESTRIÇÕES DE INFORMAÇÃO (RINF) ................................................................................................ 8 
4.2. REQUISITOS E RESTRIÇÕES DE INTERFACE HOMEM COMPUTADOR (RIHC) ................................................................... 8 
4.3. REQUISITOS DE INTERFACE EXTERNA (RIEX) .......................................................................................................... 9 
4.4. REQUISITOS E RESTRIÇÕES DE PROJETO (RPRO) ..................................................................................................... 9 
4.5. REQUISITOS E RESTRIÇÕES DE ARQUITETURA DE SOFTWARE (RARQ) .......................................................................... 9 
4.6. REQUISITOS E RESTRIÇÕES DE PLATAFORMA DE HARDWARE (RPHW) ........................................................................ 9 
4.7. REQUISITOS E RESTRIÇÕES DE PLATAFORMA DE SOFTWARE (RPSW) .......................................................................... 9 
4.8. REQUISITOS E RESTRIÇÕES DE DESEMPENHO (RDES)............................................................................................. 10 
4.9. REQUISITOS E RESTRIÇÕES DE DISPONIBILIDADE (RDIS) ......................................................................................... 10 
4.10. REQUISITOS E RESTRIÇÕES DE SEGURANÇA (RSEG) ............................................................................................... 11 
4.11. REQUISITOS E RESTRIÇÕES DE MANUTENIBILIDADE (RMAN) .................................................................................. 11 
4.12. REQUISITOS E RESTRIÇÕES DE PORTABILIDADE (RPOR) .......................................................................................... 11 
4.13. REQUISITOS DE DOCUMENTAÇÃO (RDOC) .......................................................................................................... 12 
5. MATRIZ DE RASTREABILIDADE .................................................................................................................... 12 
5.1. REQUISITOS E RESTRIÇÕES FUNCIONAIS (RFUN) .................................................................................................. 13 
5.2. REQUISITOS E RESTRIÇÕES DE INFORMAÇÃO (RINF) .............................................................................................. 14 
5.3. REQUISITOS E RESTRIÇÕES DE INTERFACE HOMEM COMPUTADOR (RIHC) ................................................................. 14 
5.4. REQUISITOS DE INTERFACE EXTERNA (RIEX) ........................................................................................................ 14 
5.5. REQUISITOS E RESTRIÇÕES DE PROJETO (RPRO) ................................................................................................... 14 
5.6. REQUISITOS E RESTRIÇÕES DE ARQUITETURA DE SOFTWARE (RARQ) ........................................................................ 14 
5.7. REQUISITOS E RESTRIÇÕES DE PLATAFORMA DE HARDWARE (RPHW) ...................................................................... 14 
5.8. REQUISITOS E RESTRIÇÕES DE PLATAFORMA DE SOFTWARE (RPSW) ........................................................................ 14 
5.9. REQUISITOS E RESTRIÇÕES DE DESEMPENHO (RDES)............................................................................................. 15 
5.10. REQUISITOS E RESTRIÇÕES DE DISPONIBILIDADE (RDIS) ......................................................................................... 15 
5.11. REQUISITOS E RESTRIÇÕES DE SEGURANÇA (RSEG) ............................................................................................... 15 
5.12. REQUISITOS E RESTRIÇÕES DE MANUTENIBILIDADE (RMAN) .................................................................................. 15 
5.13. REQUISITOS E RESTRIÇÕES DE PORTABILIDADE (RPOR) .......................................................................................... 15 
5.14. REQUISITOS DE DOCUMENTAÇÃO (RDOC) .......................................................................................................... 15 
6. SYSTEM OVERVIEW ..................................................................................................................................... 15 
6.1. UML ........................................................................................................................................................... 16 
6.2. DIAGRAMA DE CLASSES .................................................................................................................................... 22 
6.2.1 Diagrama de classes sem atributos e métodos ................................................................................. 22 
6.2.2 Exemplo de um diagrama de classe com atributos e métodos já especificados. .............................. 23 
7. CONSTRUÇÃO DE SOFTWARE ...................................................................................................................... 24 
7.1. FUNDAMENTOS .............................................................................................................................................. 24 
7.2. GERENCIANDO A CONSTRUÇÃO......................................................................................................................... 24 
7.3. CONSIDERAÇÕES PRÁTICAS ............................................................................................................................... 24 
8. APROVAÇÃO FORMAL ................................................................................................................................. 24 
9. BIBLIOGRAFIA ............................................................................................................................................. 24 
10. ABREVIAÇÕES ............................................................................................................................................. 25 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1. Introdução 
Com o alto índice de pedidos em empresas de fast-food e necessidades de serviços remotos 
surgindo a necessidade de um controle e automação no setor de entregas, possibilitando um melhor 
atendimento ao cliente e agregando uma entrega mais ágil e confiável, por esse motivo o Delivery 
WJV vem trazer um gerenciamento de pedidos, o padrão de desenvolvimento utilizado foi a versão 
mobile pois o mesmo pode ser acessado de qualquer lugar, basta ter acesso a internet e um celular 
com sistemas de Android ou iOS, possibilitando assim uma melhor administração e controle do 
processo, a presente documentação especifica os requisitos do Aplicativo Delivery WJV, de modo 
geral, um melhor atendimento do cliente possibilitando a melhor interação e maior fidelização, 
cliente/empresa. 
1.1. Objetivos 
Este documento tem o objetivo de descrever o software e especificar os requisitos do 
sistema Delivery WJV. 
1.2. Público-Alvo 
Clientes, usuários e administradores do sistema. 
1.3. Organização do documento 
O documento está dividido em tópicos como especificado no conteúdo do sumário, 
mostrado no início do documento. 
2. Casos de Uso 
2.1. Atores 
1. Cliente 
2. Gerente 
3. Recepcionista 
4. Chef / Cozinheiro 
5. Entregador 
 
2.2. Lista de casos de uso 
 
Ref. Descrição Atores Categoria 
CSU1 Receber ligação pelo aplicativo. Recepcionista Primário 
CSU2 Realizar pedido. Cliente Primário 
CSU3 Solicitar cancelamento de 
pedidos dentro do prazo de 5 
min. 
Cliente Primário 
CSU4 Cancelar pedidos após o prazo 
de confirmação. 
Gerente Primário 
CSU5 Aceitar o pedido para 
preparação. 
Chef /Cozinheiro Primário 
CSU6 Solicitar troca ou exclusão de 
condimentos. 
Cliente Primário 
CSU9 Cadastrar pratos. Chef /Cozinheiro Secundário 
CSU10 Concluir prato. Chef/Cozinheiro Primário 
CSU11 Receber pratos. Chef /Cozinheiro Primário 
CSU12 Escolher forma de pagamento. Cliente Primário 
CSU13 Receber pedido para entrega. Entregador do 
Aplicativo 
Primário 
CSU14 Permitir chat direto entre 
cliente/entregador. 
Cliente/Entregador Primário 
CSU15 Permitir chat direto entre 
cliente/restaurante. 
Cliente/ Gerente Primário 
CSU16 Sinalizar entrega/recebimento do 
pedido. 
Cliente/Entregador Primário 
CSU17 Avaliar entrega. Cliente Primário 
CSU18 Permitir observação de compra. Cliente Primário 
CSU19 Realizar Pagamento Cliente Primário 
CSU20 Visualizar cardápio Cliente Primário 
CSU21 Cadastrar Cliente Cliente Primário 
CSU22 Realizar login Todos os Atores Primário 
CSU23 Acompanhar entrega do pedido Cliente Primário 
3. Requisitos e restrições funcionais (RFUN) 
Todos os requisitos funcionais do sistema Delivery WJV estão listados na tabela abaixo. 
 
 
Ref. Função Categoria Prioridade Casos de Uso 
RFUN1 O sistema deverá registrar a 
venda de um produto. 
Evidente Alta CSU5 
RFUN2 O sistema deverá permitir 
alteração dos condimentos. 
Evidente Média CSU6 
RFUN3 O sistema deverá permitir 
cancelar pedidos dentro do 
prazo. 
Oculta Alta CSU3 
RFUN4 O sistema deverá enviar 
confirmação de compra ao 
Cliente. 
Oculta Alta CSU2/CSU5 
RFUN5 O sistema deverá permitir 
cadastro dos funcionários. 
Oculta Média CSU7 
RFUN7 O sistema deverá permitir o 
Cliente visualizar o cardápio. 
Evidente Alta CSU2 
RFUN8 O sistema deverá permitir ao 
Chef atualizar cardápio. 
Oculta Alta CSU9 
RFUN9 O sistema deverá enviar 
o pedido ao Chef. 
Oculta Alta CSU5 
RFUN11 O sistema deverá atualizar os 
pedidos após o prazo. 
Oculta Média CSU4 
RFUN12 O sistema deverá apresentar 
uma opção para sinalizar a 
conclusão do prato. 
Oculta Média CSU10 
RFUN13 O sistema deverá aceitar 
formas de pagamento online. 
Evidente Alta CSU12/CSU19 
RFUN14 O sistema deverá aceitar 
pagamento durante a entrega. 
Evidente Alta CSU12/CSU19 
RFUN15 O sistema deverá avisar no 
cardápio online quando um 
prato estiver em falta. 
Evidente Alta CSU20 
RFUN16 O sistema deverá permitir 
chat online entre 
cliente/entregador. 
Evidente Alta CSU14 
RFUN17 O sistema deverá permitir 
chat online entre 
cliente/restaurante. 
Evidente Alta CSU15 
RFUN18 O sistema deverá oferecer ao 
Cliente escolher a forma de 
como receber o pedido. 
Evidente Alta CSU16 
RFUN19 O sistema deverá oferecer a 
opção ao Cliente de dar 
gorjeta. 
Evidente Média CSU19 
RFUN20 O sistema deverá permitir o 
Cliente fazer observação ao 
realizar pedido. 
Evidente Alta CSU18 
RFUN21 O sistema deverá permitir 
cadastrar Clientes. 
Evidente Alta CSU21 / 
CSU22 
4. Requisitos e restrições não funcionais 
Os Requisitos não funcionais abaixo estão divididos em tipos de requisitos e possuem um 
identificador único para que possam ser referenciados sem ambiguidades no futuro. 
 
 
4.1. Requisitos e Restrições de Informação (RINF) 
 
Ref. Tipo Descrição Casos de Uso 
RINF1 Cadastral Login deve ser autenticado CSU22 
RINF2 Cadastral Não pode ter dois produtos com o 
mesmo nome 
CSU9 
RINF3 Cadastral Usuário deve ter CPF válido CSU22 
RINF2 Cadastral O sistema deverá solicitar 
informações do funcionário. 
CSU7 
RINF3 Cadastral O sistema deverá solicitar informações 
sobre o produto. 
CSU2/CSU9/CS
U20 
RINF4 Cadastral O sistema deverá solicitar informações 
para o cadastro de clientes. 
CSU21 
RINF5 Cadastro O sistema deverá receber o cadastro dos 
pratos disponíveis no restaurante 
CSU9/CSU20 
 
4.2. Requisitos e Restrições de Interface Homem Computador 
(RIHC) 
 
Ref. Descrição Casos de Uso 
RIHC1 Para facilitar a usabilidade na transação de venda, 
pede-se que a tela de vendas tenha uma fonte que 
permita uma fácil visualização. 
Todos 
RIHC2 O software deverá apresentar uma interface intuitiva 
de fácil usabilidade. 
Todos 
RIHC3 O software deverá ter uma seção onde o cardápio do 
dia estará em evidencia, a fim de facilitar o acesso. 
CSU20 
RIHC4 O tempo de resposta do programa, deverá ser de no 
máximo 3 segundos. 
Todos 
 
4.3. Requisitos de Interface Externa (RIEX) 
 
Ref. Descrição Casos de Uso 
RIEX1 O software deverá gerar recibo pelo email cliente. CSU19 
 
4.4. Requisitos e Restrições de Projeto (RPRO) 
 
Ref. Descrição Casos de Uso 
RPRO1 O software deverá ser desenvolvido pela equipe de 
desenvolvimento do sistema Delivery WJV. 
Todos 
RPRO2 O software deverá ser desenvolvido utilizando a 
ferramenta CASE, na linguagem Java, gerando um 
código padrão da empresa. 
Todos 
RPRO3 A equipe responsável deverá dar um feedback 
mensal sobre o andamento do projeto. 
Todos 
RPRO4 O projeto só será iniciado pela equipe responsável 
somente quando o protótipo for aceito pelo cliente. 
Todos 
 
4.5. Requisitos e Restrições de Arquitetura de Software 
(RARQ) 
 
Ref. Descrição Casos de Uso 
RARQ1 O software deverá ser desenvolvido com uma 
arquitetura de camadas que permita isolar as 
funcionalidades ligadas ao negócio das mesmas 
relacionadas com a interface homem-computador. 
Todos 
4.6. Requisitos e Restrições de Plataforma de Hardware 
(RPHW) 
 
Ref. Descrição Casos de Uso 
RPHW1 Aparelhos celulares e computadores deverão 
operaro software. 
Todos 
 
 
4.7. Requisitos e Restrições de Plataforma de Software 
(RPSW) 
 
Ref. Descrição Casos de Uso 
RPSW1 O software deverá ser desenvolvido para operar em 
sistemas mobile como IOS e ANDROID. 
Todos 
RPSW2 O software deverá ser desenvolvido para operar em 
sistemas operacionais como WINDOWS, MAC e 
LINUX. 
Todos 
RPSW3 O software deverá ter suporte de portabilidade as 
versões mais recentes dos sistemas operacionais. 
Todos 
RPSW4 O software deverá ter suporte de portabilidade a 
versão mais recente dos sistemas mobile. 
Todos 
 
4.8. Requisitos e Restrições de Desempenho (RDES) 
 
Ref. Descrição Casos de Uso 
RDES1 O ambiente onde o software rodará deverá permitir 
picos de acesso sem queda de velocidade. 
Todos 
RDES2 O tempo de resposta máximo permitido para 
transações on-line é de até 3 segundos. 
Todos 
RDES3 O software deverá ser capaz de suprir altas transações 
simultâneas da função “Realizar Pedido”. 
CSU3 
RDES4 O sistema d everá apresentar funcionalidades 
necessárias para uma alta eficiência de desempenho. 
Todos 
RDES5 O sistema deverá permitir acessos simultâneos sendo 
operados por diferentes perfis de usuários do sistema. 
Todos 
 
4.9. Requisitos e Restrições de Disponibilidade (RDIS) 
 
Ref. Descrição Casos de Uso 
RDIS1 O software deverá permanecer operante de forma 
contínua durante todos os dias da semana. 
Todos 
RDIS2 O sistema deve reiniciar por completo em até, no 
máximo, 10 segundos. 
Todos 
RDIS3 A opção de realizar pedido não pode ficar mais do 
que 30 minutos indisponível. 
Todos 
RDIS4 O software deverá restringir pedidos fora do 
horário de funcionamento do estabelecimento. 
 CSU2 
RDIS5 As manutenções e atualizações do sistema deverão 
ser feitas fora do horário de funcionamento do 
estabelecimento. 
Todos 
RDIS6 O software deverá permitir exceções no sistema para 
horários de funcionamento. 
Todos 
 
4.10. Requisitos e Restrições de Segurança (RSEG) 
 
Ref. Descrição Casos de Uso 
RSEG1 O software deverá solicitar autorização do gerente para 
excluir uma venda já registrada. 
CSU4 
RSEG2 Somente usuários previamente cadastrados possuem 
acesso a versão mobile para realizar pedidos no 
restaurante. 
Todos 
RSEG3 Somente usuários previamente cadastrados podem 
realizar compras no software. 
Todos 
RSEG4 Para qualquer atualização efetuada deverá ser registrado o 
usuário que realizou a operação assim como a data e hora. 
Todos 
RSEG5 Todo usuário do software deverá ser associado a um perfil 
que define as funcionalidades que poderão ser utilizadas 
por ele. 
Todos 
 
4.11. Requisitos e Restrições de Manutenibilidade (RMAN) 
 
Ref. Descrição Casos de Uso 
RMAN1 O projeto das responsabilidades de cada classe de objetos 
deverá seguir os padrões GRASP sugeridas no livro 
Utilizando UML e Padrões de Craig Larman. 
Todos 
RMAN2 Todo programa deve estar documentado de acordo com 
as orientações contidas na Norma de Documentação de 
Programas da empresa. 
Todos 
 
4.12. Requisitos e Restrições de Portabilidade (RPOR) 
 
Ref. Descrição Casos de Uso 
RPOR1 O software deverá ser capaz de rodar em celulares 
com sistemas Android ou em IOS. 
Todos 
RPOR2 O software deverá permitir a utilização dos 
seguintes Bancos de dados: SQL Server, MySql, 
MongoDB, POstgre SQL ou Oracle 
Todos 
 
4.13. Requisitos de Documentação (RDOC) 
 
Ref. Descrição Casos de Uso 
RDOC1 O software deve prover ajuda on-line em todas as 
suas telas. 
Todos 
RDOC2 O software deverá conter um Chatbot para eventuais 
dúvidas sobre funcionamento. 
Todos 
RDOC3 A empresa responsável pelo desenvolvimento 
deverá prestar suporte ao sistema. 
Todos 
 
5. Matriz de Rastreabilidade 
 
 
 
 
 
5.1. Requisitos e Restrições Funcionais (RFUN) 
 
5.2. Requisitos e Restrições de Informação (RINF) 
 
 
5.3. Requisitos e Restrições de Interface Homem Computador 
(RIHC) 
 
5.4. Requisitos de Interface Externa (RIEX) 
 
5.5. Requisitos e Restrições de Projeto (RPRO) 
 
5.6. Requisitos e Restrições de Arquitetura de Software 
(RARQ) 
 
5.7. Requisitos e Restrições de Plataforma de Hardware 
(RPHW) 
 
5.8. Requisitos e Restrições de Plataforma de Software 
(RPSW) 
 
CSU2 CSU7 CSU9 CSU20 CSU21
RINF1 X
RINF2 X X X
RINF3 X
RINF4 X X
CSU20 Todos
RIHC1 X
RIHC2 X
RIHC3 X
RIHC4 X
CSU19
RIEX1 X
RIEX2 X
Todos
RPRO1 X
RPRO2 X
RPRO3 X
RPRO4 X
Todos
RARQ1 X
Todos
RPHW1 X
Todos
RPSW1 X
RPSW2 X
RPSW3 X
RPSW4 X
5.9. Requisitos e Restrições de Desempenho (RDES) 
 
5.10. Requisitos e Restrições de Disponibilidade (RDIS) 
 
5.11. Requisitos e Restrições de Segurança (RSEG) 
 
5.12. Requisitos e Restrições de Manutenibilidade (RMAN) 
 
5.13. Requisitos e Restrições de Portabilidade (RPOR) 
 
5.14. Requisitos de Documentação (RDOC) 
 
 
6. System Overview 
O Sistema tem o objetivo de facilitar a interação do cliente com diversos 
estabelecimentos por meio do Delivery WJV trazendo um modelo simples e prático de 
solicitações de pedidos cadastros de clientes dentre outas muitas funcionalidades o que 
CSU3 Todos
RDES1 X
RDES2 X
RDES3 X
RDES4 X
RDES5 X
CSU2 Todos
RDIS1 X
RDIS2 X
RDIS3 X
RDIS4 X
RDIS5 X
RDIS6 X
CSU4 Todos
RSEG1 X
RSEG2 X
RSEG3 X
RSEG4 X
RSEG5 X
Todos
RMAN1 X
RMAN2 X
Todos
RPOR1 X
RPOR2 X
Todos
RDOC1 x
RDOC2 x
RDOC3 x
automatiza grande parte do processo de interação entre o cliente e o a empresa além de 
rodar na maioria dos sistemas operacionais atuais inclusive em plataforma mobile. 
A seguir mostraremos um Diagrama de Contexto que resume todas as atividades 
de processamento e também ajuda os usuários a visualizar o nível mais alto do sistema 
com os limites do sistema. 
 
6.1. UML 
Na Linguagem de modelagem unificada (UML), o diagrama de caso de uso 
resume os detalhes dos usuários do seu sistema (também conhecidos como atores) e as 
interações deles com o sistema. Para criar um, use um conjunto de símbolos e conectores 
especializados. Um bom diagrama de caso de uso ajuda sua equipe a representar e 
discutir: 
• Cenários em que o sistema ou aplicativo interage com pessoas, organizações ou 
sistemas externos; 
• Metas que o sistema ou aplicativo ajuda essas entidades (conhecidas como atores) 
a atingir; 
• O escopo do sistema. 
 
Diagrama de Casos de Uso 
 
Figura 1 - Realizar acesso ao Aplicativo Delivery WJV 
 
 
Figura 2 - Realização de pedido no aplicativo Delivery WJV 
 
 
Figura 3 - Aplicativo Delivery WJV com acesso ao Estoque do estabelecimento 
 
Para montar um diagrama de caso são necessários os seguintes componentes: 
• Caso de uso: formato oval na horizontal e que representam os diferentes usos que um 
usuário pode ter. 
• Atores: bonecos palito, representando as pessoas que realmente implementam os 
casos de uso. 
• Associações: uma linha entre atores e casos de uso. Nos diagramas complexos, é 
importante saber quais atores estão associados a quais casos de uso. 
• Caixa de limite do sistema: caixa que define um escopo do sistema para os casos de 
uso. Todos os casos de uso fora da caixa são considerados fora do escopo do sistema. 
• Pacote: uma forma UML na qual colocar diferentes elementos em grupos. Assim como 
no diagrama de componentes, esses agrupamentos são representados como pastas de 
arquivos. 
 
Modelo de caso de uso detalhado. 
 
 
• Identificação: O caso de uso a ser detalhado e sua identificação. 
• Escopo: Por onde acessá-lo 
• Descrição: Qual a função designada ao caso de uso dentre o sistema 
• Ator: Um ator representa um conjunto coerente de papéis que os usuários de 
casos de uso desempenham 
• Fluxo normal: A sequência de passos a ser seguida para que o caso de uso tenha 
seu papel efetuado dentre o sistema 
• Tratamento de erro: Será a mensagem a qual o sistema mostrara caso haja uma 
exceção ou erro em alguma etapa dos passos descritos no fluxo normal. 
• Requisitos relacionados:São os requisitos que tem alguma ligação com o caso de 
uso que foi detalhado. 
 
Casos de uso detalhados: 
 
 
 
 
 
 
 
6.2. Diagrama de Classes 
6.2.1 Diagrama de classes sem atributos e métodos 
 
Na criação do diagrama de classes são utilizados diversos elementos sendo que os mais 
aparecem em projetos são: 
• Classe 
• Associação 
• Herança 
• Composição 
• Agregação 
 
6.2.2 Diagrama de classe com atributos e métodos já especificados. 
 
 
 
7. Construção de Software 
7.1. Fundamentos 
O termo Construção de Software se refere à construção detalhada de um software 
funcional, através de uma combinação de codificação, verificação e teste. Seus 
fundamentos são: 
 
• Minimizar complexidade; 
• Antecipar mudanças; 
• Construir para verificação; 
• Reuso; 
• Padrões de construção; 
 
7.2. Gerenciando a Construção 
Já quando se trata do processo deve-se atentar aos seguintes tópicos: 
 
• Construção em modelos de ciclo de vida; 
• Planejamento da construção; 
• Mensuração da construção; 
 
7.3. Considerações práticas 
Devido à influência de variáveis do mundo real, construção está mais relacionado 
as considerações práticas do que alguma outra área de conhecimento (KA). Por isso é 
importante destacar: 
 
• Design de construção; 
• Linguagem de construção; 
• Codificação; 
• Teste na construção; 
• Reuso na construção; 
• Qualidade de construção; 
• Integração; 
 
 
8. Aprovação Formal 
Data: 16/11/2021 
Local: Goiânia, Goiás, Brasil 
Versão: 1.0 
9. Bibliografia 
Fontes de informação usadas para desenvolver o Documento de Requisitos do 
sistema Delivery WJV. 
[1] EOR – Modelo de Documento de Especificação de Objetivos e 
Requisitos de Software, Versão 1.0, setembro de 2017. 
Meta-Modelo usado como guia para definição do formato e 
conteúdo deste documento. 
 
10. Abreviações 
CASE = Computer-Aided Software Engineering (Engenharia de Software Auxiliada por 
Computador) 
CSU = Caso de Uso 
EOR = Especificação de Objetivos e Requisitos 
GRASP = General Responsibility Assignment Software Patterns (Padrões de Software de 
Atribuição de Responsabilidade Geral) 
RARQ = Requisitos e Restrições de Arquitetura de Software 
RDES = Requisitos e Restrições de Desempenho 
RDIS = Requisitos e Restrições de Disponibilidade 
RDOC = Requisitos de Documentação 
Ref = Referência 
RFUN = Requisitos e Restrições Funcionais 
RIEX = Requisitos de Interface Externa 
RIHC = Requisitos e Restrições de Interface Homem-Computador 
RINF = Requisitos e Restrições de Informação 
RMAN = Requisitos e Restrições de Manutenibilidade 
RPHW = Requisitos e Restrições de Plataforma de Hardware 
RPOR = Requisitos e Restrições de Portabilidade 
RPRO = Requisitos e Restrições de Projeto 
RPSW = Requisitos e Restrições de Plataforma de Software 
RSEG = Requisitos e Restrições de Segurança 
SQL = Structured Query Language (Linguagem de Consulta Estruturada) 
UML = Unified Modeling Language (Linguagem de modelagem unificada) 
 
 
Participantes na criação deste Documento de Requisitos: João, Vinícius, Wemerson e 
Willgnner.