ENGENHARIA DE SOFTWARE

Transcrição

1 ENGENHARIA DE SOFTWARE Engenharia de Requisitos Tipos de requisitos de software Técnicas de elicitação e análise de requisitos Validação e gerenciamento de requisitos Kele Teixeira Belloze kelebelloze@gmail.com

2 TUDO COMEÇA COM A DEFINIÇÃO DOS REQUISITOS The IEEE Standard Glossary of Software Engineering Terminology [IEEE97] define requisito como uma condição ou capacidade necessária para um usuário resolver um problema ou alcançar um objetivo (...). Desta definição pode-se aferir que os requisitos de software são derivados de necessidades que usuários têm em resolver algum problema. Situa-se, então, o domínio do problema.

3 ENGENHARIA DE REQUISITOS A engenharia de requisitos é a disciplina que procura sistematizar o processo de definição de requisitos. Aborda um ponto fundamental do desenvolvimento de software: a definição do que produzir. A engenharia de requisitos tem sido identificada como uma fase crucial por tratar de conhecimentos não apenas técnicos, mas também gerenciais, organizacionais, econômicos e sociais, e estar intimamente associada a qualidade do software.

4 DIFICULDADE DE COMUNICAÇÃO Dificuldade de comunicação realmente existe? Vamos averiguar? 4

5 5

6 NECESSIDADE DO CLIENTE? Requisitos Solicitação do Cliente: Uma cadeira com quatro pernas, um assento, encosto para as costas e braços. 6

7 COM A ESPECIFICAÇÃO DADA, COMO SABER QUAL CADEIRA O CLIENTE DESEJA? Desejo do Cliente

8 DOMÍNIOS DA ENGENHARIA DE REQUISITOS

9 9 Domínio do Problema Universo de Informações Domínio da Solução

10 Universo da Informações A especificação de requisitos deve incluir não somente as especificações do domínio do problema, mas também qualquer tipo de informação que descreva o contexto do sistema. Esse contexto é conhecido como universo de informações, que é a realidade circunstanciada pelo conjunto de objetivos definidos pelos que demandam o software, e inclui todas as fontes de informação e todos os stakeholders.

11 Domínio do Problema O domínio do problema é o domínio de atuação do software e inclui todos os elementos que interagem com ele. Neste ambiente principiam as atividades da engenharia de software, a definição das necessidades do software. É tarefa dos engenheiros de requisitos entender o problema, na cultura e linguagem dos usuários, e definir um sistema que atenda às suas necessidades.

12 Domínio da Solução No domínio da solução é enfocada a definição da solução aos problemas dos usuários. Os desenvolvedores do software aplicam seus conhecimentos em busca da especificação do sistema a ser desenvolvido. Envolve as características da solução e os requisitos do sistema. Uma vez estabelecido o conjunto de características com a concordância dos stakeholders, deve-se definir os requisitos mais específicos que serão necessários impor a solução.

13 CLASSIFICAÇÃO DOS REQUISITOS

14 CLASSIFICAÇÃO DOS REQUISITOS (1/4) Funcionais: representam os comportamentos que um programa ou sistema deve apresentar diante de certas ações de seus usuários. Não-funcionais: quantificam determinados aspectos do comportamento. (Ex: tempo de resposta, tempo médio entre falhas, etc.).

15 Regras de Negócio: é toda norma ou tudo aquilo que a lei ou uso comum determina a respeito de qualquer transação que envolve uma determinada organização. Por tanto, regra de negócio é uma diretriz destinada a regulamentar o comportamento do negócio. CLASSIFICAÇÃO DOS REQUISITOS (2/4) Segundo Summerville (2007) Requisitos de Usuário: descrevem os requisitos funcionais e não-funcionais de modo que eles sejam compreensíveis pelos usuários do sistema que não possuem conhecimento técnico detalhado. Requisitos de Sistema: são versões expandidas dos requisitos do usuário. Requisitos de Domínio: são derivados do domínio da aplicação do sistema, em vez das necessidades dos usuários do sistema. Segundo Eduardo Bezerra (2007) Requisitos Normativos: restrições impostas sobre o desenvolvimento do sistema. Exemplo: restrições de custo, prazos e também as regras de negócio. The Businness Rules Group

