6º/7º CIÊNCIA DA COMPUTAÇÃO

(CC)

Desenvolvimento do Escopo de um
Projeto de um Produto de
Software

Alfredo Santos da Costa Júnior - D7512C8

Israel Carlos-D7543F9

Victor de Araújo Sabino –D726HG6

1
 SUMÁRIO

 1. Objetivo do trabalho ------------------------------------------------------------- 03

 2. Introdução --------------------------------------------------------------------------- 04
 3. Conceitos Gerais------------------------------------------------------------------- 05
 3.1. Requisitos de Software-------------------------------------------------------- 05
 3.2. Engenharia de Requisitos---------------------------------------------------- 11
 3.3. Modelagem Gráfica------------------------------------------------------------- 14
 3.4. Prototipação----------------------------------------------------------------------- 15
 4. Documentos de Requisitos ---------------------------------------------------- 16
 4.1. Descrição do problema-------------------------------------------------------- 16
 4.2. Requisitos funcionais---------------------------------------------------------- 17
 4.3 Requisitos não-funcionais---------------------------------------------------- 17
 4.4 Modelagem------------------------------------------------------------------------- 21
 4.5 Protótipos--------------------------------------------------------------------------- 23
 5. Glossário------------------------------------------------------------------------------ 27
 6. Conclusão---------------------------------------------------------------------------- 28
 7. Referências bibliográficas ------------------------------------------------------29
 8. Ficha de Atividades Práticas Supervisionadas-------------------------- 30

2
Objetivo do trabalho

O presente trabalho tem como objetivo o desenvolvimento do escopo de um

projeto de um produto de software baseado nas necessidades do cliente (ONG
Jovens Ambientalistas), que recolhe, educa e oferece formação profissionalizante
para jovens sem lar que depois de receberem cursos gratuitos por professores que
são ex-alunos, prestam serviços remunerados, fabricando brinquedos
"ambientalmente corretos" que são vendidos para o Brasil e o exterior. A referida
ONG deseja instalar uma solução computacional para melhorar o controle das
informações referentes aos serviços, produtos e financeiro da Instituição. A proposta
desse desafio é planejar o desenvolvimento do sistema proposto pelo cliente,
assegurando a melhor qualidade possível durante o desenvolvimento e resultado
final.

3
Introdução

O presente trabalho tem como objetivo apresentar uma visão geral sobre o
desenvolvimento de software para ter maior facilidade em tarefas de gerenciamento,
economia de tempo, trabalho e dinheiro aumentando a eficiência e precisão das
operações.

Esta abordagem vamos desenvolver um software para uma ONG onde busca
melhorar o controle das informações referentes aos serviços, produtos e financeiro
da Instituição. A proposta desse desafio é planejar o desenvolvimento do sistema
proposto pelo cliente, assegurando a melhor qualidade possível durante o
desenvolvimento e o resultado final.

O desenvolvimento de um software significa que existe um repertório de

problemas em constate evolução e que a solução por esse software é de enorme
importância, pois irá trabalhar de acordo com os dados oferecidos para o cliente
para uma parametrização do programa ou aplicativo.

4
3. CONCEITOS GERAIS

3.1. Requisitos de software

As falhas em requisitos estão entre as principais razões para o fracasso de

um software. Entre as principais razões destacam-se os requisitos mal organizados,
requisitos mal expressos, requisitos desnecessários para os clientes e a dificuldade
para lidar com requisitos frequentemente mutáveis.

Abaixo temos uma figura clássica na área de engenharia de software (Figura

1) que demonstra como os requisitos podem significar um grande problema na
especificação de um software.

Entre os problemas típicos encontrados com a especificação dos requisitos

temos:

A falta de conhecimento sobre o domínio: Isso normalmente leva a

entendimentos errados ou mal compreendidos. Além disso, quando temos poucos
ou nenhum modelo e anotações sofremos com esquecimentos no futuro, inclusive
com alguns conceitos iniciais ou mais básicos que quando não tomamos nota ou
modelamos temos mais chances de esquecer.

