Anotações de aula da disciplina Modelagem de Sistemas de Informação de Rede do curso de Gestão de Tecnologia da Informação - 3º semestre - UNIP Paulista.

1. Modelagem de
Sistema de
Informação
FreeDigitalPhotos.net
Introdução à disciplina

2. Plano De Estudo
O que é?
● Modelagem um sistema de informação de acordo com
determinado negócio.
● Modelagem:
○ Identificação das necessidades, apresentando as
vantagens e os possíveis problemas de
implementação.
○ Viabiliza os processos e as tecnologias necessárias
para a solução do problema.

3. Plano De Estudo
Na pratica...
Abordaremos conceitos aplicáveis sobre:
● Arquiteturas de Sistemas de Informações:
○
○
○
○
○
○
○
○
Arquitetura de Dados
Planejamento Estratégico de Dados
Planejamento Sistêmico de Dados
Modelos lógicos
Modelos Físicos
Estratégias de Banco de Dados
Bancos de Dados Distribuídos
Tendências

4. Plano De Estudo
Na pratica...
Abordaremos conceitos aplicáveis sobre:
● Arquitetura de Aplicações:
○
○
○
○
○
○
○
Planejamento Estratégico de Sistemas
Modelagem de Aplicações
Engenharia de Sistemas
Desenvolvimento Tradicional
Desenvolvimento Estruturado
Desenvolvimento Orientado a Objetos
Engenharia de Informação

5. Plano De Estudo
Na pratica...
Abordaremos conceitos aplicáveis sobre:
● Arquitetura de Tecnologia:
○ Estratégias para Desenvolvimento de Aplicações
Cooperativas
○ Estratégias para Desenvolvimento de Aplicações
Client-Server
○ Desenvolvimento com ORACLE
○ Tecnologia CASE

6. Plano De Estudo
Na pratica...
Abordaremos conceitos aplicáveis sobre:
● Arquitetura de Organização:
○
○
○
○
Quality Services em Sistemas
Estratégicas para Manutenção de Sistemas
Engenharia Reversa
Re-engenharia
● O Inter-relacionamento das Arquiteturas:
○ Modelagem de Sistema de Informação – caso real

7. Plano De Estudo
Bibliografia básica
●
LAUDON, Kenneth C.;LAUDON, Jane P. Sistema de Informações
Gerenciais 7ª Edição, São Paulo, Editora Pearson Prentice Hall
●
OLIVEIRA, Jair Figueiredo de. Sistema de Informaçãoversus Tecnologia,
São Paulo, Érica
●
FERNANDES, A. A.; KUGLER, J. L. C. Gerência de projetos de sistemas.
Rio de Janeiro, LTC.
●
PAGE-JONES, Meillir. Gerenciamento de projetos. São Paulo, Makron
Books.

8. Plano De Estudo
Frequência em sala de aula
● Cada noite de aula correspondem a 3 (três) presenças:
○ 2 (duas): Correspondem à presença em si.
○ 1 (uma): Corresponde à elaboração da tarefa em
sala de aula.
● Exigência mínima de presença em sala de aula para
aprovação: 75%

9. Plano De Estudo
Avaliação
● Padrão UNIP: NP1 e NP2
● Avaliações com questões de múltipla escolha e
dissertativas, totalizando 10 questões por avaliação.
● Média Semestral (MS) deverá ser igual ou superior a
5,0 para aprovação
MS = ((NP1 x 4) + (PIM x 2) + (NP2 x 4)) / 10

10. Qual a importância do uso sistemas
gerenciais nas empresas?
Como a empresa
faz seu
planejamento?
Em que é baseada tomada
de decisão da empresa?
Qual é o limite
financeiro?
FreeDigitalPhotos.net
Como são tratados
os dados?
Quais ferramentas
precisam ser
integradas?

