Engenharia de Software Software Requirements

Transcrição

1 Requisitos Engenharia de Software Software Requirements SWEBOK, Capítulo 2

2 Primeira Classificação de Requisito 1. Requisito do usuário: declarações sobre as funções que o sistema deve oferecer 2. Requisito do sistema: detalhamento das funções e das restrições (contrato entre cliente e desenvolvedor) 3. Requisito do projeto de software: detalha mais o requisito do sistema e serve de base para o projeto e implementação do software.

3 Conceito de Requisito Requisito é uma condição ou capacidade: 1. Necessária para um usuário resolver um problema ou alcançar um objetivo; 2. Para satisfazer uma especificação em um sistema ou em um componente; 3. Com uma representação documentada. Em: The IEEE Standard Glossary of Software Engineering i Terminology, 1997.

4 Ciclo-de-vida dos REQUISITOS Necessidade Definição Gestão Utilização Avaliação

5 Processo de Engenharia de Requisitos Necessidades Informações Elicitação Modelagem Validação Análise Especificação dos Requisitos Aquisição Representações Especificação

6 Algumas Categorias de Requisitos Requisitos de projeto Definem atividades que serão executadas no projeto Requisitos de negócio Objetivos de alto nível requeridos pelos clientes Requisitos de usuário Tarefas que os usuários são habilitados a realizarar Requisitos funcionais Funcionalidade d que o software deve prover: comportamento e propriedade: como o sistema deve se comportar quando recebe um estimulo Requisitos não funcionais Restritivos: limitam as possibilidades de solução e não representam funcionalidade do software

7 Como os Projetos Podem Ter Sucesso? Análise do Problema Entenda o problema Obtenha concordância dos envolvidos Levantamento dos Requisitos Identifique quem usará o sistema (atores) Descubra como o sistema será usado (funcionais) e todas as restrições ao seu funcionamento e desenvolvimento (não funcionais). Gerência de Requisitos Especifique os requisitos completamente Gerencie expectativas, mudanças e erros Controle o aumento do escopo Defina a equipe e a mantenha informada

8 Como o Software pode ter qualidade? A Norma ISO/IEC definem-se seis características de qualidade de software: Funcionalidade (finalidade do produto) Usabilidade d (esforço para utilizar, aprender o produto) Confiabilidade (freqüência de falhas, recuperabilidade) Eficiência (desempenho) Manutenibilidade (esforço necessário para modificar) Portabilidade (capacidade de transferir o produto para outros ambientes)

9 Gerência de Requisitos Atividades de: Acompanhar o desenvolvimento Controlar as mudanças dos requisitos Ações: Planejamento Rastreabilidade Diagnóstico e avaliação da qualidade (dos requisitos) Análise de impacto das mudanças Controle de versões (de requisitos)

10 Principais Atividades da Engenharia de Requisitos

11 Qual a diferença e a relação entre Engenharia de Requisitos e Gerência Requisitos?

12 Qualidade de Requisitos Corretos devem caracterizar um resultado a ser construído Precisos interpretação única Completos incluem todas as especificações decididas Consistentes possíveis e sem conflitos com os demais

13 Qualidade de Requisitos Priorizáveis importância, estabilidade e complexidade Verificáveis possibilidade inequívoca de medição Modificáveis mudanças de maneira fácil, completa e consistente Rastreáveis antecedentes e conseqüências

14 Elicitação dos requisitos Nesta fase o engenheiro de requisitos procura captar os requisitos do software (e do sistema), buscando obter conhecimento do domínio do problema. ELICITAR: descobrir, tornar explícito, obter o máximo de informações para o conhecimento do problema em questão. A elicitação é a tarefa de identificar os fatos relacionados aos requisitos do sistema, de forma a prover o mais correto e mais completo entendimento do que é demandado do software. Atividades principais: identificação das fontes de informação; coleta de fatos e comunicação. Utiliza-se de ferramentas, pessoal qualificado e métodos.

15 Ações para Elicitação dos requisitos Obter informação sobre domínio do problema (organizacionais e operacionais) e sistema atual (se houver): a equipe de levantamento deve conhecer o vocabulário do domínio do negócio. Preparar e realizar reuniões de levantamento e negociação. Identificar e revisar os objetivos do sistema e as informações que o sistema deverá gerir e armazenar. Identificar e revisar os requisitos it funcionais. i Identificar e revisar os requisitos não funcionais.

16 Elicitação Faz Faz Faz Coleta de Fatos Identificação de Fontes Comunicação Faz/Usa F t Usa Usa Depende de Ferramentas Pessoal Métodos e técnicas Pontos de Vista

17 Identificação das Fontes de Informação O que são stakeholders do sistema? Qualquer pessoa afetada de alguma forma pelo sistema (atores, cliente, usuário final, desenvolvedor) A análise dos stakeholders ajuda a determinar o impacto que um novo sistema de informação terá.

18 Identificação das Fontes de Informação Outras fontes de Informação: Documentação do macro-sistema Políticas Manuais Memorandos, atas, contratos Livros sobre tema relacionado Outros sistemas da empresa Sistemas externos

19 Identificação das Fontes de Informação Importante Priorizar as Fontes de Informação. Descubra: Atores mais importantes Documentos mais mencionados Rede de comunicação entre os componentes do macro-sistema Relações informais