5
 Comunicação do Usuário com o Analista: Quando temos diferentes pontos de
vista entre o Usuário e o Analista podemos ter requisitos mal feitos ou falhos. O
interessante nesse caso é fazermos um Vocabulário da Aplicação anotando
conceitos importantes e procurando fazer um vocabulário comum junto ao cliente.

Gestão de Mudanças e Evolução dos requisitos: Um grande problema

comumente encontrado é a falta de rastreabilidade ou de histórico de decisões de
uma aplicação. Quanto mais a aplicação vai crescendo mais difícil fica de sabermos
que pontos do sistema impactam em quais requisitos e também quais requisitos
impactam em quais operações do sistema. Dessa forma é sempre importante termos
uma rastreabilidade sobre quais impactos temos entre sistema e requisitos. Outra
rastreabilidade existente é a chamada Rastreabilidade de Origem que diz quem
definiu determinado requisito. Assim, quando precisamos saber quem solicitou
determinada funcionalidade podemos saber de imediato o nome do cliente. Isso
muitas vezes é importante até mesmo quando precisamos solicitar maiores detalhes
para o cliente ou então fazer alguma negociação.

Antigamente dizia-se que requisitos eram sinônimos de funções, ou seja, tudo

que o software deveria fazer funcionalmente. No entanto, atualmente assumiu-se
que requisitos de software é muito mais do que apenas funções. Requisitos são,
além de funções, objetivos, propriedades, restrições que o sistema deve possuir
para satisfazer contratos, padrões ou especificações de acordo com o(s) usuário(s).
De forma mais geral um requisito é uma condição necessária para satisfazer um
objetivo.

Portanto, um requisito é um aspecto que o sistema proposto deve fazer ou

uma restrição no desenvolvimento do sistema. Vale ressaltar que em ambos os
casos devemos sempre contribuir para resolver os problemas do cliente e não o que
o programador ou um arquiteto deseja. Dessa forma, o conjunto dos requisitos como
um todo representa um acordo negociado entre todas as partes interessadas no
sistema. Isso também não significa que o programador, arquiteto ou um analista
bem entendido no assunto de tecnologia não possam contribuir com sugestões e
propostas que levem em conta o desejo do cliente.

6
 Além disso, ainda temos um documento de requisitos que é uma coleção dos
requisitos.

Por fim, os requisitos possuem alguns objetivos centrais como estabelecer e

manter uma concordância com os clientes e outros envolvidos sobre o que o sistema
deve fazer, deve oferecer aos desenvolvedores, projetistas e testadores do sistema
uma compreensão melhor dos requisitos do sistema, definir fronteiras do sistema
definindo o que deve ser incluído e o que não deve fazer parte do sistema, fornecer
uma base para estimar o custo e o tempo de desenvolvimento do sistema e por fim
definir uma interface de usuário para o sistema.

Classificação dos Requisitos

Existem dois tipos de classificação de requisitos, são eles: Requisitos

Funcionais (RF) e Requisitos Não-Funcionais (RNF).

Os requisitos funcionais referem-se sobre o que o sistema deve fazer, ou

seja, suas funções e informações. Os requisitos não funcionais referem-se aos
critérios que qualificam os requisitos funcionais. Esses critérios podem ser de
qualidade para o software, ou seja, os requisitos de performance, usabilidade,
confiabilidade, robustez, etc. Ou então, os critérios podem ser quanto a qualidade
para o processo de software, ou seja, requisitos de entrega, implementação, etc.

Evidentemente que as prioridades podem variar conforme a natureza do

software. Isso quer dizer que um software para uma plataforma de celular terá
diferentes requisitos de um software que roda num browser na web. Assim como um
software de tempo real que precisa ser executado em 1 segundo é diferente de outro
software que pode ter um tempo maior para execução de uma determinada tarefa.

Portanto, requisitos funcionais preocupam-se com a funcionalidade e os

serviços do sistema, ou seja, as funções que o sistema deve fornecer para o cliente
e como o sistema se comportará em determinadas situações. Segue abaixo alguns
exemplos de requisitos funcionais:

