Your SlideShare is downloading. ×
0
Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02
Análise de Sistemas Orientado a Objetos - 02
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

Análise de Sistemas Orientado a Objetos - 02

155

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
155
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
17
Comments
0
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. Análise de Sistemas Orientada a Objetos Aula 02 – Requisitos
  • 2. Engenharia de Requisitos – análise e negociação Após a identificação dos requisitos do sistema, segue-se à etapa de análise dos requisitos e negociação. Algumas das atividades envolvidas na análise de requisitos incluem: • classificação: agrupamento de requisitos em "módulos" para facilitar a visão global do funcionamento pretendido para o sistema; • resolução de conflitos: dada a multiplicidade e diversidade de papéis das partes interessadas envolvidas na captura e análise de requisitos, é inevitável a existência de conflitos nos requisitos identificados; é importante resolver estes conflitos o mais breve possível; • priorização: consiste na atribuição de uma "prioridade" a cada requisito (por exemplo elevada/média/baixa); este pode ser um fator gerador de conflitos; • confirmação: é confirmada com as partes interessadas a completude dos requisitos, sua consistência e validade. A identificação e análise de requisitos é um processo iterativo que se inicia com a familiarização do domínio do futuro sistema e termina na confirmação dos requisitos, aumentando o grau de compreendimento do sistema a cada ciclo de trabalho.
  • 3. Engenharia de Requisitos – análise e negociação As dificuldades encontradas na análise são de diversas naturezas: • fatores externos (políticos) podem influenciar os requisitos (alguma parte interessada, com poder de decisão, pode exigir requisitos específicos que sirvam aos seus interesses e não aos da organização, ou forçar o seu ponto de vista em detrimento dos demais interessados que irão operar o sistema); • o ambiente (econômico e/ou organizacional) em que a análise é feita possui fatores dinâmicos, e como tal, os requisitos estão sujeitos a alterações em decorrência destes (por exemplo: novas partes interessadas são envolvidas no projeto, ou alterações em prazos e orçamentos disponíveis).
  • 4. Engenharia de Requisitos – análise e negociação Na fase de negociação, tornam-se necessários alguns cuidados para que esta decorra sem problemas, chegando-se logo a consensos. Algumas sugestões são: • saber lidar com ataques pessoais (evitando-os sempre que possível, remetendo a sua resolução para mais tarde, fora de reunião), de preferência nunca tomando partidos; • fomentar a justificação das posições (negativas) tomadas pelos intervenientes na negociação; • salientar (e procurar encontrar) os benefícios que uma solução apresenta para todos os envolvidos; • relaxar restrições, quando se torna óbvio que as atuais não levarão a um consenso.
  • 5. Engenharia de Requisitos – especificação e documentação É nesta fase que se dá a produção propriamente dita do Documento de Especificação de Requisitos. Em todos os tipos de especificação há 2 tipos de requisitos a considerar: • Requisitos funcionais: descrevem as funcionalidades que se espera que o sistema disponibilize, de uma forma completa e consistente. É aquilo que o usuário espera que o sistema ofereça, atendendo aos propósitos para qual o sistema será desenvolvido. • Requisitos não-funcionais (de qualidade): referem-se a aspectos nãofuncionais do sistema, como restrições nas quais o sistema deve operar ou propriedades emergentes do sistema. Costumam ser divididos em Requisitos não-funcionais de: Utilidade, Confiança, Desempenho, Suporte e Escalabilidade.
  • 6. Engenharia de Requisitos – especificação e documentação Exemplo de requisitos funcionais:
  • 7. Engenharia de Requisitos – especificação e documentação EXERCÍCIO:
  • 8. Engenharia de Requisitos – especificação e documentação Requisitos Não funcionais • Demonstram qualidade acerca dos serviços ou funções disponibilizadas pelo sistema. Ex.: tempo, o processo de desenvolvimento, padrões, etc. • Surgem conforme a necessidade dos usuários, em razão de orçamento e outros fatores. • Podem estar relacionados à confiabilidade, tempo de resposta e espaço nas mídias de armazenamento disponíveis. • Caso ocorra falha do não atendimento a um requisito não funcional, poderá tornar todo o sistema ineficaz. Ex.: requisito confiabilidade em um sistema de controle de voos.
  • 9. Engenharia de Requisitos – especificação e documentação Classificação dos Requisitos Não Funcionais • Requisitos de produtos : Requisitos que especificam o comportamento do produto.Ex. portabilidade; tempo na execução; confiabilidade,mobilidade, etc. • Requisitos da organização: Requisitos decorrentes de políticas e procedimentos corporativos. Ex. padrões, infra-estrutura,etc. • Requisitos externos: Requisitos decorrentes de fatores externos ao sistema e ao processo de desenvolvimento. Ex. requisitos de interoperabilidade, legislação,localização geográfica etc. • Requisitos de facilidade de uso. Ex.: usuários deverão operar o sistema após um determinado tempo de treinamento. • Requisitos de eficiência. Ex.: o sistema deverá processar n requisições por um determinado tempo. • Requisitos de confiabilidade. Ex.: o sistema deverá ter alta disponibilidade, p.exemplo, 99% do tempo.
  • 10. Engenharia de Requisitos – especificação e documentação Classificação dos Requisitos Não Funcionais • Requisitos de portabilidade. Ex.: o sistema deverá rodar em qualquer plataforma. • Requisitos de entrega.Ex.: um relatório de acompanhamento deverá ser fornecido toda segunda-feira. • Requisitos de implementação.: Ex.: o sistema deverá ser desenvolvido na linguagem Java. • Requisitos de padrões.: Ex. uso de programação orientada a objeto sob a plataforma A. • Requisitos de interoperabilidade.:Ex. o sistema deverá se comunicar com o SQL Server. • Requisitos éticos. Ex.: o sistema não apresentará aos usuários quaisquer dados de cunho privativo. • Requisitos legais. Ex.: o sistema deverá atender às normas legais, tais como padrões, leis, etc. • Requisitos de Integração. Ex.: o sistema integra com outra aplicação.
  • 11. Engenharia de Requisitos – especificação e documentação Requisitos de Domínio Pode-se também considerar os requisitos do domínio, que tal como o nome indica derivam do domínio e não de necessidades específicas dos usuários, podendo depois ser classificados como funcionais ou nãofuncionais. Podem ser requisitos funcionais novos, restrições sobre requisitos existentes ou computações específicas. Dois exemplos de requisitos do domínio são: • O calculo da média final de cada aluno é dado pela fórmula: (Nota1 * 2 + Nota2 * 3)/5; • Um aluno pode se matricular em uma disciplina desde que ele tenha sido aprovado nas disciplinas consideradas pré-requisitos.
  • 12. Engenharia de Requisitos – especificação e documentação Requisitos de Domínio - Exemplos
  • 13. Engenharia de Requisitos – especificação e documentação Requisitos de Domínio - Exercício
  • 14. Engenharia de Requisitos – especificação e documentação Requisitos de Domínio – Respostas
  • 15. Engenharia de Requisitos – especificação e documentação A documentação produzida poderá ter diferentes destinatários e como tal diferentes objetivos. Podem-se distinguir três tipos de especificação: • especificação de requisitos do usuário; • especificação de requisitos do sistema; • especificação do design da aplicação A vantagem de conceber mais do que uma especificação para um dado sistema é a de em cada especificação se comunicar apenas um determinado tipo de informação adequado ao leitor a que se destina (usando "linguagens" que o usuário conheça). Por exemplo, enquanto que nos requisitos do usuário apenas é feita uma abordagem de alto nível das funcionalidades do sistema e suas restrições, usando linguagem natural e eventualmente diagramas (esquemas). Nos requisitos do sistema cada requisito é descrito com mais detalhe introduzindo já alguns conceitos relativos à arquitetura do sistema, fazendo-se uso de linguagens estruturadas (notações gráficos como diagramas de casos de uso).
  • 16. Engenharia de Requisitos – especificação e documentação Os requisitos do usuário destinam-se portanto aos vários níveis hierárquicos da organização na qual o sistema será implementado (desde gestores a usuários), pelo que são descritos usando apenas linguagem natural, formulários e diagramas muito simples. Obviamente, neste nível de especificação surgem algumas dificuldades: • Ambiguidade: torna-se difícil descrever os requisitos de uma forma inequívoca sem tornar a sua descrição muito longa ou de difícil compreensão. • Confusão: ainda que possa não ser tão relevante do ponto de vista do cliente, a distinção entre requisitos funcionais/não-funcionais e objetivos do sistema torna-se difícil. • Agrupamento de requisitos: ao descrever as funcionalidades de um sistema, pode tornar-se difícil separar claramente os requisitos, o que leva a que vários requisitos sejam expressos como sendo apenas um.
  • 17. Engenharia de Requisitos – especificação e documentação • Algumas considerações úteis a ter em conta ao escrever uma especificação de requisitos do utilizador: • Usar o mesmo formato em todos os requisitos (evitam-se omissões e facilita-se a verificação dos requisitos). • Distinguir claramente entre comportamentos esperados e desejáveis do sistema através do uso de expressões como "O sistema permitirá criar (...)" ou "Deverá ser possível criar (...)" respectivamente. É importante deixar claro o que o sistema tem de fazer e sugestões de como o deve fazer e, acima de tudo, usar este tipo de expressões de forma consistente ao longo de todo o documento. • Usar formatação de texto para salientar determinados aspectos do documento (usando negrito, por exemplo). • Evitar usar termos demasiado técnicos ou fora do âmbito do sistema, identificando-os e definindo-os de uma forma clara quando for absolutamente necessário usá-los.
  • 18. Engenharia de Requisitos – especificação e documentação Requisitos do sistema • Os requisitos do sistema têm um carácter mais técnico; • Descrição detalhada dos requisitos do usuário. • Uso de linguagens estruturadas e notações gráficas. • Estes requisitos, destinam-se ainda aos usuários do sistema (e particularmente aos engenheiros que trabalhem nessa organização) e destinam-se também às equipes de especificação de arquitetura do sistema e de desenvolvimento.
  • 19. Engenharia de Requisitos – especificação e documentação Design da aplicação • A especificação do design da aplicação consiste num documento usado pela equipe de desenvolvimento do sistema no qual estão definidos pormenores, em um nível mais técnico, acerca da implementação do sistema e sua arquitetura. • A partir deste documento, um elemento que entre para a equipe de desenvolvimento no meio do projeto deverá ser capaz de "se situar" quando precisar de começar a codificar, compreendendo a forma como a implementação, em um nível global, está a ser feita, mas sem conhecer necessariamente os detalhes de implementação aprofundados.

×