16 CLASSIFICAÇÃO DOS REQUISITOS (3/4) EXEMPLOS: Requisitos Normativos - Regras de Negócio Uma conta não pode ter saldo negativo. Um time não pode ter mais que 11 jogadores em campo. Se uma conta tiver saldo maior que 5.000, enviar folheto sobre investimentos. Saldo é igual a crédito menos débito Uma conta é Ouro Especial se seu saldo atual é superior a e seu saldo médio é superior a Requisitos de Usuário: O LIBSYS deve fornecer um sistema de contabilidade financeira que mantenha registros de todos os pagamentos realizados pelos usuários do sistema. Os gerentes podem configurar este sistema de modo que os usuários frequentes possam receber descontos. Requisitos de Domínio: A desaceleração do trem deve ser calculada como: D trem = D controle + D gradiente

17 CLASSIFICAÇÃO DOS REQUISITOS (4/4) EXEMPLOS: Requisitos de Sistema Bomba de insulina/software de controle/srs/3.3.2 Função Descrição Calcular dose de insulina: nível seguro de açúcar Calcula a dose de insulina a ser liberada quando o nível medido de açúcar atual está na zona segura entre 3 e 7 unidades Entradas Leitura atual de açúcar (r2), as duas leituras anteriores (r0 e r1) Origem Saídas Destino Leitura atual de açúcar do sensor. Outras leituras de memória CompDose a dose de insulina a ser liberada Loop de controle principal Ação: CompDose será zero se o nível de açúcar estiver estável ou em queda, ou se o nível estiver aumentando, mas a taxa de aumento estiver diminuindo. [...] então CompDose será definido como a dose mínima que pode ser liberada. Requer Duas leituras anteriores de modo que a taxa de mudança do nível de açúcar possa ser calculada. Precondição O reservatório de insulina conter, pelo menos, o máximo de dose única permitida de insulina. Pós-condição R0 é substituído por r1, portanto r1 é substituído por r2. Efeitos colaterais Nenhum.

18 REQUISITOS FUNCIONAIS Os requisitos funcionais definem as ações fundamentais através das quais o produto aceita e processa as entradas especificadas, gerando as respectivas saídas. Exemplo: Identificação Nome Sumário Ator RF01 Manter mercadoria O Gerente de Compras atualiza o cadastro (inclusão, alteração, exclusão e consulta) das mercadorias. Gerente de Compras RF02 Registrar pedido de compra O Caixa registra o pedido de compra do cliente informando, para cada produto, a sua quantidade. Caixa RF03 Cancelar pedido de compra O Supervisor cancela um pedido de compra que ainda não foi entregue, informando o motivo do cancelamento. Supervisor RF04 Abrir caixa O Caixa dá início às operações do seu trabalho. Caixa RF05 Fechar caixa O Caixa encerra as operações do seu trabalho. Caixa

19 REQUISITOS NÃO-FUNCIONAIS (1/4) Os requisitos não funcionais podem ser classificados segundo a seguinte estrutura hierárquica Requisitos Não Funcionais Requisitos do produto Requisitos organizacionais Requisitos externos Requisitos de facilidade de uso Requisitos de confiabilidade Requisitos de portabilidade Requisitos de interoperabilidade Requisitos éticos Requisitos de eficiência Requisitos de entrega Requisitos de padrões Requisitos legais Requisitos de desempenho Requisitos de espaço Requisitos de implementação Requisitos de privacidade Requisitos de segurança

