Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Modelagem de
Sistema de
Informação
Aula 04 – Levantamento de Requisitos
Cenário atual do desenvolvimento de software
Causas de falhas em projetos de software
Requisitos e análise de sistemas
Requisitos - Definição
Segundo o Rational Unified Process (RUP):
É uma condição ou uma capacidade que deve ser atendida pe...
Engenharia de Requisitos
É um processo que engloba todas as atividades que contribuem para a
produção de um documento de r...
Engenharia de Requisitos
Engenharia de Requisitos
Engenharia de Requisitos
Este processo deve ser precedido de estudos de viabilidade que, a
partir das restrições do projet...
Engenharia de Requisitos
• Uma forma de avaliar a viabilidade de um projeto é obter, através da
interação com "as partes i...
Engenharia de Requisitos - identificação
• Algumas das atividades envolvidas nesta fase incluem:
• Compreensão do domínio:...
Engenharia de Requisitos - identificação
Algumas dificuldades típicas estão associadas:
• O cliente pode não saber exatame...
Engenharia de Requisitos - identificação
Técnicas para levantamento de requisitos: Entrevistas e Questionários
• É a técni...
Engenharia de Requisitos - identificação
Técnicas para levantamento de requisitos: Workshops de requisitos
• Consiste numa...
Engenharia de Requisitos - identificação
Técnicas para levantamento de requisitos: Cenários
• Uma forma de levar as pessoa...
Engenharia de Requisitos - identificação
Técnicas para levantamento de requisitos: Prototipagem
• Versão inicial do sistem...
Engenharia de Requisitos - identificação
Técnicas para levantamento de requisitos: Estudo etnográfico
• Análise de compone...
Engenharia de Requisitos – análise e negociação
Após a identificação dos requisitos do sistema, segue-se à etapa de anális...
Engenharia de Requisitos – análise e negociação
Na fase de negociação, tornam-se necessários alguns cuidados para que
esta...
Engenharia de Requisitos – especificação e
documentação
É nesta fase que se dá a produção propriamente dita do Documento d...
Engenharia de Requisitos – especificação e
documentação
Exemplo de requisitos funcionais:
Engenharia de Requisitos – especificação e
documentação
EXERCÍCIO:
Engenharia de Requisitos – especificação e
documentação
Requisitos Não funcionais
• Demonstram qualidade acerca dos serviç...
Engenharia de Requisitos – especificação e
documentação
Classificação dos Requisitos Não Funcionais
• Requisitos de produt...
Engenharia de Requisitos – especificação e
documentação
Classificação dos Requisitos Não Funcionais
• Requisitos de portab...
Engenharia de Requisitos – especificação e
documentação
Requisitos de Domínio
Pode-se também considerar os requisitos do d...
Engenharia de Requisitos – especificação e
documentação
Requisitos de Domínio - Exemplos
Engenharia de Requisitos – especificação e
documentação
Requisitos de Domínio - Exercício
Engenharia de Requisitos – especificação e
documentação
Requisitos de Domínio – Respostas
Upcoming SlideShare
Loading in …5
×

Modelagem de Sistemas de Informação 04

625 views

Published on