20 Comunicação Entre Clientes e os Engenheiros de Software Apresentação: A forma como a informação é apresentada Entendimento: Estabelecimento de contextos comuns. Ex. Planta; Ordem de 5,10,2,9,8,4,6...,,,,, Linguagem Nível de Abstração Retro-alimentação

21 Apresentação Diferentes e esformas de apresentação ação ajudam ou dificultam o entendimento. Distribuição ib i de Vendas Perce entual 45% 40% 35% 30% 25% 20% 15% 10% 5% 0% Produto A Produto B Produto C Produto D Distribuição de Vendas Produto A 15% Produto B 40% Produto C 20% Produto D 25%

22 Entendimento A comunicação pode ser ruidosa se os indivíduos estiverem dialogando em diferentes níveis de abstração. Conflito presente entre generalistas e especialistas. Exemplo: Devemos conquistar mercados (Diretoria) X Distribuir os vendedores (Gerência de Vendas)

23 Linguagem A linguagem é reflexo da cultura de uma sociedade. Para entendermos algo de importante para uma sociedade temos que entender sua linguagem. Deve-se compreender a linguagem g antes de elicitar as necessidades. Exemplos Conta-mãe, Dzero, Fecha a mesa, Passagem de Resultados, Zipar, FTP, TCP/IP

24 Retroalimentação Obrigar o receptor da informação a recolocar a comunicação até que o emissor responda positivamente a recolocação. Resumir,,p parafrasear, confirmar. a? a

25 Técnicas de Levantamento Entrevistas Questionários Observação / Visitas instalações (próprias ou outras) Demonstrações Pesquisa externa Análise da Documentação Joint Application Design (JAD) IBM Brain Storm Brain Writing

26 JAD - Joint Application Development Processo Usuários e desenvolvedores INTRODUÇÃO DO trabalham juntos em uma TEMA reunião com o objetivo de: identificar o problema APRESENTAÇÃO DE EXEMPLOS propor elementos de solução negociar diferentes abordagens especificar um conjunto preliminar de requisitos de solução Envolve: preparação para reunião a partir de uma requisição geral do produto reunião DISCUSSÃO CONSENSO DOCUMENTAÇÃOO PENDÊNCIA IMPASSE

27 Questionários 1. Fontes sólidas e confiáveis 2. Objetivo, dirigido e diferenciado 3. Ênfase em aspectos quantitativos

28 Análise Documental Estudo dos registros existentes (documentos e relatórios, atuais ou históricos). A áli d i f õ i Análise das informações em meio magnético (discos, fitas)

29 Entrevistas t Obtenção de informações: atitudes, comportamento, fatos vivenciados, tendências e experiências Informações sobre a empresa, atividades e a funções Visão mais concreta da realidade Coordenação de informações recebidas de fontes diversas Ênfase nos aspectos qualitativos ti

30 A entrevista - Forma mais comum: pessoal / direta - Documentação dos resultados: copiar tudo? gravar? filmar? realizar anotações? - Pessoas certas que estão nos locais certos - Perguntas certas, respostas certas - Seqüência dos entrevistados - Planejamento do tempo - Coleta prévia de dados

31 Entrevistas Procedimentos preliminares - Planejar a entrevista: objetivo, perguntas e tempo - Escolher o local: privacidade é essencial - Agendar a entrevista, informando o entrevistado da agenda -Obter informações sobre as características pessoais e funcionais do entrevistado

32 Durante a entrevista - Apresentar-se - Repassar a agenda (objetivos, patrocinador, motivo da escolha do entrevistado) - Postura do entrevistador: credibilidade, isenção, discrição; não criar ressentimentos - Deixar o entrevistado falar (redução da interferência) - Direcionar a discussão para os objetivos - Evitar perguntas fechadas - Não ultrapassar o tempo - Notar sinais de impaciência

33 Um estilo para entrevistar - Relacione a parte da entrevista c/ partes do sistema - Obtenha pontos de vista alternativos - Solicite detalhes do item que você estiver interessado - Estabeleça a dependência do assunto com outros - Confirme os dados obtidos - Focalize os requisitos (não os problemas técnicos)

34 Problemas com que lidamos Você está tomando tempo demais Você está ameaçando meu emprego Você não conhece a nossa empresa Você está tentando mudar o modo que as coisas são feitas aqui Não queremos esse sistema Mudei de opinião Aqui não há consenso de como a coisa deve ser feita Já tentaram fazer isso antes Você que está criticando, não estava aqui quando foi feito

35 Brainstorm Reunião onde todos têm liberdade de expressar suas opiniões Nenhuma crítica prévia deve ser feita São válidas colocações por impulso: o que vale é a quantidade de idéias Relacionadas as idéias, passa-se para a interpretação dos resultados

36 Brainwriting iti Dividir os participantes em grupos de 4 ou 5 pessoas Os grupos recebem uma questão O trabalho Escrever a sua opinião sobre a questão Ao terminar, colocar a folha no centro da mesa Pegar a folha de respostas de outro integrante do grupo Criticar as colocações encontradas

37 Brainwriting Criticar todos os trabalhos do grupo, por escrito Completado o ciclo, o grupo pode receber nova pergunta O presentes criticam todas as posições dos grupos Obs: Pode haver um relator por grupo Cada grupo pode receber uma questão diferente Exige um relator do trabalho final