[RF001] O Sistema deve cadastrar médicos profissionais (entrada)

[RF002] O Sistema deve emitir um relatório de clientes (saída)

7
 [RF003] O Sistema deve passar um cliente da situação "em consulta" para
"consultado" quando o cliente terminar de ser atendido (mudança de estado)

[RF004] O cliente pode consultar seus dados no sistema

Por fim, os requisitos não funcionais definem propriedades e restrições do

sistema como tempo, espaço, linguagens de programação, versões do compilador,
SGBD, Sistema Operacional, método de desenvolvimento, etc. Uma dica importante
é que os requisitos não funcionais são geralmente mensuráveis e assim devemos
preferencialmente associar uma medida ou referência para cada requisito não
funcional. A Tabela 1 mostra diversas propriedades e métricas para cada uma delas.

Propriedade Métrica
Transações processadas por segundo. Tempo de
Velocidade resposta ao usuário/evento. Tempo de atualização da
tela.
Tamanho Kbytes. Número de chips de RAM.
Facilidade de
Tempo de treinamento. Número de telas de ajuda.
uso
Tempo médio para falhar. Probabilidade de
Confiabilidade indisponibilidade. Taxa de ocorrência de falhas.
Disponibilidade.
Tempo de reinício após falha. Porcentagem de
Robustez eventos que causam falhas. Probabilidade de que os
dados sejam corrompidos por falhas.
Porcentagem de declarações dependentes de
Portabilidade
sistema-alvo. Número de sistemas-alvo.

Os requisitos não funcionais ainda são classificados em três tipos, são eles:
Requisitos do Produto Final, Requisitos Organizacionais e Requisitos Externos.

8
Requisitos do Produto Final referem-se a como o produto deve comportar-se, ou
seja, a sua velocidade de execução, confiabilidade, etc. Requisitos Organizacionais
referem-se à consequência de políticas e procedimentos organizacionais que devem
ser seguidos. Requisitos Externos referem-se a fatores externos ao sistema e ao
processo de desenvolvimento como a legislação. Além desses três tipos, os
requisitos não funcionais ainda se dividem em outros diversos tipos como demonstra
a Figura 2.

Segue abaixo alguns exemplos de requisitos não funcionais:

[RNF001] O sistema deve imprimir o relatório em até 5 segundos.

[RNF002] Todos os relatórios devem seguir o padrão de relatórios

especificado pelo setor XYZ.

[RNF003] O sistema deve ser implementado em Java.

Para ajudar os analistas a identificar o real propósito das informações obtidas

junto aos usuários, existe um sistema de classificação de requisitos chamada
FURPS+ que são as iniciais dos nomes abaixo, onde cada um tem um propósito:

Functionality (Funcionalidade): É todo o aspecto funcional do sistema sendo

desenvolvido.

Usability (Usabilidade): Indica o tempo de treinamento para um usuário se

tornar produtivo, Tempo de duração desejado para determinada operação no
sistema e Ajuda on-line, documentação do usuário e material de treinamento.
9
 Reliability (Confiabilidade): Refere-se à Disponibilidade, Tempo de correção –
tempo permitido para indisponibilidade quando ocorre uma falha, Precisão, Número
máximo de defeitos (bugs/KLOC – mil linhas de código), Categorias de bugs – bugs
devem ser categorizados por nível de impacto.

Performance (Performance ou Desempenho): Indica o Tempo de resposta

para uma transação, Troughput (ex: transações por segundos), Capacidade (ex:
transações concorrentes), Operação Parcial (Situação do sistema aceitável quando
estiver prejudicado de alguma forma), Uso de recursos: memória, espaço em disco,
comunicação, etc.

Supportability (Suportabilidade): Indica o Padrão de codificação, Convenção

de nomenclatura, Bibliotecas de classes, Utilitários de manutenção.

Plus (+): Indica Outros como Design, implementação, interface, físicos, etc.