20 REQUISITOS NÃO-FUNCIONAIS (2/4) REQUISITOS DO PRODUTO: são os requisitos que especificam o comportamento do produto. Requisitos de facilidades de uso: estabelece o esforço para utilizar, aprender o produto. Exemplo: A função de digitação de notas fiscais deve minimizar o uso do mouse a fim de aumentar a produtividade. Requisitos de espaço: quanto de memória o sistema requer. Exemplo: O software deve ocupar no máximo x de memória para que possa ser executado em tablets. Requisitos de desempenho: com que rapidez o sistema deve operar. Exemplo: A consulta ao histórico de pagamentos de um cliente não deve ser superior a 5 segundos. Requisitos de confiabilidade: estabelecem a taxa aceitável de falhas. Exemplo: O software deve possuir uma disponibilidade 24x7. Requisitos de portabilidade: capacidade do produto ser transferido para outros ambientes. Exemplo: O software deve utilizar linguagem SQL padrão ANSI-92.

21 REQUISITOS NÃO-FUNCIONAIS (3/4) REQUISITOS ORGANIZACIONAIS: são procedentes de políticas e procedimentos nas organizações do cliente e do desenvolvedor. Requisitos de entrega: especificam quando o produto e seus documentos devem ser entregues. Exemplo: O software deve estar em produção até abril de Requisitos de implementação: especificam restrições para a implementação. Exemplo: O software deve ser construído na plataforma J2EE. Requisitos de padrões: especificam os padrões e métodos que devem ser seguidos para o desenvolvimento do sistema. Exemplo: Para o desenvolvimento do sistema deve-se utilizar a metodologia SCRUM.

22 REQUISITOS NÃO-FUNCIONAIS (4/4) REQUISITOS EXTERNOS: abrange todos os requisitos procedentes de fatores externos ao sistema e a seu processo de desenvolvimento. Requisitos de interoperabilidade: definem como o sistema interage com sistemas em outras organizações. Exemplo: O sistema deve ser capaz de gerar os dados das notas fiscais para exportação para a base de dados do SINTEGRA.* Requisitos de privacidade: especialização dos requisitos legais. Exemplo: Os gerentes não podem visualizar a movimentação bancária de clientes VIP que não estejam sob sua responsabilidade. Requisitos de segurança: especialização dos requisitos legais, que são requisitos que devem ser seguidos para assegurar que o sistema funciona de acordo com a lei. Exemplo: O acesso aos módulos do software deve ser restrito por grupo de usuários. Requisitos éticos: definidos para garantir que este será aceitável para seus usuários e o público geral. Exemplo: O histórico clínico do paciente só deve estar disponível para o médico. *Sistema Integrado de Informações sobre Operações Interestaduais com Mercadorias e Serviços

23 ATIVIDADES DA ENGENHARIA DE REQUISITOS

24 ATIVIDADES DA ENGENHARIA DE REQUISITOS (1/6) Fonte: CPRE-FL Quick Guide

25 ELICITAÇÃO (2/6) Fontes Principais Stakeholders Clientes Usuários Desenvolvedores Documentos Livros Sistemas de software (específico da organização ou software comercial)

26 ELICITAÇÃO (3/6) Métodos de Coleta de Requisitos Algumas técnicas das ciências sociais, como psicologia e sociologia, têm sido estudadas e utilizadas nesta atividade, que envolve fatores comportamentais e de relacionamento humano. Entre os métodos mais comuns estão: análise de documentos; entrevistas (tutoriais, estruturadas, não-estruturadas, semi-estruturadas); reuniões (Participatory Design, Joint Application Design e Brainstorming); observação e etnografia; prototipação; questionários.

27 Exemplo de especificação de requisitos: arquivo Template para especificação de requisitos - Merci_10_ERSw Referência: Engenharia de Requisitos, Profª Carmen Asp CEFET/RJ DOCUMENTAÇÃO ESPECIFICAÇÃO DE REQUISITOS (4/6) A especificação de requisitos visa descrever de maneira sistemática quais propriedades o software terá que ter para resolver o problema do domínio. A especificação é também a forma de comunicação sistemática entre analistas e projetistas do software. O documento de especificação de requisitos além de conter uma parte textual, costuma conter diagramas que representem determinados aspectos do sistema de software.