11. Qual a importância do uso sistemas
gerenciais nas empresas?
● Essas perguntas devem ser respondidas
para a atingir as seguintes metas:
○
○
○
○
○
○
○
Excelência Operacional.
Novos Produtos.
Serviços e modelos de negócios
Relacionamento com clientes e fornecedores.
Melhor tomada de decisões.
Vantagem competitiva.
Sobrevivência.

12. Qual a importância do uso sistemas
gerenciais nas empresas?
● Tais metas são atingidas:
○ Projetando sistemas competitivos e eficazes,
○
○
○
onde as pessoas possam controlar, entender e
usar de maneira social e eticamente
responsável.
Entendendo os requisitos de sistema do
ambiente de negócios global.
Criando arquitetura de informação que apóie os
objetivos da organização.
Determinando o valor dos sistemas de
informação para o negócio.

13. Qual a importância do uso sistemas
gerenciais nas empresas?
● Para projetarmos um sistema de informação
necessitamos de processos:

14. Qual a importância do uso sistemas
gerenciais nas empresas?
● Os processos devem ser integrados:

15. Qual a importância do uso sistemas
gerenciais nas empresas?
● A solução técnica deve ser convergente:

16. Qual a importância do uso sistemas
gerenciais nas empresas?
● A tecnologia deve ser interdependente e
escalonável:

17. Qual a importância do uso sistemas
gerenciais nas empresas?

18. Modelagem de
Sistema de
Informação
FreeDigitalPhotos.net
Conceitos sobre modelagem
de sistemas

19. Fundamentos
● Modelagem um sistema de informação tem como
objetivo melhorar a tomada de decisão.
● Em situação de decisão deve-se saber:
○ Quais são as questões fundamentais.
○ Quais alternativas devem ser investigadas.
○ Onde focar a atenção.

20. Fundamentos
Abordagem simples para tomada de decisão:
Situação
Retorno
Decisões
Implementação

21. Fundamentos
Abordagem no mundo real para tomada de decisão:

22. Fundamentos
Abordagem sistemática para tomada de decisão:
Mundo
real
Situação
Análise
Validação
Intuição
Resultados
Interpretação
Mundo
simbólico
Abstração
Modelo
Decisões

23. Fundamentos
Em resumo...
● Definição do modelo, interpretação e implementação:
○ São processos essenciais para a tomada de
decisão.
● Perguntas que sempre devem ser respondidas:
○ Quais situações são passíveis de serem
modeladas?
○ Qual é a disponibilidade de dados para análise do
modelo e para obter resultados em tempo hábil e a
custos coerentes.
○ O que fazer para obter o máximo do modelo em

24. Fundamentos
Em resumo...
● Modelos possuem funções diferentes, de acordo com o
nível onde será implementado:
○ Alto nível: planejamento estratégico, planos
contingência, tempo reação;
○ Médio nível: planejamento, coordenação, logística,
adaptação;
○ Baixo nível: programação, operação, expansão,
análise impacto

25. Uso de modelos. Para que serve?
Modelos são ferramentas de análises lógicas consistentes:
●
●
●
●
●
●
●
●
Forçam a explicitação dos objetivos.
Identificam dos tipos de decisões que influenciam os objetivos.
Forçam a identificação das interações entre as decisões.
Forçam raciocínio criterioso sobre variáveis e definições
quantificáveis.
Mostram a consideração de dados que são pertinentes para
quantificação das variáveis e a determinação de interações entre
elas.
Identificam restrições ou limitações dos valores das variáveis.
Facilitam comunicação e o trabalho em grupo.
Podem ser ajustados e melhorados com a experiência e a
histórica, isto é, aprendizagem adaptativa.

26. Uso de modelos. Para que serve?
Tipo de modelo
Características
Exemplos
Físico
Tangível
Fácil compreensão
Reprodução difícil
Manipulação difícil
Escopo uso: muito baixo
Modelo aeronaves
Modelos de residências
Modelos de cidades
Analógico
Intangível
Compreensão difícil
Reprodução mais fácil
Manipulação mais fácil
Escopo de uso: baixo
Mapas de estradas
Velocímetro
Gráficos
Simbólico
Intangível
Compreensão mais difícil
Reprodução muito fácil
Manipulação muito fácil
Escopo de uso: amplo
Modelos simulação
Modelos algébricos
Modelos planilhas

