Engenharia de Requisitos: Software Orientado ao Negócio Guilherme Siqueira Simões 31/01/2017 1
MISSÃO Apoiar nossos clientes a ter mais visibilidade do desempenho de seus processos de software e a estabelecer modelos de negócios em que eles tenham o controle sobre os mesmos. DIRECIONAMENTO ESTRATÉGICO COM: Estimativas e Medição de Projetos de Software Implantação da Análise de Pontos de Função (IFPUG, NESMA, COSMIC) Auditoria de Medições de Projetos de Software Medidos com APF Benchmarking e Análises de produtividade Avaliação para Melhoria dos Processos de Software Engenharia de Requisitos Planejamento e avaliação do desempenho (Escopo, Esforço, custo, prazo, qualidade) Construção e Monitoramento de Contratos de Software baseados em Resultados Integração do Desenvolvimento Ágil com a Governança Corporativa de TI usando Métricas Funcionais 2
FORMAÇÃO PROFISSIONAL APF: Fundamentos, Benefícios e Implantação 8 horas (EAD e presencial) Preparação para o Exame CFPS 96 horas (EAD e presencial) Preparação para o Exame COSMIC 16 horas (EAD e presencial) Estimativa de Projetos de Software: Fundamentos e Técnicas 16 horas Capacitação em APF: Medição e Estimativa de Software 16 horas (EAD e presencial) Medição e Estimativa de Software com o Método COSMIC 16 horas (Presencial) Engenharia de Requisitos de Software 24 horas Introdução ao Gerenciamento de Projetos 16 horas Workshop APF: Metodologia e Práticas de Medição 16 horas (Presencial) Oficina de Contagem de Pontos de Função Sessões de 8 ~ 40 horas Oficina de Requisitos Sessões de 8 ~ 40 horas Gestão de Riscos em Projetos 16 horas Mais de 14.000 alunos capacitados O livro mais vendido de APF no país foi escrito por nós Formou >25% dos CFPS no Brasil 3
4
Objetivos desta apresentação O que é Engenharia de Requisitos A importância da Engenharia de Requisitos Por que orientado ao negócio? O que é requisito de software Os tipos de requisitos Os grupos de atividades da Engenharia de Requisitos 5
A Engenharia de Requisitos como parte da Engenharia de Software Engenharia de Software (1) a aplicação de uma abordagem sistemática, disciplinada, quantificável para o desenvolvimento, operação e manutenção de software, ou seja a aplicação de engenharia ao software. (2) o estudo de abordagens como em (1). 6
As estratégias de desenvolvimento organizam-se a partir das disciplinas Disciplinas são categorias que agregam atividades similares. Não há ordem entre as disciplinas. 7
Esforço por Disciplina no Processo Unificado 8
O que é Engenharia de Requisitos Disciplina da Engenharia de Software que consiste no uso sistemático e repetitivo de técnicas para cobrir atividades de Obtenção, Documentação, Manutenção de um conjunto de requisitos para software que atendam aos objetivos de negócio e sejam de qualidade* * Veja youtu.be/d8xmsaer2f4 9
Causas de fracasso em projetos* 47% dos projetos fracassados tem como causa gestão de requisitos deficiente Sintomas diretos ou indiretos desta deficiência: Scope Creep Comunicação deficiente Baixo envolvimento de partes interessadas e Suporte inadequado do patrocinador Organizações de baixo desempenho desperdiçam quase 10 vezes mais que as de alto desempenho *PMI s Pulse of the Profession: Requirements Management A Core Competency for Project and Program Success - 2014 10
Origem dos defeitos Em um estudo mais recente, Capers Jones afirma que 20% dos defeitos têm origem no trabalho de requisitos Software Defects Origins and Removal Methods Capers Jones - 2014 ~40% do orçamento total dos projetos é gasto em retrabalho. Em projetos maiores, ~50% Encontrar e corrigir erros originados em requisitos consome entre 70 e 85% do custo total de retrabalho do projeto em função de sua quantidade e efeito multiplicativo 11
Custo de reparo de defeitos conforme o ponto que surgem Custo unitário para detectar e reparar um erro durante a codificação Leffingwell, D; Calculating the Return on Investment from More Effective Requirements Management ; American Programmer 10(4); 13-16; 1997. Software Defect Reduction Top 10 List Barry Boehm y Victor Basili - 2001 12
Definição de Requisito ISO/IEC/IEEE 24765 (1) uma condição ou capacidade necessária por um usuário para resolver um problema ou alcançar um objetivo. (2) uma condição ou capacidade que deve ser atingida ou possuída por um sistema ou componente de um sistema para satisfazer um contrato, padrão, especificação ou outro documento formalmente imposto (3) uma representação documentada de uma condição ou capacidade como em (1) ou (2)...ou Especificação de Requisitos desejo (projeto) produto Documentação das capacidades do projeto ou produto 13
Refinamento Nível de Informação Tipos de Requisito o quê Funcionais Não Funcionais como requisitos da solução fundamentados por requisitos de transição fundamentados por requisitos das partes interessadas fundamentados por requisitos (ou necessidades) de negócio porque Domínio da Solução Domínio do Problema 14
Requisitos de Negócio ou: razões pelas quais um projeto é iniciado A contínua mudança no equilíbrio entre as forças em que a organização está inserida cria novas necessidades de negócio Problemas a serem resolvidos Oportunidades a serem aproveitadas Relacionadas a Alterações que se deseja operar Manutenção das condições atuais Descrevem metas e objetivos que uma organização pretende atingir Definem métricas usadas para medir o sucesso do projeto Ex.: Reduzir 90% da devolução de cartas por endereço incompleto (problema) Ex.: Aumentar 20% da receita do produto A com serviços em mobile (oportunidade) 15
Requisitos de Negócio E daí? Atender aos requisitos de negócio é o que satisfaz ao cliente Quando se conhece os reais requisitos de negócio, há mais liberdade para se imaginar possíveis soluções para o problema Os requisitos de negócio ajudam a priorizar os projetos Os requisitos de negócio norteiam toda a Engenharia de Requisitos São o ponto de partida do trabalho do analista de requisitos Ajudam a perceber qualquer desvio de escopo durante o levantamento e análise dos requisitos Todos os requisitos da solução devem estar relacionados a ao menos um dos requisito de negócio 16
Refinamento Nível de Informação Requisitos das Partes Interessadas o quê Funcionais Não Funcionais como requisitos da solução fundamentados por requisitos de transição fundamentados por requisitos das partes interessadas fundamentados por requisitos (ou necessidades) de negócio porque Domínio da Solução Domínio do Problema 17
Requisitos das Partes Interessadas Descrevem necessidades e como será a interação de uma parte interessada com a solução Registrados em memórias de levantamento, em geral de forma não estruturada (gravações, atas, notas, etc.) Produto do trabalho de Elicitação de Requisitos Ponte entre os requisitos de negócio e os da solução O conjunto dos requisitos das partes interessadas pode ter Requisitos similares podem ser unificados Requisitos em conflito devem ser resolvidos Matéria prima para a Análise de Requisitos 18
Refinamento Nível de Informação Requisitos de Solução e Transição o quê Funcionais Não Funcionais como requisitos da solução fundamentados por requisitos de transição fundamentados por requisitos das partes interessadas fundamentados por requisitos (ou necessidades) de negócio porque Domínio da Solução Domínio do Problema 19
Requisitos de Transição Necessários para a transição da solução atual para a nova solução entrar plenamente em operação Diferem dos demais tipos de requisitos pois são relevantes apenas durante o período de transição da solução atual para a nova. Ou seja, são descartados após o projeto, têm caráter temporário Ex.: Os dados de contrato deverão ser migrados do sistema legado para o novo sistema 20
Requisitos da Solução e Transição Os requisitos da solução e da transição subdividem-se em o quê Funcionais Não Funcionais como Descrevem o quê o software faz: processos ou tarefas da solução (e da transição) que suportam uma prática ou procedimento de uma parte interessada Expressam atributos ou restrições inerentes aos requisitos funcionais e como eles serão atendidos 21
Requisitos Funcionais Descrevem o quê a solução (ou transição) deve fazer em termos das tarefas ou serviços do usuário, sem abordar sua implementação Exemplos Efetuar gestão dos cursos Emitir certificado de participação do aluno no curso Somente alunos com frequência 75% podem emitir seu certificado Percebam que estes 3 requisitos funcionais tem diferentes níveis de objetivo (ou granularidade) 22
Níveis de Objetivo dos RFs (Granularidade) Writing Effective Use Cases, Alistair Cockburn 23
Requisitos Não Funcionais O que Abordam COMO as funcionalidades serão oferecidas ao usuário Incluem aspectos relacionados a Qualidade: usabilidade, confiabilidade, eficiência, portabilidade, facilidade de manutenção Implementação: plataforma de software, hardware, linguagem de programação. Ambiente: interoperabilidade, segurança, privacidade, sigilo Organização: locais para operação, hardware alvo, aderência a padrões. Exemplo de padrões no governo federal: Padrões Web em Governo Eletrônico e-pwg Modelo de Acessibilidade de Governo Eletrônico e-mag Arquitetura de Interoperabilidade de Governo Eletrônico e-ping 24
Grupos de Atividades Elicitação Entende o contexto e necessidades de um conjunto de partes interessadas Análise de Requisitos Documenta, modela, classifica em grupos coerentes, verifica e valida os requisitos Administra conflitos, problemas e mudanças a fim de garantir o acordo sobre o escopo da solução, prioriza requisitos, identificando a melhor forma de comunicar os requisitos e a maneira como será mantido o conhecimento obtido para uso futuro Gerência de Requisitos 25
Requisitos Partes Interessadas Elicitação Grupos de Atividades Informações Análise de Requisitos Requisitos Solução + Transição Pesquisa, investiga necessidades Mudanças Organiza, especifica, verifica e valida Requisitos Administra conflitos e mudanças, busca aprovação, prioriza Gerência de Requisitos 26
Para saber mais Curso: Engenharia de Requisitos: Software Orientado ao Negócio On-line: http://fattocs.com/pt/ereq-ead Webinars: Dificuldades ao lidar com requisitos (youtu.be/mckx4m95z88) Qualidade em Requisito (youtu.be/d8xmsaer2f4) Grupo de discussão: Engenharia de Requisitos https://br.groups.yahoo.com/groups/engenharia-requisitos 27
PERGUNTAS? Obrigado pela sua atenção! Guilherme Siqueira Simões guilherme.simoes@fattocs.com www.linkedin.com/in/guilhermesimoes Skype: guilherme.s.simoes Brasília: (61) 4063-7484 São Paulo: (11) 4063-4658 Vitória: (27) 3026-6304 Rio de Janeiro: (21) 4063-5311 28