28 VERIFICAÇÃO E VALIDAÇÃO DE REQUISITOS (5/6) Verificação (definição IEEE) Confirmar por testes e com provas objetivas que os requisitos especificados foram cumpridos. Garante que os produtos de uma dada fase implementam em sua totalidade as entradas para aquela fase ou seja o produto foi construído corretamente. Validação (definição IEEE) Confirmar por testes e com provas objetivas que requisitos particulares para um determinado uso foram cumpridos. Prova que o software implementa cada um dos requisitos corretamente e completamente ou seja, o produto correto foi construído. Como obter Verificação e Validação com provas objetivas? TESTES

29 GERENCIAMENTO DE REQUISITOS (6/6) O gerenciamento de requisitos é um processo para compreender e controlar as mudanças dos requisitos. Durante o processo de desenvolvimento, o entendimento dos stakeholders sobre o problema muda constantemente. Após o desenvolvimento do produto, muito provavelmente, surgirão novos requisitos.

30 GERENCIAMENTO DE REQUISITOS (6/6) Rastreabilidade de Requisitos Existem vários relacionamentos entre os requisitos e entre os requisitos e o projeto do sistema. Existem também ligações entre requisitos e motivos básicos do por que esses requisitos foram propostos. Quando as mudanças são propostas, você deve rastrear seu impacto em outros requisitos e no projeto do sistema. A rastreabilidade é a propriedade de uma especificação de requisitos que reflete a facilidade de encontrar os requisitos relacionados. A rastreabilidade permite um maior controle sobre os artefatos gerados ao longo do desenvolvimento facilitando sua manutenção e análise de impacto a partir de solicitações de alteração.

31 TÉCNICAS PARA ELICITAÇÃO DE REQUISITOS - Levantamento de requisitos orientado a pontos de vista - Cenários

32 LEVANTAMENTO DE REQUISITOS ORIENTADO A PONTOS DE VISTA () Para qualquer sistema, normalmente, há diferentes tipos de usuário final. Por esse motivo, existem muitos pontos de vista diferentes que devem ser considerados. Os diferentes pontos de vista a respeito de um problema vêem o problema de modos diferentes. Contudo, suas perspectivas não são inteiramente independentes, mas em geral apresentam alguma duplicidade, de modo que apresentam requisitos comuns. As abordagens orientadas a ponto de vista, na engenharia de requisitos, reconhecem esses diferentes pontos de vista e os utilizam para estruturar e organizar o processo de levantamento e os próprios requisitos.

33 LEVANTAMENTO DE REQUISITOS ORIENTADO A PONTOS DE VISTA () O método VORD (viewpoint-oriented requirements definition definição de requisitos orientada a ponto de vista) foi projetado como um framework orientado a serviço para o levantamento e análise de requisitos. Nessa etapa os analistas se reúnem com os stakeholders e utilizam a abordagem de brainstorming para identificar os serviços em potencial e as entidades que interagem com o sistema. Envolve agrupar pontos de vista relacionados, segundo uma hierarquia. Serviços comuns estão localizados nos níveis mais altos da hierarquia e herdados por pontos de vista de nível inferior. A etapa de documentação do ponto de vista tem por objetivo refinar a descrição dos pontos de vista e serviços identificados. Envolve identificar objetos em um projeto orientado a objetos, utilizando as informações de serviço que estão encapsuladas nos pontos de vista.

34 LEVANTAMENTO DE REQUISITOS ORIENTADO A PONTOS DE VISTA () Exemplo de hierarquia de ponto de vista: Serviços Consultar saldo Retirar dinheiro Cliente Todos os pontos de vista Pessoal do banco Serviços Pedir cheques Enviar mensagem Executar transação da lista Pedir extrato Transferir fundos Titular da conta Não-titular da conta Caixa Gerente Engenheiro

35 CENÁRIOS Cenários são estórias que explicam como um sistema poderá ser usado. Cada cenário aborda um ou um pequeno número de possíveis interações. O cenário geralmente começa com um esboço da interação e, durante o levantamento de requisitos, são acrescentados detalhes para criar uma distribuição completa dessa interação. O cenário pode incluir: uma descrição de estado do sistema no início do cenário; uma descrição do fluxo normal de eventos no cenário; uma distribuição do que pode sair errado e de como lidar com isso; informações sobre outras atividades que possam estar em andamento ao mesmo tempo; uma descrição do estado do sistema no final do cenário.