27. Uso de modelos. Para que serve?
Um exemplo
Eu gostaria de saber o tempo gasto em uma
viagem. Preciso implementar isso em um
computador de bordo, como fazer?
FreeDigitalPhotos.net

28. Uso de modelos. Para que serve?
Um exemplo
Eu gostaria de saber o tempo gasto em uma
viagem. Preciso implementar isso em um
computador de bordo, como fazer?
●
Modelo: abstração (aproximação) cuidadosa
(tratável) da realidade
●
Detalhar o modelo o suficiente para que:
○ Os resultados satisfaçam as necessidades.
○ Seja consistente com os dados disponíveis.
○ Haja alta correlação entre o previsto pelo
modelo e a realidade.
○ Possa ser analisado dentro das
disponibilidades.
FreeDigitalPhotos.net

29. Uso de modelos. Para que serve?
Um exemplo
● Definir variáveis
VELOCIDADE
(V)
TEMPO
(T)
DISTÂNCIA
(D)
TEMPO MÉDIO
DE PARADA
(TMP)
NÚMERO ESPERADO
DE PARADAS
(NEP)

30. Uso de modelos. Para que serve?
Um exemplo
● Modelo de alto nível
TEMPO
(T)
DISTÂNCIA
(D)
TEMPO MÉDIO
DE PARADA
(TMP)
VELOCIDADE
(V)
NÚMERO ESPERADO
DE PARADAS
(NEP)
Processamento
(análise)
Saída
(Resultado)

31. Uso de modelos. Para que serve?
Um exemplo
● Modelo de médio nível
TEMPO
(T)
DISTÂNCIA
(D)
TEMPO MÉDIO
DE PARADA
(TMP)
VELOCIDADE
(V)
NÚMERO ESPERADO
DE PARADAS
(NEP)
Processamento
(análise)
T=(D/V) + (TMP*NEP)
Saída
(Resultado)

32. Uso de modelos. Para que serve?
Um exemplo
● Modelo de baixo nível
DISTÂNCIA
(D)
VELOCIDADE
(V)
Processamento
(análise)
T=(D/V) + (TMP*NEP)
TEMPO MÉDIO
DE PARADA
(TMP)
NÚMERO ESPERADO
DE PARADAS
(NEP)
Saída
(Resultado)

33. Uso de modelos. Para que serve?
Logo, um modelo é construído com:
1.
2.
3.
4.
5.
Estudo de características da situação de decisão.
Formulação de uma representação da situação.
Analise do modelo simbólico.
Quantificação e alimentação do modelo com dados.
Validação e testes do modelo x realidade.

34. Uso de modelos: Tipos.
Projeções e análise
de decisões
Modelos
Estocásticos
Modelagem
dedutiva
Projeções e
otimizações
É o modelo matemático
que
determina
os
resultados, exatamente,
a partir das condições
iniciais.
Modelo matemático que
incorpora
elementos
probabilísticos.
Previsão, análise de
simulação, análise estatística e
estimação de parâmetros
Modelos
Determinísticos
Consulta base de dados
e cálculo de parâmetros
Modelagem
inferencial

35. Uso de modelos: Tipos.
● Modelagem dedutiva: Presume-se que o
modelo pode desenvolver-se inicialmente
focando nas variáveis, relacionando-as no
modelo com suposições matemáticas.
○ Resultado: Valoriza o conhecimento
prévio do modelador em relação aos
dados e suas aplicabilidades. Modelagem
"de cima para baixo". Usa-se poucos
dados.

36. Uso de modelos: Tipos.
● Modelagem inferencial: Presume-se que os
dados refletem a realidade, relacionando as
variáveis para estimar seus valores.
○ Resultado: Valoriza os dados exatos.
Modelagem "de baixo para cima". Usa-se
muitos dados.