Requisitos no Ciclo de Vida do Projeto

Muitos pensam que os requisitos só devem ser considerados no início do

projeto, o que não é verdade, pois os requisitos devem ser considerados durante
todo o ciclo de vida de desenvolvimento do software.

Segue abaixo as etapas onde os requisitos são utilizados durante o ciclo de

vida do projeto:

 Definição de critérios de aceitação e validação (pelos

stakeholders);
 Definição sobre O QUÊ o sistema deve fazer (especificação para
a equipe);
 Teste e Verificação do sistema sendo desenvolvido;
 Informações para gerenciamento de mudanças (Rastreabilidade,
análise de impacto);
 Alocação de tarefas para a equipe;
 Estimativa de custo/esforço/cronograma;
 Acompanhamento e Controle do andamento do projeto.

3.2. Engenharia de Requisitos

10
 Existem diferentes definições encontradas na literatura técnica para
engenharia de requisitos:

Termo usado para descrever as atividades relacionadas à investigação e

definição de escopo de um sistema de software;

Processo sistemático de desenvolvimento de requisitos através de um

processo cooperativo de análise onde os resultados das observações são
codificados em uma variedade de formatos e a acurácia das observações é
constantemente verificada;

Processo de descobrir, analisar, documentar e verificar as funções e

restrições do sistema.

Embora coerentes, estas definições podem ser melhoradas. Perceba que elas
se referem apenas às atividades relacionadas à produção de requisitos. Entretanto,
nada é dito a respeito da gerência destas atividades, também conhecida como
gerência de requisitos. Com isto em mente, podemos evoluir a definição de
engenharia de requisitos para: termo usado para descrever as atividades
relacionadas à produção (levantamento, registro, validação e verificação) e gerência
(controle de mudanças, gerência de configuração, rastreabilidade, gerência de
qualidade dos requisitos) de requisitos. A Figura 3 representa essa definição.

11
 Desta forma, os dois conceitos base (produção e gerência) devem ser
considerados em conjunto ao se definir estratégias de trabalho com requisitos nas
organizações (ver Figura 4).

Produção e Gerência de Requisitos

Neste ponto podemos citar alguns dos principais objetivos da engenharia de

requisitos como estabelecer uma visão comum entre o cliente e a equipe de projeto
em relação aos requisitos que serão atendidos pelo projeto de software, registrar e
acompanhar requisitos ao longo de todo o processo de desenvolvimento documentar
e controlar os requisitos alocados para estabelecer uma baseline para uso gerencial
e da engenharia de software, manter planos, artefatos e atividades de software
consistentes com os requisitos alocados.

Para apoiar o alcance destes objetivos, é importante que se tenha um

processo de engenharia de requisitos bem definido. Um processo de engenharia de
requisitos é um conjunto estruturado de atividades a serem seguidas para criar,
validar e manter um documento de requisitos. Poucas organizações têm um
processo de ER explicitamente definido e padronizado. Entretanto, sugere-se que
cada organização deva desenvolver um processo adequado à sua realidade. A
Figura 5 apresenta um modelo genérico de atividades que pode descrever a maioria
dos processos de engenharia de requisitos. Perceba que ele está concentrado nas
atividades de produção dos requisitos.

12
Processo de Engenharia de Requisitos

Apesar do aparente fluxo entre as atividades, não existe uma fronteira

explícita elas. Na prática existe muita sobreposição e interação entre uma atividade
e outra.

Como entradas para o processo são consideradas:

 Descrições do que os stakeholders necessitam para suportar suas atividades;

 Informações a respeito do sistema que será substituído ou de qualquer sistema
com o qual o sistema sendo definido terá que interagir;
 Padrões vigentes na organização a respeito de práticas de desenvolvimento de
sistemas, gerência de qualidade, etc.;
 Regulamentos externos, tais como leis, regulamentos de segurança ou saúde;
 Informações gerais sobre o domínio de aplicação.

3.3 Modelagem Gráfica

Existe um constante debate dentro da engenharia de software sobre a

