Engenharia de Requisitos. Aécio Costa

Transcrição

1 Aécio Costa

2 Um requisito é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar, para atingir os seus objetivos. (PFLEEGER, 2004) Um requisito é algo que o sistema é capaz de realizar ou uma propriedade que o sistema necessita apresentar. Os requisitos de um sistema são as descrições do que o sistema deve fazer, os serviços que oferece e as restrições a seu funcionamento. (SOMMERVILLE, 2012)

3 Porque requisitos são importantes?

4 Segundo o CHAOS Report: 1. Requisitos incompletos; 2. Falta de envolvimento; 3. Mudanças de objetivos; 4. Comunicação insuficiente.

5 40% do percentual de erros detectados nos sistemas, deve-se a especificações mal feitas.

6 Sommerville (2012) define dois tipos de requisitos e faz uma distinção entre requisitos de usuário e requisitos do sistema.

7 Requisitos do usuário: declarações em uma linguagem natural com diagramas, de quais serviços o sistema deverá fornecer a seus usuários e as restrições com as quais este deve operar. Requisitos do sistema: descrições mais detalhadas das funções, serviços e restrições operacionais do sistema de software.

8 Requisitos do Sistema Requisitos do Usuário

9 Requisitos do Usuário O software deve fornecer um meio de representar e acessar arquivos externos criados por outras ferramentas.

10 Requisitos do Sistema O usuário deve dispor de recursos para definir o tipo dos arquivos externos; Cada tipo de arquivo externo pode ter uma ferramenta associada que pode ser aplicada a ele; Cada tipo de arquivo externo pode ser representado por um ícone; Quando um usuário seleciona um ícone, o efeito desta seleção é aplicar a ferramenta associada com o tipo de arquivo.

11 Outros Exemplos de Requisitos O sistema deve manter registro de todos os materiais da biblioteca incluindo livros, séries, jornais e revistas, fitas de vídeo e áudio, relatórios, coleções de transparências, discos de computadores, e CD-ROMs; O sistema deve permitir os usuários pesquisarem um item através do título, autor ou ISBN; A interface de usuário do sistema deve ser implementa da usando um browser de WWW (World-Wide-Web); O sistema deve suportar pelo menos 20 transações por segundo; As facilidades do sistema que estão disponíveis para o público devem ser demonstradas em 10 minutes ou menos.

12 Exercício: Levantar 2 requisitos para um sistema de controle acadêmico de uma faculdade. Tempo: 20 Minutos Dupla

13 Engenharia de Requisitos é... O processo de descobrir, analisar, documentar e verificar esses serviços e restrições. (SOMMERVILLE, 2012)

14 Segundo Sommerville (2012) os processos de engenharia de requisitos podem incluir quatro atividades: estudo de viabilidade, elicitação e análise, especificação e validação.

15 Classificação Os requisitos podem ser classificados de duas maneiras: funcionais e não funcionais.

16 Classificação Funcionais: Descreve uma interação entre o sistema e o seu ambiente. Não funcionais: Os requisitos não funcionais colocam restrições no sistema.

17 Os requisitos não funcionais podem ser classificados mais detalhadamente como:... Requisitos de performance Requisitos de manutenabilidade Requisitos de confiabilidade Requisitos de segurança Requisitos de facilidade de uso Requisitos de portabilidade

18 Exemplos: Requisitos funcionais Criação das agendas dos médicos: responsável por criar as agendas de disponibilidade para os atendimentos prestados pelos médicos em um determinado mês; Vender carro customizado: responsável por permitir que o consumidor navegue no site e monte o carro com as características que desejar.

19 Exemplos: Requisitos não-funcionais A operação de registro na agenda não deve demorar mais de 10 segundos; O banco de dados de pedido deve ser atualizado em tempo real.

20 Levantamento de Requisitos

21 Consiste no primeiro estágio de construção de conhecimento a respeito do problema que o software deverá resolver; Neste momento os engenheiros de software trabalham com clientes e usuários finais.

22 1. Descoberta dos requisitos 4. Especificação dos requisitos 2. Classificação e organização dos requisitos 3. Priorização e negociação dos requisitos Processo de elicitação e análise de requisitos (SOMMEVILLE, 2012)