37. Uso de modelos
● Representação limitada da realidade.
● Os resultados de um modelo não é,
necessariamente, a solução para a
situação original.
● A noção de "ótimo" é um conceito
matemático em oposição a um
conceito do mundo real.
● Um modelo formulado e implementado
corretamente for cuidadosamente
interpretado,
ele
fornecerá
informações robustas para a tomada

38. Modelagem de
Sistema de
Informação
FreeDigitalPhotos.net
Ferramentas para Análise de
Sistemas: DFD

39. Fundamentos
● Devem focalizar características importantes do sistema.
● Devem permitir:
○ Entendimento do ambiente.
○ Documentar os dados necessários para a correta
construção do sistema.

40. Fundamentos
● Ferramenta CASE (Computer-Aided Software
Engineering).
● Os modelos devem contemplar:
○ Consultas e/ou relatórios do sistema do mundo real
(se existirem).
○ Informações a respeito das entidades relevantes,
envolvidas nessas consultas e/ou relatórios.

41. Fundamentos
● Exemplo: Sistema de Controle de Transportadora:
○ Entidades: motoristas e cliente.
○ Consultas: lista de entregas feitas em um dia,
número de viagens que um motorista realiza em um
mês.

42. Fundamentos
● Exemplo: Sistema de Controle de Transportadora:
○ Entidades: motoristas e cliente.
○ Consultas: lista de entregas feitas em um dia,
número de viagens que um motorista realiza em um
mês.

43. Fundamentos
● Modelos coerentes devem possuir vários "pontos de
vista":
○ Diagrama de Fluxo de Dados (DFD): perspectiva
funcional e foco de nosso estudo.
○ Diagrama Entidade-Relacionamento (DER):
perspectiva dos dados.
○ o Diagrama de Transição de Estado (DTE):
perspectiva comportamental

44. O DFD
● O Modelo Funcional representa o processamento de
dados do sistema e deve retratar as informações
obtidas durante a extração de requisitos:
○ As funções que o sistema deve ter e a interação
entre as funções.
○ As transformações que o sistema deve executar e a
correspondência entre as entradas e as saídas.
○ O tipo de serviço oferecido pelo sistema e as fontes
de informação.
○ O destino dos resultados produzidos pelo sistema.

45. O DFD
● É uma ferramenta gráfica que permite imaginar o
●
sistema como uma rede de processos funcionais
interligados por condutores de dados e contendo
depósitos para esses dados.
É necessário realizar duas tarefas importantes.
Reconhecer o Problema e Avaliar sinteticamente esse
problema:
○ Entrevistas.
○ Memorandos.
○ Manuais.
○ Documentação.
○ Anotações.
○ Conversações casuais.

46. O DFD - Notação
● O modelo gráfico utiliza somente quatro símbolos.
○
○
○
○
Processos
Fluxos de Dados
Depósitos de Dados
Entidades Externas.

47. O DFD - Notação
● O Processo (Função) representa processos individuais
●
●
que o sistema executa para transformar dados de
entrada em dados de saída e que residem dentro dos
limites do sistema (automatizado ou manual).
Ele pode representar um único programa, uma série de
programas, um módulo dentro de um programa ou, até
mesmo, um processo manual.
Usa-se na descrição um verbo e um substantivo.
1
Realizar
cálculos
1
Realizar
cálculos

48. O DFD - Notação
● O Fluxo de Dados representa o movimento de
●
●
fragmentos ou de pacotes de informação ao longo do
sistema que está sendo modelado.
Pode ocorrer entre:
○ Dois processos.
○ Processo e entidade externa.
○ Processo e depósito de dados.
Os nome dos fluxos de dados são compostos por
substantivos.
Dados
do
cliente

49. O DFD - Notação
● Os Fluxos de Dados podem ser convergentes ou
divergentes.