necessidade de documentação do sistema. Isso provavelmente advém do real
13
objetivo do software, que seria prover funcionalidades ao usuário. A documentação
do software não agrega valor ao usuário final, pois a este não interessa os
pormenores internos, apenas a aplicação em si e como utilizá-la. Desta forma, torna-
se cada vez mais complicado justificar aos demandantes, leigos em sua maioria, a
real importância da documentação técnica. (DEVMEDIA, 2015).

O sucesso de um projeto de software está ligado diretamente à sua

capacidade de atendimento às necessidades do usuário. O sucesso de uma
empresa de software é dependente da sua capacidade de produção deste produto
de software em um prazo e custo eficazes. (DEVMEDIA, 2015).

Sobre essa importância, podemos fazer um paralelo em relação às plantas de

um imóvel. Qual o valor que ela agrega ao proprietário? Qual sua real utilidade?
Apesar de não agregar valor diretamente ao imóvel, as plantas de um imóvel podem
auxiliar os executores de reformas e consertos para encontrar possíveis soluções
para determinado problema, bem como auxiliar na estratégia de execução do
serviço. Com um software também funciona da mesma forma, sua documentação
serve como um guia das estratégias futuras de desenvolvimento seja este corretivo
ou evolutivo, poupando horas e horas de análise ou pior, a adoção de soluções não
compatíveis com a arquitetura original. (DEVMEDIA, 2015).

A modelagem gráfica é um fator de extrema importância para que todas as

equipes trabalhem para entregar um produto conexo em sua composição e que
atenda todas as especificações do cliente.

3.4. Prototipação

A prototipação é um processo importante no desenvolvimento de software,

pois, além de servir como um primeiro rascunho de um produto ou serviço, tem
como objetivo amadurecer ideias e engajar pessoas no processo de criação. Esta
etapa impacta diretamente na produtividade de toda a equipe e gera valor ao cliente.
É nesta fase que as ideias são colocadas em prática para facilitar o entendimento de
uma aplicação ou sistema.
Com a prototipação, os envolvidos em um projeto verificam as
funcionalidades de um software de maneira simplificada e conferem se todos os
14
recursos estão atendendo os requisitos estabelecidos. Aplicando esta técnica, a
equipe de desenvolvimento, os profissionais de UX Design, os clientes e outros
interessados no projeto, podem analisar como todas as funcionalidades estão
distribuídas, bem como se a organização do layout está correta, se o sistema
oferece uma boa experiência para o usuário, entre outros aspectos importantes.

Além do baixo custo, a prototipação no desenvolvimento de software tem

como característica reduzir os riscos e permitir que todas as validações sejam feitas
antes da implementação. De acordo com Jakob Nielsen, cientista da computação e
cofundador da Nielsen Norman Group, "estima-se que seja 100 vezes mais barato
fazer mudanças antes de escrever qualquer código, do que aplicá-las após a
implementação".

Tipos de protótipos
Há diversos modelos de prototipação rápida e níveis de fidelidade. Um
protótipo pode ser desde um desenho na folha de papel, até algo elaborado em
software especializado, e mais parecido com a solução final. Basicamente, a
prototipação pode ser feita de três maneiras:

Protótipo de Baixa Fidelidade

Este tipo de protótipo também é conhecido como rascunho, wireframe e
sketche. Geralmente são desenhos feitos à mão, em folha de papel ou com ajuda de
post-it, representando como serão as características da interface e o seu
funcionamento. Como o material utilizado para elaborar este protótipo é simples,
consequentemente, o custo dessa solução é baixo. Por meio desta técnica, é
possível obter diversas informações, sobretudo em relação aos requisitos da
interface.

Protótipo de Média Fidelidade

Este tipo de protótipo já demanda um pouco mais de tempo para ser
elaborado e está mais próximo do que foi idealizado para o projeto. Geralmente são
feitos com o auxílio de softwares e permitem que o usuário simule o comportamento
do sistema. Com isso, é possível validar as interações e melhorar a user experience.