Engenharia de Requisitos

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Modelagem de Sistemas de Informação 04

  1. 1. Modelagem de Sistema de Informação Aula 04 – Levantamento de Requisitos
  2. 2. Cenário atual do desenvolvimento de software
  3. 3. Causas de falhas em projetos de software
  4. 4. Requisitos e análise de sistemas
  5. 5. Requisitos - Definição Segundo o Rational Unified Process (RUP): É uma condição ou uma capacidade que deve ser atendida pelo sistema. Definição do IEEE (Institute of Electrical and Electronics Engineers): É uma condição ou capacidade que deve ser atendida pelo software, necessária a um usuário para solucionar um problema ou atender a um objetivo. O conjunto de todos os requisitos formam a base para posterior desenvolvimento do sistema ou componente do sistema. SWEBOK (Software Engineer Body Of Knowledge) Expressa necessidades e restrições ao produto de software que contribui para a solução de problemas no domínio do negócio.
  6. 6. Engenharia de Requisitos É um processo que engloba todas as atividades que contribuem para a produção de um documento de requisitos e sua manutenção ao longo do tempo. O processo de engenharia de requisitos é composto por quatro atividades de alto nível : • identificação; • análise e negociação; • especificação e documentação; • validação.
  7. 7. Engenharia de Requisitos
  8. 8. Engenharia de Requisitos
  9. 9. Engenharia de Requisitos Este processo deve ser precedido de estudos de viabilidade que, a partir das restrições do projeto, determinam se este é ou não viável e se deve prosseguir para a identificação dos requisitos.
  10. 10. Engenharia de Requisitos • Uma forma de avaliar a viabilidade de um projeto é obter, através da interação com "as partes interessadas" (ou stakeholder em inglês) do projeto (em reuniões ou entrevistas, por exemplo), a resposta às seguintes questões: • Será que o sistema contribui para os objetivos da organização? • Dadas as restrições tecnológicas, organizacionais e temporais associadas ao projeto, será que o sistema pode ser implementado? • Caso haja necessidade de integração entre diferentes sistemas, será que esta é possível?
  11. 11. Engenharia de Requisitos - identificação • Algumas das atividades envolvidas nesta fase incluem: • Compreensão do domínio: é muito importante para o analista compreender o domínio no qual a organização e o projeto se inserem; quanto maior for o conhecimento acerca do domínio, mais eficaz será a comunicação entre o analista e as partes interessadas. • Identificação das partes interessadas: estes já deverão ter sido identificados nos estudos de viabilidade, porém para efeitos de identificação de requisitos convém concentrar as atenções nos usuários do sistema. • Captura: consiste na obtenção com o cliente dos requisitos (funcionais e não- funcionais) pretendidos para o sistema. • Identificação e análise de problemas: os problemas devem ser identificados (e a sua definição deve ser consensual) e devem ser propostas soluções em conjunto com as partes interessadas.
  12. 12. Engenharia de Requisitos - identificação Algumas dificuldades típicas estão associadas: • O cliente pode não saber exatamente o que deseja para o sistema, ou sabê-lo mas não conseguir articulá-lo (o que é bastante comum). • Os requisitos identificados podem não ser realistas (do ponto de vista econômico ou tecnológico, por exemplo). • Cada parte interessada pode expressar os mesmos requisitos de formas diferentes, sendo necessário - através de um bom conhecimento do domínio - identificar estas situações.
  13. 13. Engenharia de Requisitos - identificação Técnicas para levantamento de requisitos: Entrevistas e Questionários • É a técnica mais simples de utilizar. Está condicionada a alguns fatores: • Influência do entrevistador nas respostas do cliente: convém que o entrevistador dê margem ao entrevistado para expor as suas ideias sem as enviesar logo à partida. • Relação pessoal entre os intervenientes na entrevista. • Predisposição do entrevistado: caso, por exemplo, o papel do entrevistado venha a ser afetado pela introdução de um sistema na organização, este pode propositadamente dificultar o acesso à informação. • Capacidade de seguir um "plano" para a entrevista: na ausência destes planos é natural que haja tendência para que os intervenientes se dispersem um pouco, levando a que a entrevista demore mais tempo do que seria suposto. Caso a entrevista se torne demasiado longa, as pessoas podem cair na tentação de "querer despachar" sendo os últimos pontos da entrevista abordados de forma superficial (ou podem nem chegar a ser abordados).
  14. 14. Engenharia de Requisitos - identificação Técnicas para levantamento de requisitos: Workshops de requisitos • Consiste numa técnica usada através de uma reunião estruturada, da qual devem fazer parte um grupo de analistas e um grupo representando o cliente , para então obter um conjunto de requisitos bem definidos. • Ao contrário das reuniões, promove-se a interação entre todos os elementos presentes no workshop fomentando momentos de descontração como forma de dinamizar o trabalho em equipe, existindo um facilitador neutro cujo papel é conduzir o workshop e promover a discussão entre os vários intervenientes. • As tomadas de decisão devem seguir processos bem definidos e devem resultar de um processo de negociação, mediado pelo facilitador. Uma técnica que é também útil em workshops é o uso de brainstorming como forma de gerar um elevado número de ideias numa pequena quantidade de tempo. • Como resultado dos workshops deve ser produzida documentação que reflita os requisitos e decisões tomadas sobre o sistema a implementar.
  15. 15. Engenharia de Requisitos - identificação Técnicas para levantamento de requisitos: Cenários • Uma forma de levar as pessoas a imaginarem o comportamento de um sistema. Através de exemplos práticos descritivos do comportamento de um sistema, os seus usuários podem comentar acerca do seu comportamento e da interação que esperam ter com ele. Trata-se de uma abordagem informal, prática e aplicável a qualquer tipo de sistema. De um modo geral, os cenários devem incluir os seguintes elementos: • estado do sistema no início do cenário; • sequência de eventos esperada (na ausência de erros) no cenário; • listagem de erros que podem ocorrer no decorrer dos eventos do cenário e de como estes erros serão tratados; • outras atividades que podem ser executadas ao mesmo tempo que as deste cenário; • estado do sistema depois de o cenário terminar.
  16. 16. Engenharia de Requisitos - identificação Técnicas para levantamento de requisitos: Prototipagem • Versão inicial do sistema, baseada em requisitos ainda pouco definidos, mas que pode ajudar a encontrar desde cedo falhas que através da comunicação verbal não são tão facilmente identificáveis. • São desenvolvidas apenas algumas funcionalidades sendo normalmente desenvolvidas primeiro aquelas que são mais fáceis de compreender por parte do utilizador e que lhe podem trazer maior valor acrescentado. • O uso de protótipos deve ser considerado apenas mediante uma análise custo-benefício, já que os custos de desenvolvimento de um protótipo podem facilmente crescer, sendo particularmente úteis em situações em que a interface com os usuários é, para eles, um aspecto crítico.
  17. 17. Engenharia de Requisitos - identificação Técnicas para levantamento de requisitos: Estudo etnográfico • Análise de componente social das tarefas desempenhadas numa dada organização. • Quando um dado conjunto de tarefas se torna rotineiro para uma pessoa, é de se esperar que esta sinta dificuldade em articular todos os passos que segue ou todas as pessoas com as quais interage para as levar a cabo. • Através de uma observação direta das atividades realizadas durante um período de trabalho de um funcionário é possível encontrar requisitos que não seriam observáveis usando técnicas convencionais. • Esta observação pode ser acompanhada de registros áudio/vídeo, porém não convém usá-los em demasia visto que o tempo necessário para os processar pode ser demasiado. Nesta técnica assume-se que o representante do cliente observado desempenha as suas funções "corretamente", pelo que convém ter algum cuidado na escolha do mesmo.
  18. 18. 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.
  19. 19. 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.
  20. 20. 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ão- funcionais do sistema, como restrições e propriedades nas quais o sistema deve operar ou propriedades emergentes do sistema. São a forma como os requisitos funcionais devem ser alcançados.
  21. 21. Engenharia de Requisitos – especificação e documentação Exemplo de requisitos funcionais:
  22. 22. Engenharia de Requisitos – especificação e documentação EXERCÍCIO:
  23. 23. 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.
  24. 24. 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.
  25. 25. 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.
  26. 26. 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ão- funcionais. 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.
  27. 27. Engenharia de Requisitos – especificação e documentação Requisitos de Domínio - Exemplos
  28. 28. Engenharia de Requisitos – especificação e documentação Requisitos de Domínio - Exercício
  29. 29. Engenharia de Requisitos – especificação e documentação Requisitos de Domínio – Respostas

×