50. O DFD - Notação
● O Depósito de Dados representa o armazenamento de
●
●
●
dados.
Coleção de dados em repouso, enquanto o fluxo de
dados representa os dados em movimento.
É a abstração de um arquivo de dados. Ele pode
representar um arquivo, uma parcela de um arquivo ou
elementos de um banco de dados.
O nome do depósitos de dados é o mesmo nome do
fluxo de dados no plural.

51. O DFD - Notação
● As Entidades Externas (ou Terminadores) indicam
●
origem ou destino dos dados do sistema.
Representam entidades fora da modelagem do sistema.

52. O DFD - Como fazer
● Escolher nomes significativos para processos, fluxos,
depósitos de dados e entidades externas:
○
Utilizar nomes relacionados à rotina do usuário (normalmente
consultado pelo analista).
○
○
Cuidado para não abusar de siglas e abreviações.
○
○
Não colocar nomes de pessoas em processos ou entidades externas.
Evitar utilizar nomes técnicos (a não ser quando conhecida pelo
usuário);
Não utilizar nomes vagos e muito gerais para os processos, tais
como: Fazer Serviço, Funções Diversas ou Processar Dados.

53. O DFD - Como fazer
● Numerar os processos:
○
○
Facilita a identificação das hierarquias de processos.
Sequência de operação.
● Refazer o DFD quantas vezes for necessário até obter
uma boa estética.
● Evitar DFDs muito complexos.

54. O DFD - Como fazer
● Certificar-se que o DFD é inteiramente consistente,
além de manter consistência com outros DFDs
○ Cuidado com fluxos de dados e processos sem
nome.
○ Evitar processos que só tenham entradas (“buracos
negros”).
○ Evite processos que não possuam saídas (“geração
espontânea”).
○ Cuidado com depósitos de dados “somente-leitura”
(“geração espontânea”) ou “somente-escrita”
(“buracos negros”). A única exceção é quando o
depósito é externo e serve como interface entre o
sistema e o usuário.

55. O DFD - Como fazer

56. O DFD - Exemplo
Um distribuidor de peças para aparelhos eletrodomésticos pretende automatizar seu sistema de vendas.
●
●
●
●
●
●
●
●
Os pedidos dos clientes são recebidos normalmente (mas não necessariamente) por telefone, pelo
vendedor que preenche o pedido no formulário padrão verde.
O pedido, então, passa para uma outra pessoa que checa o pedido com o arquivo de fichas de
peças e coloca o número do código da peça pedida ao lado do nome e verifica se o preço está
correto.
Algumas vezes, o pedido é para uma peça cujo nome não consta no arquivo ou o preço está
incorreto e, então, o pedido é marcado como inválido e colocado de lado.
Pedidos válidos são passados para o pessoal da área de estoque, que checa o livro de inventário
de mercadorias, para verificar se há componente suficiente para atender ao pedido.
Se o estoque é insuficiente, o pessoal rejeita o pedido e envia uma nota à área de compras para
reposição do estoque.
Se o estoque é suficiente, a quantidade pedida é marcada como pendente de expedição e a via
cor-de-rosa do pedido é enviada para a contabilidade, para que seja gerada uma fatura para o
cliente.
O pessoal da expedição envia as peças pedidas ao cliente e dá baixa no inventário de
mercadorias.
O pessoal de compras atualiza o inventário de mercadorias quando recebe componentes do
fornecedor.

57. O DFD - Exemplo

58. O DFD - Exemplo
Considere o DFD que segue e que representa as funções de desenvolvimento na construção e
manutenção de um sistema de software.

59. O DFD - Exemplo de vários níveis
Diagrama de contexto.

60. O DFD - Exemplo de vários níveis
DFD nível 0.

61. O DFD - Exemplo de vários níveis
DFD nível 1.

62. O DFD - Exercício de fixação

63. O DFD - Exercício de fixação

64. Modelagem de
Sistema de
Informação
FreeDigitalPhotos.net
Usuário e requisitos
Baseado no material de Geraldo Xexéu, Prof.

