Aula 1 requisitos

1,307 views

Published on

  • Be the first to comment

Aula 1 requisitos

  1. 1. Pós Graduação em Desenvolvimento deSoftwareMódulo: Engenharia de RequisitosAula 1: RequisitosProfessor: Licardino Siqueira Pires
  2. 2. O desafio da análise• São quatro os desafios da análise:• Compreensão do domínio do problema• Comunicação interpessoal• Evolução contínua• reutilização
  3. 3. Domínio do Problema e Responsabilidade• Estudo do domínio do problema e a identificação das suascaracterísticas;• Significados:• Problema: [Jogar para frente, empurrar para frente (Grego)]; Umaquestão proposta para solução ou consideração;• Domínio: [Direito de propriedade, posse (Grego)]; A esfera oucampo de atividade ou influência; como por exemplo o domínioda arte ou política.• Assim: Domínio do Problema. Um campo sob estudoou consideração.• Exemplo: controle do espaço aéreo, a aviônica, asfinanças e as leis.
  4. 4. Domínio do Problema e Responsabilidade• Significados:• Sistema: [reunir (Grego)];Um conjunto ou arranjo de elementosrelacionados ou interligados de modo a formar uma unidade ouum todo orgânico, por exemplo sistema solar e sistema deirrigação;• Responsabilidade: [que precisa de uma resposta (Grego)]; Acondição, qualidade, fato ou ocorrência de ser responsável,exigível, cobrável ou imputável; aplica-se a pessoas, mandados,ofícios ou dívidas.• Assim: Responsabilidade do sistema. Umaorganização de elementos relacionados de modo aformar um todo.
  5. 5. Domínio do Problema e Responsabilidade• Um analista precisa especificar requisitos, reunidosconcisamente de forma que as pessoas possam ler eentender o que o analista acredita que são estesrequisitos.• Mas o crucial é entender o domínio do problema.
  6. 6. Comunicação• Todo o trabalho de análise precisa de comunicação;• Retornar ao cliente o que foi sintetizado para validação;• Negociar com cliente requisitos que não possam seratendidos, devido ao cronograma e custo;• Engenharia de software baseada fortemente em pessoas;• Os processos de software são efetivos somente até oponto em que ajudam as pessoas a se comunicarem;
  7. 7. Comunicação
  8. 8. Mudança Contínua• Requisitos sempre mudam;• “Temos que aceitar a instabilidade dos requisitos comoum fato da vida, e não condená-la como o resultado de umraciocínio mal conduzido” afirma Gerard Fischer;• Agrupar os requisitos estáveis• Tratar com diferenciação os instáveis
  9. 9. Reutilização• Reutilizar é o ato de incorporar resultados de análiseanteriores na análise atual;
  10. 10. Tarefas da Engenharia de Requisitos• O processo é composto de sete funções distintas:concepção, levantamento, elaboração, negociação,especificação, validação e gestão.
  11. 11. Concepção• Como um projeto de software é iniciado?•Existe um evento único que torna catalisador de um novosistema, ou a necessidade evolui com o tempo?
  12. 12. Levantamento•Parece simples?• Questione o cliente, o usuário quais os objetivos dosistema. Pode ser difícil.Limite maldefinidoRequisitosmudam
  13. 13. Elaboração•Refinamento das informações obtidas do cliente durante aconcepção e levantamento;•Modelo técnico refinado das funções, características erestrições de software;•O resultado final da elaboração define• Domínio do problema informacional, funcional ecomportamental.
  14. 14. ElaboraçãoConsidere por um momento que lhe foi solicitado especificar todos os requisitos para aconstrução de uma cozinha gourmet.A fim de especificar totalmente o que deve ser construído, você poderia listar todos osgabinetes e seus eletrodomésticos. Você então poderia especificar o revestimento dosbalcões, peças de encanamento e pavimentação. Essas listas poderiam fornecer umaespecificação útil, mas não fornecem um modelo completo do que você quer.Para completar o modelo, você poderia criar uma apresentação tridimensional quemostrasse a posição dos gabinetes, dos eletrodomésticos e relacionamento entre eles.Construímos modelos de análise por motivos muito semelhantes àqueles pelos quaisdesenvolveríamos uma planta ou uma apresentação 3D da cozinha. É importante avaliaros componentes do sistema em relação uns com os outros, para determinar como osrequisitos se encaixam nesse quadro e avaliar a estética do sistema tal como concebida.
  15. 15. Negociação•Usuários pedem mais do que pode ser conseguido•Usuários diferentes possuem requisitos de acordo com seusinteresses.•O Engenheiro de requisitos deve negociar.•Não deve haver ganhador e nem perdedor em umanegociação efetiva.
  16. 16. Especificação•Pode ser:• Cenários de uso• Documento escrito• Modelo gráfico•Último produto do engenheiro de requisitos•Serve como subsídio das atividades subsequentes;•Descreve a função e o desempenho de um sistema decomputador e as restrições que governarão seudesenvolvimento.
  17. 17. Validação•Os produtos de trabalho são avaliados quanto a qualidade
  18. 18. Check list da Validação• Os requisitos foram claramenteestabelecidos? Eles podem ser malinterpretados?• A fonte do requisito foi identificada?• O requisito está limitado em termosquantitativos?• Que outros requisitos se relacionam aeste requisito? Eles foram claramenteanotados em uma matriz de referênciacruzada?• O requisito viola alguma restrição dedomínio?• O requisito pode ser testado? Em casopositivo, podemos exercitar os testespara exercitar o requisito?• Pode-se relacionar o requisito a qualquermodelo de sistema que tenha sido criado?• O requisito está relacionado aos objetivosglobais do sistema/produto?• A especificação do sistema estáestruturada de modo que leve a fácilentendimento, fácil referenciação e fáciltradução em produtos de trabalho maistécnicos?• Foi criado um índice para a especificação?• Os requisitos relacionados aodesempenho, ao comportamento e àscaracterísticas operacionais do sistemaforam claramente declarados? Querequisitos podem estar implícitos?
  19. 19. Gestão de Requisitos•A cada requisito é atribuída uma identificação;•Tabelas de rastreamento são desenvolvidas
  20. 20. Requisitos• Requisitos tem papel central no processo de software,sendo considerados um fator determinante para o sucessoou fracasso de um projeto de software;•O processo de levantar, gerenciar e controlar a qualidadedos requisitos é chamado Engenharia de Requisitos;
  21. 21. Definições• Requisitos de um sistema são descrições dos serviçosque devem ser fornecidos por esse sistema e as suasrestrições operacionais(SOMMERVILLE, 2007).• Um requisito de um sistema é uma característica dosistema ou a descrição de algo que o sistema é capaz derealizar para atingir seus objetivos (PFLEEGER, 2004).• Um requisito é alguma coisa que o produto tem de fazer ouuma qualidade que ele precisa apresentar (ROBERTSON;ROBERTSON, 2006).
  22. 22. Tipos de Requisitos• Requisitos Funcionais:• são declarações de serviços que o sistema deveprover, descrevendo o que o sistema deve fazer(SOMMERVILLE, 2007).• Um requisito funcional descreve uma interação entre osistema e o seu ambiente (PFLEEGER, 2004), podendodescrever, ainda, como o sistema deve reagir aentradas específicas, como o sistema deve secomportar em situações específicas e o que o sistemanão deve fazer (SOMMERVILLE, 2007).
  23. 23. Tipos de Requisitos• Requisitos não Funcionais:• descrevem restrições sobre os serviços ou funçõesoferecidos pelo sistema (SOMMERVILLE, 2007), asquais limitam as opções para criar uma solução para oproblema (PFLEEGER, 2004).• Neste sentido, os requisitos não funcionais são muitoimportantes para a fase de projeto (design), servindocomo base para a tomada de decisões nessa fase.
  24. 24. RequisitosOrganização de Requisitos• Requisitos Funcionais• Evidentes são efetuados com conhecimento dousuário• Ocultos são efetuados pelo sistema sem oconhecimento explícito do usuário.• Transitórios: podem ser mudados por legislações enormas, por exemplo. (parametrização)• Exemplo: Registrar empréstimo.• Requisitos não-funcionais:• Obrigatórios• Desejáveis• Exemplo: O tempo de registro de cada DVD deve serinferior a um segundo.
  25. 25. Exemplo• Registrar o empréstimo de uma fita é um requisito funcional.• Estabelecer que o tempo de empréstimo da fita não pode sersuperior a 48 horas é uma restrição, ou requisito nãofuncional.
  26. 26. Classificação de requisitos nãofuncionais• Sommerville (2007), por exemplo, classifica-os em:• Requisitos de produto: especificam o comportamento doproduto (sistema). Referem-se a atributos de qualidade .• Requisitos organizacionais: são derivados de metas,políticas e procedimentos das organizações do cliente edo desenvolvedor.• Requisitos externos: referem-se a todos os requisitosderivados de fatores externos ao sistema e seu processode desenvolvimento.
  27. 27. Níveis de descrição de requisitos• Requisitos de Usuário: são declarações em linguagemnatural acompanhadas de diagramas intuitivos de quaisserviços são esperados do sistema e das restrições sob asquais ele deve operar.• Requisitos organizacionais: definem detalhadamente asfunções, serviços e restrições do sistema.
  28. 28. Documento de Especificação deRequisitos1. Introdução1. Propósito do documento de requisitos2. Escopo do produto3. Definições, escopo e abreviaturas4. Referências5. Visão geral do restante do documento2. Descrição Geral1. Perspectiva do produto2. Funções do produto3. Características dos usuários4. Restrições gerais5. Suposições e dependências3. Requisitos específicos4. Apêndices5. Índice
  29. 29. Entendendo as necessidades dos usuários• Identificar as fontes de requisitos dos Envolvidos• Definir lista de requisitos do sistema• Pode-se utilizar técnicas de brainstorming paralevantamento dos requisitos junto aos envolvidos.• Os requisitos podem ser classificados em duas grandescategorias:• Requisitos Funcionais que correspondem a listagemde tudo que o sistema deve fazer.• Requisitos não-funcionais que são restriçõescolocadas sobre como o sistema deve realizar seusrequisitos funcionais.
  30. 30. Quais são as fontes dos requisitos?AnalistasParceirosUsuáriosClienteDomínio doProblemaRequisitos IniciaisRelatórios de ProblemasSolicitações de MudançasVisitas no siteInformações dos concorrentesLegislaçõesSistemas legadosEspecificações de requisitosModelos de negóciosPlanos de negóciosObjetivos pessoais
  31. 31. Quais problemas podem ser encontrados• Envolvidos• Possuem uma ideia pré-concebida da solução• Não sabem o que eles realmente desejam• São inabilitados em articular o que eles desejam• Pensam que sabem o que eles Desejam, mas não osreconhecem quando eles são entregues• Analistas• Pensam que eles entendem os problemas do usuáriomelhor do que o usuário.• Os outros• Todo mundo enxerga as coisas do seu próprio pontode vista• Acredita que tudo é motivado politicamente (a equipecomercial deseja a implementação de requisitos queatraem mais clientes e a financeira requisitos quetornem os gastos menores)
  32. 32. Técnicas para elicitação de requisitos•Revisar as especificações de requisitos dos clientes•Entrevista•Leitura de Documentos•Questionário•Participação ativa dos usuários•Brainstorming•Workshop de requisitos•Protótipos•Observações e análises sociais
  33. 33. Técnicas para elicitação de requisitosWorkshop de requisitos• Criar consenso no escopo, riscos e característicaschaves do sistema de software.• São direcionados por um facilitador• Duração: 3 a 5 dias• Artefatos produzidos, como:• Declaração do problema• Requisitos dos envolvidos• Características chaves• Diagrama de caso de uso• Lista de risco priorizada
  34. 34. Técnicas para elicitação de requisitosBenefícios do Workshop de requisitos• Provê um framework para aplicar outras técnicas deelicitação• Workshop de caso de uso, brainstorming• Acelera o processo de elicitação• Reuni todos os envolvidos para uma discussão intensa efocado no problema• Promove a participação de todos• Resultados avaliados imediatamente
  35. 35. Técnicas para elicitação de requisitosWorkshop: Planejar e ExecutarPré-workshop Sessão Produção AcompanhamentoMotivar o workshopEstabelecer equipeOrganizá-loEnviar materiaisPreparar agendaFacilitarRastreamentoRegistrardescobertasResumir asconclusõesSintetizardescobertasCondensar infoApresentar aoclientePlanejar próximospassos
  36. 36. Reunião de Coleta de Requisitos• Jamie Lazar, Vinod e Ed, membro daequipe de software; Doug, gerente deengenharia de software; membros demarketing; facilitador• Facilitador (apontando para um quadro):Então, esta é a lista de objetos e serviçospara a função de segurança residencial.• Pessoa de Marketing: Isso praticamentecobre tudo do nosso ponto de vista.• Vinod: Alguém não mencionou que queriatoda a funcionalidade do CasaSeguraacessível via internet? Isso, incluiria afunção de segurança residencial, não?• Pessoa de Marketing: É, está certo ...Vamos ter de acrescentar essafuncionalidade e os objetos adequados.• Facilitador: Isso também acrescentaalguma restrição?• Jamie: Sim, tanto técnicos quanto legais• Representante da Produção: O quesignifica?• Jamie: Precisamos estar certos de que umapessoa de fora não pode invadir o sistema,desarmá-lo e roubar o lugar ou pior.Pesada responsabilidade de nossa parte.• Doug: Muito Certo• Marketing: Mas nós ainda precisamos deconectividade via internet ... Basta noscertificarmos de impedir a invasão de umapessoa de fora.• Ed: Isso é mais fácil de falar do que fazer...• Facilitador (interrompendo): Eu não querodiscutir esse ponto agora. Vamos anotá-locom um item de ação e prosseguir.• Facilitador: Estou sentindo que existeainda mais a considerar.
  37. 37. Técnicas para elicitação de requisitosEntrevistas• O engenheiro de requisitos ou analista discute o sistemacom diferentes stakeholders e obtêm um entendimentodos requisitos.• Vantagens: contato direto com o usuário e validaçãoimediata• Desvantagens: conhecimento tácito e diferenças decultura
  38. 38. Técnicas para elicitação de requisitosEntrevistas: tipos• Entrevistas fechadas. O engenheiro de requisitos buscarespostas para um conjunto de questões pré-definidas• Entrevistas abertas. Não há uma agenda pré-definida e oengenheiro de requisitos discute, de forma aberta, o queo stakeholders quer do sistema.
  39. 39. Técnicas para elicitação de requisitosEntrevistas• Entrevistadores devem estar de “cabeça aberta” e nãofazer a entrevista com noções pré-concebidas sobre oque é necessário• Informar aos stakeholders o ponto inicial da discussão.Isto pode ser uma questão, uma proposta de requisitosou um sistema existente• Entrevistadores devem estar cientes da políticaorganizacional - muitos requisitos reais podem não serdiscutidos devido as implicações políticas
  40. 40. Técnicas para elicitação de requisitosQuestionário• Quando existe conhecimento sobre o problema e grandenúmero de clientes• Dão idéia definida sobre como certos aspectos universode informação/software são percebidos• Possibilitam análises estatísticas• Vantagens: padronização das perguntas e tratamentoestatístico das respostas• Desvantagens: limitação do universo de respostas epouca iteração
  41. 41. Técnicas para elicitação de requisitosModos de comunicação

×