Aula3 engenharia requisitos

1,330 views
1,091 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,330
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
77
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Aula3 engenharia requisitos

  1. 1. Engenharia de Software Aula 3 – Engenharia de Requisitos Profa. Dra. Judith Pavón Universidade Salvador – UNIFACS 2012
  2. 2. Objetivo da aulaO objetivo desta aula é apresentar osconceitos básicos de Engenharia deRequisitos. 2
  3. 3. Conteúdo1. Introdução2. Importância dos requisitos3. Processo de Engenharia de Requisitos4. Classificação dos requisitos 3
  4. 4. Introdução Um processo de engenharia de requisitos eficiente evita uma compreensão incorreta dos requisitos. 4
  5. 5. Introdução Requisitos são importantes para projetos de desenvolvimento de software, pois são a base para : ­ Análise de contratos; ­ Elaboração / análise de propostas; ­ Planejamento; ­ Estimativas; ­ Análise de riscos; ­ Gestão e controle; ­ Modelagem do sistema; ­ Desenvolvimento; ­ Testes. 5
  6. 6. Introdução Problemas com requisitos levam a: ­ Clientes insatisfeitos; ­ Altos custos; ­ Perda de reputação; ­ Compreensão do “problema incorreto”; ­ Efeito cascata nas demais fases de desenvolvimento de software. 6
  7. 7. Importância dos requisitos CMMI-SE/SW (Capability Maturity Model Integration) ­ Modelo de melhoria de processo de desenvolvimento de software. ­ Modelo seguindo 5 níveis de maturidade. ­ Capacidade de um processo de software:  faixa de resultados esperados dentro de uma margem de probabilidade. ­ Maturidade do processo:  reflete em que medida ele pode ser definido, gerenciado, medido, controlado e executado de maneira eficaz. 7
  8. 8. Importância dos requisitos CMMI-SE/SW (Capability Maturity Model Integration) 5. OTIMIZADO 4. GERENCIADO 5. Processo focado na QUANTITATIVAMENTE melhoria contínua 3. DEFINIDO 4. Processo medido e controlado 2. GERENCIADO 3. Processo orientado à organização e proativo 1. 2. Processo orientado a INICIAL projetos e geralmente reativo 1. Processo imprevisível, pouco controlado e reativo 8
  9. 9. Importância dos requisitos Níveis de Maturidade - CMMI-SE/SW 9
  10. 10. Importância dos requisitos Processo de Engenharia de Requisitos (PER) no modelo CMMI nível 3. definido PER baseado em melhores práticas; melhoria contínua nível 2. repetível PER obedecendo a normas nível 1. inicial PER adhoc 10
  11. 11. Importância dos requisitos Ciclo de Vida de Software (SWEBOK, 2004)Levantamento Projeto de Implementação Teste de Manutenção de e Definição Software de Software Software Softwarede Requisitos Elicitação de Requisitos Análise de Requisitos Especificação de Requisitos ri co e né el o G Validação d de Requisitos Mo Gerenciamento de Requisitos SWEBOK – Guide to the Software Engineering Body of Knowledge (IEEE) 11
  12. 12. Importância dos requisitos 56% dos erros em um sistema associam-se a problemas na fase de identificação dos requisitos (Fonte: “Extra time saves money” Warren Kuffel). Erros mais comuns: uso de fatos incorretos, omissão, inconsistência e ambigüidade. Distribuição de Defeitos 56% Requisitos 27% Projeto 7% 10% Outros Codificação
  13. 13. Importância dos requisitosClássicas falhas de sistemas por problemas de requisitos Aeroporto de Denver: mais de US$ 50 milhões perdidos em função de erros no sistema de controle de bagagens (Flower). Sistema de Ambulâncias de Londres: o sistema foi desativado um dia após o início de suas operações com causa de seus erros e falhas de segurança, confiabilidade e usabilidade (Flower). Foguete do Satélite Ariane 5: a trajetória do foguete era controlada por um sistema de computador, que falhou junto com seu sistema backup. Comandos de diagnóstico foram enviados para os motores, fazendo com que o foguete mudasse para uma trajetória instável (Nuseibeh). 13
  14. 14. Conceitos BásicosRequisito Uma especificação do que deve ser implementado. Descrição de como o sistema deve se comportar, ou uma propriedade ou atributo do sistema. Pode ser uma restrição no processo de desenvolvimento do sistema. (Sommerville & Sawyer) Uma condição ou capacidade que o sistema deve contemplar (Pressman) Uma necessidade do usuário ou característica, função ou atributo de um sistema que pode ser percebido de uma posição externa ao sistema. (Davis) 14
  15. 15. Conceitos BásicosEngenharia de Requisitos A Engenharia de Requisitos é um processo que envolve todas as atividades necessárias para criar e manter um Documento de Especificação de Requisitos (Sommerville). A Engenharia de Requisitos é uma sub-área da Engenharia de Software que estuda o processo de definição de requisitos que o software deverá atender (Sampaio). A Engenharia de Requisitos tem como objetivo prover ao profissional de métodos, técnicas e ferramentas que auxiliem o processo de compreensão e registro dos requisitos que o sistema deve atender (Sampaio). 15
  16. 16. Processo de Engenharia de RequisitosProcesso É um conjunto organizado de atividades que transforma entradas em saídas (Pressman).Atividades do Processo de Engenharia de Requisitos (Sommerville &Kontoya) Elicitação de Requisitos ­ Os requisitos são descobertos por meio das consultas com as partes interessadas. Análise e Negociação de Requisitos ­ Requisitos são analisados e conflitos são resolvidos por meio da negociação. Documentação de Requisitos ­ Um documento de requisitos é produzido. Validação de Requisitos ­ É checada a consistência, completude e outros atributos de qualidade do documento de requisitos. Gerenciamento de Requisitos ­ Consiste no controle de mudanças dos requisitos dentro do ciclo de vida do 16 software.
  17. 17. Processo de Engenharia de Requisitos Análise Elicitação Documentaç Validação ão Gerenciamento de Requisitos Fonte: Sommerville & Sawyer, 2000 17
  18. 18. Processo de Engenharia de Requisitos Elicitar Requisitos Controlar Mudanças Analisar Requisitos Rastreabilidade RequisitosDocumentar Requisitos Gerenciar Configuração Gerenciar Qualidade Validar Requisitos de Requisitos Desenvolvimento de Requisitos Gerenciamento de Requisitos 18
  19. 19. Processo de Engenharia de Requisitos sistemas Processo de Engenharia de Requisitos existentes (Entradas e Saídas)necessidades dos usuários normas processo de requisitos da engenharia de aprovadosorganização requisitos Documento deregulamentos Requisitosinformação do Fonte: Kotonya & Sommerville, 1998 domínio 19
  20. 20. Processo de Engenharia de Requisitos Características Principais da Engenharia de Requisitos  O processo de engenharia de requisitos é estruturado como um conjunto de atividades que leva a produção do documento de requisitos.  As entradas do processo de engenharia de requisitos são as informações existentes dos sistemas, necessidade das pessoas interessadas (stakeholders), padrões organizacionais, regulamentações e informações do domínio.  Os processos de engenharia de requisitos variam radicalmente entre empresas. A maioria dos processos incluem a elicitação de requisitos, análise e negociação, a documentação e a validação dos requisitos.  A atividade de gerenciamento de requisitos é uma atividade complementar que auxilia no controle das mudanças dos requisitos. 20
  21. 21. Stakeholders Atores no Processo de Engenharia de Requisitos: Stakeholders  Quem são os “interessados no sistema”? São as pessoas que serão afetadas pelo sistema e que têm uma influência direta ou indireta na elaboração dos requisitos: ­ usuários finais, gestores e outros envolvidos nos processos organizacionais que o sistema influencia, responsáveis pelo desenvolvimento e manutenção do sistema, clientes da organização que possam vir a usar o sistema, organismos de regulação e certificação, etc. 21
  22. 22. Stakeholders Alguns exemplos de partes interessadas (stakeholders):  Gestor do sistema;  Usuários finais;  Gestores de sistemas impactados;  Funcionários;  Clientes do banco;  Especialistas no negócio;  Órgãos reguladores;  Parceiros. 22
  23. 23. Conceito deRastreabilidade Técnica usada para prover relacionamento entre requisitos, projeto e implementação final do sistema (Edwards). É uma técnica que permite que os requisitos sejam claramente ligados às suas fontes e aos artefatos criados durante o ciclo de vida de desenvolvimento do sistema (Ramesh). Habilidade de permitir que mudanças em qualquer artefato – requisitos, especificação e implementação– sejam rastreadas através do sistema (Greenspan). Rastreabilidad Domínio do Problema Necessidades e Macro-Requisitos Domínio da Requisitos Solução Projeto e Documentações 23
  24. 24. Conceito de Rastreabilidade  Uma especificação de requisitos é rastreável se permite a fácil determinação dos antecedentes e conseqüências de todos os requisitos.  Rastreabilidade para Trás: ­ Deve ser possível localizar a origem de cada requisito. ­ Deve-se saber por que existe cada requisito, e quem ou o que o originou. Isso é importante para que se possa avaliar o impacto da mudança daquele requisito, e dirimir dúvidas de interpretação.  Rastreabilidade para Frente: ­ Deve ser possível localizar quais os resultados do desenvolvimento que serão afetados por cada requisito. Isso é importante para garantir que os itens de análise, modelagem, código eteste abranjam todos os requisitos, e para localizar os itens que serão afetados por uma mudança nos requisitos. 24
  25. 25. Conceito deRastreabilidade Os usuários comunicaram uma série de mudanças nas regras de negócio do Sistema de Contabilidade. Quanto você acha que vamos levar para alterar o sistema? Cara, vai dar um trabalhão. A lógica do cálculo dos impostos está espalhado por todo o sistema. Vamos gastar um tempão só para localizar todos os lugares que teremos de mexer. 25
  26. 26. Conceito deRastreabilidade A gestão de requisitos deve prover meios para que seja possível fazer um rastreamento entre os requisitos. Devem ser criados e mantidos entre requisitos, desde os requisitos de negócio até os requisitos de implementação, de testes e de documentação. Deve ser possível seguir estes vínculos nas duas direções. 26
  27. 27. Motivos para fazer Rastreabilidade Certificação – demonstração de que todos os requisitos foram implementados. Análise de impacto – cálculo do custo, tempo e risco de uma mudança. Manutenção – Indicação dos lugares onde deverão ser feitas as alterações solicitadas. Acompanhamento do projeto – aferição do progresso de um projeto de desenvolvimento ou manutenção. 27
  28. 28. Motivos para fazer Rastreabilidade Reengenharia – vínculo entre as funções do velho sistema e o local em que as mesmas estão implementadas no novo sistema. Reutilização – identificação de pacotes reutilizáveis de requisitos, design, código e testes. Redução de riscos – redução do impacto causado pela perda de um membro da equipe que mantém conhecimento essencial sobre o projeto. Testes – apoio na identificação dos locais onde pode estar o defeito detectado. 28
  29. 29. Classificação de Requisitos 29
  30. 30. Classificação de Requisitos Níveis de Requisitos  Nível de negócio  Nível de sistema Tipos de Requisitos ­ Nível de negócio ­ Requisitos de usuário (negócio) ­ Regras de negócio ­ Nível de sistema ­ Requisitos Funcionais ­ Requisitos Não Funcionais; ­ Requisitos Inversos; 30
  31. 31. Níveis de Requisitos Existem basicamente dois níveis de requisitos: ­ Nível de negócio:  Considera-se um nível macro, onde o foco principal é o negócio, independente do sistema. ­ Nível de sistema:  Considera-se um nível mais micro, onde a preocupação é identificar todos os requisitos necessários para o negócio, que devem ser contemplados no sistema. 31
  32. 32. Nível de Negócio Existem dois tipos de requisitos neste nível: ­ Requisitos de negócio:  São as necessidades do negócio que são expressas pelos usuários ou clientes do sistema.  São declarações, em linguagem natural ou em diagramas sobre o que o negócio exige que seja desenvolvido. Os requisitos de negócio devem se concentrar no que o sistema deve atender e não no como. ­ Regras de negócio:  São restrições sobre dados ou processos de negócio. 32
  33. 33. Regras de Negócios Uma regra de negócio descrevem, restringem ou controlam os dados ou atividades de um processo de negócio. Um processo de negócio é um conjunto de um ou mais procedimentos, os quais coletivamente realizam um objetivo de negócio, normalmente dentro do contexto de uma estrutura organizacional. 33
  34. 34. Regras de Negócios Uma organização ou empresa opera de acordo com um conjunto de regras de negócio, tais como, regras jurídicas, regras de venda, regras de interação com o cliente, entre outras. As regras expressam aspectos estáticos e dinâmicos do negócio. A automatização dos processos de negócio exige a automatização das regras que regem estes processos. As regras são representadas em uma linguagem processável, com a finalidade de automatizá-las em um sistema. 34
  35. 35. ExemploRegra: O gerente designado para atender a umcliente deve estar lotado em uma agência onde o clientepossui conta corrente. Está lotado Gerente Agência Atende Pertence Possui Conta Cliente Corrente 35
  36. 36. Nível de Sistema­ Requisitos de sistema:  Estabelecem detalhadamente as funções e as restrições de sistema. O documento de requisitos de sistema, algumas vezes chamado de especificação funcional é gerado neste nível. Ele pode servir como um contrato entre o comprador do sistema e o desenvolvedor de software. 36
  37. 37. Tipos de Requisitos de Sistema Requisitos Funcionais ­ Descrevem os serviços que se espera que o sistema deve oferecer. ­ Especificam as funcionalidades do sistema. Requisitos Não Funcionais ­ Descrevem aspectos de qualidade que o software deverá apresentar, ou as restrições a serem atendidas. ­ Os requisitos não funcionais referem-se às condições nas quais deve funcionar o sistema. ­ Podem estar relacionados a propriedades do sistema, tais como, confiabilidade, desempenho, etc. Requisitos Inversos ­ Referem-se ao que o sistema não fará. Descrevem as funções e restrições que não serão consideradas na abrangência do sistema. ­ São declarações do que o sistema não deve fazer ou de condições que nunca devem ocorrer durante o uso do sistema. 37
  38. 38. Tipos de Requisitos de Sistema Exemplos de Requisitos Funcionais: ­ O sistema deve permitir o cálculo dos gastos diários, semanais, mensais e anuais com o pessoal. ­ O sistema deve permitir consultar informações gerenciais operacionais da empresa. Exemplos de Requisitos Não Funcionais: ­ O tempo de resposta do sistema não deve ultrapassar 30 segundos. ­ O software deve ser operacionalizado no sistema Linux.. ­ O sistema deve ter uma disponibilidade 24x7. Exemplos de Requisitos Inversos: ­ A integração com o banco central, contabilidade e recursos humanos não fazem parte deste sistema. 38
  39. 39. Requisitos Funcionais Como especificar requisitos funcionais?  Linguagem Natural ­ Os requisitos funcionais podem ser descritos em linguagem natural em nível macro.  Casos de uso ­ Um modelo de casos de uso é utilizado para representar as funcionalidades do sistema de forma detalhada. ­ Um modelo de casos de uso identifica quem ou o que interage com o sistema e o que sistema deve fazer. ­ Casos de uso são técnicas baseadas em cenários onde são identificados atores e sua interação com o sistema. 39
  40. 40. Requisitos Não Funcionais TIPOS DE REQUISITOS NÃO FUNCIONAIS (Sommerville)  Requisitos de produtos ­ São os requisitos que especificam o comportamento do produto. ­ Exemplo: requisitos de desempenho, que especificam com que rapidez o sistema deve operar.  Requisitos organizacionais ­ São procedentes de políticas e procedimentos nas organizações do cliente e do desenvolvedor. ­ Entre os exemplos estão os padrões de processos que devem ser utilizados, os requisitos de implementação, como a linguagem de programação ou a metodologia de processo de desenvolvimento.  Requisitos externos ­ Abrange todos os requisitos procedentes de fatores externos ao sistema e ao seu processo de desenvolvimento. ­ Exemplo: requisitos de interoperabilidade, requisitos legais, requisitos éticos. 40
  41. 41. Requisitos Não Funcionais Requisitos não-funcionais Produto Organizacionais Externos Interoperabilidade Éticos Eficiência Confiabilidade Portabilidade LegislativosFacilidade de uso Entrega Implementação Padrões Privacidade SegurançaDesempenho Espaço 41
  42. 42. Requisitos Não Funcionais  Usabilidade (facilidade de uso) ­ Definição: A facilidade de aprendizado e operação do software pelos potenciais usuários. ­ Métrica: Tempo de treinamento Habilidades do usuário / unidade de tempo Recursos de ajuda on-line ­ Exemplo:  Um balconista treinado deve ser capaz de cadastrar um cliente em no máximo 5 minutos.  Novos usuários do internet banking devem ser capazes de encontrar o serviço de recarga de celulares no máximo em duas tentativas.  Eficiência (performance) ­ Definição: medida de velocidade e eficiência do sistema em execução. ­ Métrica: Throughput (quantidade de transações/unidade de tempo) Tempo de resposta ao usuário/evento Capacidade (quantidade de usuários usando o sistema simultaneamente) ­ Exemplo:  O tempo de resposta do serviço “saldo da conta” deve ser no máximo 4 segundos. 42
  43. 43. Requisitos Não Funcionais 43
  44. 44. Requisitos Não Funcionais Portabilidade ­ Definição: A habilidade do software de se adaptar a diferentes ambientes pré-definidos. ­ Métrica: Número de sistemas-alvo Porcentagem de declarações dependentes de sistemas-alvo ­ Exemplo:  O sistema deverá ser capaz de operar em Windows e Linux. Confiabilidade ­ Definição: A habilidade do software de se comportar consistentemente de forma aceitável pelo usuário. ­ Métrica: Taxa de ocorrências de falhas Probabilidade de indisponibilidade (downtime) Disponibilidade ­ Exemplo:  O sistema deverá estar disponível 24x7. 44
  45. 45. Requisitos Não Funcionais Interoperabilidade ­ Definição: capacidade de interação com outros produtos especificados. ­ Métrica: Produtos com os quais o sistema deve se comunicar ­ Exemplo:  O sistema deverá permitir exportar os relatórios para Excel. Segurança ­ Definição: resistência ao acesso não-autorizado e à perda de informações. Se preocupa pela privacidade dos dados. ­ Métrica: Restrições de acesso  Definição de perfis de usuários  Procedimentos de segurança dos dados ­ Exemplo:  Duas cópias de segurança dos dados do sistema serão feitas diariamente e pelo menos uma delas deve ser armazenada em local externo. 45
  46. 46. Requisitos Não Funcionais Requisitos de entrega ­ Definição: indicam restrições de prazos e forma de entrega dos produtos a serem elaborados. ­ Métrica: Data de Entrega Formato de entrega de artefatos ­ Exemplo:  O módulo referente a empréstimos deve ser entregue até dia 20 de janeiro de 2008. Requisitos de implementação ­ Definição: indicam restrições quanto ao uso de ferramentas ou linguagens de programação. ­ Métrica: Lista de ferramentas Definição de padrões ­ Exemplo:  O sistema será desenvolvido utilizando a linguagem de programação Java e o SGBD PostgreSQL. 46
  47. 47. Requisitos Não Funcionais Requisitos relativos a padrões ­ Definição: indica a necessidade de obedecer métodos, normas e padrões institucionais. ­ Métrica: Lista de padrões Definição de métodos ­ Exemplo:  O sistema será desenvolvido seguindo o modelo de processo de desenvolvimento RUP. Requisitos éticos ­ Definição: abordam a prevenção da divulgação não autorizada de informações pessoais e o respeito aos indivíduos como cidadãos. ­ Métrica: Regras éticas Normas de comportamento do usuário ­ Exemplo:  O sistema deverá possuir meios de impedir a cópia e divulgação de listas de clientes para pessoas não autorizadas. 47
  48. 48. Requisitos Não Funcionais Requisitos legais ­ Definição: indica a necessidade de conformidade com determinações legais e regulatórias. ­ Métrica: Leis vigentes Normas da empresa ­ Exemplo:  O sistema deverá permitir o fornecimento dos dados pessoais sobre os clientes quando a gerencia solicitar os mesmos. 48
  49. 49. Importância dos RequisitosNão Funcionais Todos os Requisitos Funcionais devem ser satisfeitos, mas se os Requisitos Não-Funcionais forem negligenciados, o sistema falhará.
  50. 50. Exercícios de Revisão Identificação de Tipos de Requisitos  Verifique se as sentenças abaixo são requisitos verificáveis.  Caso não sejam verificáveis, há uma forma melhor de defini-los?  Caso sejam requisitos verificáveis, indicar o tipo de requisito. a) Todo funcionário deve possuir um cartão de identificação da empresa. b) O downtime do sistema é 2 horas no período da madrugada de domingo. c) O sistema deve permitir aos professores realizar uma reserva de equipamentos por meio de uma aplicação web. d) As janelas do sistema devem ter uma interface que permita aos usuários utilizar o sistema de forma intuitiva. e) O sistema deverá estar preparado para usuários com deficiências físicas. f) O sistema deve permitir a criação de um menu de opções de equipamentos que possam ser reservados. g) O sistema deverá ser desenvolvido na linguagem de programação Java. h) O sistema deve exportar dados de uma forma clara e precisa. i) A reserva de um equipamento deve ser realizada no máximo 24 horas antes do evento marcado. j) O sistema deve ter a capacidade de suportar 2500 usuários simultaneamente. k) O sistema deverá ser finalizado antes do final do ano.
  51. 51. Dúvidas 51

×