15
Apesar de ser uma solução mais elaborada, o custo desse tipo de protótipo continua
relativamente baixo.

Protótipo de Alta Fidelidade

Este tipo de protótipo oferece uma fidelidade mais próxima possível do
resultado final do software. Geralmente são desenvolvidos em linguagem de
programação - permitindo mostrar algumas das funcionalidades do sistema - e
oferece um alto grau de interatividade. Neste tipo de prototipagem, pode ocorrer a
implementação de algumas partes do sistema. Vale destacar também que há um
custo maior em sua elaboração, já que demanda mais tempo e conhecimento
técnico.

4. Documentos de Requisitos

4.1. Descrição do problema

Considere que o grupo de alunos foi contratado pela “ONG Jovens

Ambientalistas” (SOS PRESERVAÇÃO), que recolhe, educa e oferece formação
profissionalizante para jovens sem lar que depois de receberem cursos gratuitos por
professores que são ex-alunos, prestam serviços remunerados, fabricando
brinquedos “ambientalmente corretos” que são vendidos para o Brasil e o exterior. A
referida ONG deseja instalar uma solução computacional para melhorar o controle
das informações referentes aos serviços, produtos e financeiro da Instituição. A
proposta desse desafio é planejar o desenvolvimento do sistema proposto pelo
cliente, assegurando a melhor qualidade possível durante o desenvolvimento e o
resultado final.

Os requisitos foram levantados a partir de brainstorm entre o grupo. Nos

reunimos virtualmente e levantamos os requisitos de forma detalhada a partir da
descrição do cenário proposta no trabalho.

4.2. Requisitos Funcionais:  

RF01 – O sistema deverá ser reproduzido no Windows 7 ou superior

RF02- Fazer login - Professor, aluno, ou administrador deverá fazer login.

16
 RF03- Acesso ao curso (Aluno) – poderá visualizar conteúdo, enviar
atividade, acessar Ubibot (desempenho do estudante).

RF04- Acesso ao curso (Professor): Poderá editar o curso cadastrando

conteúdos e atividades.

RF05 – Acesso ao curso (Administrador): Criador do curso.

RF06 –Sistema de Vendas (Cliente): Poderá efetuar, verificar, procurar e

cancelar pedido.

RF07- Sistema de Vendas (Funcionário): Fabricar o Produto.

RF08 – Sistema de Vendas (Transportador): Calcular a postagem e entregar

o produto.

RF09 – Sistema de Vendas (Fornecedor): Fornecer o produto.

4.3. Requisitos Não Funcionais:  

Desempenho

Identificador RNF001 Categoria Desempenho

Nome Tempo limite para processamento

Data de
N/A Autor N/A
criação

Data da última
N/A Autor N/A
alteração

Versão 1 Prioridade Essencial

Descrição O sistema deverá desempenhar tarefas com

agilidade.

Com os seguintes parâmetros de tempo de

resposta:

17
 - Login: 5s

- Cadastro de estoque: 10s

- Gerar relatório mensal: 30s

- Calcular folha de pagamento de todos os

funcionários: 8s

Segurança

Identificador RNF003 Categoria Segurança

Nome Autenticação de usuário

Data de
N/A Autor N/A
criação

Data da
N/A Autor N/A
última alteração

Versão 1 Prioridade Essencial

Todo acesso ao sistema deverá ser condicionado a

Descrição inserção de senha de 8 dígitos, com pelo menos uma letra
maiúscula, um número e um caráter alfanumérico.

Usabilidade

Identificador RNF005 Categoria Usabilidade

Nome Uso de Design responsivo nas interfaces gráficas

18
Data de criação N/A Autor N/A

Data da última
N/A Autor N/A
alteração

Versão 1 Prioridade Importante

A interface do sistema deve apresentar

Descrição características de frameworks modernos, com navegação
intuitiva.

Compatibilidade

Identificador RNF006 Categoria Compatibilidade

Compatibilidade com sistemas operacionais

Nome
Windows

Data de criação N/A Autor N/A

Data da última
N/A Autor N/A
alteração