65. Usuários
● Usuários
○ São todos aqueles que usam o sistema com algum
objetivo, ou seja, realmente usam o sistema dentro
do escopo do seu objetivo.
● Stakeholders
○ São todos aqueles com algum interesse no sistema,
afetando ou sendo afetados por seus resultados.
○ É a pessoa que possui algum interesse no sistema,
em especial um interesse que envolve algum risco.

66. Interesses e objetivos
● Usuários
○ Resposta planejada do sistema.
● Stakeholders
○ Sistema pode afetar o negócio de alguma forma.
Agente ou
Interessado
Lista de objetivos e interesses
Objetivo
Interesse
Prioridade
Cliente
Fazer o pedido
Receber a mercadoria
1
Cliente
Obter status do
pedido
Prever o prazo de chegada
do pedido
2
Gerente
Obter lista de
pedidos diária
Saber a produção diária
1

67. Interesses e objetivos
● Perspectivas dos usuários
○ Interagimos com pessoas com visões e descrições
diferentes do que é o sistema.
○ Um cuidado importante que devemos ter é quanto à
posição da descrição que está sendo feita em
relação ao sistema.
○ É recomendado utilizar uma perspectiva externa, ou
seja, fatores que afetam o sistema de fora para
dentro.

68. Interesses e objetivos
● Entrevistado onisciente:
○
Descreve o sistema indicando coisas que ele “deve fazer”. Vê tanto o
sistema como os seus usuários de uma perspectiva externa,
conhecendo os mecanismos tanto por dentro quanto por fora.
○
Normalmente é a posição da alta gerência e de quem contratou o
sistema.
○
É comum que não conheça os procedimentos internos do sistema
como acontecem realmente, mas apenas de forma geral ou como
aconteciam no passado.
○
Exige funcionalidade do sistema, principalmente para atender o nível
gerencial.

69. Interesses e objetivos
● Entrevistado usuário:
○
Descreve o sistema como se o estivesse usando diretamente, muitas
vezes já usando o sistema atual.
○
Exige funções do sistema, principalmente para atender o seu nível de
atuação (gerencial ou operacional).
○
Pode apresentar alguma desconfiança, pois o novo sistema pode
exigir novos conhecimentos.
○
Conhece a entrada e a saída do sistema, mas não necessariamente
os procedimentos internos.

70. Interesses e objetivos
● Entrevistado parte do sistema:
○
Descreve o sistema visto por dentro.
○
Muitas vezes é quem vai ter o trabalho substituído, em todo ou em
parte, pelo sistema, o que pode causar desconfiança e até mesmo
franca hostilidade.
○
Conhece os procedimentos na forma como são realizados e as
exceções que podem acontecer.

71. Requisitos
● O que é requisito?
○ Uma sentença identificando uma capacidade, uma
característica física ou um fator de qualidade que
limita um produto ou um processo (IEEE 12201994).

72. Requisitos
● Requisito do usuário:
○ É algum comportamento ou característica que o
usuário deseja do software ou o sistema como um
todo; o que o usuário quer.
○ São escritos pelo próprio usuário ou levantados por
um analista de sistemas que consulta o usuário.

73. Requisitos
● Requisito do sistema:
○ É algum comportamento ou característica exigido do
sistema como um todo, incluindo hardware e
software.
○ O comportamento desejado do sistema.
○ São normalmente levantados por engenheiros ou
analistas de sistemas, refinando os requisitos dos
usuários e os transformando em termos de

74. Requisitos
● Características de um Bom Requisito:
○ Necessário: Se retirado, ele não atenderá plenamente
as expectativas do usuário.
■ Não devem existir requisitos do tipo “seria
interessante ter”.
■ Deve ser levado em conta que cada requisito
aumenta a complexidade e o custo do projeto.
○ Não-ambíguo: Possui uma e apenas uma
interpretação.
○ Verificável: Não ser vago ou geral e sendo
quantificado de uma maneira que permita a

