Your SlideShare is downloading. ×

Aula3 engenharia requisitos

720
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
720
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
48
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. Engenharia de Software Aula 3 – Engenharia de Requisitos Profa. Dra. Judith Pavón Universidade Salvador – UNIFACS 2012
  • 2. Objetivo da aulaO objetivo desta aula é apresentar osconceitos básicos de Engenharia deRequisitos. 2
  • 3. Conteúdo1. Introdução2. Importância dos requisitos3. Processo de Engenharia de Requisitos4. Classificação dos requisitos 3
  • 4. Introdução Um processo de engenharia de requisitos eficiente evita uma compreensão incorreta dos requisitos. 4
  • 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. 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. 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. 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. Importância dos requisitos Níveis de Maturidade - CMMI-SE/SW 9
  • 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. 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. 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. 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. 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. 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. 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. Processo de Engenharia de Requisitos Análise Elicitação Documentaç Validação ão Gerenciamento de Requisitos Fonte: Sommerville & Sawyer, 2000 17
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Classificação de Requisitos 29
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Requisitos Não Funcionais 43
  • 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. 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. 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. 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. 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. 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. 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. Dúvidas 51