36 ANÁLISE DE DOCUMENTOS A análise de documentos é uma técnica usualmente aplicada na qual explora-se o conhecimento escrito encontrado no universo de informações. A análise dos documentos permite um contato com o vocabulário utilizado no domínio do problema e auxilia na construção do glossário de termos especializados, que tem por objetivo definir os objetos e equalizar o conhecimento dos stakeholders.

37 ENTREVISTAS Entrevistas tutoriais: o entrevistado fica no comando, praticamente lecionando sobre um determinado assunto. Entrevistas informais (não estruturadas): o entrevistador age espontaneamente, perguntando ao entrevistado sem obedecer a nenhuma organização. Esse tipo de entrevista oferece flexibilidade ao entrevistador e, normalmente, é utilizado no início do processo de elicitação. Entrevistas estruturadas: são preparadas pelo entrevistador, que define previamente o andamento do procedimento de aquisição de conhecimento. Entrevistas semi-estruturadas: são entrevistas que misturam as características das entrevistas estruturadas e das entrevistas não estruturadas. Um fator importante a ser considerado nas entrevistas é o registro das informações coletadas, que pode ser realizado através de anotações ou gravações de áudio ou vídeo. O material produzido deve ser organizado e serve como base para a preparação da próxima entrevista.

38 PIECES TÉCNICA PARA EXTRAÇÃO DE REQUISITOS P - Desempenho (ou performance): quantidade de tarefas executadas em um intervalo de tempo. Exemplo: Quantos atendimentos são efetuados por dia? Quantos usuários utilizam o sistema por turno? Quantos pedidos são efetuados em uma hora? I - Informação e Dados: as informações a serem acessadas pelos usuários devem ser exatamente as que eles necessitam. Exemplo: A relação de funcionários da empresa é fornecida em que intervalo de tempo? Todos os dados de cada item do pedido devem constar da nota fiscal? E - Economia: o nível de serviço e a capacidade de lidar com alta demanda. Exemplo: Você recebe um maior número de pedidos em determinada época do mês ou do ano? Existe um horário em que o registro de reclamações aumenta? C - Controle: o software é desenvolvido para funcionar de maneira prevista. Exemplo: Todos os usuários têm acesso irrestrito à base de dados do sistema? Aos usuários deverá ser requisitada autorização de acesso? E - Eficiência: redução da perda de recursos. Exemplo: Todas as funções se utilizarão deste dado? Você vai entrar com esse valor uma única vez? S - Serviços: um software é desenvolvido para prestar serviços ao usuário ou a outro software. Definir quais são esses serviços. Exemplo: O software emite ordem de serviço? O software controla o estoque em tempo real?

39 PARTICIPATORY DESIGN É uma abordagem que concentra-se mais fortemente no envolvimento dos usuários, em relação ao Joint Application Design, por facilitar o processo de aprendizado entre desenvolvedores e usuários através de experiências conjuntas em situações de trabalho simuladas. Em linhas gerais, os usuários são introduzidos no ambiente dos desenvolvedores, conhecendo possibilidades técnicas e, da mesma maneira, os desenvolvedores colaboram com os usuários em suas tarefas. Ocorre um aprendizado mútuo que vem a contribuir no processo de definição dos requisitos.

40 BRAINSTORMING A filosofia básica do brainstorming é procurar deixar que venham a tona todas as idéias possíveis, sem que estas sofram quaisquer críticas durante o processo de criação. Isto diminui os bloqueios, e permite que as idéias fluam melhor. Isto faz com que o inconsciente comece a desbloquear parte do raciocínio nãológico que estava bloqueado e, quando bem aplicado, seja um poderoso instrumento de trabalho. Nesta reunião, a característica principal é a total ausência de crítica e o julgamento adiado. As ideias que surgirem serão anotadas, por mais loucas que possam parecer, e nunca sofrerão críticas na hora em que forem formuladas.

