Modelagem de Sistemas de Informação 04

461 views
375 views

Published on

Engenharia de Requisitos

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
461
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
28
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

×