75. Requisitos
● Características de um Bom Requisito:
○ Conciso: Cada requisito define apenas um requisito
que deve ser feito e apenas o que deve ser feito, de
maneira clara e simples.
■ Não inclui explicações, motivações, definições ou
descrições do seu uso.
○ Alcançável: Realizável a um custo definido por uma
ou mais partes do sistema.
○ Consistente: Não contradiz ou duplica outro requisito.
○ Ordenável: Por estabilidade e/ou importância.

76. Requisitos
● Características de um Bom Requisito:
○
Requisito for funcional, deverá ser também
Independente da Implementação.
○
O requisito define o que deve ser feito, mas
não como!

77. Requisitos: Está bem, como eu faço
isso???
● Devemos chegar ao problema:
○ É necessário que todos concordem com a definição
do problema.
○ Entender as causas do problema:
■ O problema por trás do problema pode ser mais
importante, sendo que o problema visto
inicialmente é apenas um sintoma.
○ Identificar todos os stakeholders e usuários.
○ Definir a fronteira do sistema de solução.
○ Identificar as restrições impostas à solução.

78. Requisitos: Está bem, como eu faço
isso???
● Preencha o formulário:
○ O problema de <descrição do problema>, afeta
<stakeholders afetados> e resulta em
<impacto nos stakeholders>.
○ A solução <indicar a solução> trará os benefícios de
<lista dos principais benefícios>.

79. Requisitos funcionais e de
informação
● Requisito funcional:
○ Representa algo que o sistema deve fazer, ou seja,
uma função esperada do sistema que agregue algum
valor a seus usuários.
● Requisito informação:
○ Representa a informação que o cliente deseja obter
do sistema.
○ São as respostas fundamentais do sistema.

80. Requisitos não funcionais
● São a forma como os requisitos funcionais
devem ser alcançados.
● Eles definem propriedades e restrições do
sistema.
● Muitos requisitos não funcionais são também
requisitos de qualidade, como exigências de
desempenho e robustez.
● Outros são restrições ou exigências de uso de
tecnologia.

81. Requisitos não funcionais

82. Requisitos: Exemplo
●
●
O sistema deverá permitir que um paciente marque uma consulta.
O sistema deverá confirmar que a consulta foi aceita pelo paciente.
●
O sistema deverá permitir que um condômino solicite a segunda via de
sua conta condominial.
O sistema deverá permitir um aviso ao condômino que não pagar sua no
prazo correto.
●
●
●
O sistema deverá permitir que um fornecedor cadastre um produto no
catálogo.
O sistema deverá informar ao sistema de estoques que um produto foi
vendido.

83. Requisitos: Dicas
●
●
●
●
●
●
●
●
Use sentenças e parágrafos curtos.
Use a voz ativa.
Use verbos no futuro.
Use os termos de forma consistente e mantenha um
glossário.
Para cada requisito, avalie se a partir de sua definição
é possível determinar se ele está pronto ou não.
Garanta que todos os requisitos são verificáveis
imaginando (e possivelmente documentando) uma
forma de fazê-lo.
Verifique requisitos agregados e divida-os.
Mantenha um nível de detalhe único em todos os
requisitos.

84. Requisitos: Exemplo de
documentação
Sumário
1. Introdução
1.1 Objetivo
1.2 Escopo
1.3 Definições, acrônimos e abreviações
1.4 Referencias
1.5 Visão Geral
2. Descrição Geral
2.1 Perspectiva do Produto
2.1.1 Interfaces do Sistema
2.1.2 Interfaces do Usuário
2.1.3 Interfaces de Hardware
2.1.4 Interfaces de Software
2.1.5 Interfaces de Comunicação
2.1.6 Memória
2.1.7 Operações
2.7.8 Adaptações necessários no ambiente
2.2 Funções do Produto
2.3 Características do Usuário
2.4 Restrições
2.5 Suposições e Dependências
3. Requisitos Específicos
Apêndices
Índices