Versão 1 Prioridade Essencial

O sistema estará disponível para instalação e

Descrição
utilização nos sistemas Windows XP, 7, 8 e 10.

Implementação

Identificador RNF007 Categoria Padrão

19
 Tecnologias empregadas no processo de
Nome
implementação da plataforma.

Data de
N/A Autor N/A
criação

Data da
N/A Autor N/A
última alteração

Versão 1 Prioridade Essencial

-O sistema será implementado utilizando a

linguagem Java, junto com seus frameworks para auxiliar o
desenvolvimento.

Descrição -O SGBD utilizado será o mySQL.

-As integrações, bem como o ambiente web da

instituição será desenvolvido em javascript em conjunto
com html5 e CSS.

4.4. Modelagem

 Caso uso- Acesso ao sistema

20
  Caso de Uso – Instituição de ensino

 Caso de Uso - Sistema de vendas

Diagrama de classes

21
4.5. Protótipos

 Caso uso - Acesso ao sistema

 Caso uso – Cadastro

22
 Caso uso – Menu Principal

 Caso uso – Painel Alunos

 Caso uso – Painel Estoque

23
  Caso uso – Painel Vendas

 Caso uso – Painel Carrinho

24
5. Glossário

Browser- Termo recorrente utilizado na internet para navegador de internet.

Baseline -  linha de base definida que fica preparada para que o gerente de projeto
possa acompanhar e controlar o andamento do projeto.

Brainstorming - técnica de discussão em grupo que se vale da contribuição

espontânea de ideias por parte de todos os participantes, no intuito de resolver
algum problema ou de conceber um trabalho criativo.

Frameworks: conjunto de códigos prontos que podem ser usados no

desenvolvimento de aplicativos e sites.

Layout - Esboço do trabalho final a ser apresentado para a aprovação do cliente

Post-it-  papel adesivo que serve para fixar notas temporariamente sobre qualquer

tipo de superfície.

25
Rastreabilidade – capacidade de conhecer todo o caminho de uma determinada
matéria-prima, desde sua origem até o produto final.

Requisitos Mutáveis - que mudam em função de mudanças no ambiente no qual o

sistema opera.

Stakeholders -  são pessoas que têm interesse na gestão de empresas ou

na gestão de projetos, tendo ou não feito investimentos neles.

User experience: Experiência do Usuário

6. Conclusão

Com o sistema desenvolvido pode observar que as tarefas de controle, no

controle de serviços, o sistema vai atuar gerenciando as demandas de produção
criando objetivos para a equipe empenhada na produção, controlando a carga-
horária de cada colaborador e estabelecendo um canal de comunicação entre a
ONG e o contratante. O site funcionará com o reconhecimento do cliente puxando
suas informações, verificar suas escolhas e encaminha-las para o banco de dados
que irá salvar e processar essas informações.

26
7. Referências bibliográficas

 Introdução a requisitos de software. DEVMEDIA. Disponível em:

<https://www.devmedia.com.br/introducao-a-requisitos-de-
software/29580#:~:text=Requisitos%20s%C3%A3o%2C%20al%C3%A9m%20de
%20fun%C3%A7%C3%B5es,necess%C3%A1ria%20para%20satisfazer%20um
%20objetivo>.Acesso em 20 de maio de 2021.
 Modelagem de software. DEVMEDIA. Disponível em
<https://www.devmedia.com.br/modelagem-de-software-porque-como-e-o-que-
deve-ser-feito/33794> Acesso em 20 de maio de 2021.
 Introdução a engenharia de requisitos. DEVMEDIA. Disponível em
<https://www.devmedia.com.br/introducao-a-engenharia-de-requisitos/8034#6>
Acesso em 20 de maio de 2021.
 Prototipação. João Paulo Soares. Disponível em
<https://www.treinaweb.com.br/blog/como-funciona-a-prototipacao-no-
desenvolvimento-de-software > Acesso em 20 de maio de 2021
27
8. Ficha de Atividades Práticas

28
29
30
31