41 FAST (FACILITATED APPLICATION SPECIFICATION TECHNIQUES) Estimula a criação de uma equipe conjunta de clientes e desenvolvedores e tem algumas diretrizes: Encontros em locais neutros Regras para participação Agenda formal para cobrir os pontos importantes e informal para encorajar o fluxo de ideias Um moderador Mecanismos de definição Após o encontro, desenvolvedores e clientes escrevem a requisição do produto com uma lista de objetos, suas restrições e desempenho, podendo ser feitas mini especificações.

42 JAD - JOINT APPLICATION DESIGN Baseia-se em sessões estruturadas e disciplinadas, onde os envolvidos (representantes de todas as áreas relacionadas com os assuntos em discussão) reúnem-se para desenvolver juntos o sistema de software. O produto final é um documento que contém definições do produto/software. É uma abordagem popular da técnica FAST.

43 JAD - JOINT APPLICATION DESIGN As regras da sessão: Todos os participantes são iguais. Apenas uma pessoa fala de cada vez. Todas as opiniões são válidas. Hora para começar, interromper e terminar. Celular desligado. Recursos visuais.

44 PROTOTIPAÇÃO A prototipação é uma técnica valiosa para se obter rapidamente informações específicas sobre requisitos de informação do usuário. Protótipo é um produto que... não tem tempo de vida definido; pode servir a múltiplos propósitos; deve ser construído rapidamente e com baixo custo; é parte integrante de um design centrado no usuário, para avaliação e modificação. Definir objetivos e requisitos de informação Avaliar protótipo - Usuário - Construir/Revisar protótipo

45 PROTOTIPAÇÃO A prototipação permite capturar os seguintes tipos de informação: Reações iniciais do usuário: como o usuário se sente em relação ao sistema em desenvolvimento? Obs.: Reações ao protótipo podem ser obtidas através da observação, entrevistas, questionário ou relatório de avaliação. Sugestões do usuário para refinar ou alterar o protótipo: guiam na direção de melhor atender as necessidades dos usuários. Inovações: novas capacidades, não imaginadas antes da interação com o protótipo. Informações para revisão de planos: estabelecer prioridades e redirecionar planos.

46 QUESTIONÁRIO Deve ser preparado antecipadamente com questões objetivas (múltipla escolha). A desvantagem deste modelo em relação a Entrevista é a comunicação restrita com o usuário. A preparação do questionário exige tempo e atenção. Perguntas mal feitas podem levar a resultados não desejados. Utilização conjunta de Questionários e Entrevistas Refinar respostas não claras de um questionário em uma entrevista; Projetar um questionário com base no que foi levantado em uma entrevista.

47 TÉCNICA DE OBSERVAÇÃO Observação é uma técnica na qual o engenheiro de requisitos procura ter uma posição sobre o domínio do problema, observando seus elementos e comportamentos. As observações consistem em observar alguém no momento da realização de suas tarefas rotineiras no ambiente real. O observador procura familiarizar-se com o domínio do problema e elicitar as informações necessárias para o seu entendimento. A aquisição desse conhecimento pode ocorrer com interrupção ou não das atividades do observador.

48 ETNOGRAFIA Etnografia é a coleta direta, e o mais minuciosa possível, dos fenômenos observados, por uma impregnação duradoura e contínua e um processo que se realiza por aproximações sucessivas. É originária da antropologia, em observações de práticas das sociedades. No contexto da engenharia de requisitos, é uma técnica de observação que busca revelar informações sobre a estrutura, organização e práticas do domínio do problema. A etnografia pode levar a obtenção de requisitos fechados à prática corrente, o conhecimento tácito.

49 REFERÊNCIA Carmen Asp de Queiroz. Engenharia de Requisitos. CEFET-RJ SOMMERVILLE, Ian, Engenharia de Software, 9 a edição, São Paulo: Pearson Education Addison-Wesley, 2011.