Your SlideShare is downloading. ×
Modelagem de Sistemas de Informação
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Modelagem de Sistemas de Informação

5,627
views

Published on

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.

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.

Published in: Education

1 Comment
0 Likes
Statistics
Notes
  • Be the first to like this

No Downloads
Views
Total Views
5,627
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
199
Comments
1
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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