23 Descoberta dos requisitos Nessa etapa ocorre a interação com os stakeholders para descobrir/identificar os requisitos.

24 Classificação e organização Visa agrupar os requisitos relacionados organizando-os em grupos coerentes.

25 Priorização e organização de requisitos Como há vários interesses e stakeholders envolvidos é comum ocorrer conflito nos requisitos levantados. Essa atividade visa a resolução desses conflitos.

26 Especificação dos requisitos Os requisitos são documentados por meio de documentos formais ou informais.

27 Porque é um processo difícil?

28 Segundo Sommerville (2012) há várias razões que tornam o processo difícil: 1. Os stakeholders costumam não saber o que querem de um sistema computacional. 2. Os stakeholders expressam requisitos em seus próprios termos e com conhecimento implícito de seu próprio trabalho. 3. Diferentes stakeholders têm requisitos diferentes e podem expressar essas diferenças de várias maneiras. 4. Fatores políticos podem influenciar os requisitos de um sistema. 5. É inevitável que ocorram mudanças durante o processo de análise.

29 Técnicas de Levantamento de Requisitos Entrevistas Questionários Brainstorm Cenários Protótipos Observação Reuso de Requisitos

30 Entrevistas Fechadas: o stakeholder responde a um conjunto predefinido de perguntas. Abertas: não existe uma agenda predefinida. A equipe de engenharia de requisitos explora uma série de questões com os stakeholders do sistema e, assim, desenvolve uma melhor compreensão de suas necessidades. (Sommerville, 2012)

31 Entrevistadores devem estar de cabeça aberta e não fazer a entrevista com noções pré-concebidas sobre o que é necessário; Informar aos stakeholders o ponto inicial da discussão. Isto pode ser uma questão, uma proposta de requisitos ou um sistema existente; Entrevistadores devem estar cientes da política organizacional - muitos requisitos reais podem não serem discutidos devido as implicações políticas.

32 Questionários Quando existe conhecimento sobre o problema e grande número de clientes; Dão idéia definida sobre como certos aspectos universo de informação/software são percebidos; Possibilitam análises estatísticas; Vantagens: padronização das perguntas e tratamento estatístico das respostas. Desvantagens: limitação do universo de respostas e pouca iteração.

33 Brainstorms Mais que uma técnica de dinâmica de grupo, é uma atividade desenvolvida para explorar a potencialidade criativa de um indivíduo ou de um grupo - criatividade em equipe - colocando-a a serviço de objetivos pré-determinados. Desenvolvimento de novos produtos - obter ideias para novos produtos e efetuar melhoramentos aos produtos existentes. Resolução de problemas - consequências, soluções alternativas, análise de impacto, avaliação. Gestão de projetos - identificar objetivos dos clientes, riscos, entregas, pacotes de trabalho, recursos, tarefas e responsabilidades.

34 Cenários Cenários são estórias que explicam como um sistema poderá ser usado. Eles devem incluir: uma descrição do estado do sistema antes de começar o cenário; o fluxo normal de eventos do cenário; exceções ao fluxo normal de eventos; informações sobre atividades concorrentes; uma descrição do estado do sistema ao final do cenário. Cenários são exemplos de sessões de interação que descrevem como o usuário interage com o sistema; A descoberta de cenários expõe interações possíveis do sistema e revela as facilidades que o sistema pode precisar.

35 Cenários Ex: Pedido de Documentos Entre no sistema SysDoc Escolha o comando pedido de documentos Entre um número de referência do documento pedido Selecione um ponto de entrega Saia do sistema SysDoc Esta sequência de eventos pode ser ilustrada num diagrama

36 Cenários Ex: Pedido de Documentos User id Passwd Exceptions Operational terminal Login to EDDIS Invalid id or password Login retry Login OK Select order document Exceptions Permission denied Enter help system Order accepted Input document reference Exceptions Incorrect reference Input doc. reference Document reference OK Confirm delivery details Exceptions Delivery confirmed Logout from EDDIS Timeout Enter help system Auto-logout

37 Cenários Cenários são partes inerentes de alguns métodos de desenvolvimento orientados a objeto; O termo caso de uso ou use-case (um caso específico do uso do sistema) é usado as vezes para se referir a um cenário; Existem diferentes visões sobre o relacionamento entre caso de uso e cenários : Um caso de uso é um cenário; Um cenário é uma coleção de casos de uso. Portanto, cada interação excepcional é representada como um caso de uso separado.

38 Protótipos Um protótipo é uma versão inicial de um sistema que poderá ser usado para experimentação. Protótipos são úteis para elicitação de requisitos porque os usuários poderão experimentar com o sistema e mostrar os pontes fortes e fracos do sistema. Eles terão algo concreto para criticar. O desenvolvimento rápido dos protótipos é essencial para que eles fiquem disponíveis logo para o processo de elicitação.

39 Protótipos O protótipo permite que os usuários experimentem e descubram o que eles realmente necessitam para suportar o trabalho deles Estabelece a viabilidade e utilidade antes que altos custos de desenvolvimento tenha sido realizado Essencial para desenvolvimento do aspecto look and feel da interface do usuário Pode ser usado para teste do sistema e desenvolvimento da documentação Força um estudo detalhado dos requisitos que revela inconsistências e omissões

40 Tipos de Prototipagem Prototipagem descartável Útil para ajudar a elicitação e desenvolvimento dos requisitos. Os requisitos que devem ser prototipados devem ser aqueles que causam mais dificuldades para os clientes e que são mais difíceis de entender. Requisitos que são bem entendidos não precisam ser implementados pelo protótipo. Prototipagem evolucionária Tem como objetivo a entrega rápida de um sistema que funciona para o cliente. Assim, os requisitos que devem ser suportados pela versão inicial do protótipo, são aqueles que estão bem entendidos e que podem prover funcionalidade ao usuário final. Somente após largo uso do sistema é que requisitos que foram pouco entendidos deverão ser implementados

41 Custos e problemas da Prototipagem Custos de treinamento - o desenvolvimento de protótipos pode requerer o uso de ferramentas de propósito especial Custos de desenvolvimento - depende do tipo de protótipo sendo desenvolvido Extensão dos prazos de desenvolvimento - desenvolver um protótipo pode estender o prazo, embora o tempo de prototipagem possa ser recuperado pois o trabalho de correção de erros possa ser evitado Incompletudo - pode não ser possível prototipar os requisitos críticos do sistema

42 Abordagem para prototipagem Prototipagem no papel uma simulação do sistema é desenvolvida em papel usada para experimentação do sistema. Prototipagem executável uma linguagem de quarta geração ou um ambiente de prototipagem rápida é usada para o desenvolvimento de um protótipo executável. e

43 Observação As pessoas geralmente acham difícil descrever o que elas fazem pois isto é muito natural para elas. As vezes, a melhor forma de entende será observá-las no trabalho; Etnografia é uma técnica das ciências sociais que se mostrou útil no entendimento das processos reais realizados nos trabalhos; Os processo reais de trabalho geralmente diferem daqueles processos formais descritos Um etnógrafo passa algum tempo observando as pessoas no trabalho e constrói uma imagem de como o trabalho é realizado.

44 Reuso Reuso envolve considerar requisitos que foram desenvolvidos para um sistema e usá-los em sistemas diferentes; O reuso de requisitos economiza tempo e esforço, pois requisitos reutilizados já foram analisados e validados em outros sistemas; Atualmente o reuso de requisitos é um processo informal. Contudo, um reuso mais sistemático economizaria muito esforço.

45 Reuso Capacidade de se aproveitar análises anteriores que diferencia um analista experiente de um inexperiente; Vantagens: produtividade e qualidade (componentes já validados). Desvantagens: dificuldade de se promover reutilização sem modificação.

46 Problemas no Levantamento Não existir muito tempo para a elicitação; Preparação inadequada dos engenheiros; Stakeholders não estarem convencidos da necessidade de um novo sistema.

47 Validação de Requisitos

48 A validação de requisitos é o processo pelo qual se verifica se os requisitos definem o sistema que o cliente realmente quer. (Sommeville, 2012)

49 1. Verificação de validade; 2. Verificações de consistência; 3. Verificações de completude; 4. Verificações de realismo; 5. Verificabilidade.

50 1. Verificação de validade: Diferentes stakeholders, diferentes necessidades. É necessário um compromisso com os requisitos. 2. Verificações de consistência: Não deve existir conflito entre os requisitos. 3. Verificações de completude: Todas as funções e restrições devem ser contempladas. 4. Verificação de realismo: Os requisitos podem ser implementados? Orçamento e cronograma reais. 5. Verificabilidade: Deve ser possível escrever um conjunto de testes que comprovem que o sistema atende a cada requisito especificado

51 Documentação de Requisitos

52 É um documento formal usado para comunicar os requisitos aos clientes, engenheiros e gerentes. O documento de requisitos descreve: Os serviços e funções que o sistema deve prover; As limitações sobre as quais o sistema deve operar; Propriedades gerais do sistema, isto é limitações nas propriedades emergentes: Confiabilidade Manutenabilidade Desempenho (Performance) Usabilidade Segurança Definições de outros sistemas com o qual o sistema deve se integrar.

53 O documento de requisitos ainda descreve: Limitações nos processos usados para desenvolver o sistema; Descrições sobre o hardware no qual o sistema irá executar. Adicionalmente, deverá sempre conter uma capítulo introdutório que provê um resumo do sistema, necessidades de negócio suportadas pelo sistema e um glossário que explica a terminologia usada.

54 Quem usa o Documento de Requisitos? Clientes do Sistema Especificam os requisitos e os lêem para checar se eles satisfazem suas necessidades. Gerentes de Projeto Usam os documentos de requisitos para planejarem uma proposta para o sistema e o processo de desenvolvimento do sistema. Engenheiros de Sistema Usam os requisitos para entenderem o sistema em construção.

55 Quem usa o Documento de Requisitos? Engenheiros de teste do sistema Usam os requisitos para desenvolverem testes de validação do sistema. Engenheiros de manutenção do sistema Usam os requisitos para entenderem o sistema.

56 Uma vez que requisitos de usuário e de sistema têm propósitos e público alvo diferentes, é útil descrevê-los em documentos diferentes. Pfleeger (2004) sugere que dois tipos de documentos de requisitos sejam elaborados: Documento de definição dos requisitos Documento de especificação dos requisitos

57 Documento de definição dos requisitos Segundo Pfleeger (2004): 1. Em primeiro lugar, esboçamos o propósito geral do sistema. As referências a outros sistemas relacionados são incluídas, e incorporamos quaisquer termos e abreviações que possam ser úteis.

58 2. Em seguida, descrevemos o fundamento e os objetivos de desenvolvimento do sistema; 3. Se o cliente propôs uma nova abordagem para a solução do problema, esboçamos uma descrição da abordagem; 4. Uma vez que registramos a visão geral do problema, descrevemos as características detalhadas do sistema proposto; 5. Finalmente, discutimos o ambiente em que o sistema irá operar. Incluímos os requisitos de suporte técnico, segurança e privacidade, e também quaisquer restrições especiais de hardware ou software que deverão ser contempladas.

59 Documento de especificação dos requisitos O documento de especificação dos requisitos é escrito a partir da perspectiva do desenvolvedor. Redefine os requisitos de usuário em termos mais técnicos, apropriados para o desenvolvimento de software, sendo produzido por analistas de requisitos.

60 Matriz de Rastreabilidade

61 Projeto FACULDADE DOS GUARARAPES CURSO GESTÃO DE TECNOLOGIA Especificação de Requisitos Documento de Requisitos Dupla NOME DO PROJETO Aluno(s) Atenção! Este documento é um modelo e deve ser alterado de acordo com o contexto escolhido no Projeto de Engenharia de Software. Toda parte que estiver entre <> deve ser alterado para o contexto do Projeto. Este é somente um modelo! Documento: Projeto - ES Unidade I FG.doc Disciplina: Engenharia de Software Professor: Aécio Costa Jaboatão